[jira] Updated: (CXF-3114) WS-RM's RMTxStore's does not recover stored sequences after restart

["Aki Yoshida (JIRA)" <ji...@apache.org>]

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

Aki Yoshida updated CXF-3114:
-----------------------------

    Attachment: rt-ws-fixes.zip

Fixes for CXF-3114
2.2.x-fixes

Two svn diff files are included:
rt-ws-rm.txt (svn diff rt/ws/rm)
systests-ws-spec.txt (svn diff systests/ws-spec)

Changes
1. rt/ws/rm
Changed RMTxStore so that it has the correct transaction grouping.
Changed RMManager so that it restores the destination sequences from
the persistence after the server is restarted. 

Previously, the source sequences were restored but the destination
sequences were not. This lead to problems at the server side when
the server is restarted while the client continues to send messages
using the same sequence. This problem was previously not captured by
ServerPersistenceTest as described below.

2. systest/ws/rm
Changed ServerPersistenceTest to check whether the RetransmissionQueue is
empty after the completion of the transmission. Once the message is
queued in the RetransmissionQueue and being retransmitted, the client
receives the Response with status done (Note*). Because of this,
previously ServerPersistenceTest did not capture this error. 

In order to make sure that the messages transmitted after the server's
restart reach the server and are correctly acknowledged, the
RetransmissionQueue's queue size is checked to see whether all
messages have been transmitted and acknowledged.

Note*
The current CXF's behavior is that, when some exception occurs during
the first transmission, the call simply returns without an exception
as the message is queued in the RetransmissionQueue and being
retransmitted. The Response objecet returned to the caller has its
exception attribute set but also the done attribute set. This is the
reason why the previous ServerPersisteceTest didn't catch this error.
We probably should set the done flag only after the transmission of
the message is acknowledged. In this case, we can also rely on this
attribute. But I think it is reasonable to verify the
RetransmissionQueue's state as well in the unit test.


> WS-RM's RMTxStore's does not recover stored sequences after restart
> -------------------------------------------------------------------
>
>                 Key: CXF-3114
>                 URL: https://issues.apache.org/jira/browse/CXF-3114
>             Project: CXF
>          Issue Type: Bug
>         Environment: CXF 2.2.11 with Derby 10.6.2.1
>            Reporter: Aki Yoshida
>            Assignee: Freeman Fang
>         Attachments: rt-ws-fixes.zip
>
>
> When WS-RM's derby storage is activated, the sequence data are persisted in the database.
> However, these sequence data are not loaded from the database when the WS-RM component is restarted.
> This problem appears to be caused by the init method of the persistence class org.apache.cxf.ws.rm.persistence.jdbc.RMTxStore which leaves an uncommitted transaction to the relevant tables open. Consequently, the next select statement that loads the persisted sequence data is not seeing the content.
> The original source code fragment of this method looks like this:
> {code}
>         try {
>             connection.setAutoCommit(false);
>             createTables();
>         } catch (SQLException ex) {
>             LogUtils.log(LOG, Level.SEVERE, "CONNECT_EXC", ex);
>             SQLException se = ex;
>             while (se.getNextException() != null) {
>                 se = se.getNextException();
>                 LogUtils.log(LOG, Level.SEVERE, "CONNECT_EXC", se);
>             }
>             throw new RMStoreException(ex);
>         }   
> {code}
> The suggested change would be as follows:
> {code}
>         try {
>             connection.setAutoCommit(true);
>             createTables();
>         } catch (SQLException ex) {
>             LogUtils.log(LOG, Level.SEVERE, "CONNECT_EXC", ex);
>             SQLException se = ex;
>             while (se.getNextException() != null) {
>                 se = se.getNextException();
>                 LogUtils.log(LOG, Level.SEVERE, "CONNECT_EXC", se);
>             }
>             throw new RMStoreException(ex);
>         } finally {
>             try {
>                 connection.setAutoCommit(false);                
>             } catch (SQLException ex) {
>                 LogUtils.log(LOG, Level.SEVERE, "CONNECT_EXC", ex);
>                 throw new RMStoreException(ex);
>             }
>         }
> {code}
> In the above code, the setAutoCommit(true) statement could be omitted if we simply want to rely on the default autoCommit mode.
> In any case, the suggested code makes sure that the subsequence statement is correctly executed.

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