The WS being proxied is composed of a lot of code, so I'd need to take
some time and throw together a test project to provide. In the
meantime, I've noticed a bit more odd behavior. I set up a test case
that only runs one response returning method on the WS. Using the
config you suggested it hangs and the test times out as previously
encountered, However, when Mule gives up I see four WS invocations
logged in my JBoss stdout. I have no explanation for this. Perhaps
Mule is mistakenly firing off multiple requests and due to some
threading issues they get blocked causing the timeout? Then when the
blocking thread gives up the others pass through? That's my
off-the-top-of-the-head idea.
On Mon, Oct 6, 2008 at 2:23 PM, Mohit Manrai <
manrai.java@...> wrote:
>
> I am not sure if it is uncommon but i have faced similar issue while proxying
> a webservice
> deployed on xmethods.com - As it turned out to be it was a firewall issue
> and i had to configure
> http connector to use proxy server for the call. However, in your case as
> original service is on your local system, i am not sure what could be the
> cause.
>
> It would be helpful if you could attach code.
>
>
>
>
>
> redijedi wrote:
>>
>> I tried the set up you suggested and it still hangs. I still get
>> "Content must be set before entity is written" and
>> "java.io.IOException: chunked stream ended unexpectedly" related
>> exceptions in the Mule stdout. I am a little amazed that I'm one of a
>> handful of people experiencing this issue. Is it uncommon to proxy web
>> service calls through mule?
>>
>> On Mon, Oct 6, 2008 at 4:43 AM, Mohit Manrai <
manrai.java@...>
>> wrote:
>>>
>>> Following worked for me :
>>>
>>> <service name="ProxyService">
>>> <inbound>
>>> <inbound-endpoint
>>> address="${proxyService.url}"
>>> remoteSync="true"
>>> synchronous="true" />
>>> </inbound>
>>> <component
>>> class="org.mule.transport.soap.WSProxyService" />
>>> <outbound>
>>> <outbound-pass-through-router>
>>> <outbound-endpoint
>>>
>>> address="${actualService.url}" />
>>> </outbound-pass-through-router>
>>> </outbound>
>>> </service>
>>>
>>> i am using plain http URL's for end points. WSProxyService also returns
>>> the
>>> actual wsdl. The only problem i have seen with above approach is that it
>>> doesn't work too well if query string has something other then ?wsdl. for
>>> ex: if your wsdl has xsd imports soap ui or any other client will report
>>> an
>>> error when it will try to fetch ?xsd=som.xsd from server. If you have
>>> correct soap message above technique should work for you as well.
>>>
>>> Regards,
>>> Mohit Manrai
>>>
>>>
>>>
>>>
>>>
>>> redijedi wrote:
>>>>
>>>> I'm attempting to simply proxy an existing WS for version management,
>>>> etc. At this point all I'm trying to do is simply pass requests from
>>>> the new endpoint to the existing one. I've read this doc
>>>> (
http://www.mulesource.org/display/MULE2USER/Proxying+Web+Services) on
>>>> how to do it, but it's not working out so well. My config is as
>>>> follows:
>>>>
>>>>
>>>> <service name="service">
>>>>
>>>> <inbound>
>>>>
>>>> <cxf:inbound-endpoint
>>>>
>>>> address="
http://localhost:63081/service"
>>>> proxy="true" />
>>>>
>>>> </inbound>
>>>>
>>>>
>>>> <outbound>
>>>>
>>>> <outbound-pass-through-router>
>>>>
>>>> <cxf:outbound-endpoint
>>>>
>>>> address="
http://localhost:8080/service/soap"
>>>> proxy="true" />
>>>>
>>>> </outbound-pass-through-router>
>>>>
>>>> </outbound>
>>>>
>>>> </service>
>>>>
>>>>
>>>> This appears to be inline with the doc. The first thing I noted is
>>>> that it's not presenting the proxied WSDL. The original WSDL at
>>>>
http://localhost:8080/service/soap?wsdl is correct, but the WSDL at
>>>>
http://localhost:63081/service?wsdl refers to the ProxyService and is
>>>> completely different. However, the client can still connect, so I'm
>>>> willing to live with this oddity if I can get this functional even
>>>> though it'd be nice to not have to.
>>>>
>>>> The bigger issue is that when a client that was previously working
>>>> when configured to hit the original service address attempts to use
>>>> the new address it hangs, then times out. Looking at the stdout of
>>>> mule I see that it receives and passes on a request, but immediately
>>>> closing the HTTP connections. It hangs too until it times out. Upon
>>>> timing out, or maybe just before (it happens very quickly) something
>>>> is sent to the original address, but it appears as if no parameters
>>>> are sent. I get output on the stdout of the JBoss instance hosting the
>>>> original service that shows that the correct operation was called, but
>>>> with no arguments.
>>>>
>>>> I've fiddled with all combinations of synchronous and asyncRemote with
>>>> no change.
>>>>
>>>> This is day 2 of trying to solve this. I've already googled the crap
>>>> out of the issue and am officially tired. Any help is greatly
>>>> appreciated.
>>>>
>>>> Thanks,
>>>> T
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>
http://xircles.codehaus.org/manage_email>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>>
http://www.nabble.com/CXF-WS-Proxy-Hangs-tp19801221p19834020.html>>> Sent from the Mule - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>
http://xircles.codehaus.org/manage_email>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>
http://xircles.codehaus.org/manage_email>>
>>
>>
>>
>
> --
> View this message in context:
http://www.nabble.com/CXF-WS-Proxy-Hangs-tp19801221p19843431.html> Sent from the Mule - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>
http://xircles.codehaus.org/manage_email>
>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email