qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lorenz Quack (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (QPID-6819) Schedule socket accepts on the thread pool
Date Thu, 12 Nov 2015 11:40:11 GMT

    [ https://issues.apache.org/jira/browse/QPID-6819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14998585#comment-14998585
] 

Lorenz Quack edited comment on QPID-6819 at 11/12/15 11:39 AM:
---------------------------------------------------------------

EDIT: this comment is now obsolete. See next comment.

I think there is something wrong here.
Yesterday  I had a test failure that seems related to this change:
{noformat}
2015-11-09 23:30:38,623         ERROR [IO-pool-Port-amqp-6] o.a.q.t.u.InternalBrokerHolder
Uncaught exception from thread IO-pool-Port-amqp-6
java.lang.NullPointerException: null
        at org.apache.qpid.server.transport.SelectorThread$SelectionTask$1.run(SelectorThread.java:191)
~[qpid-broker-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
        at org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:448) ~[qpid-broker-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
~[na:1.8.0_60]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
~[na:1.8.0_60]
        at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_60]
{noformat}
The line numbers are a little off because I had added some debug lines.
The null pointer happened on the line {{transport.acceptSocketChannel(channel);}} (I believe
currently that should be line 189 on trunk).
It is hard to see how this could null pointer but I think there is a race with {{unregisterConnection()}}.
In the unlucky case 
* {{processSelectionKeys()}} enters {{if(key.isAcceptable())}} on line 166.
* before line 168 is executed {{unregisterConnection()}} calls {{connection.getSocketChannel().register(connection.getSelectionTask().getSelector(),
0);}} (line 480) setting the attachment to {{null}}
* when {{processSelectionKeys()}} continues it will null pointer.

One other more general point about the SelectionThread/Task code. I think the intent would
be clearer if instead of calling register repeatedly to set the interest we would call interestOps(ops)
on the key. 


was (Author: lorenz.quack):
I think there is something wrong here.
Yesterday  I had a test failure that seems related to this change:
{noformat}
2015-11-09 23:30:38,623         ERROR [IO-pool-Port-amqp-6] o.a.q.t.u.InternalBrokerHolder
Uncaught exception from thread IO-pool-Port-amqp-6
java.lang.NullPointerException: null
        at org.apache.qpid.server.transport.SelectorThread$SelectionTask$1.run(SelectorThread.java:191)
~[qpid-broker-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
        at org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:448) ~[qpid-broker-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
~[na:1.8.0_60]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
~[na:1.8.0_60]
        at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_60]
{noformat}
The line numbers are a little off because I had added some debug lines.
The null pointer happened on the line {{transport.acceptSocketChannel(channel);}} (I believe
currently that should be line 189 on trunk).
It is hard to see how this could null pointer but I think there is a race with {{unregisterConnection()}}.
In the unlucky case 
* {{processSelectionKeys()}} enters {{if(key.isAcceptable())}} on line 166.
* before line 168 is executed {{unregisterConnection()}} calls {{connection.getSocketChannel().register(connection.getSelectionTask().getSelector(),
0);}} (line 480) setting the attachment to {{null}}
* when {{processSelectionKeys()}} continues it will null pointer.

One other more general point about the SelectionThread/Task code. I think the intent would
be clearer if instead of calling register repeatedly to set the interest we would call interestOps(ops)
on the key. 

> Schedule socket accepts on the thread pool
> ------------------------------------------
>
>                 Key: QPID-6819
>                 URL: https://issues.apache.org/jira/browse/QPID-6819
>             Project: Qpid
>          Issue Type: Improvement
>          Components: Java Broker
>            Reporter: Keith Wall
>            Assignee: Keith Wall
>             Fix For: qpid-java-6.0
>
>         Attachments: 0001-QPID-6819-Java-Broker-Schedule-socket-accepts-on-the.patch
>
>
> Testing with very large numbers of connections shows that accepting socket connections
in the same thread as the selector can be a bottleneck.  Change the algorithm to schedule
the accept of new socket connections as a task, deregistering {{OP_ACCEPT}} from the selector,
whilst the task is in progress.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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


Mime
View raw message