hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lorenzo Moretti (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HTTPCORE-48) Make SSL IOSession decorator to use an Executor interface to execute all potentially blocking handshake tasks
Date Wed, 21 Nov 2007 17:57:43 GMT

    [ https://issues.apache.org/jira/browse/HTTPCORE-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544541
] 

Lorenzo Moretti commented on HTTPCORE-48:
-----------------------------------------

Hi all,
First I would like to congratulate all contributors for the great work on HttpCore. Impressive.

I have been working with HttpCore alpha 6 for the past weeks and recently ran into a deadlock.
I was wondering if it was related to this issue. Since I am quite new to both NIO and SSL
it might very well be that the code for my tests was inappropriate. I obtained the following
deadlock stack trace using "kill -QUIT" on the process (Linux RHEL4, jdk 1.6_02).

After the deadlock description I have very briefly explained what my test methods do. I am
not sure they are relevant since they do not do any locking themselves, but *that* in itself
might be the source of the problem! :)

Object <0x8c65a988>, if I am not mistaken, is the SharedInputBuffer.mutex.
Thread "RequestWorker_12" was spawned within ThrottlingHttpServiceHandler.handleRequest()
by this.executor.execute().
Thread "TestService_IOD_11" was spawned within AbstractMultiworkerIOReactor.execute() by this.threadFactory.newThread()

=============================
"RequestWorker_12":
  waiting to lock monitor 0x08083ac8 (object 0x8c61cd18, a org.apache.http.impl.nio.reactor.SSLIOSession),
  which is held by "TestService_IOD_11"
"TestService_IOD_11":
  waiting to lock monitor 0x08083a64 (object 0x8c65a988, a java.lang.Object),
  which is held by "RequestWorker_12"

Java stack information for the threads listed above:
===================================================
"RequestWorker_12":
        at org.apache.http.impl.nio.reactor.SSLIOSession.setEvent(SSLIOSession.java:371)
        - waiting to lock <0x8c61cd18> (a org.apache.http.impl.nio.reactor.SSLIOSession)
        at org.apache.http.impl.nio.NHttpConnectionBase.requestInput(NHttpConnectionBase.java:154)
        at org.apache.http.nio.util.SharedInputBuffer.waitForData(SharedInputBuffer.java:104)
        - locked <0x8c65a988> (a java.lang.Object)
        at org.apache.http.nio.util.SharedInputBuffer.read(SharedInputBuffer.java:137)
        - locked <0x8c65a988> (a java.lang.Object)
        at org.apache.http.nio.entity.ContentInputStream.read(ContentInputStream.java:63)
        at TestHttpServer.readData(TestHttpServer.java:451)
        at TestHttpServer.access$200(TestHttpServer.java:62)
        at TestHttpServer$TestHandler3.handle(TestHttpServer.java:312)
        at org.apache.http.nio.protocol.ThrottlingHttpServiceHandler.handleRequest(ThrottlingHttpServiceHandler.java:477)
        at org.apache.http.nio.protocol.ThrottlingHttpServiceHandler.access$000(ThrottlingHttpServiceHandler.java:91)
        at org.apache.http.nio.protocol.ThrottlingHttpServiceHandler$1.run(ThrottlingHttpServiceHandler.java:195)
        at java.lang.Thread.run(Thread.java:619)
        at DefaultRequestExecutor$Worker.run(DefaultRequestExecutor.java:43)
"TestService_IOD_11":
        at org.apache.http.nio.util.SharedInputBuffer.consumeContent(SharedInputBuffer.java:71)
        - waiting to lock <0x8c65a988> (a java.lang.Object)
        at org.apache.http.nio.protocol.ThrottlingHttpServiceHandler.inputReady(ThrottlingHttpServiceHandler.java:227)
        - locked <0x8c658408> (a org.apache.http.nio.protocol.ThrottlingHttpServiceHandler$ServerConnState)
        at org.apache.http.impl.nio.DefaultNHttpServerConnection.consumeInput(DefaultNHttpServerConnection.java:135)
        at org.apache.http.impl.nio.reactor.SSLServerIOEventDispatch.inputReady(SSLServerIOEventDispatch.java:132)
        - locked <0x8c61cd18> (a org.apache.http.impl.nio.reactor.SSLIOSession)
        at IoEventDispatchWrapper.inputReady(IoEventDispatchWrapper.java:45)
        at org.apache.http.impl.nio.reactor.BaseIOReactor.validate(BaseIOReactor.java:137)
        at org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:141)
        at org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:69)
        at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:281)
        at DebugThreadFactory$1.run(DebugThreadFactory.java:29)
        at java.lang.Thread.run(Thread.java:619)

Found 1 deadlock.


RequestWorker_12 uses:
* DefaultRequestExecutor$Worker.run(): runs the Runnable created by ThrottlingHttpServiceHandler.requestReceived().
* TestHttpServer$TestHandler3.handle(): acts as an echo by setting the response body with
the contents of the request body (status is set to SC_OK).
* TestHttpServer.readData(): transfers bytes from an HttpEntityEnclosingRequest.getEntity().getContent()
to a ByteArrayOutputStream.

TestService_IOD_11 uses:
* DebugThreadFactory$1is a dynamically created Thread based on the Runnable passed to ThreadFactory.newThread().
* DebugThreadFactory$1.run(): sets logging information before invoking Runnable.run().
* IoEventDispatchWrapper.inputReady(): invokes the IOEventDispatch.inputReady() for the dispatch
it wraps.



Thanks for your time,

-- Lorenzo


> Make SSL IOSession decorator to use an Executor interface to execute all potentially
blocking handshake tasks
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: HTTPCORE-48
>                 URL: https://issues.apache.org/jira/browse/HTTPCORE-48
>             Project: HttpComponents Core
>          Issue Type: Improvement
>          Components: HttpCore NIO
>            Reporter: Oleg Kalnichevski
>             Fix For: 4.0-beta1
>
>
> Presently the SSL IOSession decorator executes all potentially blocking handshake tasks
on the I/O thread. Use an Executor interface from java.util.concurrent to make possible the
execution of handshake tasks using worker threads, thus making the I/O thread available for
processing I/O events even if some SSL connections are blocked pending completion of a handshake
task.
> Oleg

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org


Mime
View raw message