hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc Beyerle (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HTTPCORE-155) Performance issues with IBM JRE 6.0
Date Thu, 18 Dec 2008 17:57:44 GMT

    [ https://issues.apache.org/jira/browse/HTTPCORE-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657832#action_12657832

Marc Beyerle commented on HTTPCORE-155:

Hi Oleg,

Thank you for your positive feedback. You are really tough to convince ;-) Following your
suggestions, I changed a few things in the code itself, without changing the ideas behind
the patch: The queue is a regular instance member now, and I don't exhibit the queue itself
to the "outside world", but rather only offer an add()... method.

In addition, I now changed the existing code as little as possible - for example, I moved
the processing of the queue in an extra method, so that the amount of lines of code in the
main loop in AbstractIOReactor grows as little as possible.

Here's a bit more explanation of what I implemented, just to give you an idea about the decisions
I had to take: Since the constructor of IOSessionImpl already depends on SelectionKey and
contains exception handling, it's not much additional cost to add a reference to the calling
AbstractIOReactor (plus check) there.

The reason, why the loop in processPendingInterestOps() is entirely within the synchronized
block, is to process all pending operations, which exist at the time of invocation, in one
operation. If for example only the interestOpsQueue.remove() call was placed within the synchronized
block, then this would allow the queue to grow while the processing is in progress.

The only detail that I can think of right now, which one could implement differently, is to
move the check for a valid operationType from addInterestOpsQueueElement() to the constructor
of IOSessionQueueElement. But this would require exception handling there, which is more expensive
than the if/else check in the method. Anyways, the queue elements are checked in detail in
the add()... method, before they enter the queue.

I ran some tests with both JVMs again, and the above changes didn't have a negative effect
on throughput. Again, I couldn't observe any exceptions.

> Performance issues with IBM JRE 6.0
> -----------------------------------
>                 Key: HTTPCORE-155
>                 URL: https://issues.apache.org/jira/browse/HTTPCORE-155
>             Project: HttpComponents HttpCore
>          Issue Type: Bug
>          Components: HttpCore NIO
>    Affects Versions: 4.0-beta1
>         Environment: Windows 2003 SP2 - IBM J2RE 1.6.0 build 2.4 - HTTPCore Beta1 - Dual
Core CPU 3.0Ghz - 1Gbps networking
>            Reporter: Tom McSorley
>             Fix For: 4.1
>         Attachments: AbstractIOReactor.diff, AbstractIOReactor.java, IOSessionImpl.diff,
IOSessionImpl.java, javacore.20081203.153723.32300.0001.txt, patch.08-12-17.tar.gz
> I'm issuing a second HTTP Request on a connection that has very recently returned a null
for the submitRequest() call...  this 2nd request is being issued approximately 500ms after
the submitRequest() null is returned... so the connection has just been established, an HTTP
Request/Response-200 cycle has completed just prior to this 2nd request being issued.  I'm
seeing unusually long delays in the requestOutput() call (verified by surrounding timing prints)...
that can range anywhere from a few milliseconds on up to 60 seconds...  It eventually unwinds,
and then the submitRequest() is called... this 2nd request is dispatched and works fine...
but, it is delayed considerably...  Is this a known issue and is there a possible work-around?
> Here's the JVM related thread information:
> The thread being delayed and stuck in the requestOutput() call for a long time (mostly
longer than 5 seconds):
> 3XMTHREADINFO      "pool-2-thread-5" TID:0x2AEECE00, j9thread_t:0x2A7189A8, state:B,
> 3XMTHREADINFO1            (native thread ID:0x1B44, native priority:0x5, native policy:UNKNOWN)
> 4XESTACKTRACE          at sun/nio/ch/SelectionKeyImpl.interestOps(SelectionKeyImpl.java:60)
> 4XESTACKTRACE          at org/apache/http/impl/nio/reactor/IOSessionImpl.setEvent(IOSessionImpl.java:113)
> 4XESTACKTRACE          at org/apache/http/impl/nio/NHttpConnectionBase.requestOutput(NHttpConnectionBase.java:158)
> .... (non important stack information removed)
> 4XESTACKTRACE          at java/util/concurrent/ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:919)
> 4XESTACKTRACE          at java/lang/Thread.run(Thread.java:735)
> Here's the monitor that this thread is blocked and waiting on:
> 2LKMONINUSE      sys_mon_t:0x2A708AF8 infl_mon_t: 0x2A708B30:
> 3LKMONOBJECT       sun/nio/ch/Util$1@00B09208/00B09214: Flat locked by "I/O dispatcher
7" (0x2A208E00), entry count 1
> 3LKWAITERQ            Waiting to enter:
> 3LKWAITER                "pool-2-thread-5" (0x2AEECE00)
> And here's the thread that currently has this monitor locked:
> 3XMTHREADINFO      "I/O dispatcher 7" TID:0x2A208E00, j9thread_t:0x2A6EC73C, state:R,
> 3XMTHREADINFO1            (native thread ID:0x830, native priority:0x5, native policy:UNKNOWN)
> 4XESTACKTRACE          at sun/nio/ch/WindowsSelectorImpl$SubSelector.poll0(Native Method)
> 4XESTACKTRACE          at sun/nio/ch/WindowsSelectorImpl$SubSelector.poll(WindowsSelectorImpl.java:308(Compiled
> 4XESTACKTRACE          at sun/nio/ch/WindowsSelectorImpl$SubSelector.access$500(WindowsSelectorImpl.java(Compiled
> 4XESTACKTRACE          at sun/nio/ch/WindowsSelectorImpl.doSelect(WindowsSelectorImpl.java:162(Compiled
> 4XESTACKTRACE          at sun/nio/ch/SelectorImpl.lockAndDoSelect(SelectorImpl.java:69(Compiled
> 4XESTACKTRACE          at sun/nio/ch/SelectorImpl.select(SelectorImpl.java:80(Compiled
> 4XESTACKTRACE          at org/apache/http/impl/nio/reactor/AbstractIOReactor.execute(AbstractIOReactor.java:121)
> 4XESTACKTRACE          at org/apache/http/impl/nio/reactor/BaseIOReactor.execute(BaseIOReactor.java:70)
> 4XESTACKTRACE          at org/apache/http/impl/nio/reactor/AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:318)
> 4XESTACKTRACE          at java/lang/Thread.run(Thread.java:735)
> I should also note that we're attempting to use 1000 client instances on this single
system... each with potentially 2 active connections simultaneously... there is also virtually
no CPU load (i.e. less then 5%) on this system...

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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message