Hi again,
It seems that the difference is that SUN ONE fails when receiving a
multipart http message as the one below:
POST /XFireServer/services/EchoServiceClean HTTP/1.1
Connection: Close
SOAPAction: ""
Content-Type: multipart/related; type="application/xop+xml";
start="<[EMAIL PROTECTED]>"; start-info="text/xml";
boundary="----=_Part_0_16316379.1168530865515"
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; XFire
Client +http://xfire.codehaus.org)
Host: localhost:9191
Content-Length: 585
------=_Part_0_16316379.1168530865515
Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
Content-Transfer-Encoding: 8bit
Content-ID: <[EMAIL PROTECTED]>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";><soap:Body><echo
xmlns="http://pt.brisa.integration.viaverde/EchoService";><in0
xmlns="http://pt.brisa.integration.viaverde/EchoService";>0123456789</in0></echo></soap:Body></soap:Envelope>
------=_Part_0_16316379.1168530865515--
Is there any way to disable this feature?
Thank you very much,
António Lourinho
On 1/11/07, Tomek Sztelak <[EMAIL PROTECTED]> wrote:
Try to disable expect-continue flag on client side :
Client client = Client.getInstance(MySOAPClient );
client.setProperty(CommonsHttpMessageSender.DISABLE_EXPECT_CONTINUE,"true");
On 1/11/07, Antonio Lourinho <[EMAIL PROTECTED]> wrote:
> Hi,
>
> In SOAP UI i receive a response.
>
> With the xfire client i cannot.
>
> Could it be an issue with commons-httpclient?
>
> I used tcpmon to watch the http request sent to the server and it
> includes the 100 continue header. Could it be it since i know that the
> server thread blocks while parsing the http header?
>
> Thank you,
> António Lourinho
>
> On 1/11/07, Tomek Sztelak <[EMAIL PROTECTED]> wrote:
> > Hi
> >
> > On 1/11/07, Antonio Lourinho <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > >
> > >
> > > I deployed the exact same war in tomcat 4 and it has no problem there.
> > >
> > But its not the same as trying another client :)
> >
> > Btw, are you able to see service wsdl w/o problems ?
> >
> > > António Lourinho
> > >
> > > On 1/11/07, Tomek Sztelak <[EMAIL PROTECTED]> wrote:
> > > > Did you try to run service from tools like SOAP UI ?
> > > >
> > > > On 1/10/07, Antonio Lourinho <[EMAIL PROTECTED]> wrote:
> > > > > Hello,
> > > > >
> > > > > Has anyone ever deployed a xfire webservice on a sun one application
server?
> > > > >
> > > > > I installed a web application with xfire jars and 5 services.
> > > > >
> > > > > I ran a client from the command line and the following occurrs:
> > > > >
> > > > > 1. The cliente is indefinitely blocked trying to read from the socket.
> > > > >
> > > > > 2. In the server side i managed to discover, in a thread dump, that
> > > > > there is a lockup as described below:
> > > > >
> > > > > "httpWorkerThread-8080-0" daemon prio=10 tid=0x277f2808 nid=0x1644
> > > > > runnable [0x2a72f000..0x2a72fc68]
> > > > > at
org.apache.coyote.http11.InternalInputBuffer.parseHeader(InternalInputBuffer.java:805)
> > > > > at
org.apache.coyote.http11.InternalInputBuffer.parseHeaders(InternalInputBuffer.java:607)
> > > > > at
com.sun.enterprise.web.connector.grizzly.ProcessorTask.parseRequest(ProcessorTask.java:731)
> > > > > at
com.sun.enterprise.web.connector.grizzly.ProcessorTask.processNonBlocked(ProcessorTask.java:572)
> > > > > at
com.sun.enterprise.web.connector.grizzly.ProcessorTask.process(ProcessorTask.java:844)
> > > > > at
com.sun.enterprise.web.connector.grizzly.ReadTask.executeProcessorTask(ReadTask.java:287)
> > > > > at
com.sun.enterprise.web.connector.grizzly.ReadTask.doTask(ReadTask.java:212)
> > > > > at
com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:252)
> > > > > at
com.sun.enterprise.web.connector.grizzly.WorkerThread.run(WorkerThread.java:75)
> > > > >
> > > > > It seems that the lockup is while parsing the http header.
> > > > >
> > > > > Thanks in advance for any help,
> > > > > António Lourinho
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe from this list please visit:
> > > > >
> > > > > http://xircles.codehaus.org/manage_email
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > -----
> > > > When one of our products stops working, we'll blame another vendor
> > > > within 24 hours.
> > > >
> > > > ---------------------------------------------------------------------
> > > > 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
> > >
> > >
> >
> >
> > --
> > -----
> > When one of our products stops working, we'll blame another vendor
> > within 24 hours.
> >
> > ---------------------------------------------------------------------
> > 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
>
>
--
-----
When one of our products stops working, we'll blame another vendor
within 24 hours.
---------------------------------------------------------------------
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
