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

["Daniel Kulp (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CXF-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Kulp resolved CXF-1933.
------------------------------

       Resolution: Won't Fix
    Fix Version/s: Invalid


This improvement request has been open for years and no-one has stepped up to implement it. As such, it does not seems to be a priority for the existing CXF community. If, in the future, someone would like to tackle this, feel free to open is and attach a patch.

> 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: Invalid
>
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira