Previously, the STOMP broker relay did not support heart-beats. It sent
0,0 in the heart-beats header for its own CONNECTED message, and set the
heart-beats header to 0,0 when it was forwarding a CONNECTED from from a
client to the broker.
The broker relay now supports heart-beats for the system relay session.
It will send heart-beats at the send interval that's been negotiated
with the broker and will also expect to receive heart-beats at the
receive interval that's been negotiated with the broker. The receive
interval is multiplied by a factor of three to satisfy the STOMP spec's
suggestion of lenience and ActiveMQ 5.8.0's heart-beat behaviour (see
AMQ-4710).
The broker relay also supports heart-beats between clients and the
broker. For any given client's relay session, any heart-beats received
from the client are forwarded on to the broker and any heart-beats
received from the broker are sent back to the client.
Internally, a heart-beat is represented as a Message with a byte array
payload containing the single byte of new line ('\n') character and
'empty' headers. SubscriptionMethodReturnValueHandler has been updated
to default the message type to SimpMessageType.MESSAGE. This eases
the distinction between a heartbeat and a message that's been created
from a return value from application code.
Extended DefaultAopProxyFactory to create Objenesis based proxies if the
library is on the classpath. This allows classes without a default
constructor being CGLib proxied. We're now falling back to original CGLib
based behavior in case the proxy creation using Objenesis fails.
Objenesis 2.0 is now inlined into spring-core to avoid interfering with
other Objenesis versions on the classpath.
Issue: SPR-10594
Added AsyncRestTemplate, the asynchronous counterpart to the
RestTemplate that was introduced in Spring 3. All methods on the
AsyncRestTemplate are similar to those found on the synchronous
RestTemplatem, except that they return Future wrappers instead of
concrete results.
To enable this, this commit introduces the AsyncClientHttpRequest and
AsyncClientHttpRequestFactory, similar to the ClientHttpRequest and
ClientHttpRequestFactory, except that ClientHttpRequest returns a
Future<ClientHttpResponse> for the execute method. Two implementations
of these interfaces are provided, one based on the HttpURLConnection
incombination with a Spring AsyncTaskExecutor and one based on Apache
HttpComponents HttpAsyncClient.
Issue: SPR-8804
Upgrade to Reactor snapshot builds to take advantage of TcpClient's
reconnect support that was added post-M1. Now, the system relay session
will try every 5 seconds to establish a connection with the broker, both
when first connecting and in the event of subsequently becoming
disconnected.
A more sophisticated reconnection policy, including back off and
failover to different brokers, is possible with the Reactor API. We may
want to enhance the relay's reconnection policy in the future.
Typically, a broken connection is identified by the failure to forward
a message to the broker. As things stand, the message id then discarded.
Any further messages that are forwarded before the connection's been
re-established are queued for forwarding once the CONNECTED frame's been
received. We may want to consider also queueing the message that failed
to send, however we would then need to consider the possibility of the
message itself being what caused the broker to close the connection
and resending it would simply cause the connection to be closed again.
Components that are using a StompBrokerRelayMessageHandler may want
to know whether or not the broker's unavailable. If they're sending
messages to the relay via an asynchronous channel there's currently
no way for them to find this out.
This commit enhances StompBrokerRelayMessageHandler to publish
application events when the broker's availability changes:
BrokerBecameAvailableEvent and BrokerBecameUnavailableEvent.
Irrespective of the number of relay sessions only a single event is
published for each change in the broker's availability.
A SockJS message frame is an array of JSON-encoded messages and before
this change the use of the Jackson 2 library was hard-coded.
A Jackson 2 and Jackson 1.x implementations are provided and
automatically used if those libraries are present on the classpath.
Issue: SPR-10800
Update META-INF/MANIFEST.MF for spring-instrument to include
necessary attributes for running under Java 7:
Can-Redefine-Classes : true
Can-Retransform-Classes: true
Can-Set-Native-Method-Prefix : false
(see http://docs.oracle.com/javase/7/docs/api/java/lang/instrument/
package-summary.html)
Prior to this commit `InstrumentationSavingAgent.getInstrumentation().
addTransformer(t, true);` would fail under Java 7.
Issue: SPR-10731
A new type MessageHeaderAccesssor provides read/write access to
MessageHeaders along with typed getter/setter methods along the lines
of the existing MessageBuilder methods (internally MessageBuilder
merely delegates to MessageHeaderAccessor). This class is extensible
with sub-classes expected to provide typed getter/setter methods for
specific categories of message headers.
NativeMessageHeaderAccessor is one specific sub-class that further
provides read/write access to headers from some external message
source (e.g. STOMP headers). Native headers are stored in a separate
MultiValueMap and kept under a specific key.
Since JDK 8 is required to build Spring framework 4, and permanent
generation is gone from Java 8, to eliminate warnings about no longer
available MaxPermSize switch, it should be removed or replaced with new
MaxMetaspaceSize switch.
This fix replaces old with new switch to limit the amount of native
memory used for class metadata.
Issue: SPR-10571
Rossen Stoyanchev
Jeremy Grelle
Phillip Webb
Andy Wilkinson
Rob Winch
Oliver Gierke
Juergen Hoeller
Arjen Poutsma
Phillip Webb
Sam Brannen
Stevo Slavic
Rossen Stoyanchev