During my summer holidays, I have simplified its API to make it more object-oriented instead of a simple translation of the protocol frames. The new API is backwards compatible except for the susbcription change.
The documentation has been updated to reflect the new API.
The message objects passed to the subscribe callback now have ack() and nack() methods to directly acknowledge (or not) the message.
var sub = client.subscribe("/queue/test",
function(message) {
// do something with the message
...
// and acknowledge it
message.ack();
},
{ack: 'client'}
);
Unsubscription
Instead of returning an id from client.subscribe(), subscribe() returns an object with an id property corresponding to the subscription ID and an unsubscribe() method.
var subscription = client.subscribe(...);
...
subscription.unsubscribe();
Transaction
The begin() method returns a JavaScript object with commit() and abort() methods to complete the transaction.
var tx = client.begin();
message.ack({ transaction: tx.id, receipt: 'my-receipt' });
...
tx.commit(); // or tx.abort();
A transaction ID is automatically generated when calling 'begin() and is available in the returned object's id property.
Miscellaneous changes and fixes
default onreceive method
When a subscription is automatically created on the broker-side, the received messages are discarded by the Stomp.client that find no matching callback for the subscription headers. To workaround that, the client can set a default onreceive callback that will be called if no matching subscription is found.
By default, debug messages are now written in window.console.
STOMP can now be used from a WebWorker (an example shows how to use it).
STOMP frame fragmentation
If the STOMP frames are big to send on a single WebSocket frame, some web server may have trouble process them. It is now possible to split a STOMP frame on multiple Web Socket frames by configuring the client.maxWebSocketFrameSize (in bytes). If the STOMP frame is bigger than this size, it will be send over multiple Web Socket frames (default is 16KiB).
use the 1st value for repeated headers
Stomp.js was keeping the last value of repeated headers. This has been fixed according to the specification to take the 1st value of repeated headers.
We bought a siphon for cooking some time ago and are having fun with it to prepare desserts and starters (we made a mousse de foie gras that was awesome). Yesterday, we prepared a velours de mangue (velvet of mango).
One of the most important new features is Shared Subscription.
Let's assume you are using a topic to send messages. There are several components subscribed to this topic that are processing the messages in different fashion (for example to process jobs A and B).
When a message M is sent to the topic, all consumers subscribed to the topic receive it:
M +--------------+
---> | consumer CA1 | < a consumer for the job A >
+----------+ M +-------+ / +--------------+
| producer | ---> | topic |
+----------+ +-------+ \ M +--------------+
---> | consumer CB1 | < a consumer for the job B >
+--------------+
The consumer CB1 is subscribed to the topic. Every time, it receives a message, it processes the job B.
Unfortunately, this job is time-consuming and we would like to scale it out by having several consumers for the job B running on different machines.
We can not have several consumers on the topic for this job, otherwise they would all receive copies of the same message and process it several times. What we need is a set of consumers that receives a single message from the topic amongst them.
If the component is running inside a Java EE application server, you can use a Message-Drive Bean for that. If the component is a Java SE application, you are out of luck.
Before JMS 2.0, each messaging brokers has different ways to provide this feature.
Diverts allow you to transparently divert messages routed to one address to some other address, without making any changes to any client application logic.
We use a divert to route the messages sent to the topic to another queue (let's called it Queue_B since it's for the processing job B). Everytime a message is sent to the topic, a copy is also routed to the queue. Our divert is non-exclusive since we want it to still be received by the topic consumers.
We can then create as many consumers we want for Queue_B. Since this destination is a queue, only one of them will receive a message that was initially sent to the topic:
Among CB1, CB2 and CB3, only CB3 received the message sent to the topic.
There are still many shortcomings of using diverts (or similar features) to share consumers of a topic.
for each set of shared consumers, a system administrator must create and administrate on the server one more divert and one more queue.
the shared consumers are no longer consuming from the original topic but from a specific queue. That makes the messaging topology more complex to setup and configure in the client applications.
the management of the messaging system becomes also more complex: there is no way to know how many subscribers are "really" listening to the topic, this information is lost when messages are routed by the divert.
Enter JMS 2.0 and its "shared subscription".
A non-durable shared subscription is used by a client which needs to be able to share the work of receiving messages from a topic subscription amongst multiple consumers. A non-durable shared subscription may therefore have more than one consumer. Each message from the subscription will be delivered to only one of the consumers on that subscription.
The basic idea behing sharing a subscription is to have a set of consumers (identified by a shared subscription name) receiving exclusively a message from a topic.
That solves all the issues we originally had in a standard fashion. We can now create many shared consumers with the shared subscription name << sub B >> to have them process messages for the job B and scale out nicely:
Sharability and durability of subscriptions are two orthogonal notions and all the combination are possible:
a unshared non-durable subscription can only have one consumer that will not receive messages sent while its consumer was offline
a unshared durable subscription can only have one consumer that will receive the messages sent while its consumer was offline
a shared non-durable subscription can have many consumers that will not receive messages sent while all consumers were offline.
a shared durable subscription can have many consumers that will not receive the messages sent while all consumers were offline.
JMS 2.0 is an incremental update to JMS that should simplify any Java application using messages. Shared subscription is one of this interesting new features.
Insightful portrait of Tim Duncan on the cusp of his 5th NBA finals (he won his first fours):
Sometimes people will mention the swimming when trying to pinpoint the origin of Duncan’s remarkable discipline and relentless consistency. Duncan swam until he was 14 and seemed on a path toward the Olympics like his sister, Tricia. That was when Hurricane Hugo roared through the Island and wrecked the swimming pool. More, that was the year his mother, Ione, died of cancer. She had been his greatest fan, the loudest cheers at the pool, the voice inside his head. He would talk about the little nursery rhyme that she would repeat to him over and over and over …
Good, better, best Never let it rest Until your good is better And your better is your best
You can’t help but think that if you cut Tim Duncan open, those words would be etched on his heart.
There has never been a basket-ball player so consistent for the whole span of his career (stats per 36 minutes):
1st year - 21 year old, 19.4 points, 11 rebounds, 2.5 assists, 2.4 blocks, 57.7 true shooting %
7th year - 27 year old, 21.9 points, 12.2 rebounds, 3.0 assists, 2.6 blocks, 53.4 true shooting %
17th year - 36 year old, 21.3 points, 11.9 rebounds, 3.2 assists, 3.2, blocks, 55.4 true shooting %
I am rooting for the spurs for these finals! #GoSpursGo
This sunday was held the 2013 edition of Uriage Cabriolet Classic, a large gathering of classic (and more recent) cars.
I am not a connaisseur of cars but I can recognize a beautiful one when I see it. I really enjoy the attention to details of these cars and the love and care of their owners (the engines were all shining!).
This gathering is an opportunity to appreciate all the shapes and colours of cars. Even the most modest cars look fantastic with out of the ordinary colours.
Spoiler: he loves the camera and, unsurprisingly, makes beautiful pictures with it.
I bought his book, The Print and the Process, this week-end. It is a beautifully crafted book composed of 4 sections, Venic, Iceland, Kenya, and Antarctica providing a variety of scenes (it's mostly landscapes and portraits though, it's a David duChemin's book after all :) Each section is composed of a set of 20-30 images without any text that helps appreciate the flow of pictures without any interruption. At the end of each section, there is a text for each images where the author describes what his intent or feeling was when he took the picture.
The book is bound along the short edge in landscape mode. This design makes the beautiful landscape images really stand out.
Beautiful book, gorgeous photos and instructive reading. Heartily recommended.
