jms-spec
  1. jms-spec
  2. JMS_SPEC-37

Last Value Cache Feature for a topic.

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: 2.0
    • Fix Version/s: None
    • Labels:
      None

      Description

      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.

        Activity

        Hide
        rdohna added a comment -

        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.

        Show
        rdohna added a comment - 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.
        Hide
        alexandre.navarro added a comment -

        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.

        Show
        alexandre.navarro added a comment - 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.
        Hide
        timlfox added a comment -

        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)

        Show
        timlfox added a comment - 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)
        Hide
        rdohna added a comment -

        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.

        Show
        rdohna added a comment - 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.
        Hide
        Nigel Deakin added a comment -

        Will be reviewed after the JMS 2.0 early draft. Tagging accordingly.

        Show
        Nigel Deakin added a comment - Will be reviewed after the JMS 2.0 early draft. Tagging accordingly.

          People

          • Assignee:
            Unassigned
            Reporter:
            alexandre.navarro
          • Votes:
            2 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: