Message Delivery Order - Weblogic

This is a discussion on Message Delivery Order - Weblogic ; Hi, I am looking to exactly match the order of delivery of the messages published to a topic to the order of delivery the messages are subscribed to by MDB listening to the topic. From the documentation, I could make ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Message Delivery Order

  1. Message Delivery Order


    Hi,

    I am looking to exactly match the order of delivery of the messages published
    to a topic to the order of delivery the messages are subscribed to by MDB listening
    to the topic. From the documentation, I could make out that this order of delivery
    is guaranteed by JMS for normal mode of operation, but it is not guaranteed for
    redelivered messages. I could find out from the previous postings in this forum
    that WLS 8.1 does guarantee the order of delivery even for redelivered and recovered
    messages but the previous versions do not. We are using WLS 6.1 and hence I can
    conclude that the order is not guaranteed for redelivered messages. I would like
    to know if there is any other way to achieve this guaranteed order of delivery.
    I was just thinking in the lines of configuring a destination key for the topic
    with JMSMessageId set to ascending so that it is always FIFO and setting the MessagesMaximum
    field for the MDB's connectionFactory to 1. Would that make sure that the order
    is maintained even for redelivered messages ?
    Please help.

    Thanks,
    Goutam.

  2. Re: Message Delivery Order



    Saswati Mukherjee wrote:

    > Hi,
    >
    > I am looking to exactly match the order of delivery of the messages published
    > to a topic to the order of delivery the messages are subscribed to by MDB listening
    > to the topic. From the documentation, I could make out that this order of delivery
    > is guaranteed by JMS for normal mode of operation, but it is not guaranteed for
    > redelivered messages. I could find out from the previous postings in this forum
    > that WLS 8.1 does guarantee the order of delivery even for redelivered and recovered
    > messages but the previous versions do not. We are using WLS 6.1 and hence I can
    > conclude that the order is not guaranteed for redelivered messages. I would like
    > to know if there is any other way to achieve this guaranteed order of delivery.
    > I was just thinking in the lines of configuring a destination key for the topic
    > with JMSMessageId set to ascending so that it is always FIFO and setting the MessagesMaximum
    > field for the MDB's connectionFactory to 1. Would that make sure that the order
    > is maintained even for redelivered messages ?


    No, it would not. In fact, JMS already does this much.

    Actually, you *might* be able to take advantage of MDB's defined
    side-effects: When a Runtime is thrown from "onMessage()"
    of a *non-transactional* MDB, the instance closes and then
    recreates itself (and its subscription).
    - So assuming the MDB is non-transactional...
    - And assuming "max-beans-in-free-pool" is set to "1"...
    - If the MDB is a durable subscriber it won't be able
    to automatically recreate itself and reconnect until the
    old previous instance finishes closing, the messages
    will be ordered for the new instance.
    - If the MDB is a nondurable subscriber, then the recreate
    will, by definition, be an entirely new subscription,
    and ordering will be fine. (But messages sent to
    the topic will be missed while the session is
    recreating itself.)

    Another option is to continue to use 6.1 for the MDB but
    start up and 8.1 instance solely for running JMS remotely.
    I'm not 100% sure, but I think ordering would
    be guaranteed on the 6.1 JMS client as long you follow
    the documented 8.1 ordered redelivery restrictions. Contact
    BEA support to confirm.


    > Please help.
    >
    > Thanks,
    > Goutam.



  3. Re: Message Delivery Order


    Hi Tom,

    Thanks a lot for the information. In our case the MDB has to be transactional.
    Meaning, if the processing of the message in the onMessage() of the MDB is not
    as expected, then we should rollback that message and try to do the same processing
    again. I am not sure if there is any other way to accomplish this other than making
    the MDB transactional. If there is not, then I think the first option you have
    mentioned is ruled out for our case. Please confirm. Then I would try to explore
    the second option you have mentioned, i.e. running the MDB in WLS 6.1 and running
    the JMS in WLS 8.1.

    Thanks again,
    Saswati.


    Tom Barnes
    wrote:
    >
    >
    >Saswati Mukherjee wrote:
    >
    >> Hi,
    >>
    >> I am looking to exactly match the order of delivery of the messages

    >published
    >> to a topic to the order of delivery the messages are subscribed to

    >by MDB listening
    >> to the topic. From the documentation, I could make out that this order

    >of delivery
    >> is guaranteed by JMS for normal mode of operation, but it is not guaranteed

    >for
    >> redelivered messages. I could find out from the previous postings in

    >this forum
    >> that WLS 8.1 does guarantee the order of delivery even for redelivered

    >and recovered
    >> messages but the previous versions do not. We are using WLS 6.1 and

    >hence I can
    >> conclude that the order is not guaranteed for redelivered messages.

    >I would like
    >> to know if there is any other way to achieve this guaranteed order

    >of delivery.
    >> I was just thinking in the lines of configuring a destination key for

    >the topic
    >> with JMSMessageId set to ascending so that it is always FIFO and setting

    >the MessagesMaximum
    >> field for the MDB's connectionFactory to 1. Would that make sure that

    >the order
    >> is maintained even for redelivered messages ?

    >
    >No, it would not. In fact, JMS already does this much.
    >
    >Actually, you *might* be able to take advantage of MDB's defined
    >side-effects: When a Runtime is thrown from "onMessage()"
    >of a *non-transactional* MDB, the instance closes and then
    >recreates itself (and its subscription).
    >- So assuming the MDB is non-transactional...
    >- And assuming "max-beans-in-free-pool" is set to "1"...
    >- If the MDB is a durable subscriber it won't be able
    >to automatically recreate itself and reconnect until the
    >old previous instance finishes closing, the messages
    >will be ordered for the new instance.
    >- If the MDB is a nondurable subscriber, then the recreate
    >will, by definition, be an entirely new subscription,
    >and ordering will be fine. (But messages sent to
    >the topic will be missed while the session is
    >recreating itself.)
    >
    >Another option is to continue to use 6.1 for the MDB but
    >start up and 8.1 instance solely for running JMS remotely.
    >I'm not 100% sure, but I think ordering would
    >be guaranteed on the 6.1 JMS client as long you follow
    >the documented 8.1 ordered redelivery restrictions. Contact
    >BEA support to confirm.
    >
    >
    >> Please help.
    >>
    >> Thanks,
    >> Goutam.

    >



  4. Re: Message Delivery Order



    Saswati Mukherjee wrote:
    > Hi Tom,
    >
    > Thanks a lot for the information. In our case the MDB has to be transactional.
    > Meaning, if the processing of the message in the onMessage() of the MDB is not
    > as expected, then we should rollback that message and try to do the same processing
    > again. I am not sure if there is any other way to accomplish this other than making
    > the MDB transactional. If there is not, then I think the first option you have
    > mentioned is ruled out for our case. Please confirm.


    I think so, but I recommend seeing if you can get a second opinion.

    One thing you could try, but I'm not 100% sure if it would always
    work, would be to cache the message-id of the message you are
    rolling back. Then, keep forcing roll backs on subsequent
    messages until the cached message is received again. You might
    try raising this solution through customer support to see
    if you can get confirmation as to whether this would work.


    > Then I would try to explore
    > the second option you have mentioned, i.e. running the MDB in WLS 6.1 and running
    > the JMS in WLS 8.1.


    If it is possible for you to go this route, I recommend it. Again, it
    would need customer support verification to see if this is supported.

    >
    > Thanks again,
    > Saswati.
    >
    >
    > Tom Barnes
    > wrote:
    >
    >>
    >>Saswati Mukherjee wrote:
    >>
    >>
    >>>Hi,
    >>>
    >>>I am looking to exactly match the order of delivery of the messages

    >>
    >>published
    >>
    >>>to a topic to the order of delivery the messages are subscribed to

    >>
    >>by MDB listening
    >>
    >>>to the topic. From the documentation, I could make out that this order

    >>
    >>of delivery
    >>
    >>>is guaranteed by JMS for normal mode of operation, but it is not guaranteed

    >>
    >>for
    >>
    >>>redelivered messages. I could find out from the previous postings in

    >>
    >>this forum
    >>
    >>>that WLS 8.1 does guarantee the order of delivery even for redelivered

    >>
    >>and recovered
    >>
    >>>messages but the previous versions do not. We are using WLS 6.1 and

    >>
    >>hence I can
    >>
    >>>conclude that the order is not guaranteed for redelivered messages.

    >>
    >>I would like
    >>
    >>>to know if there is any other way to achieve this guaranteed order

    >>
    >>of delivery.
    >>
    >>>I was just thinking in the lines of configuring a destination key for

    >>
    >>the topic
    >>
    >>>with JMSMessageId set to ascending so that it is always FIFO and setting

    >>
    >>the MessagesMaximum
    >>
    >>>field for the MDB's connectionFactory to 1. Would that make sure that

    >>
    >>the order
    >>
    >>>is maintained even for redelivered messages ?

    >>
    >>No, it would not. In fact, JMS already does this much.
    >>
    >>Actually, you *might* be able to take advantage of MDB's defined
    >>side-effects: When a Runtime is thrown from "onMessage()"
    >>of a *non-transactional* MDB, the instance closes and then
    >>recreates itself (and its subscription).
    >>- So assuming the MDB is non-transactional...
    >>- And assuming "max-beans-in-free-pool" is set to "1"...
    >>- If the MDB is a durable subscriber it won't be able
    >>to automatically recreate itself and reconnect until the
    >>old previous instance finishes closing, the messages
    >>will be ordered for the new instance.
    >>- If the MDB is a nondurable subscriber, then the recreate
    >>will, by definition, be an entirely new subscription,
    >>and ordering will be fine. (But messages sent to
    >>the topic will be missed while the session is
    >>recreating itself.)
    >>
    >>Another option is to continue to use 6.1 for the MDB but
    >>start up and 8.1 instance solely for running JMS remotely.
    >>I'm not 100% sure, but I think ordering would
    >>be guaranteed on the 6.1 JMS client as long you follow
    >>the documented 8.1 ordered redelivery restrictions. Contact
    >>BEA support to confirm.
    >>
    >>
    >>
    >>>Please help.
    >>>
    >>>Thanks,
    >>>Goutam.

    >>

    >



+ Reply to Thread