You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Christian Schneider (JIRA)" <ji...@apache.org> on 2008/12/06 11:19:44 UTC

[jira] Created: (CXF-1933) jms transport: Handling client restart in async request / reply case

jms transport: Handling client restart in async request / reply case
--------------------------------------------------------------------

                 Key: CXF-1933
                 URL: https://issues.apache.org/jira/browse/CXF-1933
             Project: CXF
          Issue Type: New Feature
          Components: Transports
    Affects Versions: 2.1.3
            Reporter: Christian Schneider
             Fix For: 2.1.4


Imagine the following scenario:
- Client sends request (e.g. to create an object on the server db). It expects the reply on a reply queue
- Client goes down and is restarted
- Server creates the object and returns success and an identifier for the object
- Client receives the reply but discards it as it has no matching corraltion id
=> So the information gets lost. I this case this is bad as the client can not just retry the operation

I could imaginge the following solution:
- Client is compiled with an async front end. So it listens for replies on a handler method
- The client sends the reuest with reply to set to a permanent reply queue (temp queue would not make sense here)
- Client goes down and is restarted
- Server creates the object and returns success and an identifier for the object
- Client receives the reply. The correlation matching is turned off and the client correctly handles the reply
=> Information will never be lost (at least if combined with jms transactions)
Another advantage of this approach is that a reply can be handled by another instance of the client. 

So what I think has to be done:
- Add a config setting to turn on or off correltation matching
- Check if an uncorrelated reply can be handled by the other parts of CXF. Does someone know if this should work?

So what do you think?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (CXF-1933) jms transport: Handling client restart in async request / reply case

Posted by "Christian Schneider (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CXF-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christian Schneider updated CXF-1933:
-------------------------------------

    Fix Version/s:     (was: 2.1.4)
                   2.2

> jms transport: Handling client restart in async request / reply case
> --------------------------------------------------------------------
>
>                 Key: CXF-1933
>                 URL: https://issues.apache.org/jira/browse/CXF-1933
>             Project: CXF
>          Issue Type: New Feature
>          Components: Transports
>    Affects Versions: 2.1.3
>            Reporter: Christian Schneider
>             Fix For: 2.2
>
>
> Imagine the following scenario:
> - Client sends request (e.g. to create an object on the server db). It expects the reply on a reply queue
> - Client goes down and is restarted
> - Server creates the object and returns success and an identifier for the object
> - Client receives the reply but discards it as it has no matching corraltion id
> => So the information gets lost. I this case this is bad as the client can not just retry the operation
> I could imaginge the following solution:
> - Client is compiled with an async front end. So it listens for replies on a handler method
> - The client sends the reuest with reply to set to a permanent reply queue (temp queue would not make sense here)
> - Client goes down and is restarted
> - Server creates the object and returns success and an identifier for the object
> - Client receives the reply. The correlation matching is turned off and the client correctly handles the reply
> => Information will never be lost (at least if combined with jms transactions)
> Another advantage of this approach is that a reply can be handled by another instance of the client. 
> So what I think has to be done:
> - Add a config setting to turn on or off correltation matching
> - Check if an uncorrelated reply can be handled by the other parts of CXF. Does someone know if this should work?
> So what do you think?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (CXF-1933) jms transport: Handling client restart in async request / reply case

Posted by "Christian Schneider (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/CXF-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12654049#action_12654049 ] 

Christian Schneider commented on CXF-1933:
------------------------------------------

Forgot to add the link to the mailing list where the problem came up:
http://www.nabble.com/jms-client-restart-td20853766.html

> jms transport: Handling client restart in async request / reply case
> --------------------------------------------------------------------
>
>                 Key: CXF-1933
>                 URL: https://issues.apache.org/jira/browse/CXF-1933
>             Project: CXF
>          Issue Type: New Feature
>          Components: Transports
>    Affects Versions: 2.1.3
>            Reporter: Christian Schneider
>             Fix For: 2.1.4
>
>
> Imagine the following scenario:
> - Client sends request (e.g. to create an object on the server db). It expects the reply on a reply queue
> - Client goes down and is restarted
> - Server creates the object and returns success and an identifier for the object
> - Client receives the reply but discards it as it has no matching corraltion id
> => So the information gets lost. I this case this is bad as the client can not just retry the operation
> I could imaginge the following solution:
> - Client is compiled with an async front end. So it listens for replies on a handler method
> - The client sends the reuest with reply to set to a permanent reply queue (temp queue would not make sense here)
> - Client goes down and is restarted
> - Server creates the object and returns success and an identifier for the object
> - Client receives the reply. The correlation matching is turned off and the client correctly handles the reply
> => Information will never be lost (at least if combined with jms transactions)
> Another advantage of this approach is that a reply can be handled by another instance of the client. 
> So what I think has to be done:
> - Add a config setting to turn on or off correltation matching
> - Check if an uncorrelated reply can be handled by the other parts of CXF. Does someone know if this should work?
> So what do you think?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.