You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Ujjwal Gulecha <uj...@gmail.com> on 2018/03/22 21:31:21 UTC
CXF stub timeouts
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
ᐧ
Re: CXF stub timeouts
Posted by Ujjwal Gulecha <uj...@gmail.com>.
Hi,
Thanks a lot Colm!
That answers my questions!
ᐧ
On 26 March 2018 at 02:35, Colm O hEigeartaigh <co...@apache.org> 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 <co...@apache.org>
>>> 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 <
>>>> ujjwal.gulecha@gmail.com> 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
Re: CXF stub timeouts
Posted by Colm O hEigeartaigh <co...@apache.org>.
>
> 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 <co...@apache.org>
>> 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 <
>>> ujjwal.gulecha@gmail.com> 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
Re: CXF stub timeouts
Posted by Ujjwal Gulecha <uj...@gmail.com>.
Hi Colm,
Another question is that I noticed that when I used cxf version 2.7.18
for cxf-rt-ws-policy, cxf-rt-ws-security, cxf-rt-frontend-jaxws
and cxf-rt-transports-http, I was getting that error at random times. When
I have now switched to version 3.2.2, I haven't seen that error.
Was there some known issue in 2.7.18 that could have caused this error to
appear ?
Thanks
ᐧ
On 23 March 2018 at 08:19, Ujjwal Gulecha <uj...@gmail.com> wrote:
> PFA the security policy part.
>
> I don't really know the issue on server side. I have a few questions, It
> would be great if you could answer them. Thank you so much!
>
> 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?
> 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?
>
> 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 <co...@apache.org>
> 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 <ujjwal.gulecha@gmail.com
>> > 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
Re: CXF stub timeouts
Posted by Ujjwal Gulecha <uj...@gmail.com>.
PFA the security policy part.
I don't really know the issue on server side. I have a few questions, It
would be great if you could answer them. Thank you so much!
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?
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?
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 <co...@apache.org> 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 <uj...@gmail.com>
> 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
Re: CXF stub timeouts
Posted by Colm O hEigeartaigh <co...@apache.org>.
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 <uj...@gmail.com>
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