You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Daniel Kulp (JIRA)" <ji...@apache.org> on 2012/06/06 16:29:23 UTC
[jira] [Created] (CXF-4363) JMS transport uses the
"clientReceiveTimeout" on server side
Daniel Kulp created CXF-4363:
--------------------------------
Summary: JMS transport uses the "clientReceiveTimeout" on server side
Key: CXF-4363
URL: https://issues.apache.org/jira/browse/CXF-4363
Project: CXF
Issue Type: Improvement
Components: Transports
Affects Versions: 2.6.1
Reporter: Daniel Kulp
Fix For: 2.6.2
The JMS transport always uses the "clientReceiveTimeout" to configure the timeout of the DefaultMessageListenerContainer which doesn't make sense on the server side. Worse, if that value is set very high, the server may hang in the endpoint.stop() call when trying to stop the service as it has to wait for the receive to timeout. The values should be separated so clients and servers can use separate values.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-4363) JMS transport uses the
"clientReceiveTimeout" on server side
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Kulp resolved CXF-4363.
------------------------------
Resolution: Fixed
Fix Version/s: 2.5.5
2.4.9
Assignee: Daniel Kulp
> JMS transport uses the "clientReceiveTimeout" on server side
> ------------------------------------------------------------
>
> Key: CXF-4363
> URL: https://issues.apache.org/jira/browse/CXF-4363
> Project: CXF
> Issue Type: Improvement
> Components: Transports
> Affects Versions: 2.6.1
> Reporter: Daniel Kulp
> Assignee: Daniel Kulp
> Fix For: 2.4.9, 2.5.5, 2.6.2
>
>
> The JMS transport always uses the "clientReceiveTimeout" to configure the timeout of the DefaultMessageListenerContainer which doesn't make sense on the server side. Worse, if that value is set very high, the server may hang in the endpoint.stop() call when trying to stop the service as it has to wait for the receive to timeout. The values should be separated so clients and servers can use separate values.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira