On 1 Feb 2008, at 03:15, robert lazarski wrote:
Me == clueless . Just some general advice though. Have you thought
about submitting patches to fix the NIO issues? I notice that
someone
from the synapse team (IIRC), three weeks ago, asked you to submit a
test case for your failure in one of the jira's you posted.
Robert, I know. I'll do that as soon as I find some time.
As I've said before Michele, you easily have some of the most
complex
and long going use cases for axis2 as a non-committer. Your
involvement via patches certainly have a better chance of getting
developer attention.
In respect to this issue, I can at least try to be a bit helpful:
1) Have you tried running your code on anything else besides OSX to
see if these socket issues are OS related? I've run into several
socket and nio issues specific to linux for example.
Yes. Indeed my problem occurs on a 4 CPUs linux box
2) Have you tried running http 1.0 instead of 1.1 ?
Yes, it doesn't make any difference.
3) SimpleHTTPServer has never been meant for production use, so stop
trying to use it like that. Fixing the nio issues seem to me to
be the
better path.
Yes, but the nio code comes from Synapse... and this would mean
digging into the Synapse code (which I don't know).
My understanding of TIME_WAIT, via an old usenet post of mine, was
best explained to me this way:
"After the connection is closed, there might still be some stray
packets that were delayed and could still arrive. The TIME_WAIT
status retains a record of a recent connection, so that the system
can recognize these as delay packets."
Are these connections going from CLOSE_WAIT to TIME_WAIT? Can
you do
a 'netstat -anp' and show the transition states?
Well, netstat doesn't show me any transition, only the current state
What issue do you
have with TIME_WAIT exactly?
The number of connections in TIME_WAIT state grows very fast to a
value > 500, and after that the my app. hangs (without crashing, it
just freezes)
Anyways, since SimpleHTTPServer is deep involved into the several
hundred unit / integration tests, I don't see major changes
happening
at this point.
4) Obviously try the latest axis2 nightlies and post questions to
the
http commons / reactor list. Its possible the latest snapshot of
reactor fixes your issue and can be promoted to the upcomming axis2
1.4 .
I'll try.
HTH,
Robert
Michele
On Jan 31, 2008 7:48 PM, Michele Mazzucco
<[EMAIL PROTECTED]> wrote:
Hello again,
I've tried to write a TransportListener which uses Jetty as http
server
-- but I had no success: when requests come I get the following
error
<?xml version='1.0' encoding='utf-8'?><soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:wsa="http://www.w3.org/2005/08/
addressing"><soapenv:Header><wsa:Action>http://www.w3.org/2005/08/
addressing/soap/fault</wsa:Action></
soapenv:Header><soapenv:Body><soapenv:Fault><faultcode>soapenv:Serv
er
</faultcode><faultstring>java.lang.NullPointerException</
faultstring><detail><Exception>org.apache.axis2.AxisFault:
java.lang.NullPointerException
at
org.apache.axis2.transport.http.AxisServlet.doPost
(AxisServlet.java:182)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:
709)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:
802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:178)
at
org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:126)
at
org.apache.catalina.valves.ErrorReportValve.invoke
(ErrorReportValve.java:105)
at
org.apache.catalina.core.StandardEngineValve.invoke
(StandardEngineValve.java:107)
at
org.apache.catalina.connector.CoyoteAdapter.service
(CoyoteAdapter.java:148)
at
org.apache.coyote.http11.Http11Processor.process
(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol
$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:
664)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket
(PoolTcpEndpoint.java:527)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt
(LeaderFollowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool
$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.lang.NullPointerException
at
ncl.qosp.modules.manager.RouterDispatcher.isFault
(RouterDispatcher.java:230)
at
ncl.qosp.modules.manager.RouterDispatcher.invoke
(RouterDispatcher.java:267)
at org.apache.axis2.engine.Phase.invoke(Phase.java:292)
at
org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:212)
at
org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:132)
at
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostR
eq
uest(HTTPTransportUtils.java:275)
at
org.apache.axis2.transport.http.AxisServlet.doPost
(AxisServlet.java:120)
... 16 more
I'm attaching my implementation.
Any help is appreciated,
Michele
On Thu, 2008-01-31 at 19:47 +0000, Michele Mazzucco wrote:
Hello everybody,
I'm facing a serious problem with too many connections left in
TIME_WAIT
state, causing my system to hang.
Since on the server side I run some ServiceClient instances as
well I
wasn't sure about the root of my problem, but after some
investigations
I've found out that the responsible for this is the
SimpleHTTPServer
used as transport receiver for incoming http requests.
Given that the NIO listener/sender are not stable (see the JIRAs
below)
I have to stick with these. Is there anything I can do?
Is there any way to inject a custom http connection manager and
manually
clean up the unused connections?
Thanks in advance,
Michele
[1] https://issues.apache.org/jira/browse/AXIS2-3473
[2] http://www.mail-archive.com/axis-user@ws.apache.org/
msg37314.html
[3] https://issues.apache.org/jira/browse/AXIS2-3428
------------------------------------------------------------------
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-------------------------------------------------------------------
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
