SOAPProcessor strange behavior

[johan.kumps]

Hi,

I'm currently having a strange issue with the SOAPProcessor.

Using SOAPUI I send request A to an ESB actions chain published as a Web Service. Whitin this chain I do some transformations using the XSLTAction. When I send a request I get the correct response, sending the message again returns the request again, sending the same request again I get the correct response and so on.

Does anybody recognize this behavior?

Thanks in advance for helping me out.

Johan,

[kconner]

Sounds very strange, almost as if you have multiple services sending replies.  Can you attach your jboss-esb.xml?

[johan.kumps]

Indeed very strange. This is my jboss-esb.xml :

<?xml version = "1.0" encoding = "UTF-8"?>
<jbossesb
    xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.2.0.xsd"
    parameterReloadSecs="5">

    <providers>
        <jms-provider name="JBossMQ" connection-factory="ConnectionFactory">
            <jms-bus busid="wims-sws-purchase-order-mediationEsbChannel">
                <jms-message-filter dest-type="QUEUE"
                    dest-name="queue/SellerServiceProxy_Request_esb" selector="serviceName='SellerServiceProxy'" />
            </jms-bus>
            <jms-bus busid="wims-sws-purchase-order-mediationEsbChannel">
                <jms-message-filter dest-type="QUEUE"
                    dest-name="queue/POResponseService_Request_esb" selector="serviceName='POResponseService'" />
            </jms-bus>
        </jms-provider>
    </providers>

    <services>
        <service category="PurchaseOrderMediation" name="SellerServiceProxy"
            description="Proxy for the SellerService (Customer facing)">
            <listeners>
                <jms-listener name="SellerServiceProxy"
                    busidref="wims-sws-purchase-order-mediationEsbChannel" maxThreads="10" />
            </listeners>
            <actions inXsd="/3A4_Simplified_PurchaseOrderRequest.xsd"
                outXsd="/3A4_Simplified_PurchaseOrderConfirmation.xsd" faultXsd="/fault.xsd"
                validate="false">
                <action name="print-before-req-xform" class="org.jboss.soa.esb.actions.SystemPrintln">
                    <property name="message" value="[xform_Pip3A4PurchaseOrderRequest_to_RDF] Message before transformation" />
                </action>
                <action name="xform_Pip3A4PurchaseOrderRequest_to_RDF"
                    class="org.jboss.soa.esb.actions.transformation.xslt.XsltAction">
                    <property name="templateFile" value="/xform/Pip3A4PurchaseOrderRequest_to_RDF.xsl"/>
                    <property name="failOnWarning" value="true"/>
                     <property name="resultType" value="STRING"/>
                </action>
                <action name="print-after-req-xform" class="org.jboss.soa.esb.actions.SystemPrintln">
                    <property name="message" value="[xform_Pip3A4PurchaseOrderRequest_to_RDF] Message after transformation" />
                </action>
               
                <action name="service-invocation" class="org.moon.purchasing.mediation.SellerServiceInvocationAction" process="invoke">
                   
                </action>
                               
                <action name="print-before-res-xform" class="org.jboss.soa.esb.actions.SystemPrintln">
                    <property name="message" value="[xform_RDF_to_Pip3A4PurchaseOrderConfirmation] Message before transformation" />
                </action>
                <action name="xform_RDF_to_Pip3A4PurchaseOrderConfirmation"
                    class="org.jboss.soa.esb.actions.transformation.xslt.XsltAction">
                    <property name="templateFile" value="/xform/RDF_to_Pip3A4PurchaseOrderConfirmation.xsl"/>
                    <property name="failOnWarning" value="true"/>
                     <property name="resultType" value="STRING"/>
                </action>
                <action name="print-after-res-xform" class="org.jboss.soa.esb.actions.SystemPrintln">
                    <property name="message" value="[xform_RDF_to_Pip3A4PurchaseOrderConfirmation] Message after transformation" />
                </action>
            </actions>
        </service>

        <service category="PurchaseOrderMediation" name="POResponseService"
            description="POResponseService used by Moon legacy to send Line Item comfirmation messages to.">
            <listeners>
                <jms-listener name="POResponseService"
                    busidref="wims-sws-purchase-order-mediationEsbChannel" maxThreads="1" />
            </listeners>
            <actions inXsd="/POResponse-request.xsd"
                outXsd="/POResponse-response.xsd" faultXsd="/fault.xsd"
                validate="false">
                <action name="action"
                    class="org.moon.purchasing.POResponseServiceAction"
                    process="confirmLineItem" />
            </actions>
        </service>
    </services>

</jbossesb>

Please refer to the SellerServiceProxy service.

It indeed seams like their is some loadbalancing and some inconsistent deployments on different nodes but this can not be the case because I'm working single node, so no load balancing, nor clustering.

Johan,

[johan.kumps]

I can even reproduce the issue when having only a SystemPrintln action in my pipeline. Even when having validate set to true and having an action returning an invalid response message according to the XSD, I get alternating responses (request, validation failure msg, request, validation failure msg, ...)

I do not see what I'm doing wrong. Can I debug somewhere?

[kconner]

Looks like the busids are the same, which we obviously are not picking up on, and both services are listening to it.

[johan.kumps]

Hi Kevin,

The busid are indeed the same in the jboss-esb.xml I send you. I altered it and it's working correct now.

Is this something I misunderstood? Does the busid need to be unique? I thought the queuename was making things unique.

[kconner]

The busids should be unique within a jboss-esb.xml, we should be detecting duplicates but are obviously not (this is a bug).

Both services were listening to the same source (bus), hence the behaviour you have seen.

[johan.kumps]

Thanks Kevin,

I will keep this in mind! Should I file a Jira issue for this or do you do it?

Johan,

[kconner]

If you could create the issue, it would be appreciated.

Thanks