[adinn]

Mauro Molinari wrote:

this is not enough, indeed. To make the ParticipantRecoveryInitialisation to execute (which is the one that sets that recovery manager instance) I have to also uncomment the ParticipantSideInitialisation in xts-properties.xml.

Hmm, I am not sure exactly what you tried nor whether it is what I was suggesting. What you need is for the coordinator side initialisation routine to install the ATParticipantRecoveryModule. This means you need to add it to the list of coordinator recovery modules. The normal settings add it to the list of participant recovery modules. So, if you are using the beans.xml you would set the config as follows:

<property name="coordinatorRecoveryModules">
            <list elementClass="java.lang.String">
                <value>org.jboss.jbossts.xts.recovery.participant.at.ATParticipantRecoveryModule</value>               
                <value>org.jboss.jbossts.xts.recovery.coordinator.at.ATCoordinatorRecoveryModule</value>
                <value>org.jboss.jbossts.xts.recovery.coordinator.at.SubordinateATCoordinatorRecoveryModule</value>
                <value>org.jboss.jbossts.xts.recovery.coordinator.ba.BACoordinatorRecoveryModule</value>
                <value>org.jboss.jbossts.xts.recovery.coordinator.ba.SubordinateBACoordinatorRecoveryModule</value>
            </list>
</property

If you are using a property file to define the settings you need to  use this

<entry key="org.jboss.jbossts.xts.recovery.coordinatorRecoveryModule1">org.jboss.jbossts.xts.recovery.participant.at.ATParticipantRecoveryModule</entry>
<entry key="org.jboss.jbossts.xts.recovery.coordinatorRecoveryModule2">org.jboss.jbossts.xts.recovery.coordinator.at.ATCoordinatorRecoveryModule</entry>
<entry key="org.jboss.jbossts.xts.recovery.coordinatorRecoveryModule3">org.jboss.jbossts.xts.recovery.coordinator.at.SubordinateATCoordinatorRecoveryModule</entry>
<entry key="org.jboss.jbossts.xts.recovery.coordinatorRecoveryModule4">org.jboss.jbossts.xts.recovery.coordinator.ba.BACoordinatorRecoveryModule</entry>
<entry key="org.jboss.jbossts.xts.recovery.coordinatorRecoveryModule5">org.jboss.jbossts.xts.recovery.coordinator.ba.SubordinateBACoordinatorRecoveryModule</entry>

The coordinator side initialisation installs each entry in this list in order. So, the participant module needs to be the first one in the beans list (or have a key which sorts first if you are using properties.

Mauro Molinari wrote:

Anyway, I have a doubt on the synchronization: the whole thing seems to work even if I uncomment the ParticipantSideInitialisation but I leave the definition of ATParticipantRecoveryModule AFTER that of the Coordinator recovery modules (like it is in the template xts-properties11.xml found in xts/config folder of the source distribution).

I think this is because the whole initialisation takes place in one thread, while the periodic recovery happens in another. So, the only requirement is that the initialisation has finished BEFORE the periodic recovery thread starts to use the recovery manager. However, my concern is that since this code is not synchronized, in some circumstances the periodic recovery thread may fail even if I move the definition of ATParticipantRecoveryModule before those of the Coordinator recovery modules.

I don't know if I've been sufficiently clear... Maybe I'm totally wrong.

The periodic recovery thread can only execute the recovery module code once the recovery modules have been installed in its module list. So, if it runs before initialisation has been done then it will not finx the modules. If it runs after initialistaion is done or even in the middle  of initialisation) then the module install method will have been called before the recovery thread is able to access the module. Here is the code from class CoordinatorRecoveryInitialisation:

        try {
            XTSRecoveryModule module = (XTSRecoveryModule)clazz.newInstance();
            module.install();
            RecoveryManager.manager().addModule(module);
            recoveryModules.add(module);
        } catch (InstantiationException ie) {
            RecoveryLogger.i18NLogger.error_recovery_coordinator_CoordinatorRecoveryInitialisation_3(className, ie);
        } catch (IllegalAccessException iae) {
            RecoveryLogger.i18NLogger.error_recovery_coordinator_CoordinatorRecoveryInitialisation_4(className, iae);
        }

So, as long as you place the AT participant recovery module first in the coordinator's recovery list the AT recovery manager will get created before any of the AT recovery modules can be executed by the periodic recovery thread.

[adinn]

Mauro Molinari wrote:

Anyway, I think I'm at a good point now: the error I get when I try to launch a servlet which acts as a client to a webservice (and uses transaction demarcation through XTS) is the following:

AVVERTENZA: Interceptor for {http://docs.oasis-open.org/ws-tx/wscoor/2006/06}ActivationService#{http://docs.oasis-open.org/ws-tx/wscoor/2006/06}CreateCoordinationContextOperation has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: Could not send Message.
 ... 
Caused by: java.io.IOException: IOException invoking http://ws-mauro.ost.lan:8080/ws-c11/ActivationService: HTTP response '404: Not Found'
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) 
 ...
Caused by: java.io.IOException: HTTP response '404: Not Found' 
 ...

which means I need to configure the WSDL endpoint URL of the ActivationService. Unfortunately, I can't go futher with my experiments until this is doable.

Well, that's pretty good going and it looks like it will not take much to get the fixes you need into trunk. Thank you for persevering with this and congratulations on getting it this close to working.

Can you tell me the actual URL at which your activation and registration coordinator services have been deployed? Can you also provide the addresses at which the participant services have been deployed?

regards,

Andrew Dinn

[mauromol]

Andrew Dinn ha scritto:

Can you tell me the actual URL at which your activation and registration coordinator services have been deployed? Can you also provide the addresses at which the participant services have been deployed?

Hi Andrew,

I have three webapps, called xts-client, xts-server (the participant) and xts-coord. Every webapp has CXF configured so that the CXFServlet responds at /services; in other words you can use the following URLs:

- http://<clientBindAddress>:<clientBindPort>/xts-client/services => to list the services deployed on the Client

- http://<participantBindAddress>:<participantBindPort>/xts-server/services => to list the services deployed on the Participant

- http://<coordinatorBindAddress>:<coordinatorBindPort>/xts-coord/services => to list the services deployed on the Coordinator

Then I configured the needed WS-C and WS-AT services to be exposed at the following endpoint URLs:

- http://<clientBindAddress>:<clientBindPort>/xts-client/services/CompletionInitiatorService

- http://<participantBindAddress>:<participantBindPort>/xts-server/services/ParticipantService

- http://<coordinatorBindAddress>:<coordinatorBindPort>/xts-coord/services/CompletionCoordinatorService

- http://<coordinatorBindAddress>:<coordinatorBindPort>/xts-coord/services/CoordinatorService

- http://<coordinatorBindAddress>:<coordinatorBindPort>/xts-coord/services/ActivationService

- http://<coordinatorBindAddress>:<coordinatorBindPort>/xts-coord/services/RegistrationService

Mauro.

[adinn]

Hi Mauro,

I have fixed and closed all the remaining issues. You should now be able to use the current trunk to run your code.

You can either use properties or injection to specify the end point mappings for WS-C coordinator services and WS-T client, coordinator and participant services. See the comments in config/properties11.xml or sar/META-INF/xts11-jboss-beans.xml for an example of how to reset the URL path component.

regards,

Andrew Dinn

[mauromol]

I have seen the updates in JIRA, thank you very much! :-)

I hope to be able to test the new code soon!

I'll let you know.

Mauro.