I found out the clocks are off by more than 5 mins.
Syncing them fixed the issue. But the clocks might get out of sync again.
Are 'timestampStrict' and 'timeToLive' the relevant properties for handling
such scenarios?
Thanks,
Giriraj.
On Tue, May 6, 2014 at 5:03 AM, Colm O hEigeartaigh <cohei...@apache.org>wrote:
>
> The most likely reason is that the local time on the service machine is
> out by more than 5 minutes. Timezones shouldn't come into it, as the client
> should be sending the time in UTC format. You can disable this check via a
> configuration property if necessary.
>
> Colm.
>
>
> On Fri, May 2, 2014 at 10:52 PM, Giriraj Bhojak <girira...@gmail.com>wrote:
>
>> Hi Everyone,
>>
>> I am getting following message while receiving a response from the web
>> service call.
>> I am not sure what's going on.
>>
>> ID: 1
>> Response-Code: 500
>> Encoding: UTF-8
>> Content-Type: text/xml;charset=UTF-8
>> Headers: {connection=[close], content-type=[text/xml;charset=UTF-8],
>> Date=[Fri, 02 May 2014 21:43:39 GMT], Server=[Apache-Coyote/1.1],
>> transfer-encoding=[chunked]}
>> Payload: <soap:Envelope xmlns:soap="
>> http://schemas.xmlsoap.org/soap/envelope/";><soap:Body><soap:Fault><faultcode
>> xmlns:ns1="
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd";>ns1:MessageExpired</faultcode><faultstring>The
>> message has expired (WSSecurityEngine: Invalid timestamp The security
>> semantics of the message have
>> expired)</faultstring></soap:Fault></soap:Body></soap:Envelope>
>>
>>
>> When I test with the web-service client and web service provider deployed
>> on my machine, everything works fine.
>> In the above scenario, the web-service client is on one machine and the
>> web service provider on another machine.
>> I am trying to find if the provider server is in a different timezone
>> than the client.
>>
>> But does anyone know what's the issue here?
>>
>> Thanks,
>> Giriraj.
>>
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
