Why isn't UIMA AS using the JMS message expiration feature ?

[Jörn Kottmann <ko...@gmail.com>]

Hello,

I noticed that messages sent from the client
to the service can pill up in the queue in the
case the service is not available e.g. down for an
update.

In the case the client uses a timeout it should also
set the JMS message expiration to the timeout,
then the broker can remove old messages

Should I open a jira for this ?

Jörn

Re: Why isn't UIMA AS using the JMS message expiration feature ?

[Jaroslaw Cwiklik <ui...@gmail.com>]

Jorn, the UIMA AS client adds the TTL to each outgoing message as long as
you have the process timeout set. Currently, the UIMA AS client uses the
following logic  when adding TTL:
                 // get process timeout value
                 long timeoutValue = cacheEntry.getProcessTimeout();

                 if (timeoutValue > 0 && addTimeToLive ) {
                   // Set high time to live value
                   message.setJMSExpiration(10 * timeoutValue);
                 }

In the above, addTimeToLive is true by default. The expiration time should
probably be parametrized. :)

Check AMQ forums and you'll see that there are quite a few postings about
TTL logic. If I am not mistaken, the expired messages are not removed until
you connect a consumer to the queue. Try to restart the consumer to see if
the messages disappear. Are the clocks on two machines different?

JC



On Tue, Jan 12, 2010 at 10:00 AM, Jörn Kottmann <ko...@gmail.com> wrote:

> Hello,
>
> I noticed that messages sent from the client
> to the service can pill up in the queue in the
> case the service is not available e.g. down for an
> update.
>
> In the case the client uses a timeout it should also
> set the JMS message expiration to the timeout,
> then the broker can remove old messages
>
> Should I open a jira for this ?
>
> Jörn
>