Re: [mule-user] Upgrade from 1.3-rc4 to 1.3.3 FileConnector problem.

[kenneth.w...@telenet.be]

Since you're running it inside eclipse, have you tried debugging? There's a mail from me on this list indicating that some runtime exceptions are not handled properly and are not logged. Maybe there's a jar missing in your classpath resulting in NoClassDefFoundErrors that might not get logged.

---------------------------------------------------------------------
To unsubscribe from this list please visit:

http://xircles.codehaus.org/manage_email

[qwilson]

Kenny,

I could not find any exceptions that were not getting logged, I stepped
through the code and the difference is in the
org.mule.impl.model.AbstractComponent class. In the start method is where I
got to and noticed a big difference.

Here is the code

org.mule.impl.model.AbstractComponent

1.3.-RC4
public void start() throws UMOException {
if (stopped.get()) {
stopped.set(false);
doStart();
}
fireComponentNotification(ComponentNotification.COMPONENT_STARTED);
}

1.3.3

public void start() throws UMOException
{
start(false);
}

This is where it seems version 1.3.3 just dies off and rc4 start polling.
Looks like maybe the file component need to override or something, just
guessing.

Thanks
Quince

--
View this message in context: http://www.nabble.com/Upgrade-from-1.3-rc4-to-1.3.3-FileConnector-problem.-tf3305191.html#a9205461
Sent from the Mule - User mailing list archive at Nabble.com.

[kenneth.w...@telenet.be]

Do your files match the filter pattern: *.nmon
Please note, this is very case sensitive.

[m.r...@enbw.com]

Hi,

We're trying to handle a synchronous request (WS call) involving two Mule
instances and a JMS queue. The setup should work like this:

WS client -> Mule 1 -> JMS queue -> Mule 2 -> external WS

Obviously the result of the "external WS" call has to be returned to the
client who initiated the request. This doesn't seem to work with our current
Mule configuration as long as JMS is involved. HTTP-only *did* work,
however, using this configuration:

Mule 1:

<mule-descriptor name="DEMO_WS"
implementation="org.mule.components.simple.BridgeComponent">
<inbound-router>
<!--
<endpoint address="jms://testqueue" synchronous="true"/>
-->
<endpoint address="http://mule1:8081/DEMO_WS" synchronous="true"/>
</inbound-router>
<outbound-router>
<router className="org.mule.routing.outbound.OutboundPassThroughRouter">
<endpoint address="http://mule2:8082/DEMO_WS" synchronous="true"/>
</router>
</outbound-router>
</mule-descriptor>

Mule 2:

<mule-descriptor name="DEMO_WS"
implementation="org.mule.components.simple.BridgeComponent">
<inbound-router>
<endpoint address="http://0.0.0.0:8082/DEMO_WS" synchronous="true"/>
</inbound-router>
<outbound-router>
<router className="org.mule.routing.outbound.OutboundPassThroughRouter">
<!--
<endpoint address="jms://testqueue" synchronous="true"/>
-->
<endpoint address="http://external.host:8083/EXTERNAL_WS"
synchronous="true"/>
</router>
</outbound-router>
</mule-descriptor>

We assumed that changing Mule 1 outbound / Mule 2 inbound to something like
"jms://testqueue" would be all that's required to make the two Mules
communicate using JMS. Routing is OK up to the point when the response
should be sent back to the client, which is when this exception is thrown:

org.codehaus.xfire.XFireRuntimeException: Could not invoke service.. Nested
exception is org.codehaus.xfire.fault.XFireFault: Unexpected EOF in prolog
at [row,col {unknown-source}]: [1,0]
org.codehaus.xfire.fault.XFireFault: Unexpected EOF in prolog
at [row,col {unknown-source}]: [1,0]
at
org.codehaus.xfire.fault.XFireFault.createFault(XFireFault.java:89)
at org.codehaus.xfire.client.Client.onReceive(Client.java:386)

I realize that this is an XFire-Exception but as far as the debugger shows,
it occurs because null is returned to the client.

What would we have to change in order to achieve synchronous communication
over JMS? According to the documentation the synchronous-flag should enable
request-response, i.e. automatically set up a temporary queue for the
response. Is remoteSync required here? The documentation is a bit unclear on
this, so any help is appreciated.

Regards,
Michael

[Andrew Perepelytsya]

JMS synchronous request-response would only work for non-transacted cases, remoteSync will be disabled forcefully if a TX is detected (simply because it's impossible to do anything with such a config).

For JMS try reconfiguring it to use async but with a SingleResponseAggregator, for example. That would still look like a sync call to the client, with aggregator timeout acting as a general request timeout.

Andrew

[qwilson]

Yes, the filter can also be removed with the same issue.

I have also been trying differant versions, 1.3 is fine, but 1.3.1 complains
of a legacy style descriptor. Currently trying to figure out what is
"legacy" about the descriptor.

Thanks

--
View this message in context: http://www.nabble.com/Upgrade-from-1.3-rc4-to-1.3.3-FileConnector-problem.-tf3305191.html#a9206926

Sent from the Mule - User mailing list archive at Nabble.com.

[qwilson]

Another intersting point,
1.3 ok
1.3.1 complains of legacy config
1.3.2 ok
1.3.3 just sits there

all versions running the exact same config, I just switch out the references
lib for the other version.

Thanks
Quince

qwilson wrote:
>
> Yes, the filter can also be removed with the same issue.
>
> I have also been trying differant versions, 1.3 is fine, but 1.3.1
> complains of a legacy style descriptor. Currently trying to figure out
> what is "legacy" about the descriptor.
>
> Thanks
>
>
>
> kennywest wrote:
>>
>> Do your files match the filter pattern: *.nmon
>> Please note, this is very case sensitive.
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>

--
View this message in context: http://www.nabble.com/Upgrade-from-1.3-rc4-to-1.3.3-FileConnector-problem.-tf3305191.html#a9207323

[qwilson]

Finally got it to run but have to be root. I will start a new message for
this.

qwilson wrote:
>
> Another intersting point,
> 1.3 ok
> 1.3.1 complains of legacy config
> 1.3.2 ok
> 1.3.3 just sits there
>
> all versions running the exact same config, I just switch out the
> references lib for the other version.
>
> Thanks
> Quince
>
>
> qwilson wrote:
>>
>> Yes, the filter can also be removed with the same issue.
>>
>> I have also been trying differant versions, 1.3 is fine, but 1.3.1
>> complains of a legacy style descriptor. Currently trying to figure out
>> what is "legacy" about the descriptor.
>>
>> Thanks
>>
>>
>>
>> kennywest wrote:
>>>
>>> Do your files match the filter pattern: *.nmon
>>> Please note, this is very case sensitive.
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list please visit:
>>>
>>> http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>
>>
>
>

--
View this message in context: http://www.nabble.com/Upgrade-from-1.3-rc4-to-1.3.3-FileConnector-problem.-tf3305191.html#a9239785

[m.r...@enbw.com]

Hi Andrew,

 

Can you please explain, how to achive "JMS synchronous request-response for non-transacted cases".

Is it possible to disable transactions?

 

Regards,

Michael

-----Ursprüngliche Nachricht-----
Von: Andrew Perepelytsya [mailto:aper...@gmail.com]
Gesendet: Mittwoch, 28. Februar 2007 17:13
An: us...@mule.codehaus.org
Betreff: Re: [mule-user] SOAP gateway with JMS

[Andrew Perepelytsya]

Michael,

Try to configure a JMS transaction factory on the endpoint with action NONE.

Andrew

[m.r...@enbw.com]

Hi,

I'm still trying to figure out synchronous communication over JMS (using
Mule 1.3.2). From the documentation (UMOEndpoint / remoteSync):

---------------
For certain providers that support the notion of a backchannel such as
sockets (outputStream) or Jms (ReplyTo) Mule can automatically wait for a
response from a backchannel when dispatching over these protocols
---------------

Could someone provide me with a working example config for the following
scenario:

(HTTP endpoint) Mule 1 ---> JMS queue ---> Mule 2

Incoming requests on Mule 1 have to be forwarded to the queue and received
by Mule 2 (does business logic). The result is returned to Mule 1 via the
queue.

Currently, I'm using a BridgeComponent on Mule 1 in combination with an
OutboundPassThroughRouter/reply-to. Like so:

<mule-descriptor name="M1"
implementation="org.mule.components.simple.BridgeComponent">
<inbound-router>
<endpoint address="http://localhost:8081/m1"

synchronous="true"/>
</inbound-router>
<outbound-router>
<router
className="org.mule.routing.outbound.OutboundPassThroughRouter">

<endpoint address="jms://m1.request" remoteSync="true"
remoteSyncTimeout="10000"/>
<reply-to address="jms://m1.response"/>
</router>
</outbound-router>
</mule-descriptor>

With this configuration the request gets sent to the JMS queue as expected.
The BridgeComponent, however, immediately returns null without even trying
to connect to the response queue. Debugging shows that on Mule 2 the request
is received via JMS, replyTo is set to "jms://m1.response" but nothing gets
sent back to the queue.

To solve the problem on Mule 1, I've added a response-router to the config:

<response-router timeout="10000">
<endpoint address="jms://m1.response"/>
<router className="test.routers.SingleResponseAggregator"/>
</response-router>

Again, no dice.

As the docs mention synchronous communication over JMS a lot, there must be
some obvious mistake in the config. If someone has done this before please
let me know what's wrong with my setup.

[Marie Claire Rizzo]

Hi

I'm looking into your case. I still have to run some more tests however,
so if you need a quick fix you could try creating a pojo which uses the
MuleClient to dispatch on jms://m1.request and receives from
jms://m1.response

--

Marie Rizzo
Ricston Consulting
Tel: +356 21 334457
Fax: +356 21 334457
Skype: marie.rizzo

[Marie Claire Rizzo]

Hi

In order to make the http wait for the JMS reply before sending back to
the client, you need the following:
1.) set remoteSync="true" on the http endpoint.
2.) create a response-router to get the response from the jms queue. Use
this instead of the replyTo. Configure it as shown below.
3.) declare a JMSMessageToObject transformer and set it as a
responseTransformer on the http endpoint.

<transformers>
<transformer name="JMSMessageToObject"
className="org.mule.providers.jms.transformers.JMSMessageToObject"/>
</transformers>

<model name="Mule">
<mule-descriptor name="Service1"
implementation="org.mule.components.simple.EchoComponent">
<inbound-router>
<endpoint address="http://localhost:10901"
remoteSync="true" responseTransformers="JMSMessageToObject"/>
</inbound-router>

<outbound-router>
<router
className="org.mule.routing.outbound.OutboundPassThroughRouter">
<endpoint address="jms://queue1"/>
</router>
</outbound-router>

<response-router timeout="70000">
<endpoint address="jms://queue2"/>
<router
className="org.mule.routing.response.SingleResponseRouter"/>
</response-router>
</mule-descriptor>
</model>

The above configuration worked for me so I hope this helps you in
solving your problem.

Regards
Marie Rizzo