hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Berlin (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (HTTPCORE-155) Performance issues with IBM JRE 6.0
Date Wed, 24 Dec 2008 18:44:44 GMT

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

sberlin edited comment on HTTPCORE-155 at 12/24/08 10:43 AM:
----------------------------------------------------------------

The issue stems from the fact the documentation of SelectionKey states that it is OK for a
naive implementation of a SelectionKey read or write to block indefinitely if a selection
operation is already in progress.  The issue is not so much with the fact that an implementation
blocks -- it has more to do with the fact that it can block indefinitely while a selection
is in progress.

This documentation is counter to the most typical (and easiest) use of a SelectionKey.  The
average NIO program allows users to change the interestOps on any thread, and after changing
the ops, wakes up the selector.  On the Sun JVM this is allowed and works quite perfectly
-- the ops change, the selector wakes up, the selector loops again and selects on the new
interestOps.

In my opinion, the documentation on SelectionKey that is is OK to block while a selection
is in progress should be removed.  It makes implementing a high-performance NIO program much
more difficult to architect properly.

If the code were to workaround the fact that this blocking is acceptable and "normal" behavior,
the code would need to change such that code requesting a change in interestOps must:

 1) Locally replicate the desired interestOps (including all prior interestOps changes).
 2) Wakeup the Selector
 3) The selector thread must retrieve the desire interestOps from each local replication and
set the new interestOps on the actual SelectionKey.
 4) Perform the select.

In effect, this requires a duplication of SelectionKey's job.  Each SelectionKey must have
associated with it the newly desired ops that can only actually be set by the selector after
it wakes up.

      was (Author: sberlin):
    The issue stems from the fact the documentation of SelectionKey states that it is OK for
a naive implementation of a SelectionKey read or write to block indefinitely if a selection
operation is already in progress.  The issue is not so much with the fact that an implementation
blocks -- it has more to do with the fact that it can block if a selection is in progress.

This documentation is counter to the most typical (and easiest) use of a SelectionKey.  The
average NIO program allows users to change the interestOps on any thread, and after changing
the ops, wakes up the selector.  On the Sun JVM this is allowed and works quite perfectly
-- the ops change, the selector wakes up, the selector loops again and selects on the new
interestOps.

In my opinion, the documentation on SelectionKey that is is OK to block while a selection
is in progress should be removed.  It makes implementing a high-performance NIO program much
more difficult to architect properly.

If the code were to workaround the fact that this blocking is acceptable and "normal" behavior,
the code would need to change such that code requesting a change in interestOps must:

 1) Locally replicate the desired interestOps (including all prior interestOps changes).
 2) Wakeup the Selector
 3) The selector thread must retrieve the desire interestOps from each local replication and
set the new interestOps on the actual SelectionKey.
 4) Perform the select.

In effect, this requires a duplication of SelectionKey's job.  Each SelectionKey must have
associated with it the newly desired ops that can only actually be set by the selector after
it wakes up.
  
> 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, patch.08-12-18.tar.gz,
patch.08-12-22.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,
prio=5
> 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,
prio=5
> 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
Code))
> 4XESTACKTRACE          at sun/nio/ch/WindowsSelectorImpl$SubSelector.access$500(WindowsSelectorImpl.java(Compiled
Code))
> 4XESTACKTRACE          at sun/nio/ch/WindowsSelectorImpl.doSelect(WindowsSelectorImpl.java:162(Compiled
Code))
> 4XESTACKTRACE          at sun/nio/ch/SelectorImpl.lockAndDoSelect(SelectorImpl.java:69(Compiled
Code))
> 4XESTACKTRACE          at sun/nio/ch/SelectorImpl.select(SelectorImpl.java:80(Compiled
Code))
> 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


Mime
View raw message