Hi,
Thanks a lot Colm!

That answers my questions!
ᐧ

On 26 March 2018 at 02:35, Colm O hEigeartaigh <[email protected]> wrote:

>
>
>> 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
>



-- 
Ujjwal Gulecha

Reply via email to