Problem with QMUX Asynch Request - Expired msg doesn't get called

[LiNa]

Hi,

I am currently working on SAF process. I am modifying jpos-ee SAF from
QMUX synch request to QMUX asynch request and integrate with
ISOResponseListener. The ISOResponseListener class extends QBean so
that it will get deployed during Q2 startup and configurable.

Everything works fine until there are messages in QMUX waiting to get
expired and there is new messages put in the QMUX request. Once that
happens, the ISOResponseListener expired method get called later and
later. I have configured the timeout to be 50 seconds, but once this
happens it gets timeout like after 5 min, 13 min, 30 min...

Has anyone experiencing this problem before? I am suspecting it is
something to do with synchronized(ar) function in QMux request method.
Please share.

Thanks

Regards,

Lina

[Mark Salter]

LiNa wrote:
>
> Everything works fine until there are messages in QMUX waiting to get
> expired and there is new messages put in the QMUX request. Once that
> happens, the ISOResponseListener expired method get called later and
> later. I have configured the timeout to be 50 seconds, but once this
> happens it gets timeout like after 5 min, 13 min, 30 min...

I recall you previously asked about controlling or guaranteeing the
timely expiration of messages - I think you had some processing you
wanted to do in a timely fashion on timeout (no response?). Did you
modify the QMUX code to this end or are you using 'base' jPOS?

Is the Expiration method being called only as messages flow - rather
than independently?

>
> Has anyone experiencing this problem before? I am suspecting it is
> something to do with synchronized(ar) function in QMux request method.

Do you have any logs, or traces showing the activity (or not)?

I'm wondering how we could replicate the problem outside of your
environment?

--
Mark

[Mark Salter]

LiNa wrote:

> I am suspecting it is
> something to do with synchronized(ar) function in QMux request method.

I don't see that synchronisation on an object instanced for the current
thread could affect multiple threads. So I don't think the
synchronisation is the problem - can you say what lead you to this
conclusion at all?

However I also don't see why the synchronisation (QMUX.java line 256) on
the instanced AsyncRequest object is even needed? I am happy to think
it is there for a reason, I just don't see it *yet).

--
Mark

[Alejandro Revilla]

>
> However I also don't see why the synchronisation (QMUX.java line 256) on
> the instanced AsyncRequest object is even needed? I am happy to think
> it is there for a reason, I just don't see it *yet).
>

If I recall correctly, under some really heavy load situations involving
message retransmissions, one could get a response that would trigger a
responseReceived on the ISOResponseListener before scheduling the timer
task, that's why we have that synchronized block.

[Mark Salter]

Ok, that would be 'interesting' to see that scenario in action -
something the Gladiator team experienced?

Do you agree that the synchronisation is unlikely to be cause the
'increasing' delay 'LiNa' is seeing?

--
Mark

[Alejandro Revilla]

>
> Ok, that would be 'interesting' to see that scenario in action -
> something the Gladiator team experienced?
>

Exactly :)

>
> Do you agree that the synchronisation is unlikely to be cause the
> 'increasing' delay 'LiNa' is seeing?
>

Absolutely, I don't think that's the problem.

[LiNa]

Hi Alejandro and Mark,

Thank you for your reply.
After posting this thread, I finally modified the QMUX as below and
the problem ceased.

I see that the DefaultTimer is a static class with only one thread
running. Any reason why it must be a static class? Do you foresee any
problem with my new QMux?


public class QMUX extends org.jpos.q2.iso.QMUX {
public void request (ISOMsg m, long timeout, ISOResponseListener
rl, Object handBack)
throws ISOException
{
String key = getKey (m);
String req = key + ".req";
m.setDirection(0);
AsyncRequest ar = new AsyncRequest (rl, handBack);
// synchronized (ar) {
// if (timeout > 0)
// DefaultTimer.getTimer().schedule (ar, timeout);
// }
Timer timer = new Timer();
timer.schedule(ar, timeout);
sp.out (req, ar, timeout);
sp.out (out, m, timeout);
}


Thanks

[LiNa]

Below is the trace log. The setting for expiry in Qmux is 10 seconds
while inter message delay is 50 seconds. You can see when 0300 message
is placed initially, the timer works fine but when there is another
message (0500) placed in the queue and no response from the host, the
timer get delayed and turn out to be the same for 0300 and 0500
message. In between these transactions there are other transactions
with response.

<log realm="channel/10.13.200.34:9090" at="Tue Dec 01 12:21:15 MYT
2009.581">
<send>
<isomsg direction="outgoing">
<header>6000000121</header>
<field id="0" value="0300"/>
<field id="3" value="000000"/>
<field id="11" value="000677"/>
<field id="12" value="122115"/>
<field id="13" value="1201"/>
<field id="24" value="000"/>
<field id="41" value="00000000"/>
<field id="42" value="SWITCH1 "/>
<field id="61" value="xxxxxxxxxxxxx"/>
<field id="63" value="xxxxxxxxxxxxx"/>
</isomsg>
</send>
</log>

<log realm="saf" at="Tue Dec 01 12:21:25 MYT 2009.588">
<debug>
In expired: stan: 000677
</debug>
</log>

<log realm="saf" at="Tue Dec 01 12:21:25 MYT 2009.594">
<debug>
FROM Theard : saf-7 Read Message FROM QUEUE : 000677
</debug>
</log>

<log realm="saf" at="Tue Dec 01 12:22:15 MYT 2009.604">
<debug>
Timeout after sleep....: Stan : 000677
</debug>
</log>

<log realm="channel/10.13.200.34:9090" at="Tue Dec 01 12:22:15 MYT
2009.605">
<send>
<isomsg direction="outgoing">
<header>6001210000</header>
<field id="0" value="0301"/>
<field id="3" value="000000"/>
<field id="11" value="000677"/>
<field id="12" value="122115"/>
<field id="13" value="1201"/>
<field id="24" value="000"/>
<field id="41" value="00000000"/>
<field id="42" value="SWITCH1 "/>
<field id="61" value="xxxxxxxxxxxxxxx"/>
<field id="63" value="xxxxxxxxxxxxxxx"/>
</isomsg>
</send>
</log>
<log realm="saf" at="Tue Dec 01 12:22:25 MYT 2009.614">
<debug>
In expired: stan: 000677
</debug>
</log>

<log realm="saf" at="Tue Dec 01 12:22:25 MYT 2009.624">
<debug>
FROM Theard : saf-9 Read Message FROM QUEUE : 000677
</debug>
</log>

<log realm="channel/10.13.200.34:9090" at="Tue Dec 01 12:23:04 MYT
2009.266">
<send>
<isomsg direction="outgoing">
<header>6000000121</header>
<field id="0" value="0500"/>
<field id="3" value="960000"/>
<field id="11" value="984290"/>
<field id="12" value="122304"/>
<field id="13" value="1201"/>
<field id="24" value="000"/>
<field id="41" value="00000005"/>
<field id="42" value="888000016604203"/>
<field id="60" value="000080"/>
<field id="63" value="0000012100000019"/>
</isomsg>
</send>
</log>


<log realm="saf" at="Tue Dec 01 12:23:15 MYT 2009.634">
<debug>
Timeout after sleep....: Stan : 000677
</debug>
</log>
<log realm="channel/10.13.200.34:9090" at="Tue Dec 01 12:23:15 MYT
2009.635">
<send>
<isomsg direction="outgoing">
<header>6001210000</header>
<field id="0" value="0301"/>
<field id="3" value="000000"/>
<field id="11" value="000677"/>
<field id="12" value="122115"/>
<field id="13" value="1201"/>
<field id="24" value="000"/>
<field id="41" value="00000000"/>
<field id="42" value="SWITCH1 "/>
<field id="61" value="xxxxxxxxxxxxxxx"/>
<field id="63" value="xxxxxxxxxxxxxxx"/>
</isomsg>
</send>
</log>

<log realm="saf" at="Tue Dec 01 12:36:04 MYT 2009.109">
<debug>
In expired: stan: 984290
</debug>
</log>
<log realm="saf" at="Tue Dec 01 12:36:04 MYT 2009.109">
<debug>
In expired: stan: 000677
</debug>
</log>

<log realm="saf" at="Tue Dec 01 12:36:04 MYT 2009.114">
<debug>
FROM Theard : saf-2 Read Message FROM QUEUE : 000677
</debug>
</log>
<log realm="saf" at="Tue Dec 01 12:36:04 MYT 2009.114">
<debug>
FROM Theard : saf-12 Read Message FROM QUEUE : 984290
</debug>
</log>

<log realm="saf" at="Tue Dec 01 12:36:54 MYT 2009.124">
<debug>
Timeout after sleep....: Stan : 984290
</debug>
</log>
<log realm="saf" at="Tue Dec 01 12:36:54 MYT 2009.124">
<debug>
Timeout after sleep....: Stan : 000677
</debug>
</log>

<log realm="channel/10.13.200.34:9090" at="Tue Dec 01 12:36:54 MYT
2009.138">
<send>
<isomsg direction="outgoing">
<header>6000000121</header>
<field id="0" value="0501"/>
<field id="3" value="960000"/>
<field id="11" value="984290"/>
<field id="12" value="122304"/>
<field id="13" value="1201"/>
<field id="24" value="000"/>
<field id="41" value="00000005"/>
<field id="42" value="888000016604203"/>
<field id="60" value="000080"/>
<field id="63" value="0000012100000019"/>
</isomsg>
</send>
</log>

<log realm="channel/10.13.200.34:9090" at="Tue Dec 01 12:36:54 MYT
2009.140">
<send>
<isomsg direction="outgoing">
<header>6001210000</header>
<field id="0" value="0301"/>
<field id="3" value="000000"/>
<field id="11" value="000677"/>
<field id="12" value="122115"/>
<field id="13" value="1201"/>
<field id="24" value="000"/>
<field id="41" value="00000000"/>
<field id="42" value="SWITCH1 "/>
<field id="61" value="xxxxxxxxxxxxxxx"/>
<field id="63" value="xxxxxxxxxxxxxxx"/>
</isomsg>
</send>
</log>

<log realm="saf" at="Tue Dec 01 12:48:58 MYT 2009.910">
<debug>
In expired: stan: 984290
</debug>
</log>

<log realm="saf" at="Tue Dec 01 12:48:58 MYT 2009.910">
<debug>
In expired: stan: 000677
</debug>
</log>

<log realm="saf" at="Tue Dec 01 12:48:58 MYT 2009.914">
<debug>
FROM Theard : saf-13 Read Message FROM QUEUE : 984290
</debug>
</log>
<log realm="saf" at="Tue Dec 01 12:48:58 MYT 2009.914">
<debug>
FROM Theard : saf-5 Read Message FROM QUEUE : 000677
</debug>
</log>

<log realm="saf" at="Tue Dec 01 12:49:48 MYT 2009.924">
<debug>
Timeout after sleep....: Stan : 984290
</debug>
</log>

<log realm="saf" at="Tue Dec 01 12:49:48 MYT 2009.924">
<debug>
Timeout after sleep....: Stan : 000677
</debug>
</log>

<log realm="channel/10.13.200.34:9090" at="Tue Dec 01 12:49:48 MYT
2009.924">
<send>
<isomsg direction="outgoing">
<header>6000000121</header>
<field id="0" value="0501"/>
<field id="3" value="960000"/>
<field id="11" value="984290"/>
<field id="12" value="122304"/>
<field id="13" value="1201"/>
<field id="24" value="000"/>
<field id="41" value="00000005"/>
<field id="42" value="888000016604203"/>
<field id="60" value="000080"/>
<field id="63" value="0000012100000019"/>
</isomsg>
</send>
</log>

<log realm="channel/10.13.200.34:9090" at="Tue Dec 01 12:49:48 MYT
2009.926">
<send>
<isomsg direction="outgoing">
<header>6000000121</header>
<field id="0" value="0301"/>
<field id="3" value="000000"/>
<field id="11" value="000677"/>
<field id="12" value="122115"/>
<field id="13" value="1201"/>
<field id="24" value="000"/>
<field id="41" value="00000000"/>
<field id="42" value="SWITCH1 "/>
<field id="61" value="xxxxxxxxxxxxxxx"/>
<field id="63" value="xxxxxxxxxxxxxxx"/>
</isomsg>
</send>
</log>

[Mark Salter]

LiNa wrote:
> Below is the trace log. The setting for expiry in Qmux is 10 seconds
> while inter message delay is 50 seconds. You can see when 0300 message
> is placed initially, the timer works fine but when there is another
> message (0500) placed in the queue and no response from the host, the
> timer get delayed and turn out to be the same for 0300 and 0500
> message. In between these transactions there are other transactions
> with response.

May I ask how many times you will keep sending the repeat messages?
Does the recipient expect you to keep sending (and expecting a response)
forever? If you just keep repeating, why does the expiration need to be
accurate - as long as you get to it, does it matter? Note, I'm not
suggesting you don't have a problem (with the delay increasing); I'm
just trying to understand your actual need; in the hope it is not unique
and there is another - perhaps better - approach.

If the delay on the response coming back is 50 seconds, why don't we see
any response at all?

I wonder if you have key clashes between the original and repeat
messages, what is your QMUX key (which fields).

> <log realm="saf" at="Tue Dec 01 12:22:15 MYT 2009.604">
> <debug>
> Timeout after sleep....: Stan : 000677
> </debug>
> </log>

What does the message above indicate? How long is your 'saf' sleeping
for - is the duration of this sleep changing or static? Perhaps include
the duration of target sleep duration in this debug message so we can see?

--
Mark

[LiNa]

On Jun 30, 3:01 pm, Mark Salter <marksal...@talktalk.net> wrote:
> LiNa wrote:
> > Below is the trace log. The setting for expiry in Qmux is 10 seconds
> > while inter message delay is 50 seconds. You can see when 0300 message
> > is placed initially, the timer works fine but when there is another
> > message (0500) placed in the queue and no response from the host, the
> > timer get delayed and turn out to be the same for 0300 and 0500
> > message. In between these transactions there are other transactions
> > with response.
>
> May I ask how many times you will keep sending the repeat messages?

[Lina] It is configurable in SAF process, currently configured to 100
times.

> Does the recipient expect you to keep sending (and expecting a response)
> forever?  If you just keep repeating, why does the expiration need to be
> accurate - as long as you get to it, does it matter?  Note, I'm not
> suggesting you don't have a problem (with the delay increasing); I'm
> just trying to understand your actual need; in the hope it is not unique
> and there is another - perhaps better - approach.

[Lina] Yes, the expectation is always store and forward until receive
a response from
host. This case is discovered acccidentally when the host did
not reply, and
the specs dictates that the retry is within 1 min interval.
If the delay is few seconds,
I think it's acceptable, but this case the delay is 13 min!

>
> If the delay on the response coming back is 50 seconds, why don't we see
> any response at all?

[Lina] Actually the timeout waiting for response is 10 seconds, after
that it will go to sleep for
for 50 seconds before re-transmission.
This case is discovered accidentally while host did not
reply. Under normal circumstances,
host should reply within 10 seconds.

>
> I wonder if you have key clashes between the original and repeat
> messages, what is your QMUX key (which fields).

[Lina] hm..you suspect this is the culprit? My QMux key is only field
11. But MTI for repeat is retransmission MTI

>
> >   <log realm="saf" at="Tue Dec 01 12:22:15 MYT 2009.604">
> >     <debug>
> >       Timeout after sleep....: Stan : 000677
> >     </debug>
> >   </log>
>
> What does the message above indicate?  How long is your 'saf' sleeping
> for - is the duration of this sleep changing or static?  Perhaps include
> the duration of target sleep duration in this debug message so we can see?

[Lina] this is the 50 seconds sleep before retransmission (after 10
seconds timeout). The duration is static.
>
> --
> Mark

[Mark Salter]

LiNa wrote:
>> May I ask how many times you will keep sending the repeat messages?
>>
>
> [Lina] It is configurable in SAF process, currently configured to 100
> times.

Ok

>
>> Does the recipient expect you to keep sending (and expecting a
>> response) forever? If you just keep repeating, why does the
>> expiration need to be accurate - as long as you get to it, does it
>> matter? Note, I'm not suggesting you don't have a problem (with
>> the delay increasing); I'm just trying to understand your actual
>> need; in the hope it is not unique and there is another - perhaps
>> better - approach.
>
> [Lina] Yes, the expectation is always store and forward until receive
> a response from host. This case is discovered acccidentally when the
> host did not reply, and the specs dictates that the retry is within 1
> min interval. If the delay is few seconds, I think it's acceptable,
> but this case the delay is 13 min!

Ok - I see, but can't see why the delay might be increasing, I think you
are going to have to find it in your environment, perhaps my suggestion
below will have some benefit for you.

>> If the delay on the response coming back is 50 seconds, why don't
>> we see any response at all?
>
> [Lina] Actually the timeout waiting for response is 10 seconds, after
> that it will go to sleep for for 50 seconds before re-transmission.
> This case is discovered accidentally while host did not reply. Under
> normal circumstances, host should reply within 10 seconds.

In your testing set-up, shouldn't you also have responses arriving late
- so they have timed out - perhaps this will become another test case.
Something in your previous post suggested to me that the test system
would respond after 50 seconds, so I was expecting to see responses -
late or otherwise.

BTW, if your test responder never does respond, - are your testing that
you stop sending repeats after the configured number of times (100)?

>> I wonder if you have key clashes between the original and repeat
>> messages, what is your QMUX key (which fields).
>
> [Lina] hm..you suspect this is the culprit? My QMux key is only field
> 11. But MTI for repeat is retransmission MTI

I wonder if this might come into play, but with no responses currently
coming back I wonder what the QMUX thinks is going on? In my mind as it
checks it's space to see if there is a request that matches the current
response is the time the Expired method on an 'old' request object will
be called.

To suggest a different approach:-

You are currently relying on the Expiration time out to trigger the need
for a 'sleep and repeat send'...

Can't you drive your SAF queue by checking for a time out on :-

QMUX.request(ISOMsg request, int time out)

to populate and maintain your SAF queue?

If the original request times out, add a message to your 'SAF queue'.

In your SAF processing task, periodically try a repeat, if a response to
the repeat arrives, delete the entry as done, if not requeue it.

If a response (repeat or orginal) arrives after your time out - perhaps
the other system is also reimplementing a similar SAF process - then
processing messages arriving on the QMUX.unhandled key will allow you to
find and delete your SAF repeat as it is no longer needed. This is
where key matching clashes might matter

Note, you need to take care when handling of this SAF queue to ensure
that you don't remove an item but fail to requeue, perhaps an
'in-progress' marker and attempt count is needed.

You also probably want to avoid a 'repeat flood' controlling the
frequency and speed of SAF queue scan might be easier if the SAF
processing is decoupled from the primary message exchanges.

Hth

--
Mark

[Alejandro Revilla]

>
> After posting this thread, I finally modified the QMUX as below and
> the problem ceased.
>

With your change, your ISORequestListener.expired callback method would
never get called.

>
> I see that the DefaultTimer is a static class with only one thread
> running. Any reason why it must be a static class?
>

Yes, it sorts and chains all scheduled timer tasks, it's more efficient
than creating hundreds of Timer objects.

[Alejandro Revilla]

>
> Can't you drive your SAF queue by checking for a time out on :-
>
> QMUX.request(ISOMsg request, int time out)
>
> to populate and maintain your SAF queue?
>

or... can't you use our SAF implementation (see opt/saf in jposee) ?

[Mark Salter]

Perfect, place a SAF in 'front' of a MUX:-

saf.send(request, responseDestKey...);
ISOMsg response = sp.in(responseDestKey, timeout);

if (response != null) {
// Do something with our response .
} else {
// Do something without a response 8).
}

... fire and forget 8).

I initially looked for a saf.request method (rather than saf.send) but I
see the approach, just perfect for LiNa (I hope).

Thanks Alejandro!

--
Mark

[Alejandro Revilla]

Well... I'm not sure if it will work, the SAF is a one-way thing, there's no easy way to deal with the response.

[Mark Salter]

Alejandro Revilla wrote:
> Well... I'm not sure if it will work, the SAF is a one-way thing, there's no
> easy way to deal with the response.

Sorry Alejandro, may I clarify please...

Do you think the example code in my reply is not good, or that
implementing a saf.request(request, timeout) method is harder than I
imagine?

--
Mark

[apr]

> Do you think the example code in my reply is not good, or that
> implementing a saf.request(request, timeout) method is harder than I
> imagine?

If I understand correctly, your code would send the message via the
SAF, but then would
pull the key entry from the space. That would confuse the MUX and the
SAF wouldn't
know that there's a reply for the message, and would in turn re-
transmit it.

[Mark Salter]

Perhaps I am missing something...

The responseKey parm on the send appears to be the space queue into
which the saf will place the response (once received) - I assumed this
was for the sender's benefit and so he could complete his 'response
handling' process whenever it occurred?

Would one use SAF.send() as the way to send any request for which saf
was required through the associate mux'd connection?

Perhaps responseKey has another use I can't see?

Sorry Alejandro, please bear with me.

--
Mark

[apr]

Sorry Mark,

You are right. At first sight, I thought that would be a key managed
by QMUX,
but you suggested to use SAF's ability to provide the responses back
(which is a nice
one).

Please ignore my comment.

PS.- Do you have a recommendations on how to write smart answers? :) :)

[Mark Salter]

apr wrote:
> Sorry Mark,
>
> You are right. At first sight, I thought that would be a key managed
> by QMUX,
> but you suggested to use SAF's ability to provide the responses back
> (which is a nice
> one).

I would like to add a .request method (matching mux's) so that the
sender has the option of sending and waiting as well...

> PS.- Do you have a recommendations on how to write smart answers? :) :)

8)

--
Mark

[apr]

>
> I would like to add a .request method (matching mux's) so that the
> sender has the option of sending and waiting as well...
>

Sounds OK, in that case, SAF could implement MUX, with the added
benefit that
in case of a crash, SAF would still try to send entries.

[Mark Salter]

The MUX interface introduces the request with the callback (extra to
think about), but no worries, I will take a look.

Thanks Alejandro.

I wonder to if LiNa has evolved their approach...

--
Mark

[Alejandro Revilla]

>
> The MUX interface introduces the request with the callback (extra to
> think about), but no worries, I will take a look.
>

We can through an ISOException ("Not implemented").

[LiNa]

Hi Mark and Alejandro,

Sorry for late reply, was so caught up with the project. The reason
why I don't use jposee SAF is because I want to use QMUX asynch
request. After I modified the timer, the ISOResponseListener.expired
get called perfectly on the exact timeout. Once the expired get
called, it will place the message back to SAF queue for
retransmission..

[Mark Salter]

LiNa wrote:
>
> Sorry for late reply, was so caught up with the project.

Understood.

> The reason why I don't use jposee SAF is because I want to use QMUX
> asynch request.

Of course that is your choice. At present though you are using this to
implement a SAF process, which the SAF implementation *could* handle for
you.

> After I modified the timer, the ISOResponseListener.expired get
> called perfectly on the exact timeout. Once the expired get called,
> it will place the message back to SAF queue for retransmission..

If you are happy with your current position and approach, then great; I
am glad you found a solution.

--
Mark

[Mark Salter]

LiNa wrote:
>
> Thank you for your reply.
> After posting this thread, I finally modified the QMUX as below and
> the problem ceased.
>

> public class QMUX extends org.jpos.q2.iso.QMUX {
> public void request (ISOMsg m, long timeout, ISOResponseListener
> rl, Object handBack)
> throws ISOException
> {
> String key = getKey (m);
> String req = key + ".req";
> m.setDirection(0);
> AsyncRequest ar = new AsyncRequest (rl, handBack);
> // synchronized (ar) {
> // if (timeout > 0)
> // DefaultTimer.getTimer().schedule (ar, timeout);
> // }
> Timer timer = new Timer();
> timer.schedule(ar, timeout);
> sp.out (req, ar, timeout);
> sp.out (out, m, timeout);
> }
>

So LiNa's change above sorted the issue - the handback.expired method is
called.

Perhaps we should take a look at why the current code did not work for
LiNa sometime?

--
Mark

[Mark Salter]

Mark Salter wrote:

>> public class QMUX extends org.jpos.q2.iso.QMUX {
>> public void request (ISOMsg m, long timeout, ISOResponseListener
>> rl, Object handBack)
>> throws ISOException
>> {
>> String key = getKey (m);
>> String req = key + ".req";
>> m.setDirection(0);
>> AsyncRequest ar = new AsyncRequest (rl, handBack);
>> // synchronized (ar) {
>> // if (timeout > 0)
>> // DefaultTimer.getTimer().schedule (ar, timeout);
>> // }
>> Timer timer = new Timer();
>> timer.schedule(ar, timeout);
>> sp.out (req, ar, timeout);
>> sp.out (out, m, timeout);
>> }
>>

> Perhaps we should take a look at why the current code did not work for
> LiNa sometime?
>
LiNa, it occurs to me that the only real difference in your code is that
the call to timer.schedule(ar, timeout) is no longer synchronised nor
conditional on timeout > 0.

Could you possibly confirm that in your set-up with your change reverted:-

that timeout is > 0 and that :-
DefaultTimer.getTimer().schedule (ar, timeout);
was being called please?

If you could then remove the synchronized statement and try again please?

I appreciate you may have already tried some of this, but if you could
help me eliminate the obvious problems before I go digging, that would
be great.

Thanks.

--
Mark

[Alejandro Revilla]

Good question Mark,

I don't like the idea of creating a new Timer for every request.