Mailing-List: contact uima-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: uima-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of msa@schor.com designates
 64.5.52.13 as permitted sender)
Message-ID: <4B28D2DB.4080507@schor.com>
Date: Wed, 16 Dec 2009 07:30:19 -0500
From: Marshall Schor <msa@schor.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: uima-user@incubator.apache.org
Subject: Re: Error on getMeta call to remote service
References: <4B28B036.7010700@ilsp.gr>
In-Reply-To: <4B28B036.7010700@ilsp.gr>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit


Prokopis Prokopidis wrote:
>> On Tue, Dec 15, 2009 at 3:52 PM, Prokopis Prokopidis
>> <prok...@gmail.com> wrote:
>>
>> > If it's any help, when calling the service from the
>> > machine on which it has been deployed, or when reversing
>> > the service-client roles between the two machines,
>> > everything works as in the README file.
>>
>> Hmmm, smells like a clock synchronization problem. In order to avoid
>> undeliverable messages building up on a broker, timeout settings
>> are used to create time-to-live properties in the JMS messages.
>> ActiveMQ implements time-to-live based on the client and server
>> machine clocks.
>>
>> Eddie
>
> Thank you! Following your advice and after synchronizing the clocks on
> both machines (via ntpd) I managed to call the service as expected.
>
> Since I am no ActiveMQ expert, I'm now left wondering whether there is
> a way to ensure that similar problems do not come up if a real-life
> service is accessed by clients with unsynchronized clocks (on which
> clients, of course,  I will not be able to synchronize the clock).

Yes, this is a known issue with various versions of ActiveMQ.  You can
find these issues via searching the web with keywords like:
ActiveMQ clock sync synchronize time live
>
> Is this an issue which can be resolved in the client or server side
> code and in the example of the AS distribution as well? Should I
> create an issue in JIRA?

I'm not the expert here.  However, there was a mention of some kind of
work-around, on this Jira:
https://issues.apache.org/activemq/browse/AMQ-975

where a user said:

In my case I don't have the machines synchronized, because producers,
consumers and brokers ... run in different countries and are
administrated by different people.

and the response was:

You should set the timestamp on messages on your broker by using the
TimeStampBrokerPlugin -
http://activemq.apache.org/maven/activemq-core/apidocs/org/apache/activemq/broker/util/TimeStampingBrokerPlugin.html^


see http://activemq.apache.org/interceptors.html^ for info on how to set
a broker interceptor

The api says:

A Broker interceptor which updates a JMS Client's timestamp on the
message with a broker timestamp. Useful when the clocks on client
machines are known to not be correct and you can only trust the time set
on the broker machines. Enabling this plugin will break JMS compliance
since the timestamp that the producer sees on the messages after as
send() will be different from the timestamp the consumer will observe
when he receives the message. This plugin is not enabled in the default
ActiveMQ configuration.

[ Show » <https://issues.apache.org/activemq/browse/AMQ-975> ]
Rob Davies
<https://issues.apache.org/activemq/secure/ViewProfile.jspa?name=rajdavies>
added a comment - 23/May/09 02:00 AM You should set the timestamp on
messages on your broker by using the TimeStampBrokerPlugin -
http://activemq.apache.org/maven/activemq-core/apidocs/org/apache/activemq/broker/util/TimeStampingBrokerPlugin.html^
see http://activemq.apache.org/interceptors.html^ for info on how to set
a broker interceptor
Hope this helps...

-Marshall
>
> Best,
>
> Prokopis
>
>
>