[jira] [Commented] (QPIDJMS-430) Lock-Free FifoMessageQueue
[ https://issues.apache.org/jira/browse/QPIDJMS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16687215#comment-16687215 ] ASF GitHub Bot commented on QPIDJMS-430: Github user franz1981 commented on the issue: https://github.com/apache/qpid-jms/pull/26 I have TBH that I'm not getting such a big boost as I was expecting, but probably because there are other bottlenecks (the consumer side on the broker) that are not' helping to measure it correctly: at least now `dequeueNoWait` is really a lock-free operation and if used could help to achieve a great performance boost. > Lock-Free FifoMessageQueue > -- > > Key: QPIDJMS-430 > URL: https://issues.apache.org/jira/browse/QPIDJMS-430 > Project: Qpid JMS > Issue Type: Improvement >Reporter: Francesco Nigro >Priority: Minor > Fix For: 0.39.0 > > > A lock-free single producer multi consumer double ended queue would allow for > the common cases (enqueue/dequeue) to benefit from a better throughput and > lower latencies while allowing busy spin waits to benefits from some > additional boost -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-jms issue #26: QPIDJMS-430 Lock-Free FifoMessageQueue
Github user franz1981 commented on the issue: https://github.com/apache/qpid-jms/pull/26 I have TBH that I'm not getting such a big boost as I was expecting, but probably because there are other bottlenecks (the consumer side on the broker) that are not' helping to measure it correctly: at least now `dequeueNoWait` is really a lock-free operation and if used could help to achieve a great performance boost. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1964) [c] pn_proactor_wait() can return empty event batches.
[
https://issues.apache.org/jira/browse/PROTON-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway updated PROTON-1964:
Description:
The bug PROTON-1586 had events returned after a connection was
TRANSPORT_CLOSED and no longer existed (original reproducer below) The bug
still exists in a more subtle form - the proactor can return an *empty* event
batch after TRANSPORT_CLOSED. This does not cause segfaults but is incorrect
behavior according to the proactor documentation.
It can be reproduced by editing TEST_CASE("proactor_proton_1586") in
c/tests/proactor_tests.cpp, read the comments there.
The original fix to PROTON-1586 was to have the connection_driver batch to hide
events after TRANSPORT_CLOSE by returning NULL as if the batch were empty.
However, that is too late to prevent the batch being returned by the proactor -
from the proactors perspective it is not empty, it contains
CONNECTION_LOCAL_CLOSE but it looks empty to the user.
This is really a bug in the pn_connection_driver, not the proactor, and it
should be fixed there so that all proactors and non-proactor applications will
benefit.
Original reproducer:
Run the send examples code with an invalid hostname like shown in the following
-
{noformat}
[gmurthy@localhost build]$ pwd
/home/gmurthy/opensource/qpid-proton/build
[gmurthy@localhost build]$
[gmurthy@localhost build]$
[gmurthy@localhost build]$ examples/c/send nosuchhost
PN_TRANSPORT_CLOSED: proton:io: No address associated with hostname - connect
to nosuchhost:5672
epoll proactor failure in
/home/gmurthy/opensource/qpid-proton/proton-c/src/proactor/epoll.c:648: "arming
polled file descriptor": No such file or directory
Aborted (core dumped)
[gmurthy@localhost build]$
{noformat}
The proactor code coredumps.
was:
The bug PROTON-1586 had events returned after a connection was
TRANSPORT_CLOSED and no longer existed (original reproducer below) The bug
still exists in a more subtle form - the proactor can return an *empty* event
batch after TRANSPORT_CLOSED. This does not cause segfaults but is incorrect
behavior according to the proactor documentation.
It can be reproduced by editing TEST_CASE("proactor_proton_1586") in
c/tests/proactor_tests.cpp, read the comments there.
The original fix to PROTON-1586 was to have the connection_driver batch to hide
events after TRANSPORT_CLOSE by returning NULL as if the batch were empty.
However, that is too late to prevent the batch being returned by the proactor -
from the proactors perspective it is not empty, it contains
CONNECTION_LOCAL_CLOSE but it looks empty to the user.
Original reproducer:
Run the send examples code with an invalid hostname like shown in the following
-
{noformat}
[gmurthy@localhost build]$ pwd
/home/gmurthy/opensource/qpid-proton/build
[gmurthy@localhost build]$
[gmurthy@localhost build]$
[gmurthy@localhost build]$ examples/c/send nosuchhost
PN_TRANSPORT_CLOSED: proton:io: No address associated with hostname - connect
to nosuchhost:5672
epoll proactor failure in
/home/gmurthy/opensource/qpid-proton/proton-c/src/proactor/epoll.c:648: "arming
polled file descriptor": No such file or directory
Aborted (core dumped)
[gmurthy@localhost build]$
{noformat}
The proactor code coredumps.
> [c] pn_proactor_wait() can return empty event batches.
> --
>
> Key: PROTON-1964
> URL: https://issues.apache.org/jira/browse/PROTON-1964
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
> Fix For: proton-c-0.18.0
>
>
> The bug PROTON-1586 had events returned after a connection was
> TRANSPORT_CLOSED and no longer existed (original reproducer below) The bug
> still exists in a more subtle form - the proactor can return an *empty* event
> batch after TRANSPORT_CLOSED. This does not cause segfaults but is incorrect
> behavior according to the proactor documentation.
> It can be reproduced by editing TEST_CASE("proactor_proton_1586") in
> c/tests/proactor_tests.cpp, read the comments there.
> The original fix to PROTON-1586 was to have the connection_driver batch to
> hide events after TRANSPORT_CLOSE by returning NULL as if the batch were
> empty. However, that is too late to prevent the batch being returned by the
> proactor - from the proactors perspective it is not empty, it contains
> CONNECTION_LOCAL_CLOSE but it looks empty to the user.
> This is really a bug in the pn_connection_driver, not the proactor, and it
> should be fixed there so that all proactors and non-proactor applications
> will benefit.
> Original reproducer:
> Run the send examples code with an invalid hostname like shown in the
> following -
> {noformat}
> [gmurthy@localhost build]$ pwd
> /home/gmurthy
[jira] [Commented] (QPIDJMS-430) Lock-Free FifoMessageQueue
[ https://issues.apache.org/jira/browse/QPIDJMS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16687209#comment-16687209 ] ASF GitHub Bot commented on QPIDJMS-430: Github user tabish121 commented on the issue: https://github.com/apache/qpid-jms/pull/26 Yes, that test is exposing some issues in the 5.x broker which is unrelated to this change. > Lock-Free FifoMessageQueue > -- > > Key: QPIDJMS-430 > URL: https://issues.apache.org/jira/browse/QPIDJMS-430 > Project: Qpid JMS > Issue Type: Improvement >Reporter: Francesco Nigro >Priority: Minor > Fix For: 0.39.0 > > > A lock-free single producer multi consumer double ended queue would allow for > the common cases (enqueue/dequeue) to benefit from a better throughput and > lower latencies while allowing busy spin waits to benefits from some > additional boost -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1964) [c] pn_proactor_wait() can return empty event batches.
[
https://issues.apache.org/jira/browse/PROTON-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway updated PROTON-1964:
Description:
The bug PROTON-1586 had events returned after a connection was
TRANSPORT_CLOSED and no longer existed (original reproducer below) The bug
still exists in a more subtle form - the proactor can return an *empty* event
batch after TRANSPORT_CLOSED. This does not cause segfaults but is incorrect
behavior according to the proactor documentation.
It can be reproduced by editing TEST_CASE("proactor_proton_1586") in
c/tests/proactor_tests.cpp, read the comments there.
The original fix to PROTON-1586 was to have the connection_driver batch to hide
events after TRANSPORT_CLOSE by returning NULL as if the batch were empty.
However, that is too late to prevent the batch being returned by the proactor -
from the proactors perspective it is not empty, it contains
CONNECTION_LOCAL_CLOSE but it looks empty to the user.
Original reproducer:
Run the send examples code with an invalid hostname like shown in the following
-
{noformat}
[gmurthy@localhost build]$ pwd
/home/gmurthy/opensource/qpid-proton/build
[gmurthy@localhost build]$
[gmurthy@localhost build]$
[gmurthy@localhost build]$ examples/c/send nosuchhost
PN_TRANSPORT_CLOSED: proton:io: No address associated with hostname - connect
to nosuchhost:5672
epoll proactor failure in
/home/gmurthy/opensource/qpid-proton/proton-c/src/proactor/epoll.c:648: "arming
polled file descriptor": No such file or directory
Aborted (core dumped)
[gmurthy@localhost build]$
{noformat}
The proactor code coredumps.
was:
The original but
Run the send examples code with an invalid hostname like shown in the following
-
{noformat}
[gmurthy@localhost build]$ pwd
/home/gmurthy/opensource/qpid-proton/build
[gmurthy@localhost build]$
[gmurthy@localhost build]$
[gmurthy@localhost build]$ examples/c/send nosuchhost
PN_TRANSPORT_CLOSED: proton:io: No address associated with hostname - connect
to nosuchhost:5672
epoll proactor failure in
/home/gmurthy/opensource/qpid-proton/proton-c/src/proactor/epoll.c:648: "arming
polled file descriptor": No such file or directory
Aborted (core dumped)
[gmurthy@localhost build]$
{noformat}
The proactor code coredumps.
> [c] pn_proactor_wait() can return empty event batches.
> --
>
> Key: PROTON-1964
> URL: https://issues.apache.org/jira/browse/PROTON-1964
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
> Fix For: proton-c-0.18.0
>
>
> The bug PROTON-1586 had events returned after a connection was
> TRANSPORT_CLOSED and no longer existed (original reproducer below) The bug
> still exists in a more subtle form - the proactor can return an *empty* event
> batch after TRANSPORT_CLOSED. This does not cause segfaults but is incorrect
> behavior according to the proactor documentation.
> It can be reproduced by editing TEST_CASE("proactor_proton_1586") in
> c/tests/proactor_tests.cpp, read the comments there.
> The original fix to PROTON-1586 was to have the connection_driver batch to
> hide events after TRANSPORT_CLOSE by returning NULL as if the batch were
> empty. However, that is too late to prevent the batch being returned by the
> proactor - from the proactors perspective it is not empty, it contains
> CONNECTION_LOCAL_CLOSE but it looks empty to the user.
> Original reproducer:
> Run the send examples code with an invalid hostname like shown in the
> following -
> {noformat}
> [gmurthy@localhost build]$ pwd
> /home/gmurthy/opensource/qpid-proton/build
> [gmurthy@localhost build]$
> [gmurthy@localhost build]$
> [gmurthy@localhost build]$ examples/c/send nosuchhost
> PN_TRANSPORT_CLOSED: proton:io: No address associated with hostname - connect
> to nosuchhost:5672
> epoll proactor failure in
> /home/gmurthy/opensource/qpid-proton/proton-c/src/proactor/epoll.c:648:
> "arming polled file descriptor": No such file or directory
> Aborted (core dumped)
> [gmurthy@localhost build]$
> {noformat}
> The proactor code coredumps.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-jms issue #26: QPIDJMS-430 Lock-Free FifoMessageQueue
Github user tabish121 commented on the issue: https://github.com/apache/qpid-jms/pull/26 Yes, that test is exposing some issues in the 5.x broker which is unrelated to this change. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-430) Lock-Free FifoMessageQueue
[ https://issues.apache.org/jira/browse/QPIDJMS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16687204#comment-16687204 ] ASF GitHub Bot commented on QPIDJMS-430: Github user franz1981 commented on the issue: https://github.com/apache/qpid-jms/pull/26 The failing test `JmsConnectionCloseVariationsTest.testCloseBeforeBrokerStoppedRepeated` seems that is not allocating any `FifoMessageQueue`: i suppose its failure is indipendent by this PR. > Lock-Free FifoMessageQueue > -- > > Key: QPIDJMS-430 > URL: https://issues.apache.org/jira/browse/QPIDJMS-430 > Project: Qpid JMS > Issue Type: Improvement >Reporter: Francesco Nigro >Priority: Minor > Fix For: 0.39.0 > > > A lock-free single producer multi consumer double ended queue would allow for > the common cases (enqueue/dequeue) to benefit from a better throughput and > lower latencies while allowing busy spin waits to benefits from some > additional boost -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-jms issue #26: QPIDJMS-430 Lock-Free FifoMessageQueue
Github user franz1981 commented on the issue: https://github.com/apache/qpid-jms/pull/26 The failing test `JmsConnectionCloseVariationsTest.testCloseBeforeBrokerStoppedRepeated` seems that is not allocating any `FifoMessageQueue`: i suppose its failure is indipendent by this PR. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1964) [c] pn_proactor_wait() can return empty event batches.
[
https://issues.apache.org/jira/browse/PROTON-1964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway updated PROTON-1964:
Description:
The original but
Run the send examples code with an invalid hostname like shown in the following
-
{noformat}
[gmurthy@localhost build]$ pwd
/home/gmurthy/opensource/qpid-proton/build
[gmurthy@localhost build]$
[gmurthy@localhost build]$
[gmurthy@localhost build]$ examples/c/send nosuchhost
PN_TRANSPORT_CLOSED: proton:io: No address associated with hostname - connect
to nosuchhost:5672
epoll proactor failure in
/home/gmurthy/opensource/qpid-proton/proton-c/src/proactor/epoll.c:648: "arming
polled file descriptor": No such file or directory
Aborted (core dumped)
[gmurthy@localhost build]$
{noformat}
The proactor code coredumps.
was:
Run the send examples code with an invalid hostname like shown in the following
-
{noformat}
[gmurthy@localhost build]$ pwd
/home/gmurthy/opensource/qpid-proton/build
[gmurthy@localhost build]$
[gmurthy@localhost build]$
[gmurthy@localhost build]$ examples/c/send nosuchhost
PN_TRANSPORT_CLOSED: proton:io: No address associated with hostname - connect
to nosuchhost:5672
epoll proactor failure in
/home/gmurthy/opensource/qpid-proton/proton-c/src/proactor/epoll.c:648: "arming
polled file descriptor": No such file or directory
Aborted (core dumped)
[gmurthy@localhost build]$
{noformat}
The proactor code coredumps.
> [c] pn_proactor_wait() can return empty event batches.
> --
>
> Key: PROTON-1964
> URL: https://issues.apache.org/jira/browse/PROTON-1964
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Reporter: Alan Conway
>Assignee: Alan Conway
>Priority: Major
> Fix For: proton-c-0.18.0
>
>
> The original but
>
> Run the send examples code with an invalid hostname like shown in the
> following -
> {noformat}
> [gmurthy@localhost build]$ pwd
> /home/gmurthy/opensource/qpid-proton/build
> [gmurthy@localhost build]$
> [gmurthy@localhost build]$
> [gmurthy@localhost build]$ examples/c/send nosuchhost
> PN_TRANSPORT_CLOSED: proton:io: No address associated with hostname - connect
> to nosuchhost:5672
> epoll proactor failure in
> /home/gmurthy/opensource/qpid-proton/proton-c/src/proactor/epoll.c:648:
> "arming polled file descriptor": No such file or directory
> Aborted (core dumped)
> [gmurthy@localhost build]$
> {noformat}
> The proactor code coredumps.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-430) Lock-Free FifoMessageQueue
[ https://issues.apache.org/jira/browse/QPIDJMS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16687185#comment-16687185 ] ASF GitHub Bot commented on QPIDJMS-430: Github user franz1981 commented on the issue: https://github.com/apache/qpid-jms/pull/26 Just as a reference: I'm getting about 80 M msg/sec with the new `FifoMessageQueue` while near 2.5 M msg/sec with the original one. On a end-to-end test I'm getting a 20% more throughput with my machine (that has not many cores and not fast ones). > Lock-Free FifoMessageQueue > -- > > Key: QPIDJMS-430 > URL: https://issues.apache.org/jira/browse/QPIDJMS-430 > Project: Qpid JMS > Issue Type: Improvement >Reporter: Francesco Nigro >Priority: Minor > Fix For: 0.39.0 > > > A lock-free single producer multi consumer double ended queue would allow for > the common cases (enqueue/dequeue) to benefit from a better throughput and > lower latencies while allowing busy spin waits to benefits from some > additional boost -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-jms issue #26: QPIDJMS-430 Lock-Free FifoMessageQueue
Github user franz1981 commented on the issue: https://github.com/apache/qpid-jms/pull/26 Just as a reference: I'm getting about 80 M msg/sec with the new `FifoMessageQueue` while near 2.5 M msg/sec with the original one. On a end-to-end test I'm getting a 20% more throughput with my machine (that has not many cores and not fast ones). --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1964) [c] pn_proactor_wait() can return empty event batches.
Alan Conway created PROTON-1964:
---
Summary: [c] pn_proactor_wait() can return empty event batches.
Key: PROTON-1964
URL: https://issues.apache.org/jira/browse/PROTON-1964
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Reporter: Alan Conway
Assignee: Alan Conway
Fix For: proton-c-0.18.0
Run the send examples code with an invalid hostname like shown in the following
-
{noformat}
[gmurthy@localhost build]$ pwd
/home/gmurthy/opensource/qpid-proton/build
[gmurthy@localhost build]$
[gmurthy@localhost build]$
[gmurthy@localhost build]$ examples/c/send nosuchhost
PN_TRANSPORT_CLOSED: proton:io: No address associated with hostname - connect
to nosuchhost:5672
epoll proactor failure in
/home/gmurthy/opensource/qpid-proton/proton-c/src/proactor/epoll.c:648: "arming
polled file descriptor": No such file or directory
Aborted (core dumped)
[gmurthy@localhost build]$
{noformat}
The proactor code coredumps.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1177) Edge router does not show any node in the network
[ https://issues.apache.org/jira/browse/DISPATCH-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16687116#comment-16687116 ] ASF GitHub Bot commented on DISPATCH-1177: -- Github user ganeshmurthy commented on the issue: https://github.com/apache/qpid-dispatch/pull/420 Should it say "Router is Standalone or Edge - No Router List". > Edge router does not show any node in the network > - > > Key: DISPATCH-1177 > URL: https://issues.apache.org/jira/browse/DISPATCH-1177 > Project: Qpid Dispatch > Issue Type: Bug > Components: Management Agent >Reporter: Fernando Giorgetti >Assignee: Ganesh Murthy >Priority: Major > > When running "qdstat -n" on an Edge-Router, which is connected to its uplink > interior router, no nodes are displayed and message says it is a Standalone > instance: _*"Router is Standalone - No Router List".*_ -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch issue #420: DISPATCH-1177 - Added new option -e to qdstat. Thi...
Github user ganeshmurthy commented on the issue: https://github.com/apache/qpid-dispatch/pull/420 Should it say "Router is Standalone or Edge - No Router List". --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1186) qdstat to include csv output format
Chuck Rolke created DISPATCH-1186: - Summary: qdstat to include csv output format Key: DISPATCH-1186 URL: https://issues.apache.org/jira/browse/DISPATCH-1186 Project: Qpid Dispatch Issue Type: Improvement Components: Management Agent Affects Versions: 1.4.1 Reporter: Chuck Rolke qdstat text output is difficult to manage after a cut and paste. For instance, _qdstat -l_ shows some rows where the columns are blank. This makes it difficult to reconstruct the original display given just the body text. See _qdstat -l_ example in [https://raw.githubusercontent.com/apache/qpid-dispatch/master/docs/books/user-guide/monitoring-using-qdstat.adoc] Even having a two-word column title "conn id" adds confusion. With a CSV format and quoted strings this table could be communicated through email, chat, or Jira with authority. Readers would not have to guess about which data goes in which columns. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1177) Edge router does not show any node in the network
[ https://issues.apache.org/jira/browse/DISPATCH-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16687024#comment-16687024 ] ASF GitHub Bot commented on DISPATCH-1177: -- Github user fgiorgetti commented on the issue: https://github.com/apache/qpid-dispatch/pull/420 @ganeshmurthy I have executed qdstat with -e on a formed network here and I see the "edge" routers from an interior router, and the "interior" router when executed against edge. It makes sense. What about the message when we run "qdstat -n" on an edge router, which shows: "Router is Standalone - No Router List". Is it changing? Thanks. > Edge router does not show any node in the network > - > > Key: DISPATCH-1177 > URL: https://issues.apache.org/jira/browse/DISPATCH-1177 > Project: Qpid Dispatch > Issue Type: Bug > Components: Management Agent >Reporter: Fernando Giorgetti >Assignee: Ganesh Murthy >Priority: Major > > When running "qdstat -n" on an Edge-Router, which is connected to its uplink > interior router, no nodes are displayed and message says it is a Standalone > instance: _*"Router is Standalone - No Router List".*_ -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch issue #420: DISPATCH-1177 - Added new option -e to qdstat. Thi...
Github user fgiorgetti commented on the issue: https://github.com/apache/qpid-dispatch/pull/420 @ganeshmurthy I have executed qdstat with -e on a formed network here and I see the "edge" routers from an interior router, and the "interior" router when executed against edge. It makes sense. What about the message when we run "qdstat -n" on an edge router, which shows: "Router is Standalone - No Router List". Is it changing? Thanks. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-430) Lock-Free FifoMessageQueue
[ https://issues.apache.org/jira/browse/QPIDJMS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16686991#comment-16686991 ] ASF GitHub Bot commented on QPIDJMS-430: Github user jdanekrh commented on the issue: https://github.com/apache/qpid-jms/pull/26 Won't work with JDK < 8 is fine with qpid-jms, I think https://github.com/apache/qpid-jms/blob/master/pom.xml#L37-L39 I'll check tomorrow if IBM JDK supports this. I am fairly sure OpenJDK will have it... > Lock-Free FifoMessageQueue > -- > > Key: QPIDJMS-430 > URL: https://issues.apache.org/jira/browse/QPIDJMS-430 > Project: Qpid JMS > Issue Type: Improvement >Reporter: Francesco Nigro >Priority: Minor > Fix For: 0.39.0 > > > A lock-free single producer multi consumer double ended queue would allow for > the common cases (enqueue/dequeue) to benefit from a better throughput and > lower latencies while allowing busy spin waits to benefits from some > additional boost -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-jms issue #26: QPIDJMS-430 Lock-Free FifoMessageQueue
Github user jdanekrh commented on the issue: https://github.com/apache/qpid-jms/pull/26 Won't work with JDK < 8 is fine with qpid-jms, I think https://github.com/apache/qpid-jms/blob/master/pom.xml#L37-L39 I'll check tomorrow if IBM JDK supports this. I am fairly sure OpenJDK will have it... --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-431) Refactor the Failover provider to improve performance
[ https://issues.apache.org/jira/browse/QPIDJMS-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16686988#comment-16686988 ] ASF subversion and git services commented on QPIDJMS-431: - Commit be560e69bf8d059166871c86f177abb6ae4fbbe6 in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=be560e6 ] QPIDJMS-431 Refactor the FailoverProvider to improve performance Refactor how the failover provider handles the workload passing though it and how it deals with connection failures to make its presence as transparent as possible to overall client performance. > Refactor the Failover provider to improve performance > - > > Key: QPIDJMS-431 > URL: https://issues.apache.org/jira/browse/QPIDJMS-431 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.38.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Major > Fix For: 0.39.0 > > > Currently when using failover with the client there is a significant impact > on client performance due to the way the provider serializes work. We can > refactor this to handle most of the work on the clients thread and hand off > to the underlying provider the remainder of the work. This reduces the > impact on senders to a relatively small amount and the consumer side sees > nearly transparent impacts. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-430) Lock-Free FifoMessageQueue
[ https://issues.apache.org/jira/browse/QPIDJMS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16686954#comment-16686954 ] ASF GitHub Bot commented on QPIDJMS-430: Github user franz1981 commented on the issue: https://github.com/apache/qpid-jms/pull/26 It won't work with JDK < 8 and is specific of oracle AFAIK (I could be wrong of course!) > Lock-Free FifoMessageQueue > -- > > Key: QPIDJMS-430 > URL: https://issues.apache.org/jira/browse/QPIDJMS-430 > Project: Qpid JMS > Issue Type: Improvement >Reporter: Francesco Nigro >Priority: Minor > Fix For: 0.39.0 > > > A lock-free single producer multi consumer double ended queue would allow for > the common cases (enqueue/dequeue) to benefit from a better throughput and > lower latencies while allowing busy spin waits to benefits from some > additional boost -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-jms issue #26: QPIDJMS-430 Lock-Free FifoMessageQueue
Github user franz1981 commented on the issue: https://github.com/apache/qpid-jms/pull/26 It won't work with JDK < 8 and is specific of oracle AFAIK (I could be wrong of course!) --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-jms issue #26: QPIDJMS-430 Lock-Free FifoMessageQueue
Github user jdanekrh commented on the issue: https://github.com/apache/qpid-jms/pull/26 Wouldn't `@Contended` annotation work just as well? http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-November/007309.html (I just googled it...) --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-430) Lock-Free FifoMessageQueue
[ https://issues.apache.org/jira/browse/QPIDJMS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16686944#comment-16686944 ] ASF GitHub Bot commented on QPIDJMS-430: Github user jdanekrh commented on the issue: https://github.com/apache/qpid-jms/pull/26 Wouldn't `@Contended` annotation work just as well? http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-November/007309.html (I just googled it...) > Lock-Free FifoMessageQueue > -- > > Key: QPIDJMS-430 > URL: https://issues.apache.org/jira/browse/QPIDJMS-430 > Project: Qpid JMS > Issue Type: Improvement >Reporter: Francesco Nigro >Priority: Minor > Fix For: 0.39.0 > > > A lock-free single producer multi consumer double ended queue would allow for > the common cases (enqueue/dequeue) to benefit from a better throughput and > lower latencies while allowing busy spin waits to benefits from some > additional boost -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-430) Lock-Free FifoMessageQueue
[ https://issues.apache.org/jira/browse/QPIDJMS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16686859#comment-16686859 ] ASF GitHub Bot commented on QPIDJMS-430: Github user franz1981 commented on the issue: https://github.com/apache/qpid-jms/pull/26 The reason behind the abstract classes for padding between fields to avoid false sharing (that could lead to a 1/10 of performance): ``` OFFSET SIZE TYPE DESCRIPTION VALUE 012(object header) N/A 12 4 (alignment/padding gap) 16 8 long FifoMessageQueuePad0.p01 N/A 24 8 long FifoMessageQueuePad0.p02 N/A 32 8 long FifoMessageQueuePad0.p03 N/A 40 8 long FifoMessageQueuePad0.p04 N/A 48 8 long FifoMessageQueuePad0.p05 N/A 56 8 long FifoMessageQueuePad0.p06 N/A 64 8 long FifoMessageQueuePad0.p07 N/A 72 8 long FifoMessageQueuePad0.p10 N/A 80 8 long FifoMessageQueuePad0.p11 N/A 88 8 long FifoMessageQueuePad0.p12 N/A 96 8 long FifoMessageQueuePad0.p13 N/A 104 8 long FifoMessageQueuePad0.p14 N/A 112 8 long FifoMessageQueuePad0.p15 N/A 120 8 long FifoMessageQueuePad0.p16 N/A 128 8 long FifoMessageQueuePad0.p17 N/A 136 8 long FifoMessageQueueProducerFields.tail N/A 144 8 long FifoMessageQueueProducerFields.producerLimit N/A 152 8 long FifoMessageQueuePad1.p01 N/A 160 8 long FifoMessageQueuePad1.p02 N/A 168 8 long FifoMessageQueuePad1.p03 N/A 176 8 long FifoMessageQueuePad1.p04 N/A 184 8 long FifoMessageQueuePad1.p05 N/A 192 8 long FifoMessageQueuePad1.p06 N/A 200 8 long FifoMessageQueuePad1.p07 N/A 208 8 long FifoMessageQueuePad1.p08 N/A 216 8 long FifoMessageQueuePad1.p10 N/A 224 8 long FifoMessageQueuePad1.p11 N/A 232 8 long FifoMessageQueuePad1.p12 N/A 240 8 long FifoMessageQueuePad1.p13 N/A 248 8 long FifoMessageQueuePad1.p14 N/A 256 8 long FifoMessageQueuePad1.p15 N/A 264 8 long FifoMessageQueuePad1.p16 N/A 272 8 long FifoMessageQueuePad1.p17 N/A 280 8 long
[GitHub] qpid-jms issue #26: QPIDJMS-430 Lock-Free FifoMessageQueue
Github user franz1981 commented on the issue: https://github.com/apache/qpid-jms/pull/26 The reason behind the abstract classes for padding between fields to avoid false sharing (that could lead to a 1/10 of performance): ``` OFFSET SIZE TYPE DESCRIPTION VALUE 012(object header) N/A 12 4 (alignment/padding gap) 16 8 long FifoMessageQueuePad0.p01 N/A 24 8 long FifoMessageQueuePad0.p02 N/A 32 8 long FifoMessageQueuePad0.p03 N/A 40 8 long FifoMessageQueuePad0.p04 N/A 48 8 long FifoMessageQueuePad0.p05 N/A 56 8 long FifoMessageQueuePad0.p06 N/A 64 8 long FifoMessageQueuePad0.p07 N/A 72 8 long FifoMessageQueuePad0.p10 N/A 80 8 long FifoMessageQueuePad0.p11 N/A 88 8 long FifoMessageQueuePad0.p12 N/A 96 8 long FifoMessageQueuePad0.p13 N/A 104 8 long FifoMessageQueuePad0.p14 N/A 112 8 long FifoMessageQueuePad0.p15 N/A 120 8 long FifoMessageQueuePad0.p16 N/A 128 8 long FifoMessageQueuePad0.p17 N/A 136 8 long FifoMessageQueueProducerFields.tail N/A 144 8 long FifoMessageQueueProducerFields.producerLimit N/A 152 8 long FifoMessageQueuePad1.p01 N/A 160 8 long FifoMessageQueuePad1.p02 N/A 168 8 long FifoMessageQueuePad1.p03 N/A 176 8 long FifoMessageQueuePad1.p04 N/A 184 8 long FifoMessageQueuePad1.p05 N/A 192 8 long FifoMessageQueuePad1.p06 N/A 200 8 long FifoMessageQueuePad1.p07 N/A 208 8 long FifoMessageQueuePad1.p08 N/A 216 8 long FifoMessageQueuePad1.p10 N/A 224 8 long FifoMessageQueuePad1.p11 N/A 232 8 long FifoMessageQueuePad1.p12 N/A 240 8 long FifoMessageQueuePad1.p13 N/A 248 8 long FifoMessageQueuePad1.p14 N/A 256 8 long FifoMessageQueuePad1.p15 N/A 264 8 long FifoMessageQueuePad1.p16 N/A 272 8 long FifoMessageQueuePad1.p17 N/A 280 8 long FifoMessageQueueConsumerFields.head N/A 288 8 long FifoMessageQueueConsumerFields.headLock N/A 296 4int FifoMessageQue
[jira] [Created] (QPIDJMS-431) Refactor the Failover provider to improve performance
Timothy Bish created QPIDJMS-431: Summary: Refactor the Failover provider to improve performance Key: QPIDJMS-431 URL: https://issues.apache.org/jira/browse/QPIDJMS-431 Project: Qpid JMS Issue Type: Improvement Components: qpid-jms-client Affects Versions: 0.38.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.39.0 Currently when using failover with the client there is a significant impact on client performance due to the way the provider serializes work. We can refactor this to handle most of the work on the clients thread and hand off to the underlying provider the remainder of the work. This reduces the impact on senders to a relatively small amount and the consumer side sees nearly transparent impacts. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-430) Lock-Free FifoMessageQueue
[ https://issues.apache.org/jira/browse/QPIDJMS-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16686794#comment-16686794 ] ASF GitHub Bot commented on QPIDJMS-430: GitHub user franz1981 opened a pull request: https://github.com/apache/qpid-jms/pull/26 QPIDJMS-430 Lock-Free FifoMessageQueue You can merge this pull request into a Git repository by running: $ git pull https://github.com/franz1981/qpid-jms lock_free_fifo_q Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-jms/pull/26.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #26 commit f8c1a18ec8738e3d302c9cce43f7abae4674 Author: Francesco Nigro Date: 2018-11-14T13:33:58Z QPIDJMS-430 Lock-Free FifoMessageQueue > Lock-Free FifoMessageQueue > -- > > Key: QPIDJMS-430 > URL: https://issues.apache.org/jira/browse/QPIDJMS-430 > Project: Qpid JMS > Issue Type: Improvement >Reporter: Francesco Nigro >Priority: Minor > Fix For: 0.39.0 > > > A lock-free single producer multi consumer double ended queue would allow for > the common cases (enqueue/dequeue) to benefit from a better throughput and > lower latencies while allowing busy spin waits to benefits from some > additional boost -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-430) Lock-Free FifoMessageQueue
Francesco Nigro created QPIDJMS-430: --- Summary: Lock-Free FifoMessageQueue Key: QPIDJMS-430 URL: https://issues.apache.org/jira/browse/QPIDJMS-430 Project: Qpid JMS Issue Type: Improvement Reporter: Francesco Nigro Fix For: 0.39.0 A lock-free single producer multi consumer double ended queue would allow for the common cases (enqueue/dequeue) to benefit from a better throughput and lower latencies while allowing busy spin waits to benefits from some additional boost -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-jms pull request #26: QPIDJMS-430 Lock-Free FifoMessageQueue
GitHub user franz1981 opened a pull request: https://github.com/apache/qpid-jms/pull/26 QPIDJMS-430 Lock-Free FifoMessageQueue You can merge this pull request into a Git repository by running: $ git pull https://github.com/franz1981/qpid-jms lock_free_fifo_q Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-jms/pull/26.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #26 commit f8c1a18ec8738e3d302c9cce43f7abae4674 Author: Francesco Nigro Date: 2018-11-14T13:33:58Z QPIDJMS-430 Lock-Free FifoMessageQueue --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7541) [Broker-J] Close Consumers when a Queue is deleted
[ https://issues.apache.org/jira/browse/QPID-7541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16686480#comment-16686480 ] ASF GitHub Bot commented on QPID-7541: -- GitHub user alex-rufous opened a pull request: https://github.com/apache/qpid-broker-j/pull/17 QPID-7541: [Broker-J] Close consumers when a Queue is deleted The proposed changes allow to close queue sending and receiving links and mark all in-progress queue transactions as read-only. If in-progress transaction is in process of committing/rollingback when queue is deleted, the deletion functionality is waiting for the transaction discharge to complete in order to avoid loosing any messages in case of pushing deleted queue messages into alternate destination. You can merge this pull request into a Git repository by running: $ git pull https://github.com/alex-rufous/qpid-broker-j QPID-7541 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-broker-j/pull/17.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #17 commit 540ad5840ad2168f2e21a212c0fbe5e618617833 Author: Alex Rudyy Date: 2018-11-14T12:39:36Z QPID-7541: [Broker-J] Close consumers when a Queue is deleted > [Broker-J] Close Consumers when a Queue is deleted > -- > > Key: QPID-7541 > URL: https://issues.apache.org/jira/browse/QPID-7541 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Reporter: Lorenz Quack >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > Attachments: > 0001-QPID-7541-Broker-J-Close-Consumers-when-a-Queue-is-d.patch, > proton-j_client.log, simultaneous_closing.log > > > Currently when a Queue is deleted the associated Consumers are not closed. > This is essentially a resource leak. > Note: In 6.1.x, for the AMQP 1.0 protocol, deleting a queue did detach the > sending links (without error). Receiving links were not detached. This > code (org.apache.qpid.server.protocol.v1_0.ConsumerTarget_1_0#queueDeleted) > was removed in 7.0.x and this JIRA raised. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7372) [Java Broker] Remove hard dependency on logback from broker-core
[ https://issues.apache.org/jira/browse/QPID-7372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16686487#comment-16686487 ] ASF GitHub Bot commented on QPID-7372: -- Github user alex-rufous commented on the issue: https://github.com/apache/qpid-broker-j/pull/13 Hi nitin1706, com.sleepycat:je::7.4.5 is compiled with java8 whilst Qpid 6.x is java 7 compatible. In order to keep Qpid 6.x java7 compatible, we cannot upgrade JE to version 7.4.5. Please, use Qpid 7.0.x. It already depends on com.sleepycat:je::7.4.5. > [Java Broker] Remove hard dependency on logback from broker-core > > > Key: QPID-7372 > URL: https://issues.apache.org/jira/browse/QPID-7372 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Rob Godfrey >Assignee: Rob Godfrey >Priority: Major > Fix For: qpid-java-6.1 > > > Currently the SystemConfig class has a hard dependency on LogBack, and forces > instantiation / resetting the logback config. > To allow for easier embedding of the broker we can move this instantiation > out of the core model and into the code use to bootstrap the broker instance. > We can also move the logback dependent model objects into a separate plugin. > In this way the System Config (and child Broker) will simply use whatever > has been set up for them in slf4j and an embedder of the broker could choose > to use a different logging provider or supply a logback configuration which > is not managed by the broker itself. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-broker-j issue #13: QPID-7372, hasn't been fixed fully, there is still ...
Github user alex-rufous commented on the issue: https://github.com/apache/qpid-broker-j/pull/13 Hi nitin1706, com.sleepycat:je::7.4.5 is compiled with java8 whilst Qpid 6.x is java 7 compatible. In order to keep Qpid 6.x java7 compatible, we cannot upgrade JE to version 7.4.5. Please, use Qpid 7.0.x. It already depends on com.sleepycat:je::7.4.5. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-broker-j pull request #17: QPID-7541: [Broker-J] Close consumers when a...
GitHub user alex-rufous opened a pull request: https://github.com/apache/qpid-broker-j/pull/17 QPID-7541: [Broker-J] Close consumers when a Queue is deleted The proposed changes allow to close queue sending and receiving links and mark all in-progress queue transactions as read-only. If in-progress transaction is in process of committing/rollingback when queue is deleted, the deletion functionality is waiting for the transaction discharge to complete in order to avoid loosing any messages in case of pushing deleted queue messages into alternate destination. You can merge this pull request into a Git repository by running: $ git pull https://github.com/alex-rufous/qpid-broker-j QPID-7541 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-broker-j/pull/17.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #17 commit 540ad5840ad2168f2e21a212c0fbe5e618617833 Author: Alex Rudyy Date: 2018-11-14T12:39:36Z QPID-7541: [Broker-J] Close consumers when a Queue is deleted --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
