>
> Was there some known issue in 2.7.18 that could have caused this error to
> appear ?
>

I'm not sure off-hand, possibly there was a fix relating to how tokens were
renewed by the client that has gone in since CXF 2.7.x


> 1) if once the stub is instantiated, will the same token be used for every
>> call? If token expires, then while renewing token, only the timestamp
>> changes but the token remains the same?
>>
>
Yes the same token is used for every call from the client. If the token is
renewed then it will re-use the old identifier (at least this is what the
CXF Ws-SecureConversation impl does). It generates a new "Instance" field
though to identify the different instances of the same token.


> 2) If server idle/receive/connection timeout is say 5 hours and token
>> expires in 10 hours. If no request has been made with this token for 5
>> hours, the server would make this token invalid right? so on the server
>> side the token is invalid but on client side it still is valid as 5 more
>> hours are left. Am I right in this assumption?
>>
>
The validity of the token is not tied to the underlying transport - if the
client were to establish another connection then the token would still be
valid on the server side.

Colm.


>
>> I think these are the issues causing this error
>> I would love your take on this. Thank You again
>> Ujjwal Gulecha
>> ᐧ
>>
>> On 23 March 2018 at 02:51, Colm O hEigeartaigh <[email protected]>
>> wrote:
>>
>>> More information is required here - what does the message look like,
>>> what is the true exception on the service side, what is the security
>>> binding of the service, etc?
>>>
>>> Colm.
>>>
>>> On Thu, Mar 22, 2018 at 9:31 PM, Ujjwal Gulecha <
>>> [email protected]> wrote:
>>>
>>>> Hi all,
>>>> I was wondering if there is a way to increase the timeout the stub that
>>>> is generated from a wsdl2java for SOAP services?
>>>> The securitypolicy uses usernametoken.
>>>>
>>>> This is the error that is received from the server
>>>>
>>>>  The message could not be processed. This is most likely because the
>>>>> action 'xxxx' is incorrect or because the message contains an invalid
>>>>> or expired security context token or because there is a mismatch between
>>>>> bindings. The security context token would be invalid if the service
>>>>> aborted the channel due to inactivity. To prevent the service from 
>>>>> aborting
>>>>> idle sessions prematurely increase the Receive timeout on the service
>>>>> endpoint's binding
>>>>
>>>>
>>>>
>>>> Thanks!
>>>> --
>>>> Ujjwal Gulecha
>>>> ᐧ
>>>>
>>>
>>>
>>>
>>> --
>>> Colm O hEigeartaigh
>>>
>>> Talend Community Coder
>>> http://coders.talend.com
>>>
>>
>>
>>
>> --
>> Ujjwal Gulecha
>>
>
>
>
> --
> Ujjwal Gulecha
>



-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Reply via email to