[ANNOUNCE] Apache Qpid Proton-J 0.29.0 released
The Apache Qpid (http://qpid.apache.org) community is pleased to announce the immediate availability of Apache Qpid Proton-J 0.29.0. Apache Qpid Proton-J is a messaging library for the Advanced Message Queuing Protocol 1.0 (AMQP 1.0, ISO/IEC 19464, http://www.amqp.org). It can be used in a wide range of messaging applications including brokers, clients, routers, bridges, proxies, and more. The release is available now from our website: http://qpid.apache.org/download.html Binaries are also available via Maven Central: http://qpid.apache.org/maven.html Release notes can be found at: http://qpid.apache.org/releases/qpid-proton-j-0.29.0/release-notes.html Thanks to all involved, Robbie - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPIDJMS-409) JMS Scheduled Delivery delivers messages before time under load
[
https://issues.apache.org/jira/browse/QPIDJMS-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16581856#comment-16581856
]
Ian Rowlands edited comment on QPIDJMS-409 at 8/16/18 2:45 AM:
---
I can't easily give a sample - especially as it comes under load.
I've enabled debugging as requested. I've had a look in the log and really
couldn't see anything much. Maybe I'm missing something.
I've attached a log of a "successful" message send with a delayed delivery
message being sent. Can you see anything there which shows that the delivery
was being delayed? If not, I'm not sure where else to go with this.
If you can see the correct parameters which show a delayed delivery, what I'll
do is then find a case where it fails and attach that too. If you could point
out where in the trace it is, so I can look for it myself and maybe get a clue
as to what is happening.
was (Author: 204608):
I can't easily give a sample - especially as it comes under load.
I've enabled debugging as requested. I've had a look in the log and really
couldn't see anything much. Maybe I'm missing something.
I've attached a log of a "successful" message send with a delayed delivery
message being sent. Can you see anything there which shows that the delivery
was being delayed? If not, I'm not sure where else to go with this. If you can
see it, what I'll do is then find a case where it fails.
> JMS Scheduled Delivery delivers messages before time under load
> ---
>
> Key: QPIDJMS-409
> URL: https://issues.apache.org/jira/browse/QPIDJMS-409
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.35.0
> Environment: Application is a Spring Boot application - version
> 2.0.4.RELEASE
> Qpid JMS Client version is 0.35.0
> Operating system where problem occurs is Windows 10
> I have found this problem using the following different message brokers:
> * Apache Artemis 2.4.0
> * Apache Artemis 2.6.2
> * Apache Qpid Broker 7.0.6
>Reporter: Ian Rowlands
>Priority: Major
> Attachments: successful_delayed_delivery.txt
>
>
> When under system load, the Qpid JMS client doesn't handle scheduled message
> delivery correct - it delivers the message prior to the required time.
> When running one request, the scheduling works correctly. The load to
> reproduce this isn't very high (i.e running about 5 of my job processes
> simultaneously seems to trip it up pretty quickly).
> I have used different JMS Brokers with the same client code and the same
> problem occurs with both Brokers (see environment).
> I am using Spring JMS Template to send the JMS message. The key piece of code
> is something like:
> {{delayedDeliveryjmsTemplate.setDeliveryDelay(timeoutPeriod);}}
> {{delayedDeliveryjmsTemplate.convertAndSend(queueName, timeoutMsg, (Message
> jmsMessage) -> {}}
> {{ jmsMessage.setStringProperty(OBJECT_TYPE_FIELD,
> timeoutMsg.getClass().getSimpleName());}}
> {{jmsMessage.setStringProperty(OBJECT_TYPE_FIELD,
> timeoutMsg.getClass().getSimpleName());}}
> {{ return jmsMessage;}}
> {{});}}
> I realise you want more logging details but I'm unsure what would be best to
> log. Please let me know and I'll do so.
>
>
--
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] (QPIDJMS-409) JMS Scheduled Delivery delivers messages before time under load
[
https://issues.apache.org/jira/browse/QPIDJMS-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ian Rowlands updated QPIDJMS-409:
-
Attachment: successful_delayed_delivery.txt
> JMS Scheduled Delivery delivers messages before time under load
> ---
>
> Key: QPIDJMS-409
> URL: https://issues.apache.org/jira/browse/QPIDJMS-409
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.35.0
> Environment: Application is a Spring Boot application - version
> 2.0.4.RELEASE
> Qpid JMS Client version is 0.35.0
> Operating system where problem occurs is Windows 10
> I have found this problem using the following different message brokers:
> * Apache Artemis 2.4.0
> * Apache Artemis 2.6.2
> * Apache Qpid Broker 7.0.6
>Reporter: Ian Rowlands
>Priority: Major
> Attachments: successful_delayed_delivery.txt
>
>
> When under system load, the Qpid JMS client doesn't handle scheduled message
> delivery correct - it delivers the message prior to the required time.
> When running one request, the scheduling works correctly. The load to
> reproduce this isn't very high (i.e running about 5 of my job processes
> simultaneously seems to trip it up pretty quickly).
> I have used different JMS Brokers with the same client code and the same
> problem occurs with both Brokers (see environment).
> I am using Spring JMS Template to send the JMS message. The key piece of code
> is something like:
> {{delayedDeliveryjmsTemplate.setDeliveryDelay(timeoutPeriod);}}
> {{delayedDeliveryjmsTemplate.convertAndSend(queueName, timeoutMsg, (Message
> jmsMessage) -> {}}
> {{ jmsMessage.setStringProperty(OBJECT_TYPE_FIELD,
> timeoutMsg.getClass().getSimpleName());}}
> {{jmsMessage.setStringProperty(OBJECT_TYPE_FIELD,
> timeoutMsg.getClass().getSimpleName());}}
> {{ return jmsMessage;}}
> {{});}}
> I realise you want more logging details but I'm unsure what would be best to
> log. Please let me know and I'll do so.
>
>
--
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-409) JMS Scheduled Delivery delivers messages before time under load
[
https://issues.apache.org/jira/browse/QPIDJMS-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16581856#comment-16581856
]
Ian Rowlands commented on QPIDJMS-409:
--
I can't easily give a sample - especially as it comes under load.
I've enabled debugging as requested. I've had a look in the log and really
couldn't see anything much. Maybe I'm missing something.
I've attached a log of a "successful" message send with a delayed delivery
message being sent. Can you see anything there which shows that the delivery
was being delayed? If not, I'm not sure where else to go with this. If you can
see it, what I'll do is then find a case where it fails.
> JMS Scheduled Delivery delivers messages before time under load
> ---
>
> Key: QPIDJMS-409
> URL: https://issues.apache.org/jira/browse/QPIDJMS-409
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.35.0
> Environment: Application is a Spring Boot application - version
> 2.0.4.RELEASE
> Qpid JMS Client version is 0.35.0
> Operating system where problem occurs is Windows 10
> I have found this problem using the following different message brokers:
> * Apache Artemis 2.4.0
> * Apache Artemis 2.6.2
> * Apache Qpid Broker 7.0.6
>Reporter: Ian Rowlands
>Priority: Major
>
> When under system load, the Qpid JMS client doesn't handle scheduled message
> delivery correct - it delivers the message prior to the required time.
> When running one request, the scheduling works correctly. The load to
> reproduce this isn't very high (i.e running about 5 of my job processes
> simultaneously seems to trip it up pretty quickly).
> I have used different JMS Brokers with the same client code and the same
> problem occurs with both Brokers (see environment).
> I am using Spring JMS Template to send the JMS message. The key piece of code
> is something like:
> {{delayedDeliveryjmsTemplate.setDeliveryDelay(timeoutPeriod);}}
> {{delayedDeliveryjmsTemplate.convertAndSend(queueName, timeoutMsg, (Message
> jmsMessage) -> {}}
> {{ jmsMessage.setStringProperty(OBJECT_TYPE_FIELD,
> timeoutMsg.getClass().getSimpleName());}}
> {{jmsMessage.setStringProperty(OBJECT_TYPE_FIELD,
> timeoutMsg.getClass().getSimpleName());}}
> {{ return jmsMessage;}}
> {{});}}
> I realise you want more logging details but I'm unsure what would be best to
> log. Please let me know and I'll do so.
>
>
--
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] [Resolved] (DISPATCH-1082) Log messages can not be correlated to a specific connection
[
https://issues.apache.org/jira/browse/DISPATCH-1082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chuck Rolke resolved DISPATCH-1082.
---
Resolution: Fixed
Fix Version/s: 1.4.0
Actually fixed last minute in 1.3. Setting to 1.4 so that this issue is
reported and closed in next release cycle.
> Log messages can not be correlated to a specific connection
> ---
>
> Key: DISPATCH-1082
> URL: https://issues.apache.org/jira/browse/DISPATCH-1082
> Project: Qpid Dispatch
> Issue Type: Improvement
>Affects Versions: 1.2.0
>Reporter: Chuck Rolke
>Priority: Major
> Fix For: 1.4.0
>
>
> Several components use 'connection name' which is not unique.
> * Policy logs indicating allow/deny at protocol level
> * Connection setup
> A simple improvement is to include the connection_id integer at the beginning
> of the messages. The format should be the same as the prefix added by the
> server to proton transport tracer messages.
> Log files could be processed simply with
> {{ grep '\[4]' router.log}}
> to reveal connection setup, authenticated username associations, policy
> decisions, and AMQP frame traffic.
> This addition would also make it easier to scrape the log file for low-level
> connection life cycle details with no ambiguity.
--
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] [Resolved] (PROTON-1842) [c] Dispatch/Proton crashes when opening/closing connections
[
https://issues.apache.org/jira/browse/PROTON-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cliff Jansen resolved PROTON-1842.
--
Resolution: Fixed
Fix Version/s: proton-c-0.25.0
> [c] Dispatch/Proton crashes when opening/closing connections
>
>
> Key: PROTON-1842
> URL: https://issues.apache.org/jira/browse/PROTON-1842
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.22.0
>Reporter: Chuck Rolke
>Assignee: Alan Conway
>Priority: Major
> Fix For: proton-c-0.25.0
>
> Attachments: helloworld.cpp, race.tsan, race.vg
>
>
> Using proton cpp example code that is modified to open and close connections
> by the thousands in the main loop and having the event loop short circuit any
> messaging with:
> {{ void on_connection_open(proton::connection& c) {}}
> {{ c.close();}}
> {{ }}}
> and then directing this client example to a dispatch router 1.1.0. Eventually
> (after 100,000 to 1,000,000 connection open/closes) the router crashes with:
> {{qdrouterd: /home/chug/git/qpid-proton/c/src/proactor/epoll.c:466:
> wake_pop_front: Assertion `p->wakes_in_progress' failed.}}
> and with:
> {{qdrouterd: /home/chug/git/qpid-proton/c/src/proactor/epoll.c:2014:
> proactor_do_epoll: Assertion `ee->type == PCONNECTION_TIMER' failed.}}
> This issue seems to happen only with qpid-dispatch accepting the open/close
> event stream. Proton cpp example _server_direct_ and c example _direct_ work
> properly with the same open/close event stream mounting into the 10s of
> millions of connections.
> A core dump backtrace with the PCONNECTION_TIMER failure reads as:
> {{(gdb) bt}}
> {{#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51}}
> {{#1 0x7f795c712c41 in __GI_abort () at abort.c:79}}
> {{#2 0x7f795c709f7a in __assert_fail_base (fmt=0x7f795c85a260
> "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
> assertion=assertion@entry=0x7f795d72e15a "ee->type == PCONNECTION_TIMER", }}
> {{ file=file@entry=0x7f795d72de98
> "/home/chug/git/qpid-proton/c/src/proactor/epoll.c", line=line@entry=2014, }}
> {{ function=function@entry=0x7f795d72e320 <__PRETTY_FUNCTION__.6307>
> "proactor_do_epoll") at assert.c:92}}
> {{#3 0x7f795c709ff2 in __GI___assert_fail (assertion=0x7f795d72e15a
> "ee->type == PCONNECTION_TIMER", file=0x7f795d72de98
> "/home/chug/git/qpid-proton/c/src/proactor/epoll.c", line=2014, }}
> {{ function=0x7f795d72e320 <__PRETTY_FUNCTION__.6307> "proactor_do_epoll")
> at assert.c:101}}
> {{#4 0x7f795d72d29f in proactor_do_epoll (p=0x26b7310, can_block=true)
> at /home/chug/git/qpid-proton/c/src/proactor/epoll.c:2014}}
> {{#5 0x7f795d72d30e in pn_proactor_wait (p=0x26b7310) at
> /home/chug/git/qpid-proton/c/src/proactor/epoll.c:2030}}
> {{#6 0x7f795dbe89ad in thread_run (arg=0x26be750) at
> /home/chug/git/qpid-dispatch/src/server.c:946}}
> {{#7 0x7f795d50e50b in start_thread (arg=0x7f794f486700) at
> pthread_create.c:465}}
> {{#8 0x7f795c7d216f in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95}}
>
--
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] [Assigned] (DISPATCH-1090) Transfer/Disposition(state=release) loop forms when application disconnects abruptly from brokered queue until link credit is exhausted.
[
https://issues.apache.org/jira/browse/DISPATCH-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy reassigned DISPATCH-1090:
---
Assignee: Ganesh Murthy
> Transfer/Disposition(state=release) loop forms when application disconnects
> abruptly from brokered queue until link credit is exhausted.
>
>
> Key: DISPATCH-1090
> URL: https://issues.apache.org/jira/browse/DISPATCH-1090
> Project: Qpid Dispatch
> Issue Type: Bug
> Environment: Version 1.3.0-SNAPSHOT
> (30ff7ff1d54b8f280b36f76dc8c340cb4c88567b)
>Reporter: Keith Wall
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: Backlog
>
> Attachments: DISPATCH-1090_dispatch_server.log
>
>
> I have configured a single Dispatch Router instance to route messages through
> a broker queue (i.e. following section 7.2.5 of the
> [docs|https://qpid.apache.org/releases/qpid-dispatch-1.2.0/user-guide/index.html#routing-messages-through-broker]).
> The application does the following:
> # Forms a sending links to the queue, sends a single message then disconnects.
> # Forms a receiving link to the same queue, receives the message without
> settling then abruptly terminates the program.
> Inspecting the protocol trace, I see that after the Dispatch Router has sent
> a {{Disposition state=modified}} for the message that was held by the
> application when it terminated, a {{Transfer}}/{{Disposition state=release}}
> loop forms between the Dispatch Router and Broker until the link credit is
> exhausted.
> Protocol trace attached to this issue demonstrates the problem.
> Dispatch Router was configured by the following commands:
> {noformat}
> qdmanage create --type org.apache.qpid.dispatch.connector host=oslo.local
> port=5672 name=artemis-broker role=route-container
> qdmanage create --type org.apache.qpid.dispatch.router.config.autoLink
> addr=queue direction=in connection=artemis-broker
> qdmanage create --type org.apache.qpid.dispatch.router.config.autoLink
> addr=queue direction=out connection=artemis-broker
> qdmanage create --type=org.apache.qpid.dispatch.router.config.address
> pattern=queue waypoint=true
> {noformat}
--
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 pull request #364: NO-JIRA: Add docker build file for Centos, ...
Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/364 --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch issue #364: NO-JIRA: Add docker build file for Centos, update ...
Github user codecov-io commented on the issue: https://github.com/apache/qpid-dispatch/pull/364 # [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/364?src=pr=h1) Report > Merging [#364](https://codecov.io/gh/apache/qpid-dispatch/pull/364?src=pr=desc) into [master](https://codecov.io/gh/apache/qpid-dispatch/commit/788fe2a4ee4b28cd88b0dbd0c7e21979f08d25fb?src=pr=desc) will **decrease** coverage by `0.01%`. > The diff coverage is `n/a`. [](https://codecov.io/gh/apache/qpid-dispatch/pull/364?src=pr=tree) ```diff @@Coverage Diff@@ ## master#364 +/- ## = - Coverage 84.52% 84.5% -0.02% = Files 69 69 Lines 15730 15732 +2 = Hits13295 13295 - Misses 24352437 +2 ``` | [Impacted Files](https://codecov.io/gh/apache/qpid-dispatch/pull/364?src=pr=tree) | Coverage Π| | |---|---|---| | [src/container.c](https://codecov.io/gh/apache/qpid-dispatch/pull/364/diff?src=pr=tree#diff-c3JjL2NvbnRhaW5lci5j) | `76.55% <0%> (-0.2%)` | :arrow_down: | | [src/message.c](https://codecov.io/gh/apache/qpid-dispatch/pull/364/diff?src=pr=tree#diff-c3JjL21lc3NhZ2UuYw==) | `88% <0%> (-0.2%)` | :arrow_down: | | [src/router\_core/agent\_link.c](https://codecov.io/gh/apache/qpid-dispatch/pull/364/diff?src=pr=tree#diff-c3JjL3JvdXRlcl9jb3JlL2FnZW50X2xpbmsuYw==) | `63.79% <0%> (+0.57%)` | :arrow_up: | -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/364?src=pr=continue). > **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta) > `Π= absolute (impact)`, `ø = not affected`, `? = missing data` > Powered by [Codecov](https://codecov.io/gh/apache/qpid-dispatch/pull/364?src=pr=footer). Last update [788fe2a...483b929](https://codecov.io/gh/apache/qpid-dispatch/pull/364?src=pr=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments). --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #364: NO-JIRA: Add docker build file for Centos, ...
GitHub user mcressman opened a pull request: https://github.com/apache/qpid-dispatch/pull/364 NO-JIRA: Add docker build file for Centos, update README You can merge this pull request into a Git repository by running: $ git pull https://github.com/mcressman/qpid-dispatch docker-branch Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/364.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 #364 commit 483b9293604063480d5f706edea18cb0a3e4c8b9 Author: Mike Cressman Date: 2018-08-15T17:24:32Z NO-JIRA: Add docker build file for Centos, update README --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPIDJMS-391) Add support for the use of native OpenSSL based providers
[ https://issues.apache.org/jira/browse/QPIDJMS-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish reassigned QPIDJMS-391: Assignee: Timothy Bish > Add support for the use of native OpenSSL based providers > - > > Key: QPIDJMS-391 > URL: https://issues.apache.org/jira/browse/QPIDJMS-391 > Project: Qpid JMS > Issue Type: New Feature > Components: qpid-jms-client >Reporter: Johan Stenberg >Assignee: Timothy Bish >Priority: Minor > Labels: performance > Fix For: 0.36.0 > > > It would be great to have an option to use netty-tcnative-boringssl-static > instead of the java based SSL provider. In the ActiveMQ Artemis this was > implemented as part of https://issues.apache.org/jira/browse/ARTEMIS-1649 > In Netty 4.1.26 a new OpenSslX509KeyManagerFactory for easier configuration > was introduced. https://github.com/netty/netty/pull/8084 -- 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] [Resolved] (QPIDJMS-391) Add support for the use of native OpenSSL based providers
[ https://issues.apache.org/jira/browse/QPIDJMS-391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-391. -- Resolution: Fixed > Add support for the use of native OpenSSL based providers > - > > Key: QPIDJMS-391 > URL: https://issues.apache.org/jira/browse/QPIDJMS-391 > Project: Qpid JMS > Issue Type: New Feature > Components: qpid-jms-client >Reporter: Johan Stenberg >Priority: Minor > Labels: performance > Fix For: 0.36.0 > > > It would be great to have an option to use netty-tcnative-boringssl-static > instead of the java based SSL provider. In the ActiveMQ Artemis this was > implemented as part of https://issues.apache.org/jira/browse/ARTEMIS-1649 > In Netty 4.1.26 a new OpenSslX509KeyManagerFactory for easier configuration > was introduced. https://github.com/netty/netty/pull/8084 -- 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-391) Add support for the use of native OpenSSL based providers
[ https://issues.apache.org/jira/browse/QPIDJMS-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16581315#comment-16581315 ] ASF subversion and git services commented on QPIDJMS-391: - Commit 148436e7206aa47e1e607832084c428ab8bb7815 in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=148436e ] QPIDJMS-391 Add new documentation to cover OpenSSL support > Add support for the use of native OpenSSL based providers > - > > Key: QPIDJMS-391 > URL: https://issues.apache.org/jira/browse/QPIDJMS-391 > Project: Qpid JMS > Issue Type: New Feature > Components: qpid-jms-client >Reporter: Johan Stenberg >Priority: Minor > Labels: performance > Fix For: 0.36.0 > > > It would be great to have an option to use netty-tcnative-boringssl-static > instead of the java based SSL provider. In the ActiveMQ Artemis this was > implemented as part of https://issues.apache.org/jira/browse/ARTEMIS-1649 > In Netty 4.1.26 a new OpenSslX509KeyManagerFactory for easier configuration > was introduced. https://github.com/netty/netty/pull/8084 -- 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] (QPIDJMS-408) update to proton-j 0.29.0
[ https://issues.apache.org/jira/browse/QPIDJMS-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPIDJMS-408: --- Description: Update to proton-j 0.29.0, get the latest fixes such as PROTON-1901, and improvements such as PROTON-1911. For the latter, implementing the new API method offered (or rather overriding its default impl) can give us a decent boost in string encoding performance, useful for TextMessage throughput in particular. (was: Update to proton-j 0.29.0, get the latest fixes such as PROTON-1901, and improvements such as PROTON-1911.) Issue Type: Improvement (was: Task) > update to proton-j 0.29.0 > - > > Key: QPIDJMS-408 > URL: https://issues.apache.org/jira/browse/QPIDJMS-408 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Major > Fix For: 0.36.0 > > > Update to proton-j 0.29.0, get the latest fixes such as PROTON-1901, and > improvements such as PROTON-1911. For the latter, implementing the new API > method offered (or rather overriding its default impl) can give us a decent > boost in string encoding performance, useful for TextMessage throughput in > particular. -- 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] [Resolved] (QPIDJMS-410) update testing dependencies to current versions
[ https://issues.apache.org/jira/browse/QPIDJMS-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPIDJMS-410. Resolution: Fixed > update testing dependencies to current versions > --- > > Key: QPIDJMS-410 > URL: https://issues.apache.org/jira/browse/QPIDJMS-410 > Project: Qpid JMS > Issue Type: Task >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 0.36.0 > > > Update the Mockito and ActiveMQ test dependencies to their current releases. -- 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-410) update testing dependencies to current versions
[ https://issues.apache.org/jira/browse/QPIDJMS-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16581248#comment-16581248 ] ASF subversion and git services commented on QPIDJMS-410: - Commit b9e5ed34c6167bedc5c71f8cf4bc113982e98aed in qpid-jms's branch refs/heads/master from [~gemmellr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=b9e5ed3 ] QPIDJMS-410: update test dep versions, to Mockito 2.21.0 and ActiveMQ 5.15.5 > update testing dependencies to current versions > --- > > Key: QPIDJMS-410 > URL: https://issues.apache.org/jira/browse/QPIDJMS-410 > Project: Qpid JMS > Issue Type: Task >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 0.36.0 > > > Update the Mockito and ActiveMQ test dependencies to their current releases. -- 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-410) update testing dependencies to current versions
Robbie Gemmell created QPIDJMS-410: -- Summary: update testing dependencies to current versions Key: QPIDJMS-410 URL: https://issues.apache.org/jira/browse/QPIDJMS-410 Project: Qpid JMS Issue Type: Task Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.36.0 Update the Mockito and ActiveMQ test dependencies to their current releases. -- 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-409) JMS Scheduled Delivery delivers messages before time under load
[
https://issues.apache.org/jira/browse/QPIDJMS-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16580941#comment-16580941
]
Robbie Gemmell commented on QPIDJMS-409:
In terms of logging, enabling the protocol tracing would likely be useful:
[http://qpid.apache.org/releases/qpid-jms-0.35.0/docs/index.html#logging]
Alternatively or in addition, if you could please provide a simple runnable
reproducer of what you are doing then we could see what is going on without
trying to guess.
The client does not perform any scheduling itself, it merely stamps the
messages as appropriate and sends them to the server to handle delaying and
eventual delivery to consumers etc, so the only client issue could be that it
is itself stamping them incorrectly or not at all, which I don't see immediate
scope for in the code. If not that, then the issue would have to be in any
higher layers or the application.
> JMS Scheduled Delivery delivers messages before time under load
> ---
>
> Key: QPIDJMS-409
> URL: https://issues.apache.org/jira/browse/QPIDJMS-409
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.35.0
> Environment: Application is a Spring Boot application - version
> 2.0.4.RELEASE
> Qpid JMS Client version is 0.35.0
> Operating system where problem occurs is Windows 10
> I have found this problem using the following different message brokers:
> * Apache Artemis 2.4.0
> * Apache Artemis 2.6.2
> * Apache Qpid Broker 7.0.6
>Reporter: Ian Rowlands
>Priority: Major
>
> When under system load, the Qpid JMS client doesn't handle scheduled message
> delivery correct - it delivers the message prior to the required time.
> When running one request, the scheduling works correctly. The load to
> reproduce this isn't very high (i.e running about 5 of my job processes
> simultaneously seems to trip it up pretty quickly).
> I have used different JMS Brokers with the same client code and the same
> problem occurs with both Brokers (see environment).
> I am using Spring JMS Template to send the JMS message. The key piece of code
> is something like:
> {{delayedDeliveryjmsTemplate.setDeliveryDelay(timeoutPeriod);}}
> {{delayedDeliveryjmsTemplate.convertAndSend(queueName, timeoutMsg, (Message
> jmsMessage) -> {}}
> {{ jmsMessage.setStringProperty(OBJECT_TYPE_FIELD,
> timeoutMsg.getClass().getSimpleName());}}
> {{jmsMessage.setStringProperty(OBJECT_TYPE_FIELD,
> timeoutMsg.getClass().getSimpleName());}}
> {{ return jmsMessage;}}
> {{});}}
> I realise you want more logging details but I'm unsure what would be best to
> log. Please let me know and I'll do so.
>
>
--
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] (QPIDJMS-409) JMS Scheduled Delivery delivers messages before time under load
[
https://issues.apache.org/jira/browse/QPIDJMS-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ian Rowlands updated QPIDJMS-409:
-
Description:
When under system load, the Qpid JMS client doesn't handle scheduled message
delivery correct - it delivers the message prior to the required time.
When running one request, the scheduling works correctly. The load to reproduce
this isn't very high (i.e running about 5 of my job processes simultaneously
seems to trip it up pretty quickly).
I have used different JMS Brokers with the same client code and the same
problem occurs with both Brokers (see environment).
I am using Spring JMS Template to send the JMS message. The key piece of code
is something like:
{{delayedDeliveryjmsTemplate.setDeliveryDelay(timeoutPeriod);}}
{{delayedDeliveryjmsTemplate.convertAndSend(queueName, timeoutMsg, (Message
jmsMessage) -> {}}
{{ jmsMessage.setStringProperty(OBJECT_TYPE_FIELD,
timeoutMsg.getClass().getSimpleName());}}
{{jmsMessage.setStringProperty(OBJECT_TYPE_FIELD,
timeoutMsg.getClass().getSimpleName());}}
{{ return jmsMessage;}}
{{});}}
I realise you want more logging details but I'm unsure what would be best to
log. Please let me know and I'll do so.
was:
When under system load, the Qpid JMS client doesn't handle scheduled message
delivery correct - it delivers the message prior to the required time.
When running one request, the scheduling works correctly. The load to reproduce
this isn't very high (i.e running about 5 of my job processes simultaneously
seems to trip it up pretty quickly).
I have used different JMS Brokers with the same client code and the same
problem occurs with both Brokers (see environment).
I am using Spring JMS Template to send the JMS message. The key piece of code
is something like:
{{delayedDeliveryjmsTemplate.setDeliveryDelay(timeoutPeriod)}}
I realise you want more logging details but I'm unsure what would be best to
log. Please let me know and I'll do so.
> JMS Scheduled Delivery delivers messages before time under load
> ---
>
> Key: QPIDJMS-409
> URL: https://issues.apache.org/jira/browse/QPIDJMS-409
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.35.0
> Environment: Application is a Spring Boot application - version
> 2.0.4.RELEASE
> Qpid JMS Client version is 0.35.0
> Operating system where problem occurs is Windows 10
> I have found this problem using the following different message brokers:
> * Apache Artemis 2.4.0
> * Apache Artemis 2.6.2
> * Apache Qpid Broker 7.0.6
>Reporter: Ian Rowlands
>Priority: Major
>
> When under system load, the Qpid JMS client doesn't handle scheduled message
> delivery correct - it delivers the message prior to the required time.
> When running one request, the scheduling works correctly. The load to
> reproduce this isn't very high (i.e running about 5 of my job processes
> simultaneously seems to trip it up pretty quickly).
> I have used different JMS Brokers with the same client code and the same
> problem occurs with both Brokers (see environment).
> I am using Spring JMS Template to send the JMS message. The key piece of code
> is something like:
> {{delayedDeliveryjmsTemplate.setDeliveryDelay(timeoutPeriod);}}
> {{delayedDeliveryjmsTemplate.convertAndSend(queueName, timeoutMsg, (Message
> jmsMessage) -> {}}
> {{ jmsMessage.setStringProperty(OBJECT_TYPE_FIELD,
> timeoutMsg.getClass().getSimpleName());}}
> {{jmsMessage.setStringProperty(OBJECT_TYPE_FIELD,
> timeoutMsg.getClass().getSimpleName());}}
> {{ return jmsMessage;}}
> {{});}}
> I realise you want more logging details but I'm unsure what would be best to
> log. Please let me know and I'll do so.
>
>
--
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] (QPIDJMS-409) JMS Scheduled Delivery delivers messages before time under load
[
https://issues.apache.org/jira/browse/QPIDJMS-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ian Rowlands updated QPIDJMS-409:
-
Description:
When under system load, the Qpid JMS client doesn't handle scheduled message
delivery correct - it delivers the message prior to the required time.
When running one request, the scheduling works correctly. The load to reproduce
this isn't very high (i.e running about 5 of my job processes simultaneously
seems to trip it up pretty quickly).
I have used different JMS Brokers with the same client code and the same
problem occurs with both Brokers (see environment).
I am using Spring JMS Template to send the JMS message. The key piece of code
is something like:
{{delayedDeliveryjmsTemplate.setDeliveryDelay(timeoutPeriod)}}
I realise you want more logging details but I'm unsure what would be best to
log. Please let me know and I'll do so.
was:
When under system load, the Qpid JMS client doesn't handle scheduled message
delivery correct - it delivers the message prior to the required time.
When running one request, the scheduling works correctly.
I have used different JMS Brokers with the same client code and the same
problem occurs with both Brokers (see environment).
I am using Spring JMS Template to send the JMS message. The key piece of code
is something like:
{{delayedDeliveryjmsTemplate.setDeliveryDelay(timeoutPeriod)}}
I realise you want more logging details but I'm unsure what would be best to
log. Please let me know and I'll do so.
> JMS Scheduled Delivery delivers messages before time under load
> ---
>
> Key: QPIDJMS-409
> URL: https://issues.apache.org/jira/browse/QPIDJMS-409
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.35.0
> Environment: Application is a Spring Boot application - version
> 2.0.4.RELEASE
> Qpid JMS Client version is 0.35.0
> Operating system where problem occurs is Windows 10
> I have found this problem using the following different message brokers:
> * Apache Artemis 2.4.0
> * Apache Artemis 2.6.2
> * Apache Qpid Broker 7.0.6
>Reporter: Ian Rowlands
>Priority: Major
>
> When under system load, the Qpid JMS client doesn't handle scheduled message
> delivery correct - it delivers the message prior to the required time.
> When running one request, the scheduling works correctly. The load to
> reproduce this isn't very high (i.e running about 5 of my job processes
> simultaneously seems to trip it up pretty quickly).
> I have used different JMS Brokers with the same client code and the same
> problem occurs with both Brokers (see environment).
> I am using Spring JMS Template to send the JMS message. The key piece of code
> is something like:
> {{delayedDeliveryjmsTemplate.setDeliveryDelay(timeoutPeriod)}}
>
> I realise you want more logging details but I'm unsure what would be best to
> log. Please let me know and I'll do so.
>
>
--
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-409) JMS Scheduled Delivery delivers messages before time under load
Ian Rowlands created QPIDJMS-409:
Summary: JMS Scheduled Delivery delivers messages before time
under load
Key: QPIDJMS-409
URL: https://issues.apache.org/jira/browse/QPIDJMS-409
Project: Qpid JMS
Issue Type: Bug
Components: qpid-jms-client
Affects Versions: 0.35.0
Environment: Application is a Spring Boot application - version
2.0.4.RELEASE
Qpid JMS Client version is 0.35.0
Operating system where problem occurs is Windows 10
I have found this problem using the following different message brokers:
* Apache Artemis 2.4.0
* Apache Artemis 2.6.2
* Apache Qpid Broker 7.0.6
Reporter: Ian Rowlands
When under system load, the Qpid JMS client doesn't handle scheduled message
delivery correct - it delivers the message prior to the required time.
When running one request, the scheduling works correctly.
I have used different JMS Brokers with the same client code and the same
problem occurs with both Brokers (see environment).
I am using Spring JMS Template to send the JMS message. The key piece of code
is something like:
{{delayedDeliveryjmsTemplate.setDeliveryDelay(timeoutPeriod)}}
I realise you want more logging details but I'm unsure what would be best to
log. Please let me know and I'll do so.
--
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] (PROTON-1842) [c] Dispatch/Proton crashes when opening/closing connections
[
https://issues.apache.org/jira/browse/PROTON-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16580753#comment-16580753
]
ASF subversion and git services commented on PROTON-1842:
-
Commit c601b98618dd4f45041501b080f761db4dd8285f in qpid-proton's branch
refs/heads/master from Clifford Jansen
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=c601b98 ]
PROTON-1842: revert 79d9019 temporary mitigation for follow-on long term fix
> [c] Dispatch/Proton crashes when opening/closing connections
>
>
> Key: PROTON-1842
> URL: https://issues.apache.org/jira/browse/PROTON-1842
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.22.0
>Reporter: Chuck Rolke
>Assignee: Alan Conway
>Priority: Major
> Attachments: helloworld.cpp, race.tsan, race.vg
>
>
> Using proton cpp example code that is modified to open and close connections
> by the thousands in the main loop and having the event loop short circuit any
> messaging with:
> {{ void on_connection_open(proton::connection& c) {}}
> {{ c.close();}}
> {{ }}}
> and then directing this client example to a dispatch router 1.1.0. Eventually
> (after 100,000 to 1,000,000 connection open/closes) the router crashes with:
> {{qdrouterd: /home/chug/git/qpid-proton/c/src/proactor/epoll.c:466:
> wake_pop_front: Assertion `p->wakes_in_progress' failed.}}
> and with:
> {{qdrouterd: /home/chug/git/qpid-proton/c/src/proactor/epoll.c:2014:
> proactor_do_epoll: Assertion `ee->type == PCONNECTION_TIMER' failed.}}
> This issue seems to happen only with qpid-dispatch accepting the open/close
> event stream. Proton cpp example _server_direct_ and c example _direct_ work
> properly with the same open/close event stream mounting into the 10s of
> millions of connections.
> A core dump backtrace with the PCONNECTION_TIMER failure reads as:
> {{(gdb) bt}}
> {{#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51}}
> {{#1 0x7f795c712c41 in __GI_abort () at abort.c:79}}
> {{#2 0x7f795c709f7a in __assert_fail_base (fmt=0x7f795c85a260
> "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
> assertion=assertion@entry=0x7f795d72e15a "ee->type == PCONNECTION_TIMER", }}
> {{ file=file@entry=0x7f795d72de98
> "/home/chug/git/qpid-proton/c/src/proactor/epoll.c", line=line@entry=2014, }}
> {{ function=function@entry=0x7f795d72e320 <__PRETTY_FUNCTION__.6307>
> "proactor_do_epoll") at assert.c:92}}
> {{#3 0x7f795c709ff2 in __GI___assert_fail (assertion=0x7f795d72e15a
> "ee->type == PCONNECTION_TIMER", file=0x7f795d72de98
> "/home/chug/git/qpid-proton/c/src/proactor/epoll.c", line=2014, }}
> {{ function=0x7f795d72e320 <__PRETTY_FUNCTION__.6307> "proactor_do_epoll")
> at assert.c:101}}
> {{#4 0x7f795d72d29f in proactor_do_epoll (p=0x26b7310, can_block=true)
> at /home/chug/git/qpid-proton/c/src/proactor/epoll.c:2014}}
> {{#5 0x7f795d72d30e in pn_proactor_wait (p=0x26b7310) at
> /home/chug/git/qpid-proton/c/src/proactor/epoll.c:2030}}
> {{#6 0x7f795dbe89ad in thread_run (arg=0x26be750) at
> /home/chug/git/qpid-dispatch/src/server.c:946}}
> {{#7 0x7f795d50e50b in start_thread (arg=0x7f794f486700) at
> pthread_create.c:465}}
> {{#8 0x7f795c7d216f in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95}}
>
--
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] (PROTON-1842) [c] Dispatch/Proton crashes when opening/closing connections
[
https://issues.apache.org/jira/browse/PROTON-1842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16580754#comment-16580754
]
ASF subversion and git services commented on PROTON-1842:
-
Commit 803a47ed386497f6467dd4f5fb4f9f57d545695d in qpid-proton's branch
refs/heads/master from Clifford Jansen
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=803a47e ]
PROTON-1842: epoll proactor - add secondary/chained epollfd to maintain 1-1
count between epoll registrations and eventual callbacks on pconnections
> [c] Dispatch/Proton crashes when opening/closing connections
>
>
> Key: PROTON-1842
> URL: https://issues.apache.org/jira/browse/PROTON-1842
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.22.0
>Reporter: Chuck Rolke
>Assignee: Alan Conway
>Priority: Major
> Attachments: helloworld.cpp, race.tsan, race.vg
>
>
> Using proton cpp example code that is modified to open and close connections
> by the thousands in the main loop and having the event loop short circuit any
> messaging with:
> {{ void on_connection_open(proton::connection& c) {}}
> {{ c.close();}}
> {{ }}}
> and then directing this client example to a dispatch router 1.1.0. Eventually
> (after 100,000 to 1,000,000 connection open/closes) the router crashes with:
> {{qdrouterd: /home/chug/git/qpid-proton/c/src/proactor/epoll.c:466:
> wake_pop_front: Assertion `p->wakes_in_progress' failed.}}
> and with:
> {{qdrouterd: /home/chug/git/qpid-proton/c/src/proactor/epoll.c:2014:
> proactor_do_epoll: Assertion `ee->type == PCONNECTION_TIMER' failed.}}
> This issue seems to happen only with qpid-dispatch accepting the open/close
> event stream. Proton cpp example _server_direct_ and c example _direct_ work
> properly with the same open/close event stream mounting into the 10s of
> millions of connections.
> A core dump backtrace with the PCONNECTION_TIMER failure reads as:
> {{(gdb) bt}}
> {{#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51}}
> {{#1 0x7f795c712c41 in __GI_abort () at abort.c:79}}
> {{#2 0x7f795c709f7a in __assert_fail_base (fmt=0x7f795c85a260
> "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
> assertion=assertion@entry=0x7f795d72e15a "ee->type == PCONNECTION_TIMER", }}
> {{ file=file@entry=0x7f795d72de98
> "/home/chug/git/qpid-proton/c/src/proactor/epoll.c", line=line@entry=2014, }}
> {{ function=function@entry=0x7f795d72e320 <__PRETTY_FUNCTION__.6307>
> "proactor_do_epoll") at assert.c:92}}
> {{#3 0x7f795c709ff2 in __GI___assert_fail (assertion=0x7f795d72e15a
> "ee->type == PCONNECTION_TIMER", file=0x7f795d72de98
> "/home/chug/git/qpid-proton/c/src/proactor/epoll.c", line=2014, }}
> {{ function=0x7f795d72e320 <__PRETTY_FUNCTION__.6307> "proactor_do_epoll")
> at assert.c:101}}
> {{#4 0x7f795d72d29f in proactor_do_epoll (p=0x26b7310, can_block=true)
> at /home/chug/git/qpid-proton/c/src/proactor/epoll.c:2014}}
> {{#5 0x7f795d72d30e in pn_proactor_wait (p=0x26b7310) at
> /home/chug/git/qpid-proton/c/src/proactor/epoll.c:2030}}
> {{#6 0x7f795dbe89ad in thread_run (arg=0x26be750) at
> /home/chug/git/qpid-dispatch/src/server.c:946}}
> {{#7 0x7f795d50e50b in start_thread (arg=0x7f794f486700) at
> pthread_create.c:465}}
> {{#8 0x7f795c7d216f in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95}}
>
--
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
