You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "William Tam (JIRA)" <ji...@apache.org> on 2009/08/21 18:54:15 UTC
[jira] Issue Comment Edited: (CXF-2398) JMS Connections are not
closed when JCA recycles CXF proxy
[ https://issues.apache.org/jira/browse/CXF-2398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12746074#action_12746074 ]
William Tam edited comment on CXF-2398 at 8/21/09 9:53 AM:
-----------------------------------------------------------
While the new patch CXF-2398.patch2 addresses the problem (of prematurely destroying clients) introduced CXF-2398.patch, the new patch also raises new issues/questions.
* Creating more than one client proxy per ManagedConnectionImpl.getConnection(subject, spec) method call is needed if we are going to support Jee credential mapping. Currently, the subject is only saved in the handles map for reporting the subject of the associated handle in metadata (the new patch will break this, btw) but the subject could be used as credential to create a client proxy connection handle in the future. FYI, If you look at ManagedConnectionFactoryImpl.matchManagedConnections(), it intentionally skips the subject as a matching criteria (so the application server would call ManagedConnectionImpl.getConnection(subject, spec) with different subjects). I'd recommend not to change it.
* I think what prompted the change was the observation of too many proxies getting created. It is a problem in the ManagedConnectionImpl.getConnection(subject, spec) method that does not check the subject. We should not create new proxy if there is one already created for a given subject. We could so something like this in getConnection() to fix it.
{code}
Object handle = null;
for (Map.Entry<Object, Subject> entry : handles.entrySet()) {
if (subject == null) {
if (entry.getValue() == null) {
handle = entry.getKey();
break;
}
} else {
if (subject.equals(entry.getValue())) {
handle = entry.getKey();
break;
}
}
}
// only create a new handle, if hande is null
{code}
* I think it is fine to have the ManagedConnectionImpl.destroy() to destroy client proxies. What about the cleanup() method? The JCA spec 6.5.4.4 says we should invalidate all handles but at the same time it says cleanup() should not close physical pipe. It does not fit well in our model because we invalidate handle by destroying client (thus, closing connection). IMO, it is fine for the cleanup() method to invoke client destroy(). Right now, we are not invalidating handles. So, if you take my advice in the first bullet, we would move the closed handle from handle map to another collection (say, closedHandle) in handleCloseMethod().
{code}
handles.remove(proxy);
closedHandles.add(proxy);
{code}
When destroying the proxies, we just need to make sure we destroy the closedHandles as well.
was (Author: wtam):
While the new patch CXF-2398.patch2 addresses the problem (of prematurely destroying clients) introduced CXF-2398.patch, the new patch also raises new issues/questions.
* Creating more than one client proxy per ManagedConnectionImpl.getConnection(subject, spec) method call is needed if we are going to support Jee credential mapping. Currently, the subject is only saved in the handles map for reporting the subject of the associated handle in metadata (the new patch will break this, btw) but the subject could be used as credential to create a client proxy connection handle in the future. FYI, If you look at ManagedConnectionFactoryImpl.matchManagedConnections(), it intentionally skips the subject as a matching criteria (so the application server would call ManagedConnectionImpl.getConnection(subject, spec) with different subjects). I'd recommend not to change it.
* I think what prompted the change was the observation of too many proxies getting created. It is a problem in the ManagedConnectionImpl.getConnection(subject, spec) method that does not check the subject. We should not create new proxy if there is one already created for a given subject. We could so something like this in getConnection() to fix it.
{code}
Object handle = null;
for (Map.Entry<Object, Subject> entry : handles.entrySet()) {
if (subject == null) {
if (entry.getValue() == null) {
handle = entry.getKey();
break;
}
} else {
if (subject.equals(entry.getValue())) {
handle = entry.getKey();
break;
}
}
}
// only create a new handle, if hande is null
{code}
* I think it is fine to have the ManagedConnectionImpl.destroy() to destroy client proxies. What about the cleanup() method? The JCA spec 6.5.4.4 says we should invalidate all handles but at the same time it says cleanup() should not close physical pipe. It does not fit well in our model because we invalidate handle by destroy client (thus, closing connection). IMO, it is fine for the cleanup() method to invoke client destroy(). Right now, we are not invalidating handles. So, if you take my advice in the first bullet, we would move the closed handle from handle map to another collection (say, closedHandle) in handleCloseMethod().
{code}
handles.remove(proxy);
closedHandles.add(proxy);
{code}
When destroying the proxies, we just need to make sure we destroy the closedHandles as well.
> JMS Connections are not closed when JCA recycles CXF proxy
> ----------------------------------------------------------
>
> Key: CXF-2398
> URL: https://issues.apache.org/jira/browse/CXF-2398
> Project: CXF
> Issue Type: Bug
> Components: Integration
> Affects Versions: 2.1
> Reporter: Seumas Soltysik
> Assignee: Daniel Kulp
> Fix For: 2.1.7, 2.2.4
>
> Attachments: CXF-2398.patch, CXF-2398.patch2
>
>
> When close() is called on JCA ConnectionHandler, there is no cleanup of the underlying client proxy and its transport. Specfically when the JCA outbound use case is using JMS, JMS connections are not being closed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.