requestTimeout

[ramil]

Hi,

Im exepriencing this problem implementing timeout on a synchronus request. Everytime my producer sends a message and the consumer failed to consume it due to any possible reason (producer will a recieve a timeout exception) but after it receives the exception and the consumer returns online, it still consumes messages on JMS server.
How can i avoid this scenario? All i want is that my consumer will not these messages on JMS. I tried using timeToLive and set it 5000 millisec but still unable to avoid it.. I saw this requestTimeout property that can be set on JmsProxyFactoryBean but property was not found. I already used the 1.2.1 version. Also browsed the jar and unable to find the property.


Thanks,


Ramil

[James.Strachan]

On 8/25/06, ramil <ramil.segarra@...> wrote:
>
> Hi,
>
> Im exepriencing this problem implementing timeout on a synchronus request.
> Everytime my producer sends a message and the consumer failed to consume it
> due to any possible reason (producer will a recieve a timeout exception) but
> after it receives the exception and the consumer returns online, it still
> consumes messages on JMS server.
> How can i avoid this scenario?

In general its pretty hard to avoid. If you want to guarrentee that
the request is only ever processed if the client side is around to see
it and the request is never processed if the client is not there then
you're only real option is

* EJB with distributed transactions across the client and server side.
* block the client side forever or introduce some kind of compensating
transaction if the client times out the request but a response comes
back later


>  All i want is that my consumer will not these
> messages on JMS.

There's no way in JMS to say 'don't process this message if the sender
is not around any more' as one of the whole points of JMS is to avoid
expensive and slow distributed transactions and to deal with clients
and servers being temporarily disconnected from each other.

So setting a time to live on the message would at least make the
request message timeout afer a few seconds; though it does not
completely solve the problem as there's a window that the server gets
the message, takes a little while to process it then sends the
response back before the client times out.


> I tried using timeToLive and set it 5000 millisec but still
> unable to avoid it.. I saw this requestTimeout property that can be set on
> JmsProxyFactoryBean but property was not found. I already used the 1.2.1
> version. Also browsed the jar and unable to find the property.

So timeToLive is used to indicate how long a request should wait
before timing out together with setting a timeToLive on the message;
so after say 5 seconds the message should not be dispatched to the
server. Are you seeing the message dispatched to the server long after
the timeout should have expired? If so I wonder if its a clock sync
problem - for JMS expiration to work the assumption is the sender and
the broker have clocks in sync.

--

James
-------
http://radio.weblogs.com/0112098/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[ramil]

Is timeToLive (request timeout) = timeToLive of the message on the JMS server?
Because my client application still consumes the message when it returns online or becomes available.
Let say I called a remote method on the client but this client is not available because it still has some processing,
then i received a timeout exception. Can I set the requestTimeout on JmsProxyFactoryBean greater than the timeToLive of the message.
Are my assumptions correct, that let say i can wait longer just to make sure that the message will be deleted first before a timeout
exception will be thrown? I just want to make sure that the dispatched message will be deleted before timeout.

BTW, how can I set the requestTimeout again?

Thanks alot James,


Ramil

James.Strachan wrote:

On 8/25/06, ramil <[e-mail]> wrote:
>
> Hi,
>
> Im exepriencing this problem implementing timeout on a synchronus request.
> Everytime my producer sends a message and the consumer failed to consume it
> due to any possible reason (producer will a recieve a timeout exception) but
> after it receives the exception and the consumer returns online, it still
> consumes messages on JMS server.
> How can i avoid this scenario?

In general its pretty hard to avoid. If you want to guarrentee that
the request is only ever processed if the client side is around to see
it and the request is never processed if the client is not there then
you're only real option is

* EJB with distributed transactions across the client and server side.
* block the client side forever or introduce some kind of compensating
transaction if the client times out the request but a response comes
back later


>  All i want is that my consumer will not these
> messages on JMS.

There's no way in JMS to say 'don't process this message if the sender
is not around any more' as one of the whole points of JMS is to avoid
expensive and slow distributed transactions and to deal with clients
and servers being temporarily disconnected from each other.

So setting a time to live on the message would at least make the
request message timeout afer a few seconds; though it does not
completely solve the problem as there's a window that the server gets
the message, takes a little while to process it then sends the
response back before the client times out.


> I tried using timeToLive and set it 5000 millisec but still
> unable to avoid it.. I saw this requestTimeout property that can be set on
> JmsProxyFactoryBean but property was not found. I already used the 1.2.1
> version. Also browsed the jar and unable to find the property.

So timeToLive is used to indicate how long a request should wait
before timing out together with setting a timeToLive on the message;
so after say 5 seconds the message should not be dispatched to the
server. Are you seeing the message dispatched to the server long after
the timeout should have expired? If so I wonder if its a clock sync
problem - for JMS expiration to work the assumption is the sender and
the broker have clocks in sync.

--

James
-------
http://radio.weblogs.com/0112098/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[James.Strachan]

On 8/25/06, ramil <ramil.segarra@...> wrote:
>
> Is timeToLive (request timeout) = timeToLive of the message on the JMS
> server?

Yes. The same value is used to timeout the request and to set the JMS
expiration time

> Because my client application still consumes the message when it returns
> online or becomes available.
> Let say I called a remote method on the client but this client is not
> available because it still has some processing,
> then i received a timeout exception. Can I set the requestTimeout on
> JmsProxyFactoryBean greater than the timeToLive of the message.

We could certainly patch the code to do that - currently it appears we
are using the same value for both the request timeout and message
expiration/.

> Are my assumptions correct, that let say i can wait longer just to make sure
> that the message will be deleted first before a timeout
> exception will be thrown?

Yeah - that will certainly help. There's still a risk that it takes a
while to process the message in the server though. e.g. you timeout a
request after 5 seconds and the message lives for 2 seconds, it could
take 1 hour to process the message though :)

> I just want to make sure that the dispatched
> message will be deleted before timeout.

Are your clocks in sync?

--

James
-------
http://radio.weblogs.com/0112098/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[ramil]

Yes, my clocks are sync since both clients and server is hosted on the same machine..

Please, please patch this one for me. This I believe will solve my problem. Actually this is just for a sms gateway, so processing message could only take atmost 5 secs. That's the only clear solution for me now, I'm still reading the lingo source and patching will take atleast a two to three days.

I just want to make sure that the message is deleted before an exception will be thrown so that i can resend the message to the client again.


Thanks alot again James,



Ramil

James.Strachan wrote:

On 8/25/06, ramil <[e-mail]> wrote:
>
> Is timeToLive (request timeout) = timeToLive of the message on the JMS
> server?

Yes. The same value is used to timeout the request and to set the JMS
expiration time

> Because my client application still consumes the message when it returns
> online or becomes available.
> Let say I called a remote method on the client but this client is not
> available because it still has some processing,
> then i received a timeout exception. Can I set the requestTimeout on
> JmsProxyFactoryBean greater than the timeToLive of the message.

We could certainly patch the code to do that - currently it appears we
are using the same value for both the request timeout and message
expiration/.

> Are my assumptions correct, that let say i can wait longer just to make sure
> that the message will be deleted first before a timeout
> exception will be thrown?

Yeah - that will certainly help. There's still a risk that it takes a
while to process the message in the server though. e.g. you timeout a
request after 5 seconds and the message lives for 2 seconds, it could
take 1 hour to process the message though :)

> I just want to make sure that the dispatched
> message will be deleted before timeout.

Are your clocks in sync?

--

James
-------
http://radio.weblogs.com/0112098/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[James.Strachan]

I created this JIRA to track this issue

http://jira.codehaus.org/browse/LINGO-36

I've added a separate property, 'responseTimeout' to the client proxy
factory bean so you can set the response timeout to be greater than
the timeToLive of the request message. So you can have a timeToLive of
5000 and a responseTimeout of double that size if you like etc.


On 8/25/06, ramil <ramil.segarra@...> wrote:

>
> Yes, my clocks are sync since both clients and server is hosted on the same
> machine..
>
> Please, please patch this one for me. This I believe will solve my problem.
> Actually this is just for a sms gateway, so processing message could only
> take atmost 5 secs. That's the only clear solution for me now, I'm still
> reading the lingo source and patching will take atleast a two to three days.
>
> I just want to make sure that the message is deleted before an exception
> will be thrown so that i can resend the message to the client again.
>
>
> Thanks alot again James,
>
>
>
> Ramil
>
>
>
> James.Strachan wrote:
> >
> > On 8/25/06, ramil <ramil.segarra@...> wrote:
> >>
> >> Is timeToLive (request timeout) = timeToLive of the message on the JMS
> >> server?
> >
> > Yes. The same value is used to timeout the request and to set the JMS
> > expiration time
> >
> >> Because my client application still consumes the message when it returns
> >> online or becomes available.
> >> Let say I called a remote method on the client but this client is not
> >> available because it still has some processing,
> >> then i received a timeout exception. Can I set the requestTimeout on
> >> JmsProxyFactoryBean greater than the timeToLive of the message.
> >
> > We could certainly patch the code to do that - currently it appears we
> > are using the same value for both the request timeout and message
> > expiration/.
> >
> >> Are my assumptions correct, that let say i can wait longer just to make
> >> sure
> >> that the message will be deleted first before a timeout
> >> exception will be thrown?
> >
> > Yeah - that will certainly help. There's still a risk that it takes a
> > while to process the message in the server though. e.g. you timeout a
> > request after 5 seconds and the message lives for 2 seconds, it could
> > take 1 hour to process the message though :)
> >
> >> I just want to make sure that the dispatched
> >> message will be deleted before timeout.
> >
> > Are your clocks in sync?
> >
> > --
> >
> > James
> > -------
> > http://radio.weblogs.com/0112098/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/requestTimeout-tf2162609.html#a5982474
> Sent from the lingo - user forum at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

--

James
-------
http://radio.weblogs.com/0112098/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[J. Matthew Pryor-3]

What are the implications here where we cannot rely on clock
synchronisation to be accurate to more that 10-15 minutes? (which is the
case in our production environments)

Thanks,
Matthew

James Strachan wrote:

> I created this JIRA to track this issue
>
> http://jira.codehaus.org/browse/LINGO-36
>
> I've added a separate property, 'responseTimeout' to the client proxy
> factory bean so you can set the response timeout to be greater than
> the timeToLive of the request message. So you can have a timeToLive of
> 5000 and a responseTimeout of double that size if you like etc.
>
>
> On 8/25/06, ramil <ramil.segarra@...> wrote:
>>
>> Yes, my clocks are sync since both clients and server is hosted on
>> the same
>> machine..
>>
>> Please, please patch this one for me. This I believe will solve my
>> problem.
>> Actually this is just for a sms gateway, so processing message could
>> only
>> take atmost 5 secs. That's the only clear solution for me now, I'm still
>> reading the lingo source and patching will take atleast a two to
>> three days.
>>
>> I just want to make sure that the message is deleted before an exception
>> will be thrown so that i can resend the message to the client again.
>>
>>
>> Thanks alot again James,
>>
>>
>>
>> Ramil
>>
>>
>>
>> James.Strachan wrote:
>> >
>> > On 8/25/06, ramil <ramil.segarra@...> wrote:
>> >>
>> >> Is timeToLive (request timeout) = timeToLive of the message on the
>> JMS
>> >> server?
>> >
>> > Yes. The same value is used to timeout the request and to set the JMS
>> > expiration time
>> >
>> >> Because my client application still consumes the message when it
>> returns
>> >> online or becomes available.
>> >> Let say I called a remote method on the client but this client is not
>> >> available because it still has some processing,
>> >> then i received a timeout exception. Can I set the requestTimeout on
>> >> JmsProxyFactoryBean greater than the timeToLive of the message.
>> >
>> > We could certainly patch the code to do that - currently it appears we
>> > are using the same value for both the request timeout and message
>> > expiration/.
>> >
>> >> Are my assumptions correct, that let say i can wait longer just to
>> make
>> >> sure
>> >> that the message will be deleted first before a timeout
>> >> exception will be thrown?
>> >
>> > Yeah - that will certainly help. There's still a risk that it takes a
>> > while to process the message in the server though. e.g. you timeout a
>> > request after 5 seconds and the message lives for 2 seconds, it could
>> > take 1 hour to process the message though :)
>> >
>> >> I just want to make sure that the dispatched
>> >> message will be deleted before timeout.
>> >
>> > Are your clocks in sync?
>> >
>> > --
>> >
>> > James
>> > -------
>> > http://radio.weblogs.com/0112098/
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe from this list please visit:
>> >
>> >     http://xircles.codehaus.org/manage_email
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/requestTimeout-tf2162609.html#a5982474
>> Sent from the lingo - user forum at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[ramil]

Hi,

Implemented the responseTimeout property:
<property name="responseTimeout" value="7000" />

larger than timeToLive:
<bean id="producerConfig" class="org.logicblaze.lingo.jms.JmsProducerConfig">
                 <property name="timeToLive" value="5000"/>
</bean>


But still jms message is consumed whenever a client returns online after a response timeout exception was thrown (javax.jms.JMSException: edu.emory.mathcs.backport.java.util.concurrent.TimeoutException).

Are these properties need also to be set?
    private long multipleResponseTimeout = 5000L;
    private long remoteReferenceTimeout = 60000L;

I still can't make sure that the message is deleted on JMS server after it was dispatched.


Thanks again,



Ramil

James.Strachan wrote:

I created this JIRA to track this issue

http://jira.codehaus.org/browse/LINGO-36

I've added a separate property, 'responseTimeout' to the client proxy
factory bean so you can set the response timeout to be greater than
the timeToLive of the request message. So you can have a timeToLive of
5000 and a responseTimeout of double that size if you like etc.


On 8/25/06, ramil <[e-mail]> wrote:
>
> Yes, my clocks are sync since both clients and server is hosted on the same
> machine..
>
> Please, please patch this one for me. This I believe will solve my problem.
> Actually this is just for a sms gateway, so processing message could only
> take atmost 5 secs. That's the only clear solution for me now, I'm still
> reading the lingo source and patching will take atleast a two to three days.
>
> I just want to make sure that the message is deleted before an exception
> will be thrown so that i can resend the message to the client again.
>
>
> Thanks alot again James,
>
>
>
> Ramil
>
>
>
> James.Strachan wrote:
> >
> > On 8/25/06, ramil <[e-mail]> wrote:
> >>
> >> Is timeToLive (request timeout) = timeToLive of the message on the JMS
> >> server?
> >
> > Yes. The same value is used to timeout the request and to set the JMS
> > expiration time
> >
> >> Because my client application still consumes the message when it returns
> >> online or becomes available.
> >> Let say I called a remote method on the client but this client is not
> >> available because it still has some processing,
> >> then i received a timeout exception. Can I set the requestTimeout on
> >> JmsProxyFactoryBean greater than the timeToLive of the message.
> >
> > We could certainly patch the code to do that - currently it appears we
> > are using the same value for both the request timeout and message
> > expiration/.
> >
> >> Are my assumptions correct, that let say i can wait longer just to make
> >> sure
> >> that the message will be deleted first before a timeout
> >> exception will be thrown?
> >
> > Yeah - that will certainly help. There's still a risk that it takes a
> > while to process the message in the server though. e.g. you timeout a
> > request after 5 seconds and the message lives for 2 seconds, it could
> > take 1 hour to process the message though :)
> >
> >> I just want to make sure that the dispatched
> >> message will be deleted before timeout.
> >
> > Are your clocks in sync?
> >
> > --
> >
> > James
> > -------
> > http://radio.weblogs.com/0112098/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/requestTimeout-tf2162609.html#a5982474
> Sent from the lingo - user forum at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


--

James
-------
http://radio.weblogs.com/0112098/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[claudem]

I have a similar need on my project.

The message producer is a listener. It defines 2 methods:

 - onStart
 - onDone

Lingo implements this using temporary queues (or topics, I forgot.)

When a message should expire from the producer's perspective, the producer closes its corresponding requestor ()the listener). If the original message remains in the queue, and a consumer wakes up later on to consume it, it will try to send an onStart message back to the original producer (sending to the now gone temp queue). This fails because the producer is closed, so the consumer just exits without doing its work.

Using this approach, I do not care much about obsolete messages in the queues as they will not cause any process on the consumer if the producer is not listening anymore.

Basically, I kind of reversed the problem.

[ramil]

Hi James,


Any update on this? I still experience the same problem, message still there on JMS server after a timeout exception is thrown. Already use the new properties.


Thanks alot again,



Ramil

James.Strachan wrote:

I created this JIRA to track this issue

http://jira.codehaus.org/browse/LINGO-36

I've added a separate property, 'responseTimeout' to the client proxy
factory bean so you can set the response timeout to be greater than
the timeToLive of the request message. So you can have a timeToLive of
5000 and a responseTimeout of double that size if you like etc.


On 8/25/06, ramil <[e-mail]> wrote:
>
> Yes, my clocks are sync since both clients and server is hosted on the same
> machine..
>
> Please, please patch this one for me. This I believe will solve my problem.
> Actually this is just for a sms gateway, so processing message could only
> take atmost 5 secs. That's the only clear solution for me now, I'm still
> reading the lingo source and patching will take atleast a two to three days.
>
> I just want to make sure that the message is deleted before an exception
> will be thrown so that i can resend the message to the client again.
>
>
> Thanks alot again James,
>
>
>
> Ramil
>
>
>
> James.Strachan wrote:
> >
> > On 8/25/06, ramil <[e-mail]> wrote:
> >>
> >> Is timeToLive (request timeout) = timeToLive of the message on the JMS
> >> server?
> >
> > Yes. The same value is used to timeout the request and to set the JMS
> > expiration time
> >
> >> Because my client application still consumes the message when it returns
> >> online or becomes available.
> >> Let say I called a remote method on the client but this client is not
> >> available because it still has some processing,
> >> then i received a timeout exception. Can I set the requestTimeout on
> >> JmsProxyFactoryBean greater than the timeToLive of the message.
> >
> > We could certainly patch the code to do that - currently it appears we
> > are using the same value for both the request timeout and message
> > expiration/.
> >
> >> Are my assumptions correct, that let say i can wait longer just to make
> >> sure
> >> that the message will be deleted first before a timeout
> >> exception will be thrown?
> >
> > Yeah - that will certainly help. There's still a risk that it takes a
> > while to process the message in the server though. e.g. you timeout a
> > request after 5 seconds and the message lives for 2 seconds, it could
> > take 1 hour to process the message though :)
> >
> >> I just want to make sure that the dispatched
> >> message will be deleted before timeout.
> >
> > Are your clocks in sync?
> >
> > --
> >
> > James
> > -------
> > http://radio.weblogs.com/0112098/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/requestTimeout-tf2162609.html#a5982474
> Sent from the lingo - user forum at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


--

James
-------
http://radio.weblogs.com/0112098/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[ramil]

Hi,

Do have any idea on how we can modify Lingo just to meet this? Maybe we can help each other only if you want to. :D


Thanks,

claudem wrote:

I have a similar need on my project.

The message producer is a listener. It defines 2 methods:

 - onStart
 - onDone

Lingo implements this using temporary queues (or topics, I forgot.)

When a message should expire from the producer's perspective, the producer closes its corresponding requestor ()the listener). If the original message remains in the queue, and a consumer wakes up later on to consume it, it will try to send an onStart message back to the original producer (sending to the now gone temp queue). This fails because the producer is closed, so the consumer just exits without doing its work.

Using this approach, I do not care much about obsolete messages in the queues as they will not cause any process on the consumer if the producer is not listening anymore.

Basically, I kind of reversed the problem.

[claudem]

This is what I have already implemented in my project. Lingo has all that is required in place. I implemented what I described by looking at the org.logicblaze.lingo.example.ExampleTest class, specifically, the testClient method. I extended this example with the addition of another listener method, onStart.  

--
Claude


Hi,

Do have any idea on how we can modify Lingo just to meet this? Maybe we can help each other only if you want to. :D


Thanks,

claudem wrote:

I have a similar need on my project.

The message producer is a listener. It defines 2 methods:

 - onStart
 - onDone

Lingo implements this using temporary queues (or topics, I forgot.)

When a message should expire from the producer's perspective, the producer closes its corresponding requestor ()the listener). If the original message remains in the queue, and a consumer wakes up later on to consume it, it will try to send an onStart message back to the original producer (sending to the now gone temp queue). This fails because the producer is closed, so the consumer just exits without doing its work.

Using this approach, I do not care much about obsolete messages in the queues as they will not cause any process on the consumer if the producer is not listening anymore.

Basically, I kind of reversed the problem.

[ramil]

Hi,

I can see it more clearly now.. So what you've implemented is that everytime a client/ consumer is available it will try to send back a message to the producer of the message and of course since thats producer's queue is not there anymore it will then throw an exception and skip its next process or anything inside it right..


Thanks alot for this very useful idea,



Ramil





This is what I have already implemented in my project. Lingo has all that is required in place. I implemented what I described by looking at the org.logicblaze.lingo.example.ExampleTest class, specifically, the testClient method. I extended this example with the addition of another listener method, onStart.  

--
Claude

ramil wrote:

Hi,

Do have any idea on how we can modify Lingo just to meet this? Maybe we can help each other only if you want to. :D


Thanks,

claudem wrote:

I have a similar need on my project.

The message producer is a listener. It defines 2 methods:

 - onStart
 - onDone

Lingo implements this using temporary queues (or topics, I forgot.)

When a message should expire from the producer's perspective, the producer closes its corresponding requestor ()the listener). If the original message remains in the queue, and a consumer wakes up later on to consume it, it will try to send an onStart message back to the original producer (sending to the now gone temp queue). This fails because the producer is closed, so the consumer just exits without doing its work.

Using this approach, I do not care much about obsolete messages in the queues as they will not cause any process on the consumer if the producer is not listening anymore.

Basically, I kind of reversed the problem.

[James.Strachan]

On 8/27/06, J. Matthew Pryor <jmp@...> wrote:
> What are the implications here where we cannot rely on clock
> synchronisation to be accurate to more that 10-15 minutes? (which is the
> case in our production environments)

The implications are that JMS expirations will probably not work very
well, particularly for things of a granularity of less than 30 mins.
The JMS specification relies on clocks being sync'd. Any idea why your
production environment has such wildly different times? Timezones are
one thing (times are converted to GMT in JMS) but being out by 10-15
minutes sounds rather large. Are they not running time servers?

--

James
-------
http://radio.weblogs.com/0112098/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[J. Matthew Pryor-3]

Our software gets installed on PCs in remote outback (I mean really
remote) locations and we really have no control over how well
synchronized the clocks are.

We use Lingo to provide a SSL secure facade to remotely control the
software running on the PC, but until we can connect in, we don't know
anything about the remote environment.

Thanks,
Matthew

James Strachan wrote:

> On 8/27/06, J. Matthew Pryor <jmp@...> wrote:
>> What are the implications here where we cannot rely on clock
>> synchronisation to be accurate to more that 10-15 minutes? (which is the
>> case in our production environments)
>
> The implications are that JMS expirations will probably not work very
> well, particularly for things of a granularity of less than 30 mins.
> The JMS specification relies on clocks being sync'd. Any idea why your
> production environment has such wildly different times? Timezones are
> one thing (times are converted to GMT in JMS) but being out by 10-15
> minutes sounds rather large. Are they not running time servers?
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[James.Strachan]

On 9/4/06, J. Matthew Pryor <jmp@...> wrote:
&