Last Value Cache Feature for a topic.

[glassfishrobot]

Add the Last Value Cache Feature for a topic. When you will connect to a topic, the last message sent on the topic will be resent to the new client.

For instance, in the bank, without this feature, this JMS is generally not easily useable. The common case is you want to publish price (bid/ask) on a stock. You have a topic by stock. When a new client will connect to the topic, he will not receive a message until the price will move.

Affected Versions

[2.0]

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/jms-spec/issues/37
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: Unassigned

[glassfishrobot]

@glassfishrobot Commented Reported by alexandre.navarro

[glassfishrobot]

@glassfishrobot Commented rdohna said: I'm a complete layman here, but aren't the bid/ask messages singular events, while the price is an average over all bids/asks in a recent time slice? Even if the messages are just the rolling price averages, you may want to see a tendency as well, so you'd need at least two recent messages...

I think this is too special a use case to be put into the standard. Maybe some JMS providers will support it, but looking at the limited use case I don't think it should be required from all of them.

[glassfishrobot]

@glassfishrobot Commented alexandre.navarro said: Just consider something like one field price (not bid/ask).

When someone connect to the topic, it will not receive the current value (last value) but will wait the new price.

9h00 : price=10 9h02 : price=10.1 10h00: price=10.2

If the client will connect at 9h03, it will not that the current price is 10.1 and it will wait 58m to have the current price.

Is it clear?

Some JMS implementations (Nirvana, Solace, ...) or MOM like Reuters Market Data System (RMDS) has this feature.

This feature is essential for finance system (and I suppose in some others cases) if you don't want to redevelop some hacks around to have that.

[glassfishrobot]

@glassfishrobot Commented timlfox said: There is some more info on this functionality here http://docs.jboss.org/hornetq/2.2.5.Final/user-manual/en/html/last-value-queues.html

I would also suggest this work for queues, not just topics (HornetQ allows this on both queues and topics)

[glassfishrobot]

@glassfishrobot Commented rdohna said: The use case is clear. While I have never had it, it may be common for others. Still I would prefer not to hide that in the messaging system but to read the last value actively instead... often I'd like to read even more information than only this one. Then the topic is really only for the updates... it's only my view, but I don't think it belongs into the standard.

[glassfishrobot]

@glassfishrobot Commented @nigeldeakin said: Will be reviewed after the JMS 2.0 early draft. Tagging accordingly.

[glassfishrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA JMS_SPEC-37