You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Andrei Shakirin (Created) (JIRA)" <ji...@apache.org> on 2012/03/02 17:59:57 UTC
[jira] [Created] (CXF-4154) AbstractConduitSelector reused cached
conduit even if protocol was changed
AbstractConduitSelector reused cached conduit even if protocol was changed
--------------------------------------------------------------------------
Key: CXF-4154
URL: https://issues.apache.org/jira/browse/CXF-4154
Project: CXF
Issue Type: Bug
Components: Core
Reporter: Andrei Shakirin
Attachments: AbstractConduitSelector.patch
Hi,
Actually AbstractConduitSelector.getSelectedConduit() creates and caches conduit in selectedConduit variable. Cached conduit is reused by the next calls.
I see the following problem: if user changed protocol in URI between calls, AbstractConduitSelector still uses cached Conduit even it cannot process new URL. In my case cached HTTP consuit tries to process UDP URL.
Proposal for fix: check if protocol in URL was changed and if yes, close and reset selectedConduit.
Patch is attached.
Regards,
Andrei.
--
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] [Commented] (CXF-4154) AbstractConduitSelector reused cached
conduit even if protocol was changed
Posted by "Daniel Kulp (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237629#comment-13237629 ]
Daniel Kulp commented on CXF-4154:
----------------------------------
I'm testing a different fix today. Hopefully will commit on monday.
> AbstractConduitSelector reused cached conduit even if protocol was changed
> --------------------------------------------------------------------------
>
> Key: CXF-4154
> URL: https://issues.apache.org/jira/browse/CXF-4154
> Project: CXF
> Issue Type: Bug
> Components: Core
> Reporter: Andrei Shakirin
> Attachments: AbstractConduitSelector.patch
>
>
> Hi,
> Actually AbstractConduitSelector.getSelectedConduit() creates and caches conduit in selectedConduit variable. Cached conduit is reused by the next calls.
> I see the following problem: if user changed protocol in URI between calls, AbstractConduitSelector still uses cached Conduit even it cannot process new URL. In my case cached HTTP consuit tries to process UDP URL.
> Proposal for fix: check if protocol in URL was changed and if yes, close and reset selectedConduit.
> Patch is attached.
> Regards,
> Andrei.
--
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] [Updated] (CXF-4154) AbstractConduitSelector reused cached
conduit even if protocol was changed
Posted by "Andrei Shakirin (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrei Shakirin updated CXF-4154:
---------------------------------
Attachment: AbstractConduitSelector.patch
Patch
> AbstractConduitSelector reused cached conduit even if protocol was changed
> --------------------------------------------------------------------------
>
> Key: CXF-4154
> URL: https://issues.apache.org/jira/browse/CXF-4154
> Project: CXF
> Issue Type: Bug
> Components: Core
> Reporter: Andrei Shakirin
> Attachments: AbstractConduitSelector.patch
>
>
> Hi,
> Actually AbstractConduitSelector.getSelectedConduit() creates and caches conduit in selectedConduit variable. Cached conduit is reused by the next calls.
> I see the following problem: if user changed protocol in URI between calls, AbstractConduitSelector still uses cached Conduit even it cannot process new URL. In my case cached HTTP consuit tries to process UDP URL.
> Proposal for fix: check if protocol in URL was changed and if yes, close and reset selectedConduit.
> Patch is attached.
> Regards,
> Andrei.
--
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] [Commented] (CXF-4154) AbstractConduitSelector reused cached
conduit even if protocol was changed
Posted by "Andrei Shakirin (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237564#comment-13237564 ]
Andrei Shakirin commented on CXF-4154:
--------------------------------------
Yep, you are right. Case is a little bit exotic, but anyway - patch is not safe.
I am going to fix it in the following way: provide a thread safe cache map for the conduits with protocol as key. In getSelectedConduit() check map first and create new conduit only if it is not cached for requested protocol. In close() release all conduits from the map. Patch will be improved soon.
> AbstractConduitSelector reused cached conduit even if protocol was changed
> --------------------------------------------------------------------------
>
> Key: CXF-4154
> URL: https://issues.apache.org/jira/browse/CXF-4154
> Project: CXF
> Issue Type: Bug
> Components: Core
> Reporter: Andrei Shakirin
> Attachments: AbstractConduitSelector.patch
>
>
> Hi,
> Actually AbstractConduitSelector.getSelectedConduit() creates and caches conduit in selectedConduit variable. Cached conduit is reused by the next calls.
> I see the following problem: if user changed protocol in URI between calls, AbstractConduitSelector still uses cached Conduit even it cannot process new URL. In my case cached HTTP consuit tries to process UDP URL.
> Proposal for fix: check if protocol in URL was changed and if yes, close and reset selectedConduit.
> Patch is attached.
> Regards,
> Andrei.
--
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-4154) AbstractConduitSelector reused cached
conduit even if protocol was changed
Posted by "Daniel Kulp (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Kulp resolved CXF-4154.
------------------------------
Resolution: Fixed
Fix Version/s: 2.6
Assignee: Daniel Kulp
> AbstractConduitSelector reused cached conduit even if protocol was changed
> --------------------------------------------------------------------------
>
> Key: CXF-4154
> URL: https://issues.apache.org/jira/browse/CXF-4154
> Project: CXF
> Issue Type: Bug
> Components: Core
> Reporter: Andrei Shakirin
> Assignee: Daniel Kulp
> Fix For: 2.6
>
> Attachments: AbstractConduitSelector.patch
>
>
> Hi,
> Actually AbstractConduitSelector.getSelectedConduit() creates and caches conduit in selectedConduit variable. Cached conduit is reused by the next calls.
> I see the following problem: if user changed protocol in URI between calls, AbstractConduitSelector still uses cached Conduit even it cannot process new URL. In my case cached HTTP consuit tries to process UDP URL.
> Proposal for fix: check if protocol in URL was changed and if yes, close and reset selectedConduit.
> Patch is attached.
> Regards,
> Andrei.
--
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] [Commented] (CXF-4154) AbstractConduitSelector reused cached
conduit even if protocol was changed
Posted by "Daniel Kulp (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238446#comment-13238446 ]
Daniel Kulp commented on CXF-4154:
----------------------------------
Committed a fix last night that pretty much removes the "selectedConduit" field and keeps a list of conduits. Under normal operation, that's a single conduit, but it can "grow" as additional protocols and such require it.
Because of the field removal, not back portable to <=2.5.x. Will need to be release noted.
Can you give it a quick spin to make sure it works OK?
> AbstractConduitSelector reused cached conduit even if protocol was changed
> --------------------------------------------------------------------------
>
> Key: CXF-4154
> URL: https://issues.apache.org/jira/browse/CXF-4154
> Project: CXF
> Issue Type: Bug
> Components: Core
> Reporter: Andrei Shakirin
> Attachments: AbstractConduitSelector.patch
>
>
> Hi,
> Actually AbstractConduitSelector.getSelectedConduit() creates and caches conduit in selectedConduit variable. Cached conduit is reused by the next calls.
> I see the following problem: if user changed protocol in URI between calls, AbstractConduitSelector still uses cached Conduit even it cannot process new URL. In my case cached HTTP consuit tries to process UDP URL.
> Proposal for fix: check if protocol in URL was changed and if yes, close and reset selectedConduit.
> Patch is attached.
> Regards,
> Andrei.
--
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] [Commented] (CXF-4154) AbstractConduitSelector reused cached
conduit even if protocol was changed
Posted by "Andrei Shakirin (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238505#comment-13238505 ]
Andrei Shakirin commented on CXF-4154:
--------------------------------------
Just tested with my use case - your fix works!
Only snapshoot in findCompatibleConduit() I did not completely understand:
for (Conduit c2 : conduits) {
if (c2.getTarget() == null
|| c2.getTarget().getAddress() == null
|| c2.getTarget().getAddress().getValue() == null) {
return c2;
}
}
Does conduit with not initialized target endpoint make sense at all? AbstractConduit constructor requires target endpoint argument, of course it is possible to give null there - but is there any use case for it?
Do you think it is legal to choose such conduit if there is no another one that fit better (regarding protocol or full URL)?
I would propose just return null in findCompatibleConduit() for this case and re-initialse conduit.
> AbstractConduitSelector reused cached conduit even if protocol was changed
> --------------------------------------------------------------------------
>
> Key: CXF-4154
> URL: https://issues.apache.org/jira/browse/CXF-4154
> Project: CXF
> Issue Type: Bug
> Components: Core
> Reporter: Andrei Shakirin
> Attachments: AbstractConduitSelector.patch
>
>
> Hi,
> Actually AbstractConduitSelector.getSelectedConduit() creates and caches conduit in selectedConduit variable. Cached conduit is reused by the next calls.
> I see the following problem: if user changed protocol in URI between calls, AbstractConduitSelector still uses cached Conduit even it cannot process new URL. In my case cached HTTP consuit tries to process UDP URL.
> Proposal for fix: check if protocol in URL was changed and if yes, close and reset selectedConduit.
> Patch is attached.
> Regards,
> Andrei.
--
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] [Commented] (CXF-4154) AbstractConduitSelector reused cached
conduit even if protocol was changed
Posted by "Andrei Shakirin (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13237823#comment-13237823 ]
Andrei Shakirin commented on CXF-4154:
--------------------------------------
Ok, very curious to see how you fixed it.
> AbstractConduitSelector reused cached conduit even if protocol was changed
> --------------------------------------------------------------------------
>
> Key: CXF-4154
> URL: https://issues.apache.org/jira/browse/CXF-4154
> Project: CXF
> Issue Type: Bug
> Components: Core
> Reporter: Andrei Shakirin
> Attachments: AbstractConduitSelector.patch
>
>
> Hi,
> Actually AbstractConduitSelector.getSelectedConduit() creates and caches conduit in selectedConduit variable. Cached conduit is reused by the next calls.
> I see the following problem: if user changed protocol in URI between calls, AbstractConduitSelector still uses cached Conduit even it cannot process new URL. In my case cached HTTP consuit tries to process UDP URL.
> Proposal for fix: check if protocol in URL was changed and if yes, close and reset selectedConduit.
> Patch is attached.
> Regards,
> Andrei.
--
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] [Issue Comment Edited] (CXF-4154) AbstractConduitSelector
reused cached conduit even if protocol was changed
Posted by "Andrei Shakirin (Issue Comment Edited) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238505#comment-13238505 ]
Andrei Shakirin edited comment on CXF-4154 at 3/26/12 3:52 PM:
---------------------------------------------------------------
Just tested with my use case - your fix works!
Only snapshoot in findCompatibleConduit() I did not completely understand:
{code}
for (Conduit c2 : conduits) {
if (c2.getTarget() == null
|| c2.getTarget().getAddress() == null
|| c2.getTarget().getAddress().getValue() == null) {
return c2;
}
}
{code}
Does conduit with not initialized target endpoint make sense at all? AbstractConduit constructor requires target endpoint argument, of course it is possible to give null there - but is there any use case for it?
Do you think it is legal to choose such conduit if there is no another one that fit better (regarding protocol or full URL)?
I would propose just return null in findCompatibleConduit() for this case and re-initialse conduit.
was (Author: ashakirin):
Just tested with my use case - your fix works!
Only snapshoot in findCompatibleConduit() I did not completely understand:
for (Conduit c2 : conduits) {
if (c2.getTarget() == null
|| c2.getTarget().getAddress() == null
|| c2.getTarget().getAddress().getValue() == null) {
return c2;
}
}
Does conduit with not initialized target endpoint make sense at all? AbstractConduit constructor requires target endpoint argument, of course it is possible to give null there - but is there any use case for it?
Do you think it is legal to choose such conduit if there is no another one that fit better (regarding protocol or full URL)?
I would propose just return null in findCompatibleConduit() for this case and re-initialse conduit.
> AbstractConduitSelector reused cached conduit even if protocol was changed
> --------------------------------------------------------------------------
>
> Key: CXF-4154
> URL: https://issues.apache.org/jira/browse/CXF-4154
> Project: CXF
> Issue Type: Bug
> Components: Core
> Reporter: Andrei Shakirin
> Attachments: AbstractConduitSelector.patch
>
>
> Hi,
> Actually AbstractConduitSelector.getSelectedConduit() creates and caches conduit in selectedConduit variable. Cached conduit is reused by the next calls.
> I see the following problem: if user changed protocol in URI between calls, AbstractConduitSelector still uses cached Conduit even it cannot process new URL. In my case cached HTTP consuit tries to process UDP URL.
> Proposal for fix: check if protocol in URL was changed and if yes, close and reset selectedConduit.
> Patch is attached.
> Regards,
> Andrei.
--
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] [Commented] (CXF-4154) AbstractConduitSelector reused cached
conduit even if protocol was changed
Posted by "Daniel Kulp (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13238515#comment-13238515 ]
Daniel Kulp commented on CXF-4154:
----------------------------------
It is a valid use case. Using the UpfrontConduitSelector, an application could configure in a conduit that "protocol less" or similar that is not specific to a target. As an example, an ESB, instead of creating a conduit for each protocol, could just configure in a "SuperDoEverythingConduit" singleton or similar that is not target specific. We do want to allow that type of thing. (and there is a test that hits it which is why I added that check) :-)
Anyway, thanks for verifying that the fix works.
> AbstractConduitSelector reused cached conduit even if protocol was changed
> --------------------------------------------------------------------------
>
> Key: CXF-4154
> URL: https://issues.apache.org/jira/browse/CXF-4154
> Project: CXF
> Issue Type: Bug
> Components: Core
> Reporter: Andrei Shakirin
> Fix For: 2.6
>
> Attachments: AbstractConduitSelector.patch
>
>
> Hi,
> Actually AbstractConduitSelector.getSelectedConduit() creates and caches conduit in selectedConduit variable. Cached conduit is reused by the next calls.
> I see the following problem: if user changed protocol in URI between calls, AbstractConduitSelector still uses cached Conduit even it cannot process new URL. In my case cached HTTP consuit tries to process UDP URL.
> Proposal for fix: check if protocol in URL was changed and if yes, close and reset selectedConduit.
> Patch is attached.
> Regards,
> Andrei.
--
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] [Commented] (CXF-4154) AbstractConduitSelector reused cached
conduit even if protocol was changed
Posted by "Daniel Kulp (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-4154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13236944#comment-13236944 ]
Daniel Kulp commented on CXF-4154:
----------------------------------
There is a threading problem with the proposal that I definitely need to think more about. If two threads are making requests, one of which changes the protocol, it can close the conduit used by the other thread prematurely.
> AbstractConduitSelector reused cached conduit even if protocol was changed
> --------------------------------------------------------------------------
>
> Key: CXF-4154
> URL: https://issues.apache.org/jira/browse/CXF-4154
> Project: CXF
> Issue Type: Bug
> Components: Core
> Reporter: Andrei Shakirin
> Attachments: AbstractConduitSelector.patch
>
>
> Hi,
> Actually AbstractConduitSelector.getSelectedConduit() creates and caches conduit in selectedConduit variable. Cached conduit is reused by the next calls.
> I see the following problem: if user changed protocol in URI between calls, AbstractConduitSelector still uses cached Conduit even it cannot process new URL. In my case cached HTTP consuit tries to process UDP URL.
> Proposal for fix: check if protocol in URL was changed and if yes, close and reset selectedConduit.
> Patch is attached.
> Regards,
> Andrei.
--
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