CXF WS Proxy Hangs

[redijedi]

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

[redijedi]

Here's some of the Mule stdout if it helps:

********************************************************************************

ERROR 2008-10-03 12:08:05,793 [connector.http.0.receiver.4]
org.mule.service.DefaultServiceExceptionStrategy:
********************************************************************************
Message               : Failed to route event via endpoint:
DefaultOutboundEndpoint{endpointUri=http://localhost:8080/service/soap,
connector=HttpConnector{this=26f9e5, started=true, initialised=true,
name='connector.http.0', disposed=false,
numberOfConcurrentTransactedReceivers=4,
createMultipleTransactedReceivers=true, connected=true,
supportedProtocols=[http], serviceOverrides=null},
transformer=[ObjectToHttpClientMethodRequest{this=edbe39, name='null',
ignoreBadInput=false, returnClass=interface
org.apache.commons.httpclient.HttpMethod, sourceTypes=[interface
org.mule.api.MuleMessage, class [B, class java.lang.String, class
java.io.InputStream, interface org.mule.api.transport.OutputHandler,
class org.mule.transport.NullPayload]}],
name='endpoint.http.localhost.8080.service.soap', properties={},
transactionConfig=Transaction{factory=null, action=NEVER, timeout=0},
filter=null, deleteUnacceptedMessages=false, securityFilter=null,
synchronous=true, initialState=started, remoteSync=true,
remoteSyncTimeout=3000, endpointEncoding=UTF-8}. Message payload is of
type: PostMethod
Type                  : org.mule.api.transport.DispatchException
Code                  : MULE_ERROR-42999
JavaDoc               :
http://mule.mulesource.org/docs/apidocs/org/mule/api/transport/DispatchException.html
Payload               : org.apache.commons.httpclient.methods.PostMethod@1dfd90f
********************************************************************************
Exception stack is:
1. Content must be set before entity is written
(java.lang.IllegalStateException)
  org.apache.commons.httpclient.methods.InputStreamRequestEntity:177
(http://java.sun.com/j2se/1.5.0/docs/api/java/lang/IllegalStateException.html)
2. Failed to route event via endpoint:
DefaultOutboundEndpoint{endpointUri=http://localhost:8080/service/soap,
connector=HttpConnector{this=26f9e5, started=true, initialised=true,
name='connector.http.0', disposed=false,
numberOfConcurrentTransactedReceivers=4,
createMultipleTransactedReceivers=true, connected=true,
supportedProtocols=[http], serviceOverrides=null},
transformer=[ObjectToHttpClientMethodRequest{this=edbe39, name='null',
ignoreBadInput=false, returnClass=interface
org.apache.commons.httpclient.HttpMethod, sourceTypes=[interface
org.mule.api.MuleMessage, class [B, class java.lang.String, class
java.io.InputStream, interface org.mule.api.transport.OutputHandler,
class org.mule.transport.NullPayload]}],
name='endpoint.http.localhost.8080.service.soap', properties={},
transactionConfig=Transaction{factory=null, action=NEVER, timeout=0},
filter=null, deleteUnacceptedMessages=false, securityFilter=null,
synchronous=true, initialState=started, remoteSync=true,
remoteSyncTimeout=3000, endpointEncoding=UTF-8}. Message payload is of
type: PostMethod (org.mule.api.transport.DispatchException)
  org.mule.transport.http.HttpClientMessageDispatcher:120
(http://mule.mulesource.org/docs/apidocs/org/mule/api/transport/DispatchException.html)
********************************************************************************

On Fri, Oct 3, 2008 at 12:25 PM, Todd Orr <torr0101@...> 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

[redijedi]

Here's some of the stack. Perhaps this is really simple and I'm just
an idiot. Please, I'd love that to be the case. Just please clue me
in. Thanks:

[10-03 23:05:22] ERROR InputStreamRequestEntity [connector.http.0.receiver.4]: c
hunked stream ended unexpectedly
Unable to get the current logfile size with stat: The filename, directory name,
or volume label syntax is incorrect. (0x7b)
java.io.IOException: chunked stream ended unexpectedly
        at org.apache.commons.httpclient.ChunkedInputStream.getChunkSizeFromInpu
tStream(ChunkedInputStream.java:252)
        at org.apache.commons.httpclient.ChunkedInputStream.nextChunk(ChunkedInp
utStream.java:221)
        at org.apache.commons.httpclient.ChunkedInputStream.read(ChunkedInputStr
eam.java:176)
        at org.apache.commons.httpclient.ChunkedInputStream.read(ChunkedInputStr
eam.java:196)
        at org.apache.commons.httpclient.methods.InputStreamRequestEntity.buffer
Content(InputStreamRequestEntity.java:136)
        at org.apache.commons.httpclient.methods.InputStreamRequestEntity.getCon
tentLength(InputStreamRequestEntity.java:187)
        at org.apache.commons.httpclient.methods.EntityEnclosingMethod.getReques
tContentLength(EntityEnclosingMethod.java:336)
        at org.apache.commons.httpclient.methods.EntityEnclosingMethod.addConten
tLengthRequestHeader(EntityEnclosingMethod.java:406)
        at org.apache.commons.httpclient.methods.EntityEnclosingMethod.addReques
tHeaders(EntityEnclosingMethod.java:374)
        at org.apache.commons.httpclient.HttpMethodBase.writeRequestHeaders(Http
MethodBase.java:2177)
        at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodB
ase.java:2060)
        at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.j
ava:1096)
        at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(Htt
pMethodDirector.java:398)
        at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMe
thodDirector.java:171)
        at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.jav
a:397)
        at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.jav
a:346)
        at org.mule.transport.http.HttpClientMessageDispatcher.execute(HttpClien
tMessageDispatcher.java:109)
        at org.mule.transport.http.HttpClientMessageDispatcher.doSend(HttpClient
MessageDispatcher.java:243)
        at org.mule.transport.AbstractMessageDispatcher.send(AbstractMessageDisp
atcher.java:157)
        at org.mule.transport.AbstractConnector.send(AbstractConnector.java:1890
)
        at org.mule.endpoint.DefaultOutboundEndpoint.send(DefaultOutboundEndpoin
t.java:76)
        at org.mule.DefaultMuleSession.sendEvent(DefaultMuleSession.java:327)
        at org.mule.DefaultMuleSession.sendEvent(DefaultMuleSession.java:213)
        at org.mule.routing.outbound.AbstractOutboundRouter$2.doInTransaction(Ab
stractOutboundRouter.java:148)
        at org.mule.transaction.TransactionTemplate.execute(TransactionTemplate.
java:99)
        at org.mule.routing.outbound.AbstractOutboundRouter.send(AbstractOutboun
dRouter.java:155)
        at org.mule.routing.outbound.FilteringOutboundRouter.route(FilteringOutb
oundRouter.java:68)
        at org.mule.routing.outbound.OutboundPassThroughRouter.route(OutboundPas
sThroughRouter.java:70)
        at org.mule.routing.outbound.DefaultOutboundRouterCollection$1.doInTrans
action(DefaultOutboundRouterCollection.java:64)
        at org.mule.transaction.TransactionTemplate.execute(TransactionTemplate.
java:45)
        at org.mule.routing.outbound.DefaultOutboundRouterCollection.route(Defau
ltOutboundRouterCollection.java:69)
        at org.mule.service.AbstractService.sendToOutboundRouter(AbstractService
.java:904)
        at org.mule.model.seda.SedaService.doSend(SedaService.java:238)
        at org.mule.service.AbstractService.sendEvent(AbstractService.java:510)
        at org.mule.DefaultMuleSession.sendEvent(DefaultMuleSession.java:354)
        at org.mule.routing.inbound.DefaultInboundRouterCollection.send(DefaultI
nboundRouterCollection.java:221)
        at org.mule.routing.inbound.DefaultInboundRouterCollection.route(Default
InboundRouterCollection.java:181)
        at org.mule.transport.AbstractMessageReceiver$DefaultInternalMessageList
ener.onMessage(AbstractMessageReceiver.java:603)
        at org.mule.transport.AbstractMessageReceiver.routeMessage(AbstractMessa
geReceiver.java:346)
        at org.mule.transport.AbstractMessageReceiver.routeMessage(AbstractMessa
geReceiver.java:287)
        at org.mule.transport.http.HttpMessageReceiver$HttpWorker.doRequest(Http
MessageReceiver.java:271)
        at org.mule.transport.http.HttpMessageReceiver$HttpWorker.processRequest
(HttpMessageReceiver.java:229)
        at org.mule.transport.http.HttpMessageReceiver$HttpWorker.run(HttpMessag
eReceiver.java:189)
        at org.mule.work.WorkerContext.run(WorkerContext.java:310)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.run
Worker(ThreadPoolExecutor.java:1061)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Wor
ker.run(ThreadPoolExecutor.java:575)
        at java.lang.Thread.run(Unknown Source)


On Fri, Oct 3, 2008 at 12:56 PM, Todd Orr <torr0101@...> wrote:

> Here's some of the Mule stdout if it helps:
>
> ********************************************************************************
>
> ERROR 2008-10-03 12:08:05,793 [connector.http.0.receiver.4]
> org.mule.service.DefaultServiceExceptionStrategy:
> ********************************************************************************
> Message               : Failed to route event via endpoint:
> DefaultOutboundEndpoint{endpointUri=http://localhost:8080/service/soap,
> connector=HttpConnector{this=26f9e5, started=true, initialised=true,
> name='connector.http.0', disposed=false,
> numberOfConcurrentTransactedReceivers=4,
> createMultipleTransactedReceivers=true, connected=true,
> supportedProtocols=[http], serviceOverrides=null},
> transformer=[ObjectToHttpClientMethodRequest{this=edbe39, name='null',
> ignoreBadInput=false, returnClass=interface
> org.apache.commons.httpclient.HttpMethod, sourceTypes=[interface
> org.mule.api.MuleMessage, class [B, class java.lang.String, class
> java.io.InputStream, interface org.mule.api.transport.OutputHandler,
> class org.mule.transport.NullPayload]}],
> name='endpoint.http.localhost.8080.service.soap', properties={},
> transactionConfig=Transaction{factory=null, action=NEVER, timeout=0},
> filter=null, deleteUnacceptedMessages=false, securityFilter=null,
> synchronous=true, initialState=started, remoteSync=true,
> remoteSyncTimeout=3000, endpointEncoding=UTF-8}. Message payload is of
> type: PostMethod
> Type                  : org.mule.api.transport.DispatchException
> Code                  : MULE_ERROR-42999
> JavaDoc               :
> http://mule.mulesource.org/docs/apidocs/org/mule/api/transport/DispatchException.html
> Payload               : org.apache.commons.httpclient.methods.PostMethod@1dfd90f
> ********************************************************************************
> Exception stack is:
> 1. Content must be set before entity is written
> (java.lang.IllegalStateException)
>  org.apache.commons.httpclient.methods.InputStreamRequestEntity:177
> (http://java.sun.com/j2se/1.5.0/docs/api/java/lang/IllegalStateException.html)
> 2. Failed to route event via endpoint:
> DefaultOutboundEndpoint{endpointUri=http://localhost:8080/service/soap,
> connector=HttpConnector{this=26f9e5, started=true, initialised=true,
> name='connector.http.0', disposed=false,
> numberOfConcurrentTransactedReceivers=4,
> createMultipleTransactedReceivers=true, connected=true,
> supportedProtocols=[http], serviceOverrides=null},
> transformer=[ObjectToHttpClientMethodRequest{this=edbe39, name='null',
> ignoreBadInput=false, returnClass=interface
> org.apache.commons.httpclient.HttpMethod, sourceTypes=[interface
> org.mule.api.MuleMessage, class [B, class java.lang.String, class
> java.io.InputStream, interface org.mule.api.transport.OutputHandler,
> class org.mule.transport.NullPayload]}],
> name='endpoint.http.localhost.8080.service.soap', properties={},
> transactionConfig=Transaction{factory=null, action=NEVER, timeout=0},
> filter=null, deleteUnacceptedMessages=false, securityFilter=null,
> synchronous=true, initialState=started, remoteSync=true,
> remoteSyncTimeout=3000, endpointEncoding=UTF-8}. Message payload is of
> type: PostMethod (org.mule.api.transport.DispatchException)
>  org.mule.transport.http.HttpClientMessageDispatcher:120
> (http://mule.mulesource.org/docs/apidocs/org/mule/api/transport/DispatchException.html)
> ********************************************************************************
>
> On Fri, Oct 3, 2008 at 12:25 PM, Todd Orr <torr0101@...> 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

[redijedi]

This appears to have something to do with Mule not being able to
execute multiple CXF WS calls in a row. I have a unit test that makes
one single call to the proxied WS and it works fine. If I loop that
call more than once Mule just hangs. The following stack trace leads
me to believe it might have something to do with CXF, but non-proxied
WS do work fine with the same unit test:

org.apache.cxf.interceptor.Fault: Could not create XMLStreamReader
(input was of encoding UTF-8).
        at org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:83)
        at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:221)
        at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:77)
        at org.mule.transport.cxf.CxfServiceComponent.sendToDestination(CxfServiceComponent.java:290)
        at org.mule.transport.cxf.CxfServiceComponent.onCall(CxfServiceComponent.java:115)
        at org.mule.model.resolvers.CallableEntryPointResolver.invoke(CallableEntryPointResolver.java:52)
        at org.mule.model.resolvers.DefaultEntryPointResolverSet.invoke(DefaultEntryPointResolverSet.java:50)
        at org.mule.component.DefaultLifecycleAdapter.intercept(DefaultLifecycleAdapter.java:202)
        at org.mule.component.AbstractJavaComponent.invokeComponentInstance(AbstractJavaComponent.java:84)
        at org.mule.component.AbstractJavaComponent.doOnCall(AbstractJavaComponent.java:75)
        at org.mule.component.AbstractComponent.onCall(AbstractComponent.java:96)
        at org.mule.model.seda.SedaService.doSend(SedaService.java:237)
        at org.mule.service.AbstractService.sendEvent(AbstractService.java:510)
        at org.mule.DefaultMuleSession.sendEvent(DefaultMuleSession.java:354)
        at org.mule.routing.inbound.DefaultInboundRouterCollection.send(DefaultInboundRouterCollection.java:221)
        at org.mule.routing.inbound.DefaultInboundRouterCollection.route(DefaultInboundRouterCollection.java:181)
        at org.mule.transport.AbstractMessageReceiver$DefaultInternalMessageListener.onMessage(AbstractMessageReceiver.java:603)
        at org.mule.transport.AbstractMessageReceiver.routeMessage(AbstractMessageReceiver.java:346)
        at org.mule.transport.AbstractMessageReceiver.routeMessage(AbstractMessageReceiver.java:287)
        at org.mule.transport.http.HttpMessageReceiver$HttpWorker.doRequest(HttpMessageReceiver.java:271)
        at org.mule.transport.http.HttpMessageReceiver$HttpWorker.processRequest(HttpMessageReceiver.java:229)
        at org.mule.transport.http.HttpMessageReceiver$HttpWorker.run(HttpMessageReceiver.java:189)
        at org.mule.work.WorkerContext.run(WorkerContext.java:310)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1061)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575)
        at java.lang.Thread.run(Thread.java:595)
Caused by: com.ctc.wstx.exc.WstxIOException: chunked stream ended unexpectedly
        at com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:548)
        at com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:604)
        at com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:629)
        at com.ctc.wstx.stax.WstxInputFactory.createXMLStreamReader(WstxInputFactory.java:324)
        at org.apache.cxf.interceptor.StaxInInterceptor.handleMessage(StaxInInterceptor.java:81)
        ... 25 more
Caused by: java.io.IOException: chunked stream ended unexpectedly
        at org.apache.commons.httpclient.ChunkedInputStream.getChunkSizeFromInputStream(ChunkedInputStream.java:252)
        at org.apache.commons.httpclient.ChunkedInputStream.nextChunk(ChunkedInputStream.java:221)
        at org.apache.commons.httpclient.ChunkedInputStream.read(ChunkedInputStream.java:176)
        at org.apache.commons.httpclient.ChunkedInputStream.read(ChunkedInputStream.java:196)
        at com.ctc.wstx.io.UTF8Reader.loadMore(UTF8Reader.java:365)
        at com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:110)
        at com.ctc.wstx.io.ReaderBootstrapper.initialLoad(ReaderBootstrapper.java:245)
        at com.ctc.wstx.io.ReaderBootstrapper.bootstrapInput(ReaderBootstrapper.java:132)
        at com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:543)
        ... 29 more


Perhaps its the version of CXF that Mule is working with?

On Fri, Oct 3, 2008 at 11:08 PM, Todd Orr <torr0101@...> wrote:

> Here's some of the stack. Perhaps this is really simple and I'm just
> an idiot. Please, I'd love that to be the case. Just please clue me
> in. Thanks:
>
> [10-03 23:05:22] ERROR InputStreamRequestEntity [connector.http.0.receiver.4]: c
> hunked stream ended unexpectedly
> Unable to get the current logfile size with stat: The filename, directory name,
> or volume label syntax is incorrect. (0x7b)
> java.io.IOException: chunked stream ended unexpectedly
>        at org.apache.commons.httpclient.ChunkedInputStream.getChunkSizeFromInpu
> tStream(ChunkedInputStream.java:252)
>        at org.apache.commons.httpclient.ChunkedInputStream.nextChunk(ChunkedInp
> utStream.java:221)
>        at org.apache.commons.httpclient.ChunkedInputStream.read(ChunkedInputStr
> eam.java:176)
>        at org.apache.commons.httpclient.ChunkedInputStream.read(ChunkedInputStr
> eam.java:196)
>        at org.apache.commons.httpclient.methods.InputStreamRequestEntity.buffer
> Content(InputStreamRequestEntity.java:136)
>        at org.apache.commons.httpclient.methods.InputStreamRequestEntity.getCon
> tentLength(InputStreamRequestEntity.java:187)
>        at org.apache.commons.httpclient.methods.EntityEnclosingMethod.getReques
> tContentLength(EntityEnclosingMethod.java:336)
>        at org.apache.commons.httpclient.methods.EntityEnclosingMethod.addConten
> tLengthRequestHeader(EntityEnclosingMethod.java:406)
>        at org.apache.commons.httpclient.methods.EntityEnclosingMethod.addReques
> tHeaders(EntityEnclosingMethod.java:374)
>        at org.apache.commons.httpclient.HttpMethodBase.writeRequestHeaders(Http
> MethodBase.java:2177)
>        at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodB
> ase.java:2060)
>        at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.j
> ava:1096)
>        at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(Htt
> pMethodDirector.java:398)
>        at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMe
> thodDirector.java:171)
>        at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.jav
> a:397)
>        at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.jav
> a:346)
>        at org.mule.transport.http.HttpClientMessageDispatcher.execute(HttpClien
> tMessageDispatcher.java:109)
>        at org.mule.transport.http.HttpClientMessageDispatcher.doSend(HttpClient
> MessageDispatcher.java:243)
>        at org.mule.transport.AbstractMessageDispatcher.send(AbstractMessageDisp
> atcher.java:157)
>        at org.mule.transport.AbstractConnector.send(AbstractConnector.java:1890
> )
>        at org.mule.endpoint.DefaultOutboundEndpoint.send(DefaultOutboundEndpoin
> t.java:76)
>        at org.mule.DefaultMuleSession.sendEvent(DefaultMuleSession.java:327)
>        at org.mule.DefaultMuleSession.sendEvent(DefaultMuleSession.java:213)
>        at org.mule.routing.outbound.AbstractOutboundRouter$2.doInTransaction(Ab
> stractOutboundRouter.java:148)
>        at org.mule.transaction.TransactionTemplate.execute(TransactionTemplate.
> java:99)
>        at org.mule.routing.outbound.AbstractOutboundRouter.send(AbstractOutboun
> dRouter.java:155)
>        at org.mule.routing.outbound.FilteringOutboundRouter.route(FilteringOutb
> oundRouter.java:68)
>        at org.mule.routing.outbound.OutboundPassThroughRouter.route(OutboundPas
> sThroughRouter.java:70)
>        at org.mule.routing.outbound.DefaultOutboundRouterCollection$1.doInTrans
> action(DefaultOutboundRouterCollection.java:64)
>        at org.mule.transaction.TransactionTemplate.execute(TransactionTemplate.
> java:45)
>        at org.mule.routing.outbound.DefaultOutboundRouterCollection.route(Defau
> ltOutboundRouterCollection.java:69)
>        at org.mule.service.AbstractService.sendToOutboundRouter(AbstractService
> .java:904)
>        at org.mule.model.seda.SedaService.doSend(SedaService.java:238)
>        at org.mule.service.AbstractService.sendEvent(AbstractService.java:510)
>        at org.mule.DefaultMuleSession.sendEvent(DefaultMuleSession.java:354)
>        at org.mule.routing.inbound.DefaultInboundRouterCollection.send(DefaultI
> nboundRouterCollection.java:221)
>        at org.mule.routing.inbound.DefaultInboundRouterCollection.route(Default
> InboundRouterCollection.java:181)
>        at org.mule.transport.AbstractMessageReceiver$DefaultInternalMessageList
> ener.onMessage(AbstractMessageReceiver.java:603)
>        at org.mule.transport.AbstractMessageReceiver.routeMessage(AbstractMessa
> geReceiver.java:346)
>        at org.mule.transport.AbstractMessageReceiver.routeMessage(AbstractMessa
> geReceiver.java:287)
>        at org.mule.transport.http.HttpMessageReceiver$HttpWorker.doRequest(Http
> MessageReceiver.java:271)
>        at org.mule.transport.http.HttpMessageReceiver$HttpWorker.processRequest
> (HttpMessageReceiver.java:229)
>        at org.mule.transport.http.HttpMessageReceiver$HttpWorker.run(HttpMessag
> eReceiver.java:189)
>        at org.mule.work.WorkerContext.run(WorkerContext.java:310)
>        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.run
> Worker(ThreadPoolExecutor.java:1061)
>        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Wor
> ker.run(ThreadPoolExecutor.java:575)
>        at java.lang.Thread.run(Unknown Source)
>
>
> On Fri, Oct 3, 2008 at 12:56 PM, Todd Orr <torr0101@...> wrote:
>> Here's some of the Mule stdout if it helps:
>>
>> ********************************************************************************
>>
>> ERROR 2008-10-03 12:08:05,793 [connector.http.0.receiver.4]
>> org.mule.service.DefaultServiceExceptionStrategy:
>> ********************************************************************************
>> Message               : Failed to route event via endpoint:
>> DefaultOutboundEndpoint{endpointUri=http://localhost:8080/service/soap,
>> connector=HttpConnector{this=26f9e5, started=true, initialised=true,
>> name='connector.http.0', disposed=false,
>> numberOfConcurrentTransactedReceivers=4,
>> createMultipleTransactedReceivers=true, connected=true,
>> supportedProtocols=[http], serviceOverrides=null},
>> transformer=[ObjectToHttpClientMethodRequest{this=edbe39, name='null',
>> ignoreBadInput=false, returnClass=interface
>> org.apache.commons.httpclient.HttpMethod, sourceTypes=[interface
>> org.mule.api.MuleMessage, class [B, class java.lang.String, class
>> java.io.InputStream, interface org.mule.api.transport.OutputHandler,
>> class org.mule.transport.NullPayload]}],
>> name='endpoint.http.localhost.8080.service.soap', properties={},
>> transactionConfig=Transaction{factory=null, action=NEVER, timeout=0},
>> filter=null, deleteUnacceptedMessages=false, securityFilter=null,
>> synchronous=true, initialState=started, remoteSync=true,
>> remoteSyncTimeout=3000, endpointEncoding=UTF-8}. Message payload is of
>> type: PostMethod
>> Type                  : org.mule.api.transport.DispatchException
>> Code                  : MULE_ERROR-42999
>> JavaDoc               :
>> http://mule.mulesource.org/docs/apidocs/org/mule/api/transport/DispatchException.html
>> Payload               : org.apache.commons.httpclient.methods.PostMethod@1dfd90f
>> ********************************************************************************
>> Exception stack is:
>> 1. Content must be set before entity is written
>> (java.lang.IllegalStateException)
>>  org.apache.commons.httpclient.methods.InputStreamRequestEntity:177
>> (http://java.sun.com/j2se/1.5.0/docs/api/java/lang/IllegalStateException.html)
>> 2. Failed to route event via endpoint:
>> DefaultOutboundEndpoint{endpointUri=http://localhost:8080/service/soap,
>> connector=HttpConnector{this=26f9e5, started=true, initialised=true,
>> name='connector.http.0', disposed=false,
>> numberOfConcurrentTransactedReceivers=4,
>> createMultipleTransactedReceivers=true, connected=true,
>> supportedProtocols=[http], serviceOverrides=null},
>> transformer=[ObjectToHttpClientMethodRequest{this=edbe39, name='null',
>> ignoreBadInput=false, returnClass=interface
>> org.apache.commons.httpclient.HttpMethod, sourceTypes=[interface
>> org.mule.api.MuleMessage, class [B, class java.lang.String, class
>> java.io.InputStream, interface org.mule.api.transport.OutputHandler,
>> class org.mule.transport.NullPayload]}],
>> name='endpoint.http.localhost.8080.service.soap', properties={},
>> transactionConfig=Transaction{factory=null, action=NEVER, timeout=0},
>> filter=null, deleteUnacceptedMessages=false, securityFilter=null,
>> synchronous=true, initialState=started, remoteSync=true,
>> remoteSyncTimeout=3000, endpointEncoding=UTF-8}. Message payload is of
>> type: PostMethod (org.mule.api.transport.DispatchException)
>>  org.mule.transport.http.HttpClientMessageDispatcher:120
>> (http://mule.mulesource.org/docs/apidocs/org/mule/api/transport/DispatchException.html)
>> ********************************************************************************
>>
>> On Fri, Oct 3, 2008 at 12:25 PM, Todd Orr <torr0101@...> 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

[Mohit Manrai]

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

[redijedi]

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

[Mohit Manrai]

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 <[e-mail]> 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

[redijedi]

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

[redijedi]

Tried again. One test method that makes one response returning WS
call. It seems as though Mule passes on the request immediately, then
hangs. I watched the JBoss out and saw that upon Mule timing out 2
more requests were issued to the WS. I turned on debugging in Mule
(attached). It looks as though 2 http receivers were operating on the
request. Not sure what all this means.

On Mon, Oct 6, 2008 at 5:07 PM, Todd Orr <torr0101@...> wrote:

> 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
>>
>>
>>
>

2008-10-06 17:21:58,910  [DEBUG] [connector.http.0.receiver.2] "Removing expirable: org.mule.transport.http.HttpMessageReceiver$HttpWorker@96ad7c" org.mule.util.monitor.ExpiryMonitor.removeExpirable on line 117 logged by org.mule.util.monitor.ExpiryMonitor
2008-10-06 17:21:58,924  [DEBUG] [connector.http.0.receiver.2] "/service" org.mule.transport.http.HttpMessageReceiver$HttpWorker.doRequest on line 259 logged by org.mule.transport.http.HttpMessageReceiver
2008-10-06 17:21:58,925  [DEBUG] [connector.http.0.receiver.2] "Secondary lookup of receiver on connector: connector.http.0 with URI key: http://localhost:63081/service" org.mule.transport.http.HttpMessageReceiver.getTargetReceiver on line 501 logged by org.mule.transport.http.HttpMessageReceiver
2008-10-06 17:21:58,928  [DEBUG] [connector.http.0.receiver.2] "Message Received from: http://localhost:63081/service" org.mule.transport.AbstractMessageReceiver.routeMessage on line 315 logged by org.mule.transport.http.HttpMessageReceiver
2008-10-06 17:21:58,933  [DEBUG] [connector.http.0.receiver.2] "There is no session id on the request using key: ID. Generating new session id: cf3b7cde-93ec-11dd-a826-f975255c6f26" org.mule.DefaultMuleSession.<init> on line 122 logged by org.mule.DefaultMuleSession
2008-10-06 17:21:58,938  [DEBUG] [connector.http.0.receiver.2] "sending event to service: service.cache event is: MuleEvent: cf3bf20f-93ec-11dd-a826-f975255c6f26, sync=true, stop processing=false, DefaultInboundEndpoint{endpointUri=http://localhost:63081/service, connector=HttpConnector{this=a8e586, started=true, initialised=true, name='connector.http.0', disposed=false, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=true, connected=true, supportedProtocols=[http], serviceOverrides=null}, transformer=[], name='endpoint.http.localhost.63081.services.cache', properties={}, transactionConfig=Transaction{factory=null, action=NEVER, timeout=0}, filter=null, deleteUnacceptedMessages=false, securityFilter=null, synchronous=true, initialState=started, remoteSync=true, remoteSyncTimeout=3000, endpointEncoding=UTF-8}" org.mule.DefaultMuleSession.sendEvent on line 351 logged by org.mule.DefaultMuleSession
2008-10-06 17:21:58,938  [DEBUG] [connector.http.0.receiver.2] "Service: service.cache has received synchronous event on: http://localhost:63081/service" org.mule.service.AbstractService.sendEvent on line 506 logged by org.mule.model.seda.SedaService
2008-10-06 17:21:58,938  [DEBUG] [connector.http.0.receiver.2] "service.cache : got proxy for cf3bf20f-93ec-11dd-a826-f975255c6f26 = org.mule.component.DefaultJavaComponent component for: service.cache" org.mule.model.seda.SedaService.doSend on line 233 logged by org.mule.model.seda.SedaService
2008-10-06 17:21:58,942  [DEBUG] [connector.http.0.receiver.2] "Forwarding SOAP message" org.mule.transport.soap.WSProxyService.onCall on line 168 logged by org.mule.transport.soap.WSProxyService
2008-10-06 17:21:58,943  [DEBUG] [connector.http.0.receiver.2] "No CorrelationId is set on the message, will set a new Id" org.mule.routing.outbound.AbstractOutboundRouter.setMessageProperties on line 235 logged by org.mule.routing.outbound.OutboundPassThroughRouter
2008-10-06 17:21:58,943  [DEBUG] [connector.http.0.receiver.2] "Extracted correlation Id as: cf3959fd-93ec-11dd-a826-f975255c6f26" org.mule.routing.outbound.AbstractOutboundRouter.setMessageProperties on line 243 logged by org.mule.routing.outbound.OutboundPassThroughRouter
2008-10-06 17:21:58,944  [DEBUG] [connector.http.0.receiver.2] "Setting Correlation info on Outbound router for endpoint: http://localhost:8080/service/soap
Id=cf3959fd-93ec-11dd-a826-f975255c6f26" org.mule.routing.outbound.AbstractOutboundRouter.setMessageProperties on line 254 logged by org.mule.routing.outbound.OutboundPassThroughRouter
2008-10-06 17:21:58,944  [DEBUG] [connector.http.0.receiver.2] "Message being sent to: http://localhost:8080/service/soap" org.mule.routing.outbound.AbstractOutboundRouter.send on line 127 logged by org.mule.routing.outbound.OutboundPassThroughRouter
2008-10-06 17:21:58,945  [DEBUG] [connector.http.0.receiver.2] "org.mule.transport.http.HttpMessageAdapter/org.mule.transport.http.HttpMessageAdapter@178dc08{id=cf3959fd-93ec-11dd-a826-f975255c6f26, payload=org.apache.commons.httpclient.ChunkedInputStream, correlationId=cf3959fd-93ec-11dd-a826-f975255c6f26, correlationGroup=-1, correlationSeq=-1, encoding=UTF-8, exceptionPayload=null, properties=Properites{invocation:{}, inbound:{http.version=HTTP/1.1, User-Agent=Java/1.5.0_14, Host=localhost:63081, http.request=/service, Pragma=no-cache, Content-Type=text/xml; charset=UTF-8, Cache-Control=no-cache, Accept=*, Connection=keep-alive, http.method=POST, SOAPAction="", Transfer-Encoding=chunked}, outbound:{MULE_REMOTE_SYNC=true, MULE_REMOTE_CLIENT_ADDRESS=/127.0.0.1:60431, MULE_ORIGINATING_ENDPOINT=endpoint.http.localhost.63081.services.cache, MULE_CORRELATION_ID=cf3959fd-93ec-11dd-a826-f975255c6f26}, session:{}, }}" org.mule.routing.outbound.AbstractOutboundRouter.send on line 128 logged by org.mule.routing.outbound.OutboundPassThroughRouter
2008-10-06 17:21:58,945  [DEBUG] [connector.http.0.receiver.2] "MuleSession has received synchronous event on endpoint: DefaultOutboundEndpoint{endpointUri=http://localhost:8080/service/soap, connector=HttpConnector{this=a8e586, started=true, initialised=true, name='connector.http.0', disposed=false, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=true, connected=true, supportedProtocols=[http], serviceOverrides=null}, transformer=[ObjectToHttpClientMethodRequest{this=37d490, name='null', ignoreBadInput=false, returnClass=interface org.apache.commons.httpclient.HttpMethod, sourceTypes=[interface org.mule.api.MuleMessage, class [B, class java.lang.String, class java.io.InputStream, interface org.mule.api.transport.OutputHandler, class org.mule.transport.NullPayload]}], name='endpoint.http.localhost.8080.cache.soap', properties={}, transactionConfig=Transaction{factory=null, action=NEVER, timeout=0}, filter=null, deleteUnacceptedMessages=false, securityFilter=null, synchronous=false, initialState=started, remoteSync=false, remoteSyncTimeout=3000, endpointEncoding=UTF-8}" org.mule.DefaultMuleSession.sendEvent on line 209 logged by org.mule.DefaultMuleSession
2008-10-06 17:21:58,948  [DEBUG] [connector.http.0.receiver.2] "Creating event with data: org.apache.commons.httpclient.ChunkedInputStream, for endpoint: DefaultOutboundEndpoint{endpointUri=http://localhost:8080/service/soap, connector=HttpConnector{this=a8e586, started=true, initialised=true, name='connector.http.0', disposed=false, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=true, connected=true, supportedProtocols=[http], serviceOverrides=null}, transformer=[ObjectToHttpClientMethodRequest{this=37d490, name='null', ignoreBadInput=false, returnClass=interface org.apache.commons.httpclient.HttpMethod, sourceTypes=[interface org.mule.api.MuleMessage, class [B, class java.lang.String, class java.io.InputStream, interface org.mule.api.transport.OutputHandler, class org.mule.transport.NullPayload]}], name='endpoint.http.localhost.8080.cache.soap', properties={}, transactionConfig=Transaction{factory=null, action=NEVER, timeout=0}, filter=null, deleteUnacceptedMessages=false, securityFilter=null, synchronous=false, initialState=started, remoteSync=false, remoteSyncTimeout=3000, endpointEncoding=UTF-8}" org.mule.DefaultMuleSession.createOutboundEvent on line 440 logged by org.mule.DefaultMuleSession
2008-10-06 17:21:58,948  [DEBUG] [connector.http.0.receiver.2] "sending event: MuleEvent: cf3dc6d0-93ec-11dd-a826-f975255c6f26, sync=false, stop processing=false, DefaultOutboundEndpoint{endpointUri=http://localhost:8080/service/soap, connector=HttpConnector{this=a8e586, started=true, initialised=true, name='connector.http.0', disposed=false, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=true, connected=true, supportedProtocols=[http], serviceOverrides=null}, transformer=[ObjectToHttpClientMethodRequest{this=37d490, name='null', ignoreBadInput=false, returnClass=interface org.apache.commons.httpclient.HttpMethod, sourceTypes=[interface org.mule.api.MuleMessage, class [B, class java.lang.String, class java.io.InputStream, interface org.mule.api.transport.OutputHandler, class org.mule.transport.NullPayload]}], name='endpoint.http.localhost.8080.cache.soap', properties={}, transactionConfig=Transaction{factory=null, action=NEVER, timeout=0}, filter=null, deleteUnacceptedMessages=false, securityFilter=null, synchronous=false, initialState=started, remoteSync=false, remoteSyncTimeout=3000, endpointEncoding=UTF-8}" org.mule.DefaultMuleSession.sendEvent on line 310 logged by org.mule.DefaultMuleSession
2008-10-06 17:21:58,948  [DEBUG] [connector.http.0.receiver.2] "Borrowing a dispatcher for endpoint: http://localhost:8080/service/soap" org.mule.transport.AbstractConnector.getDispatcher on line 800 logged by org.mule.transport.http.HttpConnector
2008-10-06 17:21:58,955  [DEBUG] [connector.http.0.receiver.2] "Borrowed a dispatcher for endpoint: http://localhost:8080/service/soap = HttpClientMessageDispatcher{this=29ea31, endpoint=http://localhost:8080/service/soap, disposed=false}" org.mule.transport.AbstractConnector.getDispatcher on line 807 logged by org.mule.transport.http.HttpConnector
2008-10-06 17:21:58,955  [DEBUG] [connector.http.0.receiver.2] "Borrowed dispatcher: HttpClientMessageDispatcher{this=29ea31, endpoint=http://localhost:8080/service/soap, disposed=false}" org.mule.transport.AbstractConnector.getDispatcher on line 823 logged by org.mule.transport.http.HttpConnector
2008-10-06 17:21:58,955  [DEBUG] [connector.http.0.receiver.2] "Connecting: HttpClientMessageDispatcher{this=29ea31, endpoint=http://localhost:8080/service/soap, disposed=false}" org.mule.transport.AbstractConnectable.connect on line 187 logged by org.mule.transport.http.HttpClientMessageDispatcher
2008-10-06 17:21:58,960  [INFO]  [connector.http.0.receiver.2] "Connected: HttpClientMessageDispatcher{this=29ea31, endpoint=http://localhost:8080/service/soap, disposed=false}" org.mule.transport.AbstractConnectable.connect on line 192 logged by org.mule.transport.http.HttpClientMessageDispatcher
2008-10-06 17:21:58,961  [DEBUG] [connector.http.0.receiver.2] "Applying transformer ObjectToHttpMethod (org.mule.transport.http.transformers.ObjectToHttpClientMethodRequest)" org.mule.transformer.AbstractTransformer.transform on line 248 logged by org.mule.transport.http.transformers.ObjectToHttpClientMethodRequest
2008-10-06 17:21:58,961  [DEBUG] [connector.http.0.receiver.2] "Object before transform: org.mule.transport.http.HttpMessageAdapter/org.mule.transport.http.HttpMessageAdapter@178dc08{id=cf3959fd-93ec-11dd-a826-f975255c6f26, payload=org.apache.commons.httpclient.ChunkedInputStream, correla..." org.mule.transformer.AbstractTransformer.transform on line 249 logged by org.mule.transport.http.transformers.ObjectToHttpClientMethodRequest
2008-10-06 17:21:58,998  [DEBUG] [connector.http.0.receiver.2] "Object after transform: org.apache.commons.httpclient.methods.PostMethod@c272bc" org.mule.transformer.AbstractTransformer.transform on line 263 logged by org.mule.transport.http.transformers.ObjectToHttpClientMethodRequest
2008-10-06 17:21:59,001  [DEBUG] [connector.http.0.receiver.2] "The transformed object is of expected type. Type is: PostMethod" org.mule.transformer.AbstractTransformer.checkReturnClass on line 95 logged by org.mule.transport.http.transformers.ObjectToHttpClientMethodRequest
2008-10-06 17:21:59,098  [DEBUG] [connector.http.0.receiver.2] "Http response is: 200" org.mule.transport.http.HttpClientMessageDispatcher.doSend on line 274 logged by org.mule.transport.http.HttpClientMessageDispatcher
2008-10-06 17:21:59,098  [DEBUG] [connector.http.0.receiver.2] "Returning dispatcher for endpoint: http://localhost:8080/service/soap = HttpClientMessageDispatcher{this=29ea31, endpoint=http://localhost:8080/service/soap, disposed=false}" org.mule.transport.AbstractConnector.returnDispatcher on line 841 logged by org.mule.transport.http.HttpConnector
2008-10-06 17:21:59,098  [DEBUG] [connector.http.0.receiver.2] "new copy of message for Thread[connector.http.0.receiver.2,5,main]" org.mule.DefaultMuleMessage.newThreadCopy on line 643 logged by org.mule.DefaultMuleMessage
2008-10-06 17:21:59,100  [DEBUG] [connector.http.0.receiver.2] "Response message from sending to: http://localhost:8080/service/soap" org.mule.routing.outbound.AbstractOutboundRouter.send on line 172 logged by org.mule.routing.outbound.OutboundPassThroughRouter
2008-10-06 17:21:59,100  [DEBUG] [connector.http.0.receiver.2] "org.mule.transport.http.HttpMessageAdapter/org.mule.transport.http.HttpMessageAdapter@fa70a4{id=cf54aa32-93ec-11dd-a826-f975255c6f26, payload=org.mule.transport.http.ReleasingInputStream, correlationId=cf3959fd-93ec-11dd-a826-f975255c6f26, correlationGroup=-1, correlationSeq=-1, encoding=UTF-8, exceptionPayload=null, properties=Properites{invocation:{}, inbound:{}, outbound:{http.version=HTTP/1.1, X-Powered-By=Servlet 2.4; JBoss-4.2.2.GA (build: SVNTag=JBoss_4_2_2_GA date=200710221139)/Tomcat-5.5, User-Agent=Java/1.5.0_14, Host=localhost:63081, MULE_ENDPOINT=http://localhost:8080/service/soap, http.request=/service, http.status=200, Date=Mon, 06 Oct 2008 21:21:59 GMT, Pragma=no-cache, Content-Type=text/xml;charset=UTF-8, Cache-Control=no-cache, Accept=*, MULE_REMOTE_SYNC=true, Content-Length=260, MULE_REMOTE_CLIENT_ADDRESS=/127.0.0.1:60431, http.method=POST, MULE_CORRELATION_ID=cf3959fd-93ec-11dd-a826-f975255c6f26, SOAPAction="", Server=Apache-Coyote/1.1, Transfer-Encoding=chunked, MULE_ORIGINATING_ENDPOINT=endpoint.http.localhost.63081.services.cache}, session:{}, }}" org.mule.routing.outbound.AbstractOutboundRouter.send on line 173 logged by org.mule.routing.outbound.OutboundPassThroughRouter
2008-10-06 17:21:59,105  [DEBUG] [connector.http.0.receiver.2] "Waiting for response router message" org.mule.service.AbstractService.processAsyncReplyRouter on line 923 logged by org.mule.model.seda.SedaService
2008-10-06 17:21:59,105  [ERROR] [connector.http.0.receiver.2] "There are no routers configured on the response router. Returning the current message" org.mule.routing.response.DefaultResponseRouterCollection.getResponse on line 80 logged by org.mule.routing.response.DefaultResponseRouterCollection
2008-10-06 17:21:59,106  [DEBUG] [connector.http.0.receiver.2] "Applying transformer MuleMessageToHttpResponse (org.mule.transport.http.transformers.MuleMessageToHttpResponse)" org.mule.transformer.AbstractTransformer.transform on line 248 logged by org.mule.transport.http.transformers.MuleMessageToHttpResponse
2008-10-06 17:21:59,106  [DEBUG] [connector.http.0.receiver.2] "Object before transform: org.mule.transport.http.HttpMessageAdapter/org.mule.transport.http.HttpMessageAdapter@fa70a4{id=cf54aa32-93ec-11dd-a826-f975255c6f26, payload=org.mule.transport.http.ReleasingInputStream, correlationI..." org.mule.transformer.AbstractTransformer.transform on line 249 logged by org.mule.transport.http.transformers.MuleMessageToHttpResponse
2008-10-06 17:21:59,110  [DEBUG] [connector.http.0.receiver.2] "lookupObjects: type=interface org.mule.api.transformer.Transformer scope=2" org.mule.registry.AbstractRegistry.lookupObjects on line 516 logged by org.mule.registry.TransientRegistry
2008-10-06 17:21:59,111  [DEBUG] [connector.http.0.receiver.2] "lookupObjects: type=interface org.mule.api.transformer.Transformer scope=2" org.mule.registry.AbstractRegistry.lookupObjects on line 516 logged by org.mule.config.spring.SpringRegistry
2008-10-06 17:21:59,114  [DEBUG] [connector.http.0.receiver.2] "Applying transformer _ObjectToOutputHandler (org.mule.transformer.simple.ObjectToOutputHandler)" org.mule.transformer.AbstractTransformer.transform on line 248 logged by org.mule.transformer.simple.ObjectToOutputHandler
2008-10-06 17:21:59,114  [DEBUG] [connector.http.0.receiver.2] "Object before transform: org.mule.transport.http.ReleasingInputStream@cd43ce" org.mule.transformer.AbstractTransformer.transform on line 249 logged by org.mule.transformer.simple.ObjectToOutputHandler
2008-10-06 17:21:59,115  [DEBUG] [connector.http.0.receiver.2] "Object after transform: org.mule.transformer.simple.ObjectToOutputHandler$3@e7b3f2" org.mule.transformer.AbstractTransformer.transform on line 263 logged by org.mule.transformer.simple.ObjectToOutputHandler
2008-10-06 17:21:59,115  [DEBUG] [connector.http.0.receiver.2] "The transformed object is of expected type. Type is: ObjectToOutputHandler$3" org.mule.transformer.AbstractTransformer.checkReturnClass on line 95 logged by org.mule.transformer.simple.ObjectToOutputHandler
2008-10-06 17:21:59,116  [DEBUG] [connector.http.0.receiver.2] "Object after transform: org.mule.transport.http.HttpResponse@1d709a5" org.mule.transformer.AbstractTransformer.transform on line 263 logged by org.mule.transport.http.transformers.MuleMessageToHttpResponse
2008-10-06 17:21:59,116  [DEBUG] [connector.http.0.receiver.2] "The transformed object is of expected type. Type is: HttpResponse" org.mule.transformer.AbstractTransformer.checkReturnClass on line 95 logged by org.mule.transport.http.transformers.MuleMessageToHttpResponse
2008-10-06 17:21:59,119  [INFO]  [connector.http.0.receiver.2] "Closing HTTP connection." org.mule.transport.http.HttpMessageReceiver$HttpWorker.run on line 199 logged by org.mule.transport.http.HttpMessageReceiver
2008-10-06 17:21:59,120  [DEBUG] [connector.http.0.receiver.2] "Closing: Socket[addr=/127.0.0.1,port=60431,localport=63081]" org.mule.transport.http.HttpServerConnection.close on line 82 logged by org.mule.transport.http.HttpServerConnection
2008-10-06 17:21:59,120  [DEBUG] [connector.http.0.receiver.2] "Removing expirable: org.mule.transport.http.HttpMessageReceiver$HttpWorker@96ad7c" org.mule.util.monitor.ExpiryMonitor.removeExpirable on line 117 logged by org.mule.util.monitor.ExpiryMonitor
2008-10-06 17:21:59,276  [DEBUG] [connector.http.0.receiver.3] "Removing expirable: org.mule.transport.http.HttpMessageReceiver$HttpWorker@1e16483" org.mule.util.monitor.ExpiryMonitor.removeExpirable on line 117 logged by org.mule.util.monitor.ExpiryMonitor
2008-10-06 17:21:59,277  [DEBUG] [connector.http.0.receiver.3] "/service" org.mule.transport.http.HttpMessageReceiver$HttpWorker.doRequest on line 259 logged by org.mule.transport.http.HttpMessageReceiver
2008-10-06 17:21:59,277  [DEBUG] [connector.http.0.receiver.3] "Secondary lookup of receiver on connector: connector.http.0 with URI key: http://localhost:63081/service" org.mule.transport.http.HttpMessageReceiver.getTargetReceiver on line 501 logged by org.mule.transport.http.HttpMessageReceiver
2008-10-06 17:21:59,277  [DEBUG] [connector.http.0.receiver.3] "Message Received from: http://localhost:63081/service" org.mule.transport.AbstractMessageReceiver.routeMessage on line 315 logged by org.mule.transport.http.HttpMessageReceiver
2008-10-06 17:21:59,277  [DEBUG] [connector.http.0.receiver.3] "There is no session id on the request using key: ID. Generating new session id: cf6ffa66-93ec-11dd-a826-f975255c6f26" org.mule.DefaultMuleSession.<init> on line 122 logged by org.mule.DefaultMuleSession
2008-10-06 17:21:59,278  [DEBUG] [connector.http.0.receiver.3] "sending event to service: service.cache event is: MuleEvent: cf6ffa67-93ec-11dd-a826-f975255c6f26, sync=true, stop processing=false, DefaultInboundEndpoint{endpointUri=http://localhost:63081/service, connector=HttpConnector{this=a8e586, started=true, initialised=true, name='connector.http.0', disposed=false, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=true, connected=true, supportedProtocols=[http], serviceOverrides=null}, transformer=[], name='endpoint.http.localhost.63081.services.cache', properties={}, transactionConfig=Transaction{factory=null, action=NEVER, timeout=0}, filter=null, deleteUnacceptedMessages=false, securityFilter=null, synchronous=true, initialState=started, remoteSync=true, remoteSyncTimeout=3000, endpointEncoding=UTF-8}" org.mule.DefaultMuleSession.sendEvent on line 351 logged by org.mule.DefaultMuleSession
2008-10-06 17:21:59,278  [DEBUG] [connector.http.0.receiver.3] "Service: service.cache has received synchronous event on: http://localhost:63081/service" org.mule.service.AbstractService.sendEvent on line 506 logged by org.mule.model.seda.SedaService
2008-10-06 17:21:59,278  [DEBUG] [connector.http.0.receiver.3] "service.cache : got proxy for cf6ffa67-93ec-11dd-a826-f975255c6f26 = org.mule.component.DefaultJavaComponent component for: service.cache" org.mule.model.seda.SedaService.doSend on line 233 logged by org.mule.model.seda.SedaService
2008-10-06 17:21:59,278  [DEBUG] [connector.http.0.receiver.3] "Forwarding SOAP message" org.mule.transport.soap.WSProxyService.onCall on line 168 logged by org.mule.transport.soap.WSProxyService
2008-10-06 17:21:59,278  [DEBUG] [connector.http.0.receiver.3] "No CorrelationId is set on the message, will set a new Id" org.mule.routing.outbound.AbstractOutboundRouter.setMessageProperties on line 235 logged by org.mule.routing.outbound.OutboundPassThroughRouter
2008-10-06 17:21:59,278  [DEBUG] [connector.http.0.receiver.3] "Extracted correlation Id as: cf6ffa65-93ec-11dd-a826-f975255c6f26" org.mule.routing.outbound.AbstractOutboundRouter.setMessageProperties on line 243 logged by org.mule.routing.outbound.OutboundPassThroughRouter
2008-10-06 17:21:59,279  [DEBUG] [connector.http.0.receiver.3] "Setting Correlation info on Outbound router for endpoint: http://localhost:8080/service/soap
Id=cf6ffa65-93ec-11dd-a826-f975255c6f26" org.mule.routing.outbound.AbstractOutboundRouter.setMessageProperties on line 254 logged by org.mule.routing.outbound.OutboundPassThroughRouter
2008-10-06 17:21:59,279  [DEBUG] [connector.http.0.receiver.3] "Message being sent to: http://localhost:8080/service/soap" org.mule.routing.outbound.AbstractOutboundRouter.send on line 127 logged by org.mule.routing.outbound.OutboundPassThroughRouter
2008-10-06 17:21:59,279  [DEBUG] [connector.http.0.receiver.3] "org.mule.transport.http.HttpMessageAdapter/org.mule.transport.http.HttpMessageAdapter@8ddb93{id=cf6ffa65-93ec-11dd-a826-f975255c6f26, payload=org.apache.commons.httpclient.ChunkedInputStream, correlationId=cf6ffa65-93ec-11dd-a826-f975255c6f26, correlationGroup=-1, correlationSeq=-1, encoding=UTF-8, exceptionPayload=null, properties=Properites{invocation:{}, inbound:{http.version=HTTP/1.1, User-Agent=Java/1.5.0_14, Host=localhost:63081, http.request=/service, Pragma=no-cache, Content-Type=text/xml; charset=UTF-8, Cache-Control=no-cache, Accept=*, Connection=keep-alive, http.method=POST, SOAPAction="", Transfer-Encoding=chunked}, outbound:{MULE_REMOTE_SYNC=true, MULE_REMOTE_CLIENT_ADDRESS=/127.0.0.1:60433, MULE_ORIGINATING_ENDPOINT=endpoint.http.localhost.63081.services.cache, MULE_CORRELATION_ID=cf6ffa65-93ec-11dd-a826-f975255c6f26}, session:{}, }}" org.mule.routing.outbound.AbstractOutboundRouter.send on line 128 logged by org.mule.routing.outbound.OutboundPassThroughRouter
2008-10-06 17:21:59,279  [DEBUG] [connector.http.0.receiver.3] "MuleSession has received synchronous event on endpoint: DefaultOutboundEndpoint{endpointUri=http://localhost:8080/service/soap, connector=HttpConnector{this=a8e586, started=true, initialised=true, name='connector.http.0', disposed=false, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=true, connected=true, supportedProtocols=[http], serviceOverrides=null}, transformer=[ObjectToHttpClientMethodRequest{this=37d490, name='ObjectToHttpMethod', ignoreBadInput=false, returnClass=interface org.apache.commons.httpclient.HttpMethod, sourceTypes=[interface org.mule.api.MuleMessage, class [B, class java.lang.String, class java.io.InputStream, interface org.mule.api.transport.OutputHandler, class org.mule.transport.NullPayload]}], name='endpoint.http.localhost.8080.cache.soap', properties={}, transactionConfig=Transaction{factory=null, action=NEVER, timeout=0}, filter=null, deleteUnacceptedMessages=false, securityFilter=null, synchronous=false, initialState=started, remoteSync=false, remoteSyncTimeout=3000, endpointEncoding=UTF-8}" org.mule.DefaultMuleSession.sendEvent on line 209 logged by org.mule.DefaultMuleSession
2008-10-06 17:21:59,280  [DEBUG] [connector.http.0.receiver.3] "Creating event with data: org.apache.commons.httpclient.ChunkedInputStream, for endpoint: DefaultOutboundEndpoint{endpointUri=http://localhost:8080/service/soap, connector=HttpConnector{this=a8e586, started=true, initialised=true, name='connector.http.0', disposed=false, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=true, connected=true, supportedProtocols=[http], serviceOverrides=null}, transformer=[ObjectToHttpClientMethodRequest{this=37d490, name='ObjectToHttpMethod', ignoreBadInput=false, returnClass=interface org.apache.commons.httpclient.HttpMethod, sourceTypes=[interface org.mule.api.MuleMessage, class [B, class java.lang.String, class java.io.InputStream, interface org.mule.api.transport.OutputHandler, class org.mule.transport.NullPayload]}], name='endpoint.http.localhost.8080.cache.soap', properties={}, transactionConfig=Transaction{factory=null, action=NEVER, timeout=0}, filter=null, deleteUnacceptedMessages=false, securityFilter=null, synchronous=false, initialState=started, remoteSync=false, remoteSyncTimeout=3000, endpointEncoding=UTF-8}" org.mule.DefaultMuleSession.createOutboundEvent on line 440 logged by org.mule.DefaultMuleSession
2008-10-06 17:21:59,280  [DEBUG] [connector.http.0.receiver.3] "sending event: MuleEvent: cf706f98-93ec-11dd-a826-f975255c6f26, sync=false, stop processing=false, DefaultOutboundEndpoint{endpointUri=http://localhost:8080/service/soap, connector=HttpConnector{this=a8e586, started=true, initialised=true, name='connector.http.0', disposed=false, numberOfConcurrentTransactedReceivers=4, createMultipleTransactedReceivers=true, connected=true, supportedProtocols=[http], serviceOverrides=null}, transformer=[ObjectToHttpClientMethodRequest{this=37d490, name='ObjectToHttpMethod', ignoreBadInput=false, returnClass=interface org.apache.commons.httpclient.HttpMethod, sourceTypes=[interface org.mule.api.MuleMessage, class [B, class java.lang.String, class java.io.InputStream, interface org.mule.api.transport.OutputHandler, class org.mule.transport.NullPayload]}], name='endpoint.http.localhost.8080.cache.soap', properties={}, transactionConfig=Transaction{factory=null, action=NEVER, timeout=0}, filter=null, deleteUnacceptedMessages=false, securityFilter=null, synchronous=false, initialState=started, remoteSync=false, remoteSyncTimeout=3000, endpointEncoding=UTF-8}" org.mule.DefaultMuleSession.sendEvent on line 310 logged by org.mule.DefaultMuleSession
2008-10-06 17:21:59,280  [DEBUG] [connector.http.0.receiver.3] "Borrowing a dispatcher for endpoint: http://localhost:8080/service/soap" org.mule.transport.AbstractConnector.getDispatcher on line 800 logged by org.mule.transport.http.HttpConnector
2008-10-06 17:21:59,282  [DEBUG] [connector.http.0.receiver.3] "Borrowed a dispatcher for endpoint: http://localhost:8080/service/soap = HttpClientMessageDispatcher{this=29ea31, endpoint=http://localhost:8080/service/soap, disposed=false}" org.mule.transport.AbstractConnector.getDispatcher on line 807 logged by org.mule.transport.http.HttpConnector
2008-10-06 17:21:59,282  [DEBUG] [connector.http.0.receiver.3] "Borrowed dispatcher: HttpClientMessageDispatcher{this=29ea31, endpoint=http://localhost:8080/service/soap, disposed=false}" org.mule.transport.AbstractConnector.getDispatcher on line 823 logged by org.mule.transport.http.HttpConnector
2008-10-06 17:21:59,282  [DEBUG] [connector.http.0.receiver.3] "Applying transformer ObjectToHttpMethod (org.mule.transport.http.transformers.ObjectToHttpClientMethodRequest)" org.mule.transformer.AbstractTransformer.transform on line 248 logged by org.mule.transport.http.transformers.ObjectToHttpClientMethodRequest
2008-10-06 17:21:59,282  [DEBUG] [connector.http.0.receiver.3] "Object before transform: org.mule.transport.http.HttpMessageAdapter/org.mule.transport.http.HttpMessageAdapter@8ddb93{id=cf6ffa65-93ec-11dd-a826-f975255c6f26, payload=org.apache.commons.httpclient.ChunkedInputStream, correlat..." org.mule.transformer.AbstractTransformer.transform on line 249 logged by org.mule.transport.http.transformers.ObjectToHttpClientMethodRequest
2008-10-06 17:21:59,283  [DEBUG] [connector.http.0.receiver.3] "Object after transform: org.apache.commons.httpclient.methods.PostMethod@1b82d69" org.mule.transformer.AbstractTransformer.transform on line 263 logged by org.mule.transport.http.transformers.ObjectToHttpClientMethodRequest
2008-10-06 17:21:59,284  [DEBUG] [connector.http.0.receiver.3] "The transformed object is of expected type. Type is: PostMethod" org.mule.transformer.AbstractTransformer.checkReturnClass on line 95 logged by org.mule.transport.http.transformers.ObjectToHttpClientMethodRequest

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

    http://xircles.codehaus.org/manage_email

[redijedi]

Er. Let me retract part of my previous message. I didn't notice that
my JUnit test was annotated with @Repeat(10). So, it seems that
multiple requests at approximately the same time choke Mule. Not
exactly scalable. I turned chunking off on the CXF client too. I still
receive chunking errors in the Mule output though. I've seen posts
related to chunking errors and it would appear to have something to do
with Mule's internal HTTP transport. Not sure why so few people are
experiencing this problem. This is a blocker for my application
though. It appears that mule dev either cannot consistently replicate
this issue or believes that the issue has been corrected (in previous
versions it seems). So, this may be the end of the road for me and
mule until I can review future versions. :(

On Mon, Oct 6, 2008 at 5:34 PM, Todd Orr <torr0101@...> wrote:

> Tried again. One test method that makes one response returning WS
> call. It seems as though Mule passes on the request immediately, then
> hangs. I watched the JBoss out and saw that upon Mule timing out 2
> more requests were issued to the WS. I turned on debugging in Mule
> (attached). It looks as though 2 http receivers were operating on the
> request. Not sure what all this means.
>
> On Mon, Oct 6, 2008 at 5:07 PM, Todd Orr <torr0101@...> wrote:
>> 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

[Dan Diephouse-2]

Hi Todd,

Sorry about the frustrations you're having. I did a little digging and can't seem to reproduce or find anything that would case such an error.

I bet you it is probably related to this exception:

[10-03 23:05:22] ERROR InputStreamRequestEntity [connector.http.0.receiver.4]: c
hunked stream ended unexpectedly
Unable to get the current logfile size with stat: The filename, directory name,
or volume label syntax is incorrect. (0x7b)
java.io.IOException: chunked stream ended unexpectedly
       at org.apache.commons.httpclient.

ChunkedInputStream.getChunkSizeFromInpu
tStream(ChunkedInputStream.java:252)
       at org.apache.commons.httpclient.ChunkedInputStream.nextChunk(ChunkedInp
utStream.java:221)
       at org.apache.commons.httpclient.ChunkedInputStream.read(ChunkedInputStr
eam.java:176)


Have you tried running these test on a different machine? I have no idea what that exception mean, but it seems somehow related to your system/setup and not the CXF/Mule code.

Dan

On Mon, Oct 6, 2008 at 6:17 PM, Todd Orr <torr0101@...> wrote:

Er. Let me retract part of my previous message. I didn't notice that
my JUnit test was annotated with @Repeat(10). So, it seems that
multiple requests at approximately the same time choke Mule. Not
exactly scalable. I turned chunking off on the CXF client too. I still
receive chunking errors in the Mule output though. I've seen posts
related to chunking errors and it would appear to have something to do
with Mule's internal HTTP transport. Not sure why so few people are
experiencing this problem. This is a blocker for my application
though. It appears that mule dev either cannot consistently replicate
this issue or believes that the issue has been corrected (in previous
versions it seems). So, this may be the end of the road for me and
mule until I can review future versions. :(

On Mon, Oct 6, 2008 at 5:34 PM, Todd Orr <torr0101@...> wrote:
> Tried again. One test method that makes one response returning WS
> call. It seems as though Mule passes on the request immediately, then
> hangs. I watched the JBoss out and saw that upon Mule timing out 2
> more requests were issued to the WS. I turned on debugging in Mule
> (attached). It looks as though 2 http receivers were operating on the
> request. Not sure what all this means.
>
> On Mon, Oct 6, 2008 at 5:07 PM, Todd Orr <torr0101@...> wrote:
>> 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

--
Dan Diephouse
http://mulesource.com | http://netzooid.com/blog

[redijedi]

FYI, 2.1 seems to have resolved this issue. Thanks for your feedback.

On Mon, Oct 6, 2008 at 10:11 PM, Dan Diephouse
<dan.diephouse@...> wrote:

> Hi Todd,
>
> Sorry about the frustrations you're having. I did a little digging and can't
> seem to reproduce or find anything that would case such an error.
>
> I bet you it is probably related to this exception:
>
> [10-03 23:05:22] ERROR InputStreamRequestEntity
> [connector.http.0.receiver.4]: c
> hunked stream ended unexpectedly
> Unable to get the current logfile size with stat: The filename, directory
> name,
> or volume label syntax is incorrect. (0x7b)
> java.io.IOException: chunked stream ended unexpectedly
>        at org.apache.commons.httpclient.
> ChunkedInputStream.getChunkSizeFromInpu
> tStream(ChunkedInputStream.java:252)
>        at
> org.apache.commons.httpclient.ChunkedInputStream.nextChunk(ChunkedInp
> utStream.java:221)
>        at
> org.apache.commons.httpclient.ChunkedInputStream.read(ChunkedInputStr
> eam.java:176)
>
>
> Have you tried running these test on a different machine? I have no idea
> what that exception mean, but it seems somehow related to your system/setup
> and not the CXF/Mule code.
>
> Dan
>
>
> On Mon, Oct 6, 2008 at 6:17 PM, Todd Orr <torr0101@...> wrote:
>>
>> Er. Let me retract part of my previous message. I didn't notice that
>> my JUnit test was annotated with @Repeat(10). So, it seems that
>> multiple requests at approximately the same time choke Mule. Not
>> exactly scalable. I turned chunking off on the CXF client too. I still
>> receive chunking errors in the Mule output though. I've seen posts
>> related to chunking errors and it would appear to have something to do
>> with Mule's internal HTTP transport. Not sure why so few people are
>> experiencing this problem. This is a blocker for my application
>> though. It appears that mule dev either cannot consistently replicate
>> this issue or believes that the issue has been corrected (in previous
>> versions it seems). So, this may be the end of the road for me and
>> mule until I can review future versions. :(
>>
>> On Mon, Oct 6, 2008 at 5:34 PM, Todd Orr <torr0101@...> wrote:
>> > Tried again. One test method that makes one response returning WS
>> > call. It seems as though Mule passes on the request immediately, then
>> > hangs. I watched the JBoss out and saw that upon Mule timing out 2
>> > more requests were issued to the WS. I turned on debugging in Mule
>> > (attached). It looks as though 2 http receivers were operating on the
>> > request. Not sure what all this means.
>> >
>> > On Mon, Oct 6, 2008 at 5:07 PM, Todd Orr <torr0101@...> wrote:
>> >> 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
>>
>>
>
>
>
> --
> Dan Diephouse
> http://mulesource.com | http://netzooid.com/blog
>

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

    http://xircles.codehaus.org/manage_email