cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Schneider (JIRA)" <j...@apache.org>
Subject [jira] Updated: (CXF-1933) jms transport: Handling client restart in async request / reply case
Date Sun, 01 Feb 2009 22:27:59 GMT

     [ 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.


Mime
View raw message