timeToLive or jmsExpiry?

[Kim Pepper]

Can someone explain the difference between timeToLive and jmsExpiry properties on JmsProxyFactoryBean? I was banging my head against a wall trying to work out why messages were not being processed. It turns out the default for timeToLive is 30 seconds and if you're clocks happen to be out of sync...

We were setting the jmsExpiry to an hour but messages were still expiring. It wasn't until we compiled the source with extra debug logging that we discovered jmsExpiry is set by timeToLive.

Should the jsmExpiry property be removed if it doesn't get used?

Also, what is the maximum for timeToLive. Is 3 days too long?

[James.Strachan]

so the jmsExpiry allows you to configure what the expiration is on the JMS Message under the covers.

Irrespective of how long a message lives in JMS; you can configure the timeToLive (i.e. how long do you wait on the client until you decide the request failed).

If the client is only going to wait for 30 seconds for a response, then its usual to not have that message staying around forever in your JMS bus which is why we auto-default the jmsExpiry

[jmatthewpryor]

I posted about a similar issue a while back. If you are trying to deal
with Lingo based RPC timeouts, the use of JMS timeToLive is problematic
due to clock synchronization as you say.

not sure if this will help
http://www.nabble.com/Re%3A-how-to-set-timeout-p3445330.html

jmp

Kim Pepper wrote:

> Can someone explain the difference between timeToLive and jmsExpiry
> properties on JmsProxyFactoryBean? I was banging my head against a wall
> trying to work out why messages were not being processed. It turns out the
> default for timeToLive is 30 seconds and if you're clocks happen to be out
> of sync...
>
> We were setting the jmsExpiry to an hour but messages were still expiring.
> It wasn't until we compiled the source with extra debug logging that we
> discovered jmsExpiry is set by timeToLive.
>
> Should the jsmExpiry property be removed if it doesn't get used?
>
> Also, what is the maximum for timeToLive. Is 3 days too long?
>
> --
> View this message in context: http://www.nabble.com/timeToLive-or-jmsExpiry--t1366479.html#a3664105
> Sent from the lingo - user forum at Nabble.com.
>
>  

--
J. Matthew Pryor
Observant Pty Ltd
http://www.observant.com.au
1-300-224-688

[Kim Pepper]

I  don't understand what you mean by the expiry of the JMS message "under the covers". Why is it hidden?

The Message (which had a short expiry) is a JMS Message isn't it?

[Sanjiv Jivan]

I've had some strange behavior (not related to clock synchronization) when using timeToLive for setting client timeout as I describe here :
http://www.nabble.com/forum/ViewPost.jtp?post=3442147&framed=y

I think the asynchronous one way calls were also turning into synchronous calls. I'll try to reproduce and setup a test case. It will also be great if Lingo added some timeout related test cases since test cases serve as a great example for usage as well.

Thanks,
Sanjiv

On 3/30/06, James.Strachan <james.strachan@...> wrote:

so the jmsExpiry allows you to configure what the expiration is on the JMS
Message under the covers.

Irrespective of how long a message lives in JMS; you can configure the
timeToLive (i.e. how long do you wait on the client until you decide the
request failed).

If the client is only going to wait for 30 seconds for a response, then its
usual to not have that message staying around forever in your JMS bus which
is why we auto-default the jmsExpiry
--
View this message in context: http://www.nabble.com/timeToLive-or-jmsExpiry--t1366479.html#a3668864
Sent from the lingo - user forum at Nabble.com.

[James.Strachan]

Kim Pepper wrote:

I  don't understand what you mean by the expiry of the JMS message "under the covers". Why is it hidden?

The Message (which had a short expiry) is a JMS Message isn't it?

Yes. I just mean we have 2 timeouts here; the request-response timeout that the client side sees; then the JMS timeout that the JMS provider sees. If you are specifying a timeout for the request-response then really you should also specify a timeout for the JMS message as well.

Though if you have clock synchronisation issues we should allow folks to disable the use of JMS timeouts - though in general thats kinda bad as you could have thousands of messages hanging around forever because you didn't sync your clocks etc.

[Sanjiv Jivan]

James,
I'm a confused by you response. The "jmsExpiration" property on JmsProxyFactoryBean (which extends JmsClientInterceptor) is setting the request message's JMSExpiration header value in the populateHeaders() method of this class if its value is >= 0.

 if (jmsExpiration >= 0) {
            requestMessage.setJMSExpiration(jmsExpiration);
        }

And this is done before the message is sent via the JMS provider send() call. In the case of ActiveMQ, when the send() method of org.apache.activemq.ActiveMQSession is called, the JMSExpiration header value is *always* overridden with a value that depends on the MessageProducer's timeToLive value.

ActiveMQSession#send(ActiveMQMessageProducer producer, ActiveMQDestination destination, Message message, int deliveryMode,int priority, long timeToLive)

    long expiration = 0L;

    if (!producer.getDisableMessageTimestamp()) {
            long timeStamp = System.currentTimeMillis();
            message.setJMSTimestamp(timeStamp);
            if (timeToLive > 0) {
                expiration = timeToLive + timeStamp;
            }
        }

        message.setJMSExpiration(expiration);

So it seems pointless to expose the jmsExpiration property on JmsProxyFactoryBean. Infact it was my understandign that client applications should not set JMSExpiration directly on the Message. They should use the timeToLive propert of the MessageProducer and before the JMS provider is sending the message, it calculated the JMSExpiration based on the timeToLive property and sets this header value. (And this is what the code above in ActiveMQSession appears to be doing).

So i'm rather confused by your explanation that jmsExpiration and timeToLive accomplish different things. Can you clarify?

Thanks,
Sanjiv

On 3/30/06, James.Strachan <james.strachan@...> wrote:

so the jmsExpiry allows you to configure what the expiration is on the JMS
Message under the covers.

Irrespective of how long a message lives in JMS; you can configure the
timeToLive (i.e. how long do you wait on the client until you decide the
request failed).

If the client is only going to wait for 30 seconds for a response, then its
usual to not have that message staying around forever in your JMS bus which
is why we auto-default the jmsExpiry
--
View this message in context: http://www.nabble.com/timeToLive-or-jmsExpiry--t1366479.html#a3668864
Sent from the lingo - user forum at Nabble.com.