[jira] [Commented] (QPID-7203) Model loses audit information
[
https://issues.apache.org/jira/browse/QPID-7203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15299490#comment-15299490
]
Keith Wall commented on QPID-7203:
--
I made a simple change to resolve the problem, special casing
createdBy/createdDate/lastUpdateBy/lastUpdateDate in the same way as
AutoGeneratedSelfSignedKeyStore and SiteSpecificTrustStore already do for their
storable derived attributes. I think in the long term we should look again at
how these attributes types are represented in the model. I think the code would
be cleaner if ManagedAttribute had a flag userMaintainable. If this flag were
set false, ACO would know to reject values from the outside but would still
persist/resolve the attribute in the normal way.
> Model loses audit information
> --
>
> Key: QPID-7203
> URL: https://issues.apache.org/jira/browse/QPID-7203
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: 0.30, 0.32, qpid-java-6.0, qpid-java-6.0.1
>Reporter: Keith Wall
>
> The Broker is supposed to save audit information on each object:
> {{createdBy}}, {{createdDate}}, {{lastUpdatedBy}}, {{lastUpdatedDate}}. This
> feature is broken and has been so since at least 0.30.
> The values are persisted properly to the message store, but on recovery, they
> only make it as far as the attribute map backing the configured object. The
> mechanics of ACO fails to reunite the attribute value with the field
> underlying each attribute. As a result the audit trail is unreliable.
> The problem would affect any storable derived attribute. Other storable
> derived attributes AutoGeneratedSelfSignedKeyStore and SiteSpecificTrustStore
> use {{postResolve}} to reunite the attribute with the field.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7203) Model loses audit information
[
https://issues.apache.org/jira/browse/QPID-7203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7203:
-
Description:
The Broker is supposed to save audit information on each object: {{createdBy}},
{{createdDate}}, {{lastUpdatedBy}}, {{lastUpdatedDate}}. This feature is
broken and has been so since at least 0.30.
The values are persisted properly to the message store, but on recovery, they
only make it as far as the attribute map backing the configured object. The
mechanics of ACO fails to reunite the attribute value with the field underlying
each attribute. As a result the audit trail is unreliable.
The problem would affect any storable derived attribute. Other storable
derived attributes AutoGeneratedSelfSignedKeyStore and SiteSpecificTrustStore
use {{postResolve}} to reunite the attribute with the field.
was:
The Broker is supposed to save audit information on each object: {{createdBy}},
{{createdDate}}, {{lastUpdatedBy}}, {{lastUpdatedDate}}. This feature is
broken and has been so since at least 0.30.
The values are persisted properly to the message store, but on recovery, they
only make it as far as the attribute map backing the configured object. The
mechanics of ACO fails to reunite the attribute value with the field underlying
each attribute.
As a result the created values are lost on each save and the neither created or
last can be viewed from Management.
The problem affects all derived attributes that are storeable. From what I
can tell, this is the only case where there is a functional impact.
> Model loses audit information
> --
>
> Key: QPID-7203
> URL: https://issues.apache.org/jira/browse/QPID-7203
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: 0.30, 0.32, qpid-java-6.0, qpid-java-6.0.1
>Reporter: Keith Wall
>
> The Broker is supposed to save audit information on each object:
> {{createdBy}}, {{createdDate}}, {{lastUpdatedBy}}, {{lastUpdatedDate}}. This
> feature is broken and has been so since at least 0.30.
> The values are persisted properly to the message store, but on recovery, they
> only make it as far as the attribute map backing the configured object. The
> mechanics of ACO fails to reunite the attribute value with the field
> underlying each attribute. As a result the audit trail is unreliable.
> The problem would affect any storable derived attribute. Other storable
> derived attributes AutoGeneratedSelfSignedKeyStore and SiteSpecificTrustStore
> use {{postResolve}} to reunite the attribute with the field.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7276) Message delay improvements
[
https://issues.apache.org/jira/browse/QPID-7276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7276:
-
Assignee: (was: Keith Wall)
> Message delay improvements
> --
>
> Key: QPID-7276
> URL: https://issues.apache.org/jira/browse/QPID-7276
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.1
>
>
> QPID-7255 introduced support of message delays. To make the feature more
> useful/usable, the following additions are identified:
> # Make the Broker provide a connection property that reveals that it supports
> the notValidBefore feature. Make clients detect this feature and warn if the
> application tries to make use of the address options.
> # Extend the Queue UI to allow {{holdOnPublishEnabled}} to be enabled when
> creating or updating a queue.
> # Reveal through the UI when a Queue Entry is held.
> # Make the Message content UI treat {{NotValidBefore}} as a date/time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7276) Message delay improvements
[
https://issues.apache.org/jira/browse/QPID-7276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall reassigned QPID-7276:
Assignee: Keith Wall
> Message delay improvements
> --
>
> Key: QPID-7276
> URL: https://issues.apache.org/jira/browse/QPID-7276
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-6.1
>
>
> QPID-7255 introduced support of message delays. To make the feature more
> useful/usable, the following additions are identified:
> # Make the Broker provide a connection property that reveals that it supports
> the notValidBefore feature. Make clients detect this feature and warn if the
> application tries to make use of the address options.
> # Extend the Queue UI to allow {{holdOnPublishEnabled}} to be enabled when
> creating or updating a queue.
> # Reveal through the UI when a Queue Entry is held.
> # Make the Message content UI treat {{NotValidBefore}} as a date/time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7203) Model loses audit information
[
https://issues.apache.org/jira/browse/QPID-7203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15299478#comment-15299478
]
ASF subversion and git services commented on QPID-7203:
---
Commit 1745424 from [~k-wall] in branch 'java/trunk'
[ https://svn.apache.org/r1745424 ]
QPID-7203: [Java Broker] Ensure
createdBy/createdDate/lastUpdateBy/lastUpdateDate are resolved
This special cases these attribites in the same way as the other derived
storable attributes.
> Model loses audit information
> --
>
> Key: QPID-7203
> URL: https://issues.apache.org/jira/browse/QPID-7203
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: 0.30, 0.32, qpid-java-6.0, qpid-java-6.0.1
>Reporter: Keith Wall
>
> The Broker is supposed to save audit information on each object:
> {{createdBy}}, {{createdDate}}, {{lastUpdatedBy}}, {{lastUpdatedDate}}. This
> feature is broken and has been so since at least 0.30.
> The values are persisted properly to the message store, but on recovery, they
> only make it as far as the attribute map backing the configured object. The
> mechanics of ACO fails to reunite the attribute value with the field
> underlying each attribute.
> As a result the created values are lost on each save and the neither created
> or last can be viewed from Management.
> The problem affects all derived attributes that are storeable. From what I
> can tell, this is the only case where there is a functional impact.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1212) pn_unique_ptr operator ! returns the opposite result
[ https://issues.apache.org/jira/browse/PROTON-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-1212. - Resolution: Fixed Fix Version/s: 0.13.0 > pn_unique_ptr operator ! returns the opposite result > > > Key: PROTON-1212 > URL: https://issues.apache.org/jira/browse/PROTON-1212 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.12.0 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.13.0 > > > This would in principle be a blocker, but I don't think it is actually used > anywhere. > However I would be in favour of releasing 0.13 with this fix. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1212) pn_unique_ptr operator ! returns the opposite result
[ https://issues.apache.org/jira/browse/PROTON-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15299427#comment-15299427 ] ASF subversion and git services commented on PROTON-1212: - Commit cdc4346ecf8064ee874ba0f362a059c01d9f7b74 in qpid-proton's branch refs/heads/0.13.x from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=cdc4346 ] PROTON-1212: [C++ binding] Fix bool conversions of pn_unique_ptr > pn_unique_ptr operator ! returns the opposite result > > > Key: PROTON-1212 > URL: https://issues.apache.org/jira/browse/PROTON-1212 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.12.0 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > > This would in principle be a blocker, but I don't think it is actually used > anywhere. > However I would be in favour of releasing 0.13 with this fix. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-343) Router stops accepting connections after load from parallel senders
[ https://issues.apache.org/jira/browse/DISPATCH-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15299332#comment-15299332 ] Ted Ross commented on DISPATCH-343: --- Vishal, Can you check the integrity of your build? Make sure that the dispatch and proton libraries that you're running with are the same as you built with. You can run ldd against the qdrouterd executable to get the list of libraries. The type of problems you are reporting look like internal data corruption. Nobody else has reported seeing this and our testing has not shown any similar behavior. I'm wondering if there's something wrong with your installation or if there's something specific to Debian going on. We are putting together a Debian 8 system to test your scenario on. -Ted > Router stops accepting connections after load from parallel senders > --- > > Key: DISPATCH-343 > URL: https://issues.apache.org/jira/browse/DISPATCH-343 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 >Reporter: Vishal Sharda >Priority: Blocker > Attachments: Connection_aborted.png, Connection_aborted_1.png, > Crash.png, Crash_10S_2R.png, R1.conf, R2.conf, R3.conf, > Sender_router_crash.png, bt_qd_dealloc.png, bt_qdr_link_cleanup_CT.png, > bt_sasl.png, bt_sys_mutex_lock.png, config1_nossl.conf, config2_nossl.conf, > resource-limit-exceeded.png > > > We ran 2 parallel senders and 2 receivers with each sender sending 5 > messages. After a while we saw that router stopped accepting connections > even from qdstat. We saw various errors in the logs (screenshots attached). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (PROTON-1213) Fix quick_perf_xx targets.
[ https://issues.apache.org/jira/browse/PROTON-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen closed PROTON-1213. Resolution: Fixed > Fix quick_perf_xx targets. > -- > > Key: PROTON-1213 > URL: https://issues.apache.org/jira/browse/PROTON-1213 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding, proton-c, python-binding >Affects Versions: 0.14.0 >Reporter: Cliff Jansen >Assignee: Cliff Jansen > > The quick_perf targets for performance sanity checks have been broken > for some time. > The launch script for the quick_perf_c etc targets depended on other > test scripts which were re-written over time to fix race conditions > and python version variations. > This fix changes none of the logic, just uses the new conventions from > the other scripts. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1213) Fix quick_perf_xx targets.
[ https://issues.apache.org/jira/browse/PROTON-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15299272#comment-15299272 ] ASF subversion and git services commented on PROTON-1213: - Commit 5a1a32cbc4657125c352c6e6d24e5edfec8b4737 in qpid-proton's branch refs/heads/master from Clifford Jansen [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=5a1a32c ] PROTON-1213: Fix quick_perf_xx targets. > Fix quick_perf_xx targets. > -- > > Key: PROTON-1213 > URL: https://issues.apache.org/jira/browse/PROTON-1213 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding, proton-c, python-binding >Affects Versions: 0.14.0 >Reporter: Cliff Jansen >Assignee: Cliff Jansen > > The quick_perf targets for performance sanity checks have been broken > for some time. > The launch script for the quick_perf_c etc targets depended on other > test scripts which were re-written over time to fix race conditions > and python version variations. > This fix changes none of the logic, just uses the new conventions from > the other scripts. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1213) Fix quick_perf_xx targets.
Cliff Jansen created PROTON-1213: Summary: Fix quick_perf_xx targets. Key: PROTON-1213 URL: https://issues.apache.org/jira/browse/PROTON-1213 Project: Qpid Proton Issue Type: Bug Components: cpp-binding, proton-c, python-binding Affects Versions: 0.14.0 Reporter: Cliff Jansen Assignee: Cliff Jansen The quick_perf targets for performance sanity checks have been broken for some time. The launch script for the quick_perf_c etc targets depended on other test scripts which were re-written over time to fix race conditions and python version variations. This fix changes none of the logic, just uses the new conventions from the other scripts. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-343) Router stops accepting connections after load from parallel senders
[ https://issues.apache.org/jira/browse/DISPATCH-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15299218#comment-15299218 ] Vishal Sharda commented on DISPATCH-343: Also hit the crash reported in bt_qd_dealloc.png without SSL. > Router stops accepting connections after load from parallel senders > --- > > Key: DISPATCH-343 > URL: https://issues.apache.org/jira/browse/DISPATCH-343 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 >Reporter: Vishal Sharda >Priority: Blocker > Attachments: Connection_aborted.png, Connection_aborted_1.png, > Crash.png, Crash_10S_2R.png, R1.conf, R2.conf, R3.conf, > Sender_router_crash.png, bt_qd_dealloc.png, bt_qdr_link_cleanup_CT.png, > bt_sasl.png, bt_sys_mutex_lock.png, config1_nossl.conf, config2_nossl.conf, > resource-limit-exceeded.png > > > We ran 2 parallel senders and 2 receivers with each sender sending 5 > messages. After a while we saw that router stopped accepting connections > even from qdstat. We saw various errors in the logs (screenshots attached). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-343) Router stops accepting connections after load from parallel senders
[ https://issues.apache.org/jira/browse/DISPATCH-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Sharda updated DISPATCH-343: --- Attachment: config2_nossl.conf config1_nossl.conf The two config files used for no SSL configuration of two routers. > Router stops accepting connections after load from parallel senders > --- > > Key: DISPATCH-343 > URL: https://issues.apache.org/jira/browse/DISPATCH-343 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 >Reporter: Vishal Sharda >Priority: Blocker > Attachments: Connection_aborted.png, Connection_aborted_1.png, > Crash.png, Crash_10S_2R.png, R1.conf, R2.conf, R3.conf, > Sender_router_crash.png, bt_qd_dealloc.png, bt_qdr_link_cleanup_CT.png, > bt_sasl.png, bt_sys_mutex_lock.png, config1_nossl.conf, config2_nossl.conf, > resource-limit-exceeded.png > > > We ran 2 parallel senders and 2 receivers with each sender sending 5 > messages. After a while we saw that router stopped accepting connections > even from qdstat. We saw various errors in the logs (screenshots attached). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1211) C++ binding exception in message::correlation_id()
[ https://issues.apache.org/jira/browse/PROTON-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15299202#comment-15299202 ] ASF subversion and git services commented on PROTON-1211: - Commit ebc78988a0f28399cbbc91edb5c63a4218084571 in qpid-proton's branch refs/heads/master from Clifford Jansen [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=ebc7898 ] PROTON-1211: C++ binding - incorrect replacing of message correlation_id > C++ binding exception in message::correlation_id() > -- > > Key: PROTON-1211 > URL: https://issues.apache.org/jira/browse/PROTON-1211 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.13.0, 0.14.0 >Reporter: Cliff Jansen >Assignee: Cliff Jansen >Priority: Blocker > Fix For: 0.13.0 > > Attachments: msgid.cpp > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-343) Router stops accepting connections after load from parallel senders
[ https://issues.apache.org/jira/browse/DISPATCH-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15299200#comment-15299200 ] Vishal Sharda commented on DISPATCH-343: I have completely removed SSL. The two config files are attached. Still, I hit the crashes that I reported in bt_qdr_link_cleanup_CT.png and bt_sys_mutex_lock.png. > Router stops accepting connections after load from parallel senders > --- > > Key: DISPATCH-343 > URL: https://issues.apache.org/jira/browse/DISPATCH-343 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 >Reporter: Vishal Sharda >Priority: Blocker > Attachments: Connection_aborted.png, Connection_aborted_1.png, > Crash.png, Crash_10S_2R.png, R1.conf, R2.conf, R3.conf, > Sender_router_crash.png, bt_qd_dealloc.png, bt_qdr_link_cleanup_CT.png, > bt_sasl.png, bt_sys_mutex_lock.png, resource-limit-exceeded.png > > > We ran 2 parallel senders and 2 receivers with each sender sending 5 > messages. After a while we saw that router stopped accepting connections > even from qdstat. We saw various errors in the logs (screenshots attached). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1212) pn_unique_ptr operator ! returns the opposite result
[ https://issues.apache.org/jira/browse/PROTON-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15298959#comment-15298959 ] Justin Ross commented on PROTON-1212: - Reviewed by Alan. Approved for 0.13.0. > pn_unique_ptr operator ! returns the opposite result > > > Key: PROTON-1212 > URL: https://issues.apache.org/jira/browse/PROTON-1212 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.12.0 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > > This would in principle be a blocker, but I don't think it is actually used > anywhere. > However I would be in favour of releasing 0.13 with this fix. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-343) Router stops accepting connections after load from parallel senders
[ https://issues.apache.org/jira/browse/DISPATCH-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15298916#comment-15298916 ] Ganesh Murthy commented on DISPATCH-343: Vishal, is this problem happening to you without SSL? Can you please remove SSL from everywhere and try again? Just want make sure that we can get SSL out of the way. > Router stops accepting connections after load from parallel senders > --- > > Key: DISPATCH-343 > URL: https://issues.apache.org/jira/browse/DISPATCH-343 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 >Reporter: Vishal Sharda >Priority: Blocker > Attachments: Connection_aborted.png, Connection_aborted_1.png, > Crash.png, Crash_10S_2R.png, R1.conf, R2.conf, R3.conf, > Sender_router_crash.png, bt_qd_dealloc.png, bt_qdr_link_cleanup_CT.png, > bt_sasl.png, bt_sys_mutex_lock.png, resource-limit-exceeded.png > > > We ran 2 parallel senders and 2 receivers with each sender sending 5 > messages. After a while we saw that router stopped accepting connections > even from qdstat. We saw various errors in the logs (screenshots attached). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-343) Router stops accepting connections after load from parallel senders
[ https://issues.apache.org/jira/browse/DISPATCH-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Sharda updated DISPATCH-343: --- Attachment: bt_qdr_link_cleanup_CT.png One more backtrace of a crash. > Router stops accepting connections after load from parallel senders > --- > > Key: DISPATCH-343 > URL: https://issues.apache.org/jira/browse/DISPATCH-343 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 >Reporter: Vishal Sharda >Priority: Blocker > Attachments: Connection_aborted.png, Connection_aborted_1.png, > Crash.png, Crash_10S_2R.png, R1.conf, R2.conf, R3.conf, > Sender_router_crash.png, bt_qd_dealloc.png, bt_qdr_link_cleanup_CT.png, > bt_sasl.png, bt_sys_mutex_lock.png, resource-limit-exceeded.png > > > We ran 2 parallel senders and 2 receivers with each sender sending 5 > messages. After a while we saw that router stopped accepting connections > even from qdstat. We saw various errors in the logs (screenshots attached). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1212) pn_unique_ptr operator ! returns the opposite result
[ https://issues.apache.org/jira/browse/PROTON-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15298891#comment-15298891 ] Alan Conway commented on PROTON-1212: - Approved for 0.13. > pn_unique_ptr operator ! returns the opposite result > > > Key: PROTON-1212 > URL: https://issues.apache.org/jira/browse/PROTON-1212 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.12.0 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > > This would in principle be a blocker, but I don't think it is actually used > anywhere. > However I would be in favour of releasing 0.13 with this fix. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1212) pn_unique_ptr operator ! returns the opposite result
[ https://issues.apache.org/jira/browse/PROTON-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15298871#comment-15298871 ] ASF subversion and git services commented on PROTON-1212: - Commit 23d2686bb5d2c8963dea2d8810e8a574a33785ac in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=23d2686 ] PROTON-1212: [C++ binding] Fix bool conversions of pn_unique_ptr > pn_unique_ptr operator ! returns the opposite result > > > Key: PROTON-1212 > URL: https://issues.apache.org/jira/browse/PROTON-1212 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.12.0 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > > This would in principle be a blocker, but I don't think it is actually used > anywhere. > However I would be in favour of releasing 0.13 with this fix. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-343) Router stops accepting connections after load from parallel senders
[ https://issues.apache.org/jira/browse/DISPATCH-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Sharda updated DISPATCH-343: --- Attachment: bt_sys_mutex_lock.png bt_sasl.png bt_qd_dealloc.png Screenshots with backtrace under different types of crashes. > Router stops accepting connections after load from parallel senders > --- > > Key: DISPATCH-343 > URL: https://issues.apache.org/jira/browse/DISPATCH-343 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 >Reporter: Vishal Sharda >Priority: Blocker > Attachments: Connection_aborted.png, Connection_aborted_1.png, > Crash.png, Crash_10S_2R.png, R1.conf, R2.conf, R3.conf, > Sender_router_crash.png, bt_qd_dealloc.png, bt_sasl.png, > bt_sys_mutex_lock.png, resource-limit-exceeded.png > > > We ran 2 parallel senders and 2 receivers with each sender sending 5 > messages. After a while we saw that router stopped accepting connections > even from qdstat. We saw various errors in the logs (screenshots attached). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1212) pn_unique_ptr operator ! returns the opposite result
Andrew Stitcher created PROTON-1212: --- Summary: pn_unique_ptr operator ! returns the opposite result Key: PROTON-1212 URL: https://issues.apache.org/jira/browse/PROTON-1212 Project: Qpid Proton Issue Type: Bug Components: cpp-binding Affects Versions: 0.12.0 Reporter: Andrew Stitcher Assignee: Andrew Stitcher This would in principle be a blocker, but I don't think it is actually used anywhere. However I would be in favour of releasing 0.13 with this fix. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-910) Proton-J SASL implementation should support new SASL APIs
[ https://issues.apache.org/jira/browse/PROTON-910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher updated PROTON-910: --- Issue Type: Improvement (was: Sub-task) Parent: (was: PROTON-334) > Proton-J SASL implementation should support new SASL APIs > - > > Key: PROTON-910 > URL: https://issues.apache.org/jira/browse/PROTON-910 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Andrew Stitcher > > The Java Proton implementation should be able to support the basic SASL > implementation APIs. > This would enable removing some of the seemingly arbitrary test skips for > SASL tests if we're running in Jython. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-334) SASL Implementation for Proton C
[ https://issues.apache.org/jira/browse/PROTON-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-334. Resolution: Fixed Resolving this as Proton-J implementation or not isn't really a subtask. > SASL Implementation for Proton C > > > Key: PROTON-334 > URL: https://issues.apache.org/jira/browse/PROTON-334 > Project: Qpid Proton > Issue Type: Wish > Components: proton-c >Reporter: Ted Ross >Assignee: Andrew Stitcher > > It would be desirable to have the ability to use a plug-in module for SASL in > Proton. The following implementations could then be developed: > 1) A portable stand-alone plugin that does ANONYMOUS, PLAIN, and EXTERNAL > 2) A Cyrus-Sasl based plugin for Linux > 3) A Windows plugin -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-340) Test inter_router_plain_over_ssl fails to find SSL connection
[ https://issues.apache.org/jira/browse/DISPATCH-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-340. Resolution: Fixed Fix Version/s: 0.6.0 > Test inter_router_plain_over_ssl fails to find SSL connection > - > > Key: DISPATCH-340 > URL: https://issues.apache.org/jira/browse/DISPATCH-340 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 0.6.0 > Environment: Fedora x86_64 >Reporter: Chuck Rolke >Assignee: Chuck Rolke > Fix For: 0.6.0 > > > The test looks in results[0][xxx] for the SSL connection properties when they > are in results[1][xxx]. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-340) Test inter_router_plain_over_ssl fails to find SSL connection
[ https://issues.apache.org/jira/browse/DISPATCH-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15298816#comment-15298816 ] ASF subversion and git services commented on DISPATCH-340: -- Commit 8783d5e22b0a9bf29728c03e8c3204a4db18d4e9 in qpid-dispatch's branch refs/heads/master from [~ganeshmurthy] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=8783d5e ] DISPATCH-340 - Additional fix to allow time for the routers to be able to communicate with each other > Test inter_router_plain_over_ssl fails to find SSL connection > - > > Key: DISPATCH-340 > URL: https://issues.apache.org/jira/browse/DISPATCH-340 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 0.6.0 > Environment: Fedora x86_64 >Reporter: Chuck Rolke >Assignee: Chuck Rolke > > The test looks in results[0][xxx] for the SSL connection properties when they > are in results[1][xxx]. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7256) When invoke the method "connection.start" in a loop,reporting socket closed
[ https://issues.apache.org/jira/browse/QPID-7256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15298747#comment-15298747 ] Keith Wall commented on QPID-7256: -- Steven If you continue to have this problem I suggest you increase the Broker's logging verbosity to hopefully expose the problem. To do this enable AMQP 1.0 frame level logging within the Java Broker. You can do this using the Web Management Console by adding a Log Inclusion Rule for log event source "FRM" at level DEBUG. See https://qpid.apache.org/releases/qpid-java-6.0.1/java-broker/book/Java-Broker-Runtime.html#Java-Broker-Runtime-Logging for more details. Once you have done this, repeat your test and attach the relevant part of the qpid.log to the Jira. I suggest you keep using the newer client Qpid JMS Client 0.9.0. > When invoke the method "connection.start" in a loop,reporting socket closed > --- > > Key: QPID-7256 > URL: https://issues.apache.org/jira/browse/QPID-7256 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.32 > Environment: windows7、 jdk7 >Reporter: Steven > > I use the for loop,It will loop 1000 times,every time,I create a > connection,then send message,After the message has been sent,close the > connection. > this loop executed it for some times,It will report error,as you can see the > screen shot -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1211) C++ binding exception in message::correlation_id()
[ https://issues.apache.org/jira/browse/PROTON-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15298748#comment-15298748 ] Alan Conway commented on PROTON-1211: - e.clear() is correct, the previous code was a bug. make_wrapper doesn't make a new data object, it just makes a C++ pointer wrapper to the existing one, so repeatedly calling << will make it grow. This is old code and could be made more intuitive by the value API, where assignment replaces the existing contents. However the patch above with e.clear() is correct. > C++ binding exception in message::correlation_id() > -- > > Key: PROTON-1211 > URL: https://issues.apache.org/jira/browse/PROTON-1211 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.13.0, 0.14.0 >Reporter: Cliff Jansen >Assignee: Cliff Jansen >Priority: Blocker > Fix For: 0.13.0 > > Attachments: msgid.cpp > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-1211) C++ binding exception in message::correlation_id()
[
https://issues.apache.org/jira/browse/PROTON-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15298738#comment-15298738
]
Cliff Jansen edited comment on PROTON-1211 at 5/24/16 7:15 PM:
---
Simplest fix is to just clear the pn_data_t before new insertion:
{code}
diff -c message.cpp.cj0 message.cpp
*** 143,148
--- 143,149
void message::correlation_id(const message_id& id) {
codec::encoder e(make_wrapper(pn_message_correlation_id(pn_msg(;
+ e.clear();
e << id;
}
{code}
But perhaps new encoders should clear by default as the more intuative use (and
have a separate constructor for the "and save my current position" case).
was (Author: cliffjansen):
Simplest fix is to just clear the pn_data_t before new insertion:
{quote}
diff -c message.cpp.cj0 message.cpp
*** 143,148
--- 143,149
void message::correlation_id(const message_id& id) {
codec::encoder e(make_wrapper(pn_message_correlation_id(pn_msg(;
+ e.clear();
e << id;
}
{quote}
But perhaps new encoders should clear by default as the more intuative use (and
have a separate constructor for the "and save my current position" case).
> C++ binding exception in message::correlation_id()
> --
>
> Key: PROTON-1211
> URL: https://issues.apache.org/jira/browse/PROTON-1211
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: 0.13.0, 0.14.0
>Reporter: Cliff Jansen
>Assignee: Cliff Jansen
>Priority: Blocker
> Fix For: 0.13.0
>
> Attachments: msgid.cpp
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-1211) C++ binding exception in message::correlation_id()
[
https://issues.apache.org/jira/browse/PROTON-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15298738#comment-15298738
]
Cliff Jansen edited comment on PROTON-1211 at 5/24/16 7:14 PM:
---
Simplest fix is to just clear the pn_data_t before new insertion:
{quote}
diff -c message.cpp.cj0 message.cpp
*** 143,148
--- 143,149
void message::correlation_id(const message_id& id) {
codec::encoder e(make_wrapper(pn_message_correlation_id(pn_msg(;
+ e.clear();
e << id;
}
{quote}
But perhaps new encoders should clear by default as the more intuative use (and
have a separate constructor for the "and save my current position" case).
was (Author: cliffjansen):
Simplest fix is to just clear the pn_data_t before new insertion:
diff -c message.cpp.cj0 message.cpp
*** 143,148
--- 143,149
void message::correlation_id(const message_id& id) {
codec::encoder e(make_wrapper(pn_message_correlation_id(pn_msg(;
+ e.clear();
e << id;
}
But perhaps new encoders should clear by default as the more intuative use (and
have a separate constructor for the "and save my current position" case).
> C++ binding exception in message::correlation_id()
> --
>
> Key: PROTON-1211
> URL: https://issues.apache.org/jira/browse/PROTON-1211
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: 0.13.0, 0.14.0
>Reporter: Cliff Jansen
>Assignee: Cliff Jansen
>Priority: Blocker
> Fix For: 0.13.0
>
> Attachments: msgid.cpp
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1211) C++ binding exception in message::correlation_id()
[
https://issues.apache.org/jira/browse/PROTON-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15298738#comment-15298738
]
Cliff Jansen commented on PROTON-1211:
--
Simplest fix is to just clear the pn_data_t before new insertion:
diff -c message.cpp.cj0 message.cpp
*** 143,148
--- 143,149
void message::correlation_id(const message_id& id) {
codec::encoder e(make_wrapper(pn_message_correlation_id(pn_msg(;
+ e.clear();
e << id;
}
But perhaps new encoders should clear by default as the more intuative use (and
have a separate constructor for the "and save my current position" case).
> C++ binding exception in message::correlation_id()
> --
>
> Key: PROTON-1211
> URL: https://issues.apache.org/jira/browse/PROTON-1211
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: 0.13.0, 0.14.0
>Reporter: Cliff Jansen
>Assignee: Cliff Jansen
>Priority: Blocker
> Fix For: 0.13.0
>
> Attachments: msgid.cpp
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1211) C++ binding exception in message::correlation_id()
[ https://issues.apache.org/jira/browse/PROTON-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen updated PROTON-1211: - Attachment: msgid.cpp Repeated setting of a message's correlation_id needlessly allocates a new pn_node_t struct maxing out at 64K nodes and an encoder exception. see attached reproducer > C++ binding exception in message::correlation_id() > -- > > Key: PROTON-1211 > URL: https://issues.apache.org/jira/browse/PROTON-1211 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.13.0, 0.14.0 >Reporter: Cliff Jansen >Assignee: Cliff Jansen >Priority: Blocker > Fix For: 0.13.0 > > Attachments: msgid.cpp > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1211) C++ binding exception in message::correlation_id()
Cliff Jansen created PROTON-1211: Summary: C++ binding exception in message::correlation_id() Key: PROTON-1211 URL: https://issues.apache.org/jira/browse/PROTON-1211 Project: Qpid Proton Issue Type: Bug Components: cpp-binding Affects Versions: 0.13.0, 0.14.0 Reporter: Cliff Jansen Assignee: Cliff Jansen Priority: Blocker Fix For: 0.13.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-179) The internal ID generator is appending an extra ':' value to ID prefixes
[ https://issues.apache.org/jira/browse/QPIDJMS-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-179. -- Resolution: Fixed > The internal ID generator is appending an extra ':' value to ID prefixes > > > Key: QPIDJMS-179 > URL: https://issues.apache.org/jira/browse/QPIDJMS-179 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.8.0, 0.9.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.10.0 > > > The ID generator is adding an additional colon (:) to all IDs by mistake > making them appear as ID::XXX -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-179) The internal ID generator is appending an extra ':' value to ID prefixes
[ https://issues.apache.org/jira/browse/QPIDJMS-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15298717#comment-15298717 ] ASF subversion and git services commented on QPIDJMS-179: - Commit 6b6e1a76c9721d619c88caa8d120547766c9b255 in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=6b6e1a7 ] QPIDJMS-179 Ensure we don't add extra characters to the given prefix. > The internal ID generator is appending an extra ':' value to ID prefixes > > > Key: QPIDJMS-179 > URL: https://issues.apache.org/jira/browse/QPIDJMS-179 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.8.0, 0.9.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.10.0 > > > The ID generator is adding an additional colon (:) to all IDs by mistake > making them appear as ID::XXX -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-180) Add a JmsMessageIDPolicy that imrpoves the existing message ID type configuration
[ https://issues.apache.org/jira/browse/QPIDJMS-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15298669#comment-15298669 ] ASF subversion and git services commented on QPIDJMS-180: - Commit 95bc1aa809b406c16e31802cf66c863cb0686a53 in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=95bc1aa ] QPIDJMS-180 Add JmsMessageIDPolicy and a default implementation that preserve previous behavior. > Add a JmsMessageIDPolicy that imrpoves the existing message ID type > configuration > - > > Key: QPIDJMS-180 > URL: https://issues.apache.org/jira/browse/QPIDJMS-180 > Project: Qpid JMS > Issue Type: Sub-task > Components: qpid-jms-client >Affects Versions: 0.9.0 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.10.0 > > > Add a new policy object JmsMessageIDPolicy that improves upon the existing > Message ID type configuration by allowing MessageProducer instances to be > configured with a Message ID Builder on a per destination basis or other > application specific criteria. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-337) Huge memory leaks in Qpid Dispatch router
[ https://issues.apache.org/jira/browse/DISPATCH-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15298647#comment-15298647 ] Ted Ross commented on DISPATCH-337: --- The following are singleton allocations at startup. We should clean these up at shutdown, but this is not a blocker issue. There is no memory leak. 2 bytes in 1 blocks are definitely lost in loss record 2 of 1,521 24 bytes in 1 blocks are definitely lost in loss record 550 of 1,521 24 bytes in 1 blocks are definitely lost in loss record 551 of 1,521 40 bytes in 1 blocks are definitely lost in loss record 677 of 1,521 48 bytes in 1 blocks are definitely lost in loss record 769 of 1,521 60 bytes in 1 blocks are definitely lost in loss record 774 of 1,521 1,024 bytes in 1 blocks are definitely lost in loss record 1,264 of 1,521 1,024 bytes in 1 blocks are definitely lost in loss record 1,265 of 1,521 1,024 bytes in 1 blocks are definitely lost in loss record 1,266 of 1,521 1,200 (1,024 direct, 176 indirect) bytes in 1 blocks are definitely lost in loss record 1,282 of 1,521 2,088 (40 direct, 2,048 indirect) bytes in 1 blocks are definitely lost in loss record 1,319 of 1,521 The following are associated with normal router operation (router nodes, sessions, connections, deliveries). I would like to know more about how the router was shut down before I consider these actual memory leaks. 52 bytes in 1 blocks are definitely lost in loss record 771 of 1,521 300 bytes in 1 blocks are definitely lost in loss record 1,049 of 1,521 300 bytes in 1 blocks are definitely lost in loss record 1,050 of 1,521 392 (196 direct, 196 indirect) bytes in 1 blocks are definitely lost in loss record 1,064 of 1,521 405,104 (288 direct, 404,816 indirect) bytes in 1 blocks are definitely lost in loss record 1,518 of 1,521 408,264 (288 direct, 407,976 indirect) bytes in 1 blocks are definitely lost in loss record 1,519 of 1,521 > Huge memory leaks in Qpid Dispatch router > - > > Key: DISPATCH-337 > URL: https://issues.apache.org/jira/browse/DISPATCH-337 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.6.0 > Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and > dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines >Reporter: Vishal Sharda >Priority: Critical > Attachments: config1.conf, config2.conf, val2_receiver.txt, > val2_sender.txt > > > Valgrind shows huge memory leaks while running 2 interconnected routers with > 2 parallel senders connected to the one router and 2 parallel receivers > connected to the other router. > The CRYPTO leak that is coming from Qpid Proton 0.12.2 is already fixed here: > https://issues.apache.org/jira/browse/PROTON-1115 > However, the rest of the leaks are from qdrouterd. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-337) Huge memory leaks in Qpid Dispatch router
[ https://issues.apache.org/jira/browse/DISPATCH-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15298658#comment-15298658 ] Ted Ross commented on DISPATCH-337: --- Also, the leak reports involving embedded Python are not valid. The embedded Python engine does not free allocated objects on shutdown. This results in massive numbers of false positives from tools like valgrind. > Huge memory leaks in Qpid Dispatch router > - > > Key: DISPATCH-337 > URL: https://issues.apache.org/jira/browse/DISPATCH-337 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.6.0 > Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and > dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines >Reporter: Vishal Sharda >Priority: Critical > Attachments: config1.conf, config2.conf, val2_receiver.txt, > val2_sender.txt > > > Valgrind shows huge memory leaks while running 2 interconnected routers with > 2 parallel senders connected to the one router and 2 parallel receivers > connected to the other router. > The CRYPTO leak that is coming from Qpid Proton 0.12.2 is already fixed here: > https://issues.apache.org/jira/browse/PROTON-1115 > However, the rest of the leaks are from qdrouterd. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-346) Don't attempt to load non-existant css file when hawtio plugin loads
[ https://issues.apache.org/jira/browse/DISPATCH-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen updated DISPATCH-346: -- Priority: Trivial (was: Minor) > Don't attempt to load non-existant css file when hawtio plugin loads > > > Key: DISPATCH-346 > URL: https://issues.apache.org/jira/browse/DISPATCH-346 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 0.7.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Trivial > > When the hawtio console loads, it attempts to load dispatch.css. That file > doesn't exist and an error is printed to the debug console. > Rename the qdrTopology.css file to dispatch.css and don't attempt to load > qdrTopology.css. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-346) Don't attempt to load non-existant css file when hawtio plugin loads
Ernest Allen created DISPATCH-346: - Summary: Don't attempt to load non-existant css file when hawtio plugin loads Key: DISPATCH-346 URL: https://issues.apache.org/jira/browse/DISPATCH-346 Project: Qpid Dispatch Issue Type: Bug Components: Console Affects Versions: 0.7.0 Reporter: Ernest Allen Assignee: Ernest Allen Priority: Minor When the hawtio console loads, it attempts to load dispatch.css. That file doesn't exist and an error is printed to the debug console. Rename the qdrTopology.css file to dispatch.css and don't attempt to load qdrTopology.css. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-345) Initialize current node on entity page when logged into a different router network
Ernest Allen created DISPATCH-345: - Summary: Initialize current node on entity page when logged into a different router network Key: DISPATCH-345 URL: https://issues.apache.org/jira/browse/DISPATCH-345 Project: Qpid Dispatch Issue Type: Bug Components: Console Affects Versions: 0.7.0 Reporter: Ernest Allen Assignee: Ernest Allen Priority: Minor On the entity page there is a dropdown that shows the current router node. If this has never been set, that page will automatically select the 1st router. However, if you switch to a new router network, the dropdown is blank. The dropdown should never be blank. If the router that was previously selected is not present, it should pick the 1st router. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-344) memory growth after repeated calls from qdstat -m
michael goulish created DISPATCH-344:
Summary: memory growth after repeated calls from qdstat -m
Key: DISPATCH-344
URL: https://issues.apache.org/jira/browse/DISPATCH-344
Project: Qpid Dispatch
Issue Type: Bug
Components: Routing Engine
Affects Versions: 0.6.0
Reporter: michael goulish
0. version of dispatch code is 0.6.0 RC3
1. bring up a router
2. do not attach any clients, except...
3. ...repeatedly invoke qdstat -m on the router
result:
After 1000 calls from "qdstat -m", top shows that router memory has grown by
4947968 bytes. The output from "qdstat -m" accounts for about 63% of that, or
318 bytes.
Here are the data types that increased, according to qdstat, ordered from
largest to smallest.
Um. This table looked really nice when it was in a fixed-width font.
type size total total increase increase
beforeafter structs bytes
=
qd_log_entry_t 2104112 1040 928 1952512
qd_buffer_t536 80 11201040 557440
qd_field_iterator_t128 192 12801088 139264
qdr_delivery_t 136 64 512 448 60928
qdr_connection_t 216 64 320 256 55296
qdr_field_t40 192 12801088 43520
qd_connection_t224 64 256 192 43008
qd_message_content_t 640 1680 64 40960
qd_message_t 128 192 512 320 40960
qdpn_connector_t 600 1664 48 28800
qdr_general_work_t 64 64 512 448 28672
qdr_connection_work_t 56 64 512 448 25088
qd_composite_t 112 64 256 192 21504
qdr_link_t 264 1680 64 16896
qd_composed_field_t64 64 256 192 12288
qdr_terminus_t 64 64 256 192 12288
qdr_delivery_ref_t 24 64 512 448 10752
qdr_link_ref_t 24 64 512 448 10752
qd_parsed_field_t 80 128 256 128 10240
qdr_action_t 160 256 320 64 10240
qd_link_t 48 64 256 1929216
qdr_error_t240 320 3207680
qd_deferred_call_t 32 64 256 1926144
grand total increase from qdstat:318
grand total increase from top: 4947968
Here is the script I used
This input window is breaking some lines. >:-(
#! /bin/bash
echo "NOTE: router should already be running."
INSTALL_ROOT=${SHACKLETON_ROOT}/install
PROTON_INSTALL_DIR=${INSTALL_ROOT}/proton
DISPATCH_INSTALL_DIR=${INSTALL_ROOT}/dispatch
QDSTAT=${DISPATCH_INSTALL_DIR}/bin/qdstat
export LD_LIBRARY_PATH=${DISPATCH_INSTALL_DIR}/lib64:${PROTON_INSTALL_DIR}/lib64
export
PYTHONPATH=${DISPATCH_INSTALL_DIR}/lib/qpid-dispatch/python:${DISPATCH_INSTALL_DIR}/lib/python2.7/site-packages:${PROTON_INSTALL_DIR}/lib64/proton/bindings/python
ROUTER_PID=`ps -aef | grep qdrouterd | grep -v grep | awk '{print $2}'`
count=1
while [ $count -lt 1001 ]
do
echo "==="
echo "TEST $count"
echo "==="
count=$(( $count + 1 ))
top -b -n 1 -p ${ROUTER_PID}
${QDSTAT} -m
sleep 3
done
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (DISPATCH-323) Separate the websockify installation instruction from the usage instructions
[ https://issues.apache.org/jira/browse/DISPATCH-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen closed DISPATCH-323. - Resolution: Duplicate Fix Version/s: 0.6.0 Was fixed with DISPATCH-308 > Separate the websockify installation instruction from the usage instructions > > > Key: DISPATCH-323 > URL: https://issues.apache.org/jira/browse/DISPATCH-323 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 0.7.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Trivial > Fix For: 0.6.0 > > > For console/README.md > The instructions for manually running a proxy using websockify contain the > instructions for how to install websockify. > Since you need to install websockify whether you use the manual method or the > automatic method, the installation instruction should be separate. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-308) console documentation needs updated
[ https://issues.apache.org/jira/browse/DISPATCH-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen resolved DISPATCH-308. --- Resolution: Fixed > console documentation needs updated > --- > > Key: DISPATCH-308 > URL: https://issues.apache.org/jira/browse/DISPATCH-308 > Project: Qpid Dispatch > Issue Type: Task > Components: Console >Reporter: Robbie Gemmell >Assignee: Ernest Allen > Fix For: 0.6.0 > > > The console documentation needs updated. The text seems to cover the > 'standalone' console version but appear to be stale, with the file layout > shown being quite unlike those in the source tree and the steps seeming old > too, e.g. needing node.js. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-343) Router stops accepting connections after load from parallel senders
[ https://issues.apache.org/jira/browse/DISPATCH-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15298571#comment-15298571 ] Vishal Sharda commented on DISPATCH-343: Environment for the tests using 2 latest routers: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines. Oenssl information: vsharda@millennium-qpid-untouched-latest-2-8501:~$ dpkg -l | grep openssl ii libcurl4-openssl-dev:amd64 7.38.0-4+deb8u3 amd64development files and documentation for libcurl (OpenSSL flavour) ii libgnutls-openssl27:amd643.3.8-6+deb8u3 amd64GNU TLS library - OpenSSL wrapper ii openssl 1.0.1k-3+deb8u5 amd64Secure Sockets Layer toolkit - cryptographic utility > Router stops accepting connections after load from parallel senders > --- > > Key: DISPATCH-343 > URL: https://issues.apache.org/jira/browse/DISPATCH-343 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 >Reporter: Vishal Sharda >Priority: Blocker > Attachments: Connection_aborted.png, Connection_aborted_1.png, > Crash.png, Crash_10S_2R.png, R1.conf, R2.conf, R3.conf, > Sender_router_crash.png, resource-limit-exceeded.png > > > We ran 2 parallel senders and 2 receivers with each sender sending 5 > messages. After a while we saw that router stopped accepting connections > even from qdstat. We saw various errors in the logs (screenshots attached). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-337) Huge memory leaks in Qpid Dispatch router
[ https://issues.apache.org/jira/browse/DISPATCH-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15298556#comment-15298556 ] Vishal Sharda commented on DISPATCH-337: There are 18 places in val2_sender.txt where memory is "definitely" lost according to valgrind report attached (val2_sender.txt). All of these leaks seem to be coming from router C code. > Huge memory leaks in Qpid Dispatch router > - > > Key: DISPATCH-337 > URL: https://issues.apache.org/jira/browse/DISPATCH-337 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.6.0 > Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and > dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines >Reporter: Vishal Sharda >Priority: Critical > Attachments: config1.conf, config2.conf, val2_receiver.txt, > val2_sender.txt > > > Valgrind shows huge memory leaks while running 2 interconnected routers with > 2 parallel senders connected to the one router and 2 parallel receivers > connected to the other router. > The CRYPTO leak that is coming from Qpid Proton 0.12.2 is already fixed here: > https://issues.apache.org/jira/browse/PROTON-1115 > However, the rest of the leaks are from qdrouterd. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-343) Router stops accepting connections after load from parallel senders
[ https://issues.apache.org/jira/browse/DISPATCH-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15298536#comment-15298536 ] Ted Ross commented on DISPATCH-343: --- Vishal, Can you provide information about what platform you are building on and which openssl version you are building against? Thanks, -Ted > Router stops accepting connections after load from parallel senders > --- > > Key: DISPATCH-343 > URL: https://issues.apache.org/jira/browse/DISPATCH-343 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 >Reporter: Vishal Sharda >Priority: Blocker > Attachments: Connection_aborted.png, Connection_aborted_1.png, > Crash.png, Crash_10S_2R.png, R1.conf, R2.conf, R3.conf, > Sender_router_crash.png, resource-limit-exceeded.png > > > We ran 2 parallel senders and 2 receivers with each sender sending 5 > messages. After a while we saw that router stopped accepting connections > even from qdstat. We saw various errors in the logs (screenshots attached). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7264) Model attributes that are derived and secure (such as AutoGeneratedSelfSignedKeyStore) do not get stored encrypted causing Broker to fail on restart
[
https://issues.apache.org/jira/browse/QPID-7264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7264:
-
Status: Reviewable (was: In Progress)
> Model attributes that are derived and secure (such as
> AutoGeneratedSelfSignedKeyStore) do not get stored encrypted causing Broker
> to fail on restart
>
>
> Key: QPID-7264
> URL: https://issues.apache.org/jira/browse/QPID-7264
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
>
> Model Attributes that are derived/secure do not get encrypted by the
> configuration encryptor. If you add an {{AutoGeneratedSelfSignedCert}}
> then turn on encryption, the Broker continues to work until it is restarted,
> at which point it fails as it tries to read the secure value as if it were
> AES ciphered data.
> The only feature that currently has such an attribute is
> AutoGeneratedSelfSignedCert. This problem means that
> AutoGeneratedSelfSignedCert cannot be used at if configuration encrpytion is
> also in use.
> The work around is to create the self signed keystore externally
> (keytool/openssl etc), and import into Qpid as a Java or Non-Java Keystore.
> {noformat}
> 12:12:27.170 [main] INFO qpid.message.keystore.create - [Broker] KST-1001 :
> Create "myks"
> 12:12:27.595 [main] ERROR org.apache.qpid.server.Broker - Exception during
> startup
> java.lang.IllegalArgumentException: Unable to encrypt secret
> at
> org.apache.qpid.server.security.encryption.AESKeyFileEncrypter.decrypt(AESKeyFileEncrypter.java:106)
> ~[classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.decryptSecrets(AbstractConfiguredObject.java:2788)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer.resolveObjects(GenericRecoverer.java:187)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer.performRecover(GenericRecoverer.java:91)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer.access$000(GenericRecoverer.java:41)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer$1.execute(GenericRecoverer.java:59)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer$1.execute(GenericRecoverer.java:55)
> ~[classes/:na]
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:270)
> ~[classes/:na]
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submitWrappedTask(TaskExecutorImpl.java:154)
> ~[classes/:na]
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.run(TaskExecutorImpl.java:182)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer.recover(GenericRecoverer.java:54)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.BrokerStoreUpgraderAndRecoverer.perform(BrokerStoreUpgraderAndRecoverer.java:846)
> ~[classes/:na]
> at
> org.apache.qpid.server.model.AbstractSystemConfig.activate(AbstractSystemConfig.java:232)
> ~[classes/:na]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[na:1.8.0_66]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[na:1.8.0_66]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[na:1.8.0_66]
> at java.lang.reflect.Method.invoke(Method.java:497) ~[na:1.8.0_66]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1309)
> ~[classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1288)
> ~[classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:909)
> ~[classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:903)
> ~[classes/:na]
> at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> ~[guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)
> ~[guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> ~[guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.ExecutionList.add(ExecutionList.java:101)
> ~[guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:170)
>
[jira] [Updated] (DISPATCH-343) Router stops accepting connections after load from parallel senders
[ https://issues.apache.org/jira/browse/DISPATCH-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vishal Sharda updated DISPATCH-343: --- Attachment: Crash_10S_2R.png Router crash with 10 Senders attached to one router and 2 Receivers attached to the second router. > Router stops accepting connections after load from parallel senders > --- > > Key: DISPATCH-343 > URL: https://issues.apache.org/jira/browse/DISPATCH-343 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 >Reporter: Vishal Sharda >Priority: Blocker > Attachments: Connection_aborted.png, Connection_aborted_1.png, > Crash.png, Crash_10S_2R.png, R1.conf, R2.conf, R3.conf, > Sender_router_crash.png, resource-limit-exceeded.png > > > We ran 2 parallel senders and 2 receivers with each sender sending 5 > messages. After a while we saw that router stopped accepting connections > even from qdstat. We saw various errors in the logs (screenshots attached). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-343) Router stops accepting connections after load from parallel senders
[ https://issues.apache.org/jira/browse/DISPATCH-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15298528#comment-15298528 ] Vishal Sharda commented on DISPATCH-343: I will be switching to Debug build now and try to collect debug information. Until then, here is another crash (Crash_10S_2R.png) that I saw with 10 senders sending to one router and 2 receivers receiving from the other router. This crash is due to an invalid pointer. > Router stops accepting connections after load from parallel senders > --- > > Key: DISPATCH-343 > URL: https://issues.apache.org/jira/browse/DISPATCH-343 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 >Reporter: Vishal Sharda >Priority: Blocker > Attachments: Connection_aborted.png, Connection_aborted_1.png, > Crash.png, R1.conf, R2.conf, R3.conf, Sender_router_crash.png, > resource-limit-exceeded.png > > > We ran 2 parallel senders and 2 receivers with each sender sending 5 > messages. After a while we saw that router stopped accepting connections > even from qdstat. We saw various errors in the logs (screenshots attached). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7264) Model attributes that are derived and secure (such as AutoGeneratedSelfSignedKeyStore) do not get stored encrypted causing Broker to fail on restart
[
https://issues.apache.org/jira/browse/QPID-7264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7264:
-
Assignee: Lorenz Quack (was: Keith Wall)
> Model attributes that are derived and secure (such as
> AutoGeneratedSelfSignedKeyStore) do not get stored encrypted causing Broker
> to fail on restart
>
>
> Key: QPID-7264
> URL: https://issues.apache.org/jira/browse/QPID-7264
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2
>Reporter: Keith Wall
>Assignee: Lorenz Quack
>Priority: Minor
>
> Model Attributes that are derived/secure do not get encrypted by the
> configuration encryptor. If you add an {{AutoGeneratedSelfSignedCert}}
> then turn on encryption, the Broker continues to work until it is restarted,
> at which point it fails as it tries to read the secure value as if it were
> AES ciphered data.
> The only feature that currently has such an attribute is
> AutoGeneratedSelfSignedCert. This problem means that
> AutoGeneratedSelfSignedCert cannot be used at if configuration encrpytion is
> also in use.
> The work around is to create the self signed keystore externally
> (keytool/openssl etc), and import into Qpid as a Java or Non-Java Keystore.
> {noformat}
> 12:12:27.170 [main] INFO qpid.message.keystore.create - [Broker] KST-1001 :
> Create "myks"
> 12:12:27.595 [main] ERROR org.apache.qpid.server.Broker - Exception during
> startup
> java.lang.IllegalArgumentException: Unable to encrypt secret
> at
> org.apache.qpid.server.security.encryption.AESKeyFileEncrypter.decrypt(AESKeyFileEncrypter.java:106)
> ~[classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.decryptSecrets(AbstractConfiguredObject.java:2788)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer.resolveObjects(GenericRecoverer.java:187)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer.performRecover(GenericRecoverer.java:91)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer.access$000(GenericRecoverer.java:41)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer$1.execute(GenericRecoverer.java:59)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer$1.execute(GenericRecoverer.java:55)
> ~[classes/:na]
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:270)
> ~[classes/:na]
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submitWrappedTask(TaskExecutorImpl.java:154)
> ~[classes/:na]
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.run(TaskExecutorImpl.java:182)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer.recover(GenericRecoverer.java:54)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.BrokerStoreUpgraderAndRecoverer.perform(BrokerStoreUpgraderAndRecoverer.java:846)
> ~[classes/:na]
> at
> org.apache.qpid.server.model.AbstractSystemConfig.activate(AbstractSystemConfig.java:232)
> ~[classes/:na]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[na:1.8.0_66]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[na:1.8.0_66]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[na:1.8.0_66]
> at java.lang.reflect.Method.invoke(Method.java:497) ~[na:1.8.0_66]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1309)
> ~[classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1288)
> ~[classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:909)
> ~[classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:903)
> ~[classes/:na]
> at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> ~[guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)
> ~[guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> ~[guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.ExecutionList.add(ExecutionList.java:101)
> ~[guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:170)
[jira] [Assigned] (QPID-7264) Model attributes that are derived and secure (such as AutoGeneratedSelfSignedKeyStore) do not get stored encrypted causing Broker to fail on restart
[
https://issues.apache.org/jira/browse/QPID-7264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall reassigned QPID-7264:
Assignee: Keith Wall
> Model attributes that are derived and secure (such as
> AutoGeneratedSelfSignedKeyStore) do not get stored encrypted causing Broker
> to fail on restart
>
>
> Key: QPID-7264
> URL: https://issues.apache.org/jira/browse/QPID-7264
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
>
> Model Attributes that are derived/secure do not get encrypted by the
> configuration encryptor. If you add an {{AutoGeneratedSelfSignedCert}}
> then turn on encryption, the Broker continues to work until it is restarted,
> at which point it fails as it tries to read the secure value as if it were
> AES ciphered data.
> The only feature that currently has such an attribute is
> AutoGeneratedSelfSignedCert. This problem means that
> AutoGeneratedSelfSignedCert cannot be used at if configuration encrpytion is
> also in use.
> The work around is to create the self signed keystore externally
> (keytool/openssl etc), and import into Qpid as a Java or Non-Java Keystore.
> {noformat}
> 12:12:27.170 [main] INFO qpid.message.keystore.create - [Broker] KST-1001 :
> Create "myks"
> 12:12:27.595 [main] ERROR org.apache.qpid.server.Broker - Exception during
> startup
> java.lang.IllegalArgumentException: Unable to encrypt secret
> at
> org.apache.qpid.server.security.encryption.AESKeyFileEncrypter.decrypt(AESKeyFileEncrypter.java:106)
> ~[classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.decryptSecrets(AbstractConfiguredObject.java:2788)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer.resolveObjects(GenericRecoverer.java:187)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer.performRecover(GenericRecoverer.java:91)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer.access$000(GenericRecoverer.java:41)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer$1.execute(GenericRecoverer.java:59)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer$1.execute(GenericRecoverer.java:55)
> ~[classes/:na]
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:270)
> ~[classes/:na]
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submitWrappedTask(TaskExecutorImpl.java:154)
> ~[classes/:na]
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.run(TaskExecutorImpl.java:182)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.GenericRecoverer.recover(GenericRecoverer.java:54)
> ~[classes/:na]
> at
> org.apache.qpid.server.store.BrokerStoreUpgraderAndRecoverer.perform(BrokerStoreUpgraderAndRecoverer.java:846)
> ~[classes/:na]
> at
> org.apache.qpid.server.model.AbstractSystemConfig.activate(AbstractSystemConfig.java:232)
> ~[classes/:na]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[na:1.8.0_66]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[na:1.8.0_66]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[na:1.8.0_66]
> at java.lang.reflect.Method.invoke(Method.java:497) ~[na:1.8.0_66]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1309)
> ~[classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1288)
> ~[classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:909)
> ~[classes/:na]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:903)
> ~[classes/:na]
> at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
> ~[guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.MoreExecutors$DirectExecutor.execute(MoreExecutors.java:457)
> ~[guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
> ~[guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.ExecutionList.add(ExecutionList.java:101)
> ~[guava-18.0.jar:na]
> at
> com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:170)
>
[jira] [Updated] (QPID-7272) [Java Broker] Direct memory QpidByteBuffer created in message conversion modules should be disposed as soon as possible after becoming unused
[ https://issues.apache.org/jira/browse/QPID-7272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7272: - Description: Direct memory QpidByteBuffer in MessageConverter_to_1_0#convertServerMessage(...) is not disposed programmatically. We rely on GC to release it from memory when it became unused. There is a risk that when such QpidByteBuffers are not "garbage collected" soon enough Broker might run out of direct memory on heavy loads. Currently a user who relies heavily of message conversion with high rates of message flow, may see an OOM direct. was: Direct memory QpidByteBuffer in MessageConverter_to_1_0#convertServerMessage(...) is not disposed programmatically. We rely on GC to release it from memory when it became unused. There is a risk that when such QpidByteBuffers are not "garbage collected" soon enough Broker might run out of direct memory on heavy loads. > [Java Broker] Direct memory QpidByteBuffer created in message conversion > modules should be disposed as soon as possible after becoming unused > - > > Key: QPID-7272 > URL: https://issues.apache.org/jira/browse/QPID-7272 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.0 >Reporter: Alex Rudyy > Fix For: qpid-java-6.1 > > > Direct memory QpidByteBuffer in > MessageConverter_to_1_0#convertServerMessage(...) is not disposed > programmatically. We rely on GC to release it from memory when it became > unused. There is a risk that when such QpidByteBuffers are not "garbage > collected" soon enough Broker might run out of direct memory on heavy loads. > Currently a user who relies heavily of message conversion with high rates of > message flow, may see an OOM direct. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7272) [Java Broker] Direct memory QpidByteBuffer created in message conversion modules should be disposed as soon as possible after becoming unused
[ https://issues.apache.org/jira/browse/QPID-7272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7272: - Fix Version/s: qpid-java-6.1 > [Java Broker] Direct memory QpidByteBuffer created in message conversion > modules should be disposed as soon as possible after becoming unused > - > > Key: QPID-7272 > URL: https://issues.apache.org/jira/browse/QPID-7272 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.0 >Reporter: Alex Rudyy > Fix For: qpid-java-6.1 > > > Direct memory QpidByteBuffer in > MessageConverter_to_1_0#convertServerMessage(...) is not disposed > programmatically. We rely on GC to release it from memory when it became > unused. There is a risk that when such QpidByteBuffers are not "garbage > collected" soon enough Broker might run out of direct memory on heavy loads. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7272) [Java Broker] Direct memory QpidByteBuffer created in message conversion modules should be disposed as soon as possible after becoming unused
[ https://issues.apache.org/jira/browse/QPID-7272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7272: - Summary: [Java Broker] Direct memory QpidByteBuffer created in message conversion modules should be disposed as soon as possible after becoming unused (was: [Java Broker] Direct memory QpidByteBuffer created in message conversion modules should be disposed as soon as possible after becaming unused) > [Java Broker] Direct memory QpidByteBuffer created in message conversion > modules should be disposed as soon as possible after becoming unused > - > > Key: QPID-7272 > URL: https://issues.apache.org/jira/browse/QPID-7272 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.0 >Reporter: Alex Rudyy > Fix For: qpid-java-6.1 > > > Direct memory QpidByteBuffer in > MessageConverter_to_1_0#convertServerMessage(...) is not disposed > programmatically. We rely on GC to release it from memory when it became > unused. There is a risk that when such QpidByteBuffers are not "garbage > collected" soon enough Broker might run out of direct memory on heavy loads. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7273) The same JVM property names are used on client and broker sides for setting protocol and cipher suite white and black lists
[ https://issues.apache.org/jira/browse/QPID-7273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7273: - Fix Version/s: qpid-java-6.1 > The same JVM property names are used on client and broker sides for setting > protocol and cipher suite white and black lists > --- > > Key: QPID-7273 > URL: https://issues.apache.org/jira/browse/QPID-7273 > Project: Qpid > Issue Type: Bug > Components: Java Broker, Java Client, Java Common >Affects Versions: qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2, > qpid-java-6.0.3, qpid-java-6.1 >Reporter: Alex Rudyy > Fix For: qpid-java-6.1 > > > Both Java Client and Java Broker user JVM properties > "qpid.security.tls.protocolWhiteList" and > "qpid.security.tls.protocolBlackList" to configure TLS protocols white list > and black list accordingly. JVM properties for setting cipher suites ( > "qpid.security.tls.cipherSuiteWhiteList" and > "qpid.security.tls.cipherSuiteBlackList" ) are utilized by both components as > well. > However, Java Broker expects JSON formatted values for protocol and cipher > suite white and black lists whilst Java Client expects comma separated values > for protocol and cipher suite white and black lists. In case when both Java > Broker and Client run in the same JVMs setting of protocol and cipher suite > white and black lists would be a problem as depending from format in use > either Broker or Client would have incorrectly set white and black lists. > In order to resolve this problem we need to use different JVM property names > for Broker and Client. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7276) Message delay improvements
[
https://issues.apache.org/jira/browse/QPID-7276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7276:
-
Fix Version/s: qpid-java-6.1
> Message delay improvements
> --
>
> Key: QPID-7276
> URL: https://issues.apache.org/jira/browse/QPID-7276
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.1
>
>
> QPID-7255 introduced support of message delays. To make the feature more
> useful/usable, the following additions are identified:
> # Make the Broker provide a connection property that reveals that it supports
> the notValidBefore feature. Make clients detect this feature and warn if the
> application tries to make use of the address options.
> # Extend the Queue UI to allow {{holdOnPublishEnabled}} to be enabled when
> creating or updating a queue.
> # Reveal through the UI when a Queue Entry is held.
> # Make the Message content UI treat {{NotValidBefore}} as a date/time.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7213) [Java Broker, WMC] Only transmit data for visible tab
[ https://issues.apache.org/jira/browse/QPID-7213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack resolved QPID-7213. Resolution: Fixed > [Java Broker, WMC] Only transmit data for visible tab > - > > Key: QPID-7213 > URL: https://issues.apache.org/jira/browse/QPID-7213 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Lorenz Quack > Fix For: qpid-java-6.1 > > > Currently the WMC requests data for all open tabs. > To cut down our bandwidth usage we should only request the data for the > currently visible tab. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7213) [Java Broker, WMC] Only transmit data for visible tab
[ https://issues.apache.org/jira/browse/QPID-7213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15298417#comment-15298417 ] ASF subversion and git services commented on QPID-7213: --- Commit 1745375 from [~lorenz.quack] in branch 'java/trunk' [ https://svn.apache.org/r1745375 ] QPID-7213: [Java Broker, WMC] Only transmit data for visible tab > [Java Broker, WMC] Only transmit data for visible tab > - > > Key: QPID-7213 > URL: https://issues.apache.org/jira/browse/QPID-7213 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Lorenz Quack > Fix For: qpid-java-6.1 > > > Currently the WMC requests data for all open tabs. > To cut down our bandwidth usage we should only request the data for the > currently visible tab. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-180) Add a JmsMessageIDPolicy that imrpoves the existing message ID type configuration
Timothy Bish created QPIDJMS-180: Summary: Add a JmsMessageIDPolicy that imrpoves the existing message ID type configuration Key: QPIDJMS-180 URL: https://issues.apache.org/jira/browse/QPIDJMS-180 Project: Qpid JMS Issue Type: Sub-task Components: qpid-jms-client Affects Versions: 0.9.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.10.0 Add a new policy object JmsMessageIDPolicy that improves upon the existing Message ID type configuration by allowing MessageProducer instances to be configured with a Message ID Builder on a per destination basis or other application specific criteria. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-343) Router stops accepting connections after load from parallel senders
[ https://issues.apache.org/jira/browse/DISPATCH-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15298211#comment-15298211 ] Ted Ross commented on DISPATCH-343: --- We are trying to reproduce this locally. In the mean time, if you can get a backtrace for the router crash, that would be very helpful. > Router stops accepting connections after load from parallel senders > --- > > Key: DISPATCH-343 > URL: https://issues.apache.org/jira/browse/DISPATCH-343 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 >Reporter: Vishal Sharda >Priority: Blocker > Attachments: Connection_aborted.png, Connection_aborted_1.png, > Crash.png, R1.conf, R2.conf, R3.conf, Sender_router_crash.png, > resource-limit-exceeded.png > > > We ran 2 parallel senders and 2 receivers with each sender sending 5 > messages. After a while we saw that router stopped accepting connections > even from qdstat. We saw various errors in the logs (screenshots attached). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7272) [Java Broker] Direct memory QpidByteBuffer created in message conversion modules should be disposed as soon as possible after becaming unused
[ https://issues.apache.org/jira/browse/QPID-7272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7272: - Description: Direct memory QpidByteBuffer in MessageConverter_to_1_0#convertServerMessage(...) is not disposed programmatically. We rely on GC to release it from memory when it became unused. There is a risk that when such QpidByteBuffers are not "garbage collected" soon enough Broker might run out of direct memory on heavy loads. was: Direct memory QpidByteBuffer in MessageConverter_to_1_0#convertServerMessage(...) is not disposed programmatically. We rely on GC to release it from memory when it became unused. There is a risk that if it isn't GCd soon enough we might run out of direct memory on heavy loads. > [Java Broker] Direct memory QpidByteBuffer created in message conversion > modules should be disposed as soon as possible after becaming unused > - > > Key: QPID-7272 > URL: https://issues.apache.org/jira/browse/QPID-7272 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.0 >Reporter: Alex Rudyy > > Direct memory QpidByteBuffer in > MessageConverter_to_1_0#convertServerMessage(...) is not disposed > programmatically. We rely on GC to release it from memory when it became > unused. There is a risk that when such QpidByteBuffers are not "garbage > collected" soon enough Broker might run out of direct memory on heavy loads. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7272) [Java Broker] Direct memory QpidByteBuffer created in message conversion modules should be disposed as soon as possible after becaming unused
[ https://issues.apache.org/jira/browse/QPID-7272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7272: - Summary: [Java Broker] Direct memory QpidByteBuffer created in message conversion modules should be disposed as soon as possible after becaming unused (was: [Java Broker] Direct memory QpidByteBuffer should be disposed as soon as possible after becaming unused) > [Java Broker] Direct memory QpidByteBuffer created in message conversion > modules should be disposed as soon as possible after becaming unused > - > > Key: QPID-7272 > URL: https://issues.apache.org/jira/browse/QPID-7272 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.0 >Reporter: Alex Rudyy > > Direct memory QpidByteBuffer in > MessageConverter_to_1_0#convertServerMessage(...) is not disposed > programmatically. We rely on GC to release it from memory when it became > unused. There is a risk that if it isn't GCd soon enough we might run out of > direct memory on heavy loads. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7273) The same JVM property names are used on client and broker sides for setting protocol and cipher suite white and black lists
[ https://issues.apache.org/jira/browse/QPID-7273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7273: - Description: Both Java Client and Java Broker user JVM properties "qpid.security.tls.protocolWhiteList" and "qpid.security.tls.protocolBlackList" to configure TLS protocols white list and black list accordingly. JVM properties for setting cipher suites ( "qpid.security.tls.cipherSuiteWhiteList" and "qpid.security.tls.cipherSuiteBlackList" ) are utilized by both components as well. However, Java Broker expects JSON formatted values for protocol and cipher suite white and black lists whilst Java Client expects comma separated values for protocol and cipher suite white and black lists. In case when both Java Broker and Client run in the same JVMs setting of protocol and cipher suite white and black lists would be a problem as depending from format in use either Broker or Client would have incorrectly set white and black lists. In order to resolve this problem we need to use different JVM property names for Broker and Client. was: Both Java Client and Java Broker user JVM properties "qpid.security.tls.protocolWhiteList" and "qpid.security.tls.protocolBlackList" to configure TLS protocols white list and black list accordingly. JVM properties for setting cipher suites ( "qpid.security.tls.cipherSuiteWhiteList" and "qpid.security.tls.cipherSuiteBlackList" ) are utilized by both components as well. Java Broker expects JSON formatted values for protocol and cipher suite white and black lists whilst Java Client expects comma separated values for protocol and cipher suite white and black lists. In case when both Java Broker and Client run in the same JVMs setting of protocol and cipher suite white and black lists would be a problem as depending from format in use either Broker or Client would have incorrectly set white and black lists. In order to resolve this problem we need to use different JVM property names for Broker and Client. > The same JVM property names are used on client and broker sides for setting > protocol and cipher suite white and black lists > --- > > Key: QPID-7273 > URL: https://issues.apache.org/jira/browse/QPID-7273 > Project: Qpid > Issue Type: Bug > Components: Java Broker, Java Client, Java Common >Affects Versions: qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2, > qpid-java-6.0.3, qpid-java-6.1 >Reporter: Alex Rudyy > > Both Java Client and Java Broker user JVM properties > "qpid.security.tls.protocolWhiteList" and > "qpid.security.tls.protocolBlackList" to configure TLS protocols white list > and black list accordingly. JVM properties for setting cipher suites ( > "qpid.security.tls.cipherSuiteWhiteList" and > "qpid.security.tls.cipherSuiteBlackList" ) are utilized by both components as > well. > However, Java Broker expects JSON formatted values for protocol and cipher > suite white and black lists whilst Java Client expects comma separated values > for protocol and cipher suite white and black lists. In case when both Java > Broker and Client run in the same JVMs setting of protocol and cipher suite > white and black lists would be a problem as depending from format in use > either Broker or Client would have incorrectly set white and black lists. > In order to resolve this problem we need to use different JVM property names > for Broker and Client. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7273) The same JVM property names are used on client and broker sides for setting protocol and cipher suite white and black lists
[ https://issues.apache.org/jira/browse/QPID-7273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7273: - Description: Both Java Client and Java Broker user JVM properties "qpid.security.tls.protocolWhiteList" and "qpid.security.tls.protocolBlackList" to configure TLS protocols white list and black list accordingly. JVM properties for setting cipher suites ( "qpid.security.tls.cipherSuiteWhiteList" and "qpid.security.tls.cipherSuiteBlackList" ) are utilized by both components as well. Java Broker expects JSON formatted values for protocol and cipher suite white and black lists whilst Java Client expects comma separated values for protocol and cipher suite white and black lists. In case when both Java Broker and Client run in the same JVMs setting of protocol and cipher suite white and black lists would be a problem as depending from format in use either Broker or Client would have incorrectly set white and black lists. In order to resolve this problem we need to use different JVM property names for Broker and Client. was: Java Broker expects JSON formatted values for protocol and cipher suite white and black lists whilst Java Client expects comma separated values for protocol and cipher suite white and black lists. In case when both Java Broker and Client run in the same JVMs setting of protocol and cipher suite white and black lists would be a problem as depending from format in use either Broker or Client would have incorrectly set white and black lists. In order to resolve this problem we need to use different JVM property names for Broker and Client. > The same JVM property names are used on client and broker sides for setting > protocol and cipher suite white and black lists > --- > > Key: QPID-7273 > URL: https://issues.apache.org/jira/browse/QPID-7273 > Project: Qpid > Issue Type: Bug > Components: Java Broker, Java Client, Java Common >Affects Versions: qpid-java-6.0, qpid-java-6.0.1, qpid-java-6.0.2, > qpid-java-6.0.3, qpid-java-6.1 >Reporter: Alex Rudyy > > Both Java Client and Java Broker user JVM properties > "qpid.security.tls.protocolWhiteList" and > "qpid.security.tls.protocolBlackList" to configure TLS protocols white list > and black list accordingly. JVM properties for setting cipher suites ( > "qpid.security.tls.cipherSuiteWhiteList" and > "qpid.security.tls.cipherSuiteBlackList" ) are utilized by both components as > well. > Java Broker expects JSON formatted values for protocol and cipher suite white > and black lists whilst Java Client expects comma separated values for > protocol and cipher suite white and black lists. In case when both Java > Broker and Client run in the same JVMs setting of protocol and cipher suite > white and black lists would be a problem as depending from format in use > either Broker or Client would have incorrectly set white and black lists. > In order to resolve this problem we need to use different JVM property names > for Broker and Client. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-7275) connection.setExceptionListener() method cannot be invoked for Qpid
[ https://issues.apache.org/jira/browse/QPID-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed QPID-7275. Steven did eventually mail the list, but it was held for moderation due to not following the subscribe instructions correctly. I'll reply over there. Closing this issue. > connection.setExceptionListener() method cannot be invoked for Qpid > --- > > Key: QPID-7275 > URL: https://issues.apache.org/jira/browse/QPID-7275 > Project: Qpid > Issue Type: Bug > Components: JMS AMQP 1.0 Client >Affects Versions: 0.32 > Environment: Window7,jdk7 >Reporter: Steven > > I want to implement Re-connection functionality for AMQP 1.0,as We all know > that AMQP 1.0 protocol 's connection URL didn't support "broker-list",Hence,I > want to register the method "connection.setExceptionListener" to monitor the > connection between client socket and server socket before invoking the method > "connection.start" ,I try to mock the connection closed through the three > following way: > 1.stop the Qid server broker > 2.pull out the cable > 3.use the TCPViewer to close the connection manually. > none of the above method didn't invoke the method > "connection.setExceptionListener" > by the way,for the client API qpid-amqp-1-0-client-0.32,If the connection > URL support brokerlist feature,That would be nice,I can implement > Re-connection functionality in a nice way,Thanks in advance. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7275) connection.setExceptionListener() method cannot be invoked for Qpid
[ https://issues.apache.org/jira/browse/QPID-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297879#comment-15297879 ] Rob Godfrey commented on QPID-7275: --- Steven, as Robbie stated in his previous reply, JIRA is not the correct place to ask questions like this - it is an issue reporting system for when a genuine defect has been discovered or request for new feature is to be made General questions about using Qpid / configuration / etc should be directed to the Qpid Users mailing list (see [this|https://qpid.apache.org/discussion.html] page for details on how to subscribe to the mailing lists). Questions there will be seen by a wider range of people who may be able to help you. Also note that this is not even the correct JIRA instance for the Qpid JMS client for AMQP - if you do come across a genuine defect or request a new feature then you need to use the following JIRA instance: https://issues.apache.org/jira/browse/QPIDJMS > connection.setExceptionListener() method cannot be invoked for Qpid > --- > > Key: QPID-7275 > URL: https://issues.apache.org/jira/browse/QPID-7275 > Project: Qpid > Issue Type: Bug > Components: JMS AMQP 1.0 Client >Affects Versions: 0.32 > Environment: Window7,jdk7 >Reporter: Steven > > I want to implement Re-connection functionality for AMQP 1.0,as We all know > that AMQP 1.0 protocol 's connection URL didn't support "broker-list",Hence,I > want to register the method "connection.setExceptionListener" to monitor the > connection between client socket and server socket before invoking the method > "connection.start" ,I try to mock the connection closed through the three > following way: > 1.stop the Qid server broker > 2.pull out the cable > 3.use the TCPViewer to close the connection manually. > none of the above method didn't invoke the method > "connection.setExceptionListener" > by the way,for the client API qpid-amqp-1-0-client-0.32,If the connection > URL support brokerlist feature,That would be nice,I can implement > Re-connection functionality in a nice way,Thanks in advance. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7274) [Java Client] Asynchronous client acknowledgements
[ https://issues.apache.org/jira/browse/QPID-7274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297848#comment-15297848 ] Keith Wall commented on QPID-7274: -- Hi Jakub, Thanks for the contribution. I hope to be able to take a look and comment later this week. > [Java Client] Asynchronous client acknowledgements > -- > > Key: QPID-7274 > URL: https://issues.apache.org/jira/browse/QPID-7274 > Project: Qpid > Issue Type: Improvement > Components: Java Client >Reporter: Jakub Scholz > Attachments: sync_ack.patch > > > When the application is using client acknowledgements, they are always done > in a synchronous way with a sync() being issues after the acknowledgement. > This can have significant impact on the performance of the client > applications and it should be possible to configure the client to use > asynchronous acknowledgements. > The Java AMQP 0-10 client has already a connection URL option called > "sync_ack" which should affect whether acknowledgements are synchronous or > asynchronous, but it is used only for auto acknowledgements. It has no effect > to client acknowledgements. > Attached is a (trivial) patch which synchronizes the acknowledgements based > on the sync_ack option. It seems to work fine. However, the sync_ack option > is by default set to false. So using this option would mean that the current > behavior would change for all current applications using client > acknowledgements. I'm not sure that is desired. Would it be better to add a > new option "sync_client_ack" for the client acknowledgements which would sync > by default? Please let me know what the preferred option is and I can update > the patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7275) connection.setExceptionListener() method cannot be invoked for Qpid
[ https://issues.apache.org/jira/browse/QPID-7275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297767#comment-15297767 ] Steven commented on QPID-7275: -- Hello,Robbie I am not sure whether I am writing the correct connection URL,Could you have correct connection URL with ssl authentication using qpid-jms-client-0.9 > connection.setExceptionListener() method cannot be invoked for Qpid > --- > > Key: QPID-7275 > URL: https://issues.apache.org/jira/browse/QPID-7275 > Project: Qpid > Issue Type: Bug > Components: JMS AMQP 1.0 Client >Affects Versions: 0.32 > Environment: Window7,jdk7 >Reporter: Steven > > I want to implement Re-connection functionality for AMQP 1.0,as We all know > that AMQP 1.0 protocol 's connection URL didn't support "broker-list",Hence,I > want to register the method "connection.setExceptionListener" to monitor the > connection between client socket and server socket before invoking the method > "connection.start" ,I try to mock the connection closed through the three > following way: > 1.stop the Qid server broker > 2.pull out the cable > 3.use the TCPViewer to close the connection manually. > none of the above method didn't invoke the method > "connection.setExceptionListener" > by the way,for the client API qpid-amqp-1-0-client-0.32,If the connection > URL support brokerlist feature,That would be nice,I can implement > Re-connection functionality in a nice way,Thanks in advance. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
