[jira] [Commented] (PROTON-1298) [proton-c] SyncRequestResponseTest.test_allowed_mechs_external is very slow
[
https://issues.apache.org/jira/browse/PROTON-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16189283#comment-16189283
]
Andrew Stitcher commented on PROTON-1298:
-
[~gemmellr] Are there any special or moticable things about the systems
experiencing this? I can't seem to reproduce on my fedora 25 laptop.
I notice that one thing this test does is to try to open a random listening
port, and that may take some time if thjere are very few ports available.
However many of the tests in the same test section do the same (in fact many
tests overall do it). So it can't easily explain the very specific slow down.
The other thing it does that is not specific to this test is wait for an echo
server to finish, so if this takes a long while just for this test for some
reason this could explain the slowdown.
> [proton-c] SyncRequestResponseTest.test_allowed_mechs_external is very slow
> ---
>
> Key: PROTON-1298
> URL: https://issues.apache.org/jira/browse/PROTON-1298
> Project: Qpid Proton
> Issue Type: Test
> Components: proton-c
>Affects Versions: 0.14.0
>Reporter: Robbie Gemmell
>Assignee: Andrew Stitcher
> Fix For: proton-c-0.18.0
>
>
> SyncRequestResponseTest.test_allowed_mechs_external is very slow, the tests
> seem to sit waiting for it to complete for a long time, to the extent it
> dominates the overall test run time.
> {noformat}
> 2: proton_tests.utils.SyncRequestResponseTest.test_allowed_mechs_external ..
> start
> 2: 2016-09-08 10:40:22,513 ERROR amqp:connection:framing-error: connection
> aborted
> 2: proton_tests.utils.SyncRequestResponseTest.test_allowed_mechs_external ..
> pass
> 2: proton_tests.utils.SyncRequestResponseTest.test_connection_properties ...
> pass
> 2: proton_tests.utils.SyncRequestResponseTest.test_request_response
> pass
> 2: Totals: 422 tests, 407 passed, 15 skipped, 0 ignored, 0 failed
> 2/20 Test #2: python-test .. Passed 102.36 sec
> {noformat}
> The proton-j run of the python tests skips that particular test, and takes 30
> seconds in total on the same system.
> The same delay appears to be present on Travis CI as well, with a run of
> similar commit taking 128ec on the proton-c python tests, so it doesnt seem
> to be environment specific.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1604) Windows C++ prefers std::endl to newlines
[ https://issues.apache.org/jira/browse/PROTON-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16189048#comment-16189048 ] ASF subversion and git services commented on PROTON-1604: - Commit 95ee34e3873d90c5c9cf774452d2b10ea81f in qpid-proton's branch refs/heads/master from Clifford Jansen [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=95ee34e ] PROTON-1604: undo most of 0bed410 if readability or performance impacted, as per sage advice from astitcher > Windows C++ prefers std::endl to newlines > - > > Key: PROTON-1604 > URL: https://issues.apache.org/jira/browse/PROTON-1604 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.18.0 > Environment: Visual Studio >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: proton-c-0.18.0 > > > Using C newline escaped char sequence can result in mysteriously missing > output. > Use std::endl instead of \\n. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1321) Sunstudio 12.1 does not compile "++vector.begin()". Error message:"Operand for operator "++" must be an lvalue."
[ https://issues.apache.org/jira/browse/PROTON-1321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16188973#comment-16188973 ] Andrew Stitcher commented on PROTON-1321: - This was actually fixed in SHA af17dead. > Sunstudio 12.1 does not compile "++vector.begin()". Error message:"Operand > for operator "++" must be an lvalue." > > > Key: PROTON-1321 > URL: https://issues.apache.org/jira/browse/PROTON-1321 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Reporter: Adel Boutros >Assignee: Andrew Stitcher > Labels: patch, solaris > Fix For: 0.17.0 > > Attachments: > 0008-Sunstudio-12.1-does-not-compile-vector.begin-.-Error.patch > > > Sunstudio 12.1 does not compile "++vector.begin()". > Error message:"Operand for operator "++" must be an lvalue.". > We used a local variable to bypass that. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1321) Sunstudio 12.1 does not compile "++vector.begin()". Error message:"Operand for operator "++" must be an lvalue."
[ https://issues.apache.org/jira/browse/PROTON-1321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-1321. - Resolution: Fixed Fix Version/s: (was: proton-c-0.18.0) 0.17.0 > Sunstudio 12.1 does not compile "++vector.begin()". Error message:"Operand > for operator "++" must be an lvalue." > > > Key: PROTON-1321 > URL: https://issues.apache.org/jira/browse/PROTON-1321 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Reporter: Adel Boutros >Assignee: Andrew Stitcher > Labels: patch, solaris > Fix For: 0.17.0 > > Attachments: > 0008-Sunstudio-12.1-does-not-compile-vector.begin-.-Error.patch > > > Sunstudio 12.1 does not compile "++vector.begin()". > Error message:"Operand for operator "++" must be an lvalue.". > We used a local variable to bypass that. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1608) Logic for checking channel_max is wrong (checking against wrong protocol field)
[ https://issues.apache.org/jira/browse/PROTON-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-1608. - Resolution: Fixed > Logic for checking channel_max is wrong (checking against wrong protocol > field) > --- > > Key: PROTON-1608 > URL: https://issues.apache.org/jira/browse/PROTON-1608 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.18.0 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: proton-c-0.18.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1608) Logic for checking channel_max is wrong (checking against wrong protocol field)
[ https://issues.apache.org/jira/browse/PROTON-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16188963#comment-16188963 ] ASF subversion and git services commented on PROTON-1608: - Commit ec5c71a615e5db8b451982afc607ecc22c0f4fc1 in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=ec5c71a ] PROTON-1608: Fix incorrect logic detecting violations of channel_max > Logic for checking channel_max is wrong (checking against wrong protocol > field) > --- > > Key: PROTON-1608 > URL: https://issues.apache.org/jira/browse/PROTON-1608 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: proton-c-0.18.0 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: proton-c-0.18.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1608) Logic for checking channel_max is wrong (checking against wrong protocol field)
Andrew Stitcher created PROTON-1608: --- Summary: Logic for checking channel_max is wrong (checking against wrong protocol field) Key: PROTON-1608 URL: https://issues.apache.org/jira/browse/PROTON-1608 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: proton-c-0.18.0 Reporter: Andrew Stitcher Assignee: Andrew Stitcher Fix For: proton-c-0.18.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7947) [Java Broker] [AMQP 1.0] Improve handling of empty and overlarge frames
[ https://issues.apache.org/jira/browse/QPID-7947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16188907#comment-16188907 ] ASF subversion and git services commented on QPID-7947: --- Commit 66cef783f63ceb0252fbf236ae0577aa5e14b23d in qpid-broker-j's branch refs/heads/master from [~godfrer] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=66cef78 ] QPID-7947 : [Java Broker] [AMQP 1.0] Improve handling of empty and overlarge frames > [Java Broker] [AMQP 1.0] Improve handling of empty and overlarge frames > --- > > Key: QPID-7947 > URL: https://issues.apache.org/jira/browse/QPID-7947 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Rob Godfrey > > Empty frames should only be allowed for AMQP (and not SASL) transports. > Overlarge frames should be detected as soon as possible. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7947) [Java Broker] [AMQP 1.0] Improve handling of empty and overlarge frames
Rob Godfrey created QPID-7947: - Summary: [Java Broker] [AMQP 1.0] Improve handling of empty and overlarge frames Key: QPID-7947 URL: https://issues.apache.org/jira/browse/QPID-7947 Project: Qpid Issue Type: Bug Components: Java Broker Reporter: Rob Godfrey Empty frames should only be allowed for AMQP (and not SASL) transports. Overlarge frames should be detected as soon as possible. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1607) Some C examples can't be compiled using Visual Studio 2010
[ https://issues.apache.org/jira/browse/PROTON-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-1607. - Resolution: Fixed > Some C examples can't be compiled using Visual Studio 2010 > -- > > Key: PROTON-1607 > URL: https://issues.apache.org/jira/browse/PROTON-1607 > Project: Qpid Proton > Issue Type: Bug >Affects Versions: proton-c-0.18.0 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: proton-c-0.18.0 > > > This is because they are using C99 features. > It is straight forward to use only C89 features so we should do that. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7946) [Java Broker] ProtocolNegotiationTest only works by accident on AMQP 1.0
[ https://issues.apache.org/jira/browse/QPID-7946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16188901#comment-16188901 ] ASF subversion and git services commented on QPID-7946: --- Commit 526019c750fed803ccd16a01177009cc0bfee1ff in qpid-broker-j's branch refs/heads/master from [~godfrer] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=526019c ] QPID-7946 : Fix ProtocolNegotiationTest for AMQP 1.0 and Windows > [Java Broker] ProtocolNegotiationTest only works by accident on AMQP 1.0 > - > > Key: QPID-7946 > URL: https://issues.apache.org/jira/browse/QPID-7946 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey >Priority: Minor > > ProtocolNegotiationTest.testNoConnectionOpenSent_BrokerClosesConnection > attempts to send heartbeats to the broker after sending the first protocol > header but before authenticating. > In AMQP 1.0 you cannot send empty (heartbeat) frames while establishing a > SASL layer - empty (heartbeat) frames are only defined for AMQP frames. To > compound this error, the test is actually sending AMQP 0-8 heartbeat frames > anyway :-) > The test also fails on Windows seemingly because windows does not report the > connection has closed unless you try to read from it. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1607) Some C examples can't be compiled using Visual Studio 2010
[ https://issues.apache.org/jira/browse/PROTON-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1614#comment-1614 ] ASF subversion and git services commented on PROTON-1607: - Commit 9e862258f10a7c1ce16b4ca644202cc4c3e5af57 in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=9e86225 ] PROTON-1607: Make sure C examples are valid C89 so that VS 2010 can compile them > Some C examples can't be compiled using Visual Studio 2010 > -- > > Key: PROTON-1607 > URL: https://issues.apache.org/jira/browse/PROTON-1607 > Project: Qpid Proton > Issue Type: Bug >Affects Versions: proton-c-0.18.0 >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: proton-c-0.18.0 > > > This is because they are using C99 features. > It is straight forward to use only C89 features so we should do that. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1607) Some C examples can't be compiled using Visual Studio 2010
Andrew Stitcher created PROTON-1607: --- Summary: Some C examples can't be compiled using Visual Studio 2010 Key: PROTON-1607 URL: https://issues.apache.org/jira/browse/PROTON-1607 Project: Qpid Proton Issue Type: Bug Affects Versions: proton-c-0.18.0 Reporter: Andrew Stitcher Assignee: Andrew Stitcher Fix For: proton-c-0.18.0 This is because they are using C99 features. It is straight forward to use only C89 features so we should do that. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7946) [Java Broker] ProtocolNegotiationTest only works by accident on AMQP 1.0
Rob Godfrey created QPID-7946: - Summary: [Java Broker] ProtocolNegotiationTest only works by accident on AMQP 1.0 Key: QPID-7946 URL: https://issues.apache.org/jira/browse/QPID-7946 Project: Qpid Issue Type: Bug Components: Java Broker Reporter: Rob Godfrey Assignee: Rob Godfrey Priority: Minor ProtocolNegotiationTest.testNoConnectionOpenSent_BrokerClosesConnection attempts to send heartbeats to the broker after sending the first protocol header but before authenticating. In AMQP 1.0 you cannot send empty (heartbeat) frames while establishing a SASL layer - empty (heartbeat) frames are only defined for AMQP frames. To compound this error, the test is actually sending AMQP 0-8 heartbeat frames anyway :-) The test also fails on Windows seemingly because windows does not report the connection has closed unless you try to read from it. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-844) Make TLS cipher suites configurable
[ https://issues.apache.org/jira/browse/DISPATCH-844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-844. Resolution: Fixed > Make TLS cipher suites configurable > --- > > Key: DISPATCH-844 > URL: https://issues.apache.org/jira/browse/DISPATCH-844 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 0.8.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy > Fix For: 1.0.0 > > > A security conscious user may wish to restrict the set of ciphers to a > minimal set of those that are currently deemed secure. > Proton now allows TLS cipher suites to be configurable as seen in > https://issues.apache.org/jira/browse/PROTON-1582 > Introduce a field called "ciphers" in sslProfile and call > pn_ssl_domain_set_ciphers if ciphers field is provided by the user. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-844) Make TLS cipher suites configurable
[ https://issues.apache.org/jira/browse/DISPATCH-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16188812#comment-16188812 ] ASF subversion and git services commented on DISPATCH-844: -- Commit a33dd4602b6a08a808eb72d1e4bf514c30478908 in qpid-dispatch's branch refs/heads/master from [~ganeshmurthy] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=a33dd46 ] DISPATCH-844 - Added cipher field to sslProfile object. This will allow users to disable weak ciphers in an SSL connection > Make TLS cipher suites configurable > --- > > Key: DISPATCH-844 > URL: https://issues.apache.org/jira/browse/DISPATCH-844 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 0.8.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy > Fix For: 1.0.0 > > > A security conscious user may wish to restrict the set of ciphers to a > minimal set of those that are currently deemed secure. > Proton now allows TLS cipher suites to be configurable as seen in > https://issues.apache.org/jira/browse/PROTON-1582 > Introduce a field called "ciphers" in sslProfile and call > pn_ssl_domain_set_ciphers if ciphers field is provided by the user. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1606) (Proton-J) Using Sasl needs to be optional for Client Role
[
https://issues.apache.org/jira/browse/PROTON-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
tim taylor updated PROTON-1606:
---
Summary: (Proton-J) Using Sasl needs to be optional for Client Role (was:
(Proton-J) Using Sasl needs to be optional)
> (Proton-J) Using Sasl needs to be optional for Client Role
> --
>
> Key: PROTON-1606
> URL: https://issues.apache.org/jira/browse/PROTON-1606
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.22.0
> Environment: N/A
>Reporter: tim taylor
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> In order for my application to use Proton-j for amqps messaging, the Sasl
> layer cannot be created by the global handler (IOHandler) at
> CONNECTION_LOCAL_OPEN time. The code below breaks our ability to use proton-j
> for amqps messaging as a CLIENT against our service (SERVER).
> ...
> sasl = transport.sasl();
> sasl.client();
> sasl.setMechanisms("ANONYMOUS");
> ...
> I need these three lines of code to be optional in the global handler, or for
> a new API that allows a transport implementation to undo creating the Sasl
> layer.
> Something like:
>
> Transport transport = event.getConnection().getTransport();
> transport.disableSasl();
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-551) disconnect connections that do not complete initial protocol handshake within a given time
[ https://issues.apache.org/jira/browse/DISPATCH-551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-551. --- Resolution: Fixed A new configuration attribute has been added for listeners: bq. initialHandshakeTimeoutSeconds This is the number of seconds after a connection transport is established that the router will give to a connecting client to complete the initial handshake and send the AMQP OPEN frame. If this timeout is exceeded, the connection will be dropped. The default value is 0 (zero) which means that there will be no timeout applied. > disconnect connections that do not complete initial protocol handshake within > a given time > --- > > Key: DISPATCH-551 > URL: https://issues.apache.org/jira/browse/DISPATCH-551 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Gordon Sim >Assignee: Ted Ross > Fix For: 1.0.0 > > > Prevents lots of file handles being used without having to authenticate. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-551) disconnect connections that do not complete initial protocol handshake within a given time
[ https://issues.apache.org/jira/browse/DISPATCH-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16188770#comment-16188770 ] ASF subversion and git services commented on DISPATCH-551: -- Commit 272398ddc282da2e3751917c18e4e7f8a472ba42 in qpid-dispatch's branch refs/heads/master from [~tr...@redhat.com] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=272398d ] DISPATCH-551 - Added a configurable timeout to close connections that don't complete the opening handshake after transport establishment. > disconnect connections that do not complete initial protocol handshake within > a given time > --- > > Key: DISPATCH-551 > URL: https://issues.apache.org/jira/browse/DISPATCH-551 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Gordon Sim >Assignee: Ted Ross > Fix For: 1.0.0 > > > Prevents lots of file handles being used without having to authenticate. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-525) What are proper names and units for protocol configuration settings?
[ https://issues.apache.org/jira/browse/DISPATCH-525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-525. -- Resolution: Fixed Issue fixed with commits under DISPATCH-451 > What are proper names and units for protocol configuration settings? > > > Key: DISPATCH-525 > URL: https://issues.apache.org/jira/browse/DISPATCH-525 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Management Agent >Affects Versions: 0.7.0 >Reporter: Chuck Rolke > Fix For: 1.0.0 > > > Several settings are available in configuration objects that are used in AMQP > negotiations with clients. Some of them are confusing as they exist now and > could be redefined to make their understanding and usage easier for end > users. The same settings are defined for Router Listener and Connector and > for Policy Vhost objects. > ||Setting||Units||Range|| > |maxFrameSize|octets|uint| > |maxSessions|sessions|uint16| > |maxSessionWindow|octets|uint| > |maxMessageSize *not implemented*|octets|uint| > |linkCapacity|messages|integer| > These settings have to work in cooperation with the proton engine interface. > h2. maxFrameSize > This setting is straightforward. The range is 0..ULONG_MAX. > Using octets is fine. This value must be 512 or larger per AMQP spec. > h4. Proposal > Leave this setting unchanged. > h2. maxSessions > This setting is in units of 'sessions'. The acceptable values are in the > range 1..65536. > The number given in the configuration is one larger than the value used by > AMQP and proton. In AMQP the channel-max value of an Open is the largest > channel number that can be used. So a channel-max of 0 allows one session, > and a value of 1 allows two sessions, and so on. > I prefer to have the spec values be equal to the number of sessions allowed. > * Dispatch code subtracts one from the specified value and puts it into > proton channel-max. > * A value of zero in the spec can be disallowed or it can mean some default > value. > h4. Proposal > Leave this setting unchanged. > h2. maxSessionWindow > This setting is in octets. The range is 0..ULONG_MAX with a minimum of > max-frame-size octets. > This setting is slightly confusing as the specification is in octets. Then > that value of octets is passed to proton in pn_session_set_incoming_capacity. > Proton divides the incoming_capacity by the max-frame-size and uses the > result in a Begin incoming-window. The incoming-window then is measured in > transfer frames. For example: > * maxFrameSize = 65,536. > * maxSessionWindow = 1,000,000. > Dividing (100 / 65536) = 15 frames. The 15 is used in the > Begin/incoming-window field during negotiation with the peer. > A user expecting to have about a megabyte of buffering on the session might > be surprised to find all the buffering consumed by 15 100-byte transfer > frames. > h4. Proposal > * Rename this setting to *maxSessionFrames*. > * Change this setting's units of 'transfer frame'. Then the value sent to > proton in incoming_capacity would be calculated by (maxSessionFrames * > maxFrameSize). The value of maxSessionFrames would then appear in the > Begin/incoming-window field. > h2. maxMessageSize > This setting is in octets. The range is 0..ULONG_MAX. > This setting is TBD. No interface in proton engine is available to change it. > If this value is zero or, more typically, not set then there is no maximum > message size. > h4. Proposal > Leave this setting unchanged. > h2. linkCapacity > This setting is in transfer frames. The range is 0..LONG_MAX. > This setting defines how much credit is issued on links created on a > connection. It specifies how many transfers can be in-flight concurrently for > each link. > This setting is for Listener and Connector objects only. It is not defined > for Policy Vhost objects. > h4. Proposal > * Leave the units and current meaning of this setting unchanged. > * Add this value to the Policy Vhost settings so that it may be overridden on > a Vhost Usergroup basis. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-738) Several test failures on Solaris x86
[ https://issues.apache.org/jira/browse/DISPATCH-738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy updated DISPATCH-738: --- Fix Version/s: (was: 1.0.0) 1.1.0 > Several test failures on Solaris x86 > > > Key: DISPATCH-738 > URL: https://issues.apache.org/jira/browse/DISPATCH-738 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 0.7.0 >Reporter: Ganesh Murthy > Fix For: 1.1.0 > > > -- The C compiler identification is SunPro 5.10.0 > -- Check for working C compiler: /usr/bin/cc > -- Check for working C compiler: /usr/bin/cc -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Found PythonInterp: /python278/bin/python (found version "2.7.8") > -- Found PythonLibs: /python278/lib/libpython2.7.so (found version "2.7.8") > -- Found Proton: > /qpid-dispatch-router/dispatch-workspace/build-dir/qpid-proton/dist/release/lib64/libqpid-proton.so > > -- Could NOT find LIBWEBSOCKETS (missing: LIBWEBSOCKETS_LIBRARIES > LIBWEBSOCKETS_INCLUDE_DIRS) > -- Could NOT find VALGRIND (missing: VALGRIND_EXECUTABLE) > -- asciidoc not found: not generating HTML, man pages or PDF > -- Configuring done > -- Generating done > -- Build files have been written to: > /qpid-dispatch-router/dispatch-workspace/build-dir/qpid-dispatch > [ 1%] Generating schema_enum.h, schema_enum.c > Scanning dependencies of target qpid-dispatch > [ 2%] Building C object src/CMakeFiles/qpid-dispatch.dir/amqp.c.o > [ 4%] Building C object src/CMakeFiles/qpid-dispatch.dir/bitmask.c.o > [ 5%] Building C object src/CMakeFiles/qpid-dispatch.dir/buffer.c.o > [ 6%] Building C object src/CMakeFiles/qpid-dispatch.dir/error.c.o > [ 8%] Building C object src/CMakeFiles/qpid-dispatch.dir/compose.c.o > [ 9%] Building C object > src/CMakeFiles/qpid-dispatch.dir/connection_manager.c.o > [ 11%] Building C object src/CMakeFiles/qpid-dispatch.dir/container.c.o > [ 12%] Building C object src/CMakeFiles/qpid-dispatch.dir/dispatch.c.o > [ 13%] Building C object src/CMakeFiles/qpid-dispatch.dir/entity.c.o > [ 15%] Building C object src/CMakeFiles/qpid-dispatch.dir/entity_cache.c.o > [ 16%] Building C object src/CMakeFiles/qpid-dispatch.dir/failoverlist.c.o > [ 18%] Building C object src/CMakeFiles/qpid-dispatch.dir/hash.c.o > [ 19%] Building C object src/CMakeFiles/qpid-dispatch.dir/iovec.c.o > [ 20%] Building C object src/CMakeFiles/qpid-dispatch.dir/iterator.c.o > [ 22%] Building C object src/CMakeFiles/qpid-dispatch.dir/log.c.o > [ 23%] Building C object src/CMakeFiles/qpid-dispatch.dir/message.c.o > [ 25%] Building C object src/CMakeFiles/qpid-dispatch.dir/parse.c.o > [ 26%] Building C object src/CMakeFiles/qpid-dispatch.dir/policy.c.o > [ 27%] Building C object src/CMakeFiles/qpid-dispatch.dir/posix/driver.c.o > [ 29%] Building C object src/CMakeFiles/qpid-dispatch.dir/posix/threading.c.o > [ 30%] Building C object src/CMakeFiles/qpid-dispatch.dir/python_embedded.c.o > [ 31%] Building C object src/CMakeFiles/qpid-dispatch.dir/router_agent.c.o > [ 33%] Building C object src/CMakeFiles/qpid-dispatch.dir/router_config.c.o > [ 34%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/agent.c.o > [ 36%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/agent_address.c.o > [ 37%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/agent_config_address.c.o > [ 38%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/agent_config_auto_link.c.o > [ 40%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/agent_connection.c.o > [ 41%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/agent_config_link_route.c.o > [ 43%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/agent_link.c.o > [ 44%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/agent_router.c.o > [ 45%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/connections.c.o > [ 47%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/error.c.o > [ 48%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/forwarder.c.o > [ 50%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/route_control.c.o > [ 51%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/router_core.c.o > [ 52%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/router_core_thread.c.o > [ 54%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/route_tables.c.o > [ 55%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/management_agent.c.o > [ 56%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/terminus.c.o > [ 58%] Building C object > src/CMakeFiles/qpid-dispatch.dir/router_core/transfer.c.o >
[jira] [Assigned] (PROTON-1592) [proton-python] accessing properties of event.receiver in on_link_opened throws exception
[
https://issues.apache.org/jira/browse/PROTON-1592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross reassigned PROTON-1592:
---
Assignee: Alan Conway (was: Cliff Jansen)
> [proton-python] accessing properties of event.receiver in on_link_opened
> throws exception
> -
>
> Key: PROTON-1592
> URL: https://issues.apache.org/jira/browse/PROTON-1592
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Reporter: Jiri Daněk
>Assignee: Alan Conway
> Labels: regression
> Fix For: proton-c-0.18.0
>
>
> Apply the following patch to the {{tx-recv.py}} example
> {code}
> diff --git a/examples/python/tx_recv.py b/examples/python/tx_recv.py
> index 4baddcf5..54f3b489 100755
> --- a/examples/python/tx_recv.py
> +++ b/examples/python/tx_recv.py
> @@ -40,6 +40,9 @@ class TxRecv(MessagingHandler, TransactionHandler):
> self.container.declare_transaction(self.conn, handler=self)
> self.transaction = None
>
> +def on_link_opened(self, event):
> +event.receiver.drain_mode = True
> +
> def on_message(self, event):
> print(event.message.body)
> self.transaction.accept(event.delivery)
> {code}
> Now run first {{tx_send.py}}, then this {{tx_recv.py}}. The second command
> throws exception
> {noformat}
> $ LD_LIBRARY_PATH=`pwd`/lib64 PYTHONPATH=`pwd`/lib64/proton/bindings/python
> python ../examples/python/tx_recv.py
> Traceback (most recent call last):
> File "../examples/python/tx_recv.py", line 79, in
> Container(TxRecv(opts.address, opts.messages, opts.batch_size)).run()
> File
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
> line 148, in run
> while self.process(): pass
> File
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
> line 174, in process
> self._check_errors()
> File
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
> line 170, in _check_errors
> _compat.raise_(exc, value, tb)
> File
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
> line 4068, in dispatch
> ev.dispatch(self.handler)
> File
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
> line 3977, in dispatch
> result = dispatch(handler, type.method, self)
> File
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
> line 3857, in dispatch
> return handler.on_unhandled(method, *args)
> File
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/reactor.py",
> line 876, in on_unhandled
> event.dispatch(handler)
> File
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
> line 3980, in dispatch
> self.dispatch(h, type)
> File
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
> line 3977, in dispatch
> result = dispatch(handler, type.method, self)
> File
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
> line 3855, in dispatch
> return m(*args)
> File
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/handlers.py",
> line 298, in on_link_remote_open
> self.on_link_opened(event)
> File
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/handlers.py",
> line 313, in on_link_opened
> dispatch(self.delegate, 'on_link_opened', event)
> File
> "/home/jdanek/Work/repos/qpid-proton/install/lib64/proton/bindings/python/proton/__init__.py",
> line 3855, in dispatch
> return m(*args)
> File "../examples/python/tx_recv.py", line 44, in on_link_opened
> event.receiver.drain_mode = True
> AttributeError: 'NoneType' object has no attribute 'drain_mode'
> {noformat}
> To see this is a regression, repeat now with python-qpid-proton 0.17.0 from
> Pypi. With this previous release, there is success.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-1461) [c++] Proton C++ client silently retains presettled messages
[ https://issues.apache.org/jira/browse/PROTON-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross reassigned PROTON-1461: --- Assignee: Alan Conway (was: Cliff Jansen) > [c++] Proton C++ client silently retains presettled messages > > > Key: PROTON-1461 > URL: https://issues.apache.org/jira/browse/PROTON-1461 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: 0.17.0 > Environment: Fedora 25 > Test message source: Qpid Dispatch Router with address that has > 'distributionMode: multicast' > Test client: example simple_recv.cpp >Reporter: Chuck Rolke >Assignee: Alan Conway > Fix For: proton-c-0.18.0 > > > With distributionMode 'multicast' the router sends messages presettled. In > this mode the simple_recv program memory grows without bound until OOM. > Switching the router to use distribution mode 'closest' causes the router to > send messages unsettled. In this mode the same simple_recv client sends back > a disposition and program memory use is normal. > A brokered connection, like to Apache Artemis, behaves normally with > unsettled messages and dispositions for each. > For comparison example program proton-0.18.0/examples/python/simple_recv.py > receives router multicast presettled messages and experiences no memory > growth. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-1589) How can I handle invalid SASL PLAIN credentials error when reconnect is on?
[
https://issues.apache.org/jira/browse/PROTON-1589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross reassigned PROTON-1589:
---
Assignee: Andrew Stitcher (was: Cliff Jansen)
> How can I handle invalid SASL PLAIN credentials error when reconnect is on?
> ---
>
> Key: PROTON-1589
> URL: https://issues.apache.org/jira/browse/PROTON-1589
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.18.0
>Reporter: Jiri Daněk
>Assignee: Andrew Stitcher
>
> Apply the following patch to the simple_send.cpp example
> {code}
> diff --git a/examples/cpp/simple_send.cpp b/examples/cpp/simple_send.cpp
> index a4c2272d..053da34f 100644
> --- a/examples/cpp/simple_send.cpp
> +++ b/examples/cpp/simple_send.cpp
> @@ -27,6 +27,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -53,6 +54,12 @@ class simple_send : public proton::messaging_handler {
> proton::connection_options co;
> if (!user.empty()) co.user(user);
> if (!password.empty()) co.password(password);
> +co.sasl_enabled(true);
> +co.sasl_allow_insecure_mechs(true);
> +std::string sasl_mechanisms("PLAIN");
> +co.sasl_allowed_mechs(sasl_mechanisms);
> +proton::reconnect_options ro;
> +co.reconnect(ro);
> sender = c.open_sender(url, co);
> }
> {code}
> Now attempt to connect to AMQP broker, for example ActiveMQ Artemis instance,
> which was created with {{--require-login}}. The client gets stuck if you use
> invalid credentials.
> {noformat}
> PN_TRACE_FRM=1 examples/cpp/simple_send -a amqp://127.0.0.1:5672 -u nosuch -p
> user
> [0xed9980]: -> SASL
> [0xed9980]: <- SASL
> [0xed9980]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xed9980]:0 -> @sasl-init(65) [mechanism=:PLAIN,
> initial-response=b"\x00nosuch\x00user"]
> [0xed9980]:0 <- @sasl-outcome(68) [code=1]
> [0xed9980]: -> EOS
> [0xee7290]: -> SASL
> [0xee7290]: <- SASL
> [0xee7290]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xee7290]:0 -> @sasl-init(65) [mechanism=:PLAIN,
> initial-response=b"\x00nosuch\x00user"]
> [0xee7290]:0 <- @sasl-outcome(68) [code=1]
> [0xee7290]: -> EOS
> [0xeee6b0]: -> SASL
> [0xeee6b0]: <- SASL
> [0xeee6b0]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0xeee6b0]:0 -> @sasl-init(65) [mechanism=:PLAIN,
> initial-response=b"\x00nosuch\x00user"]
> [0xeee6b0]:0 <- @sasl-outcome(68) [code=1]
> [0xeee6b0]: -> EOS
> {noformat}
> As you can see, the client keeps reconnecting. The previous behavior, if I
> recall correctly, was to execute error handler in this case. To be exact, it
> would run {{on_transport_error}} handler.
> I think that it is reasonable for the client to stop reconnecting and run
> this handler if the reason for failed connection are wrong credentials. This
> condition is unlikely to resolve itself on multiple retries.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7945) [Java Broker] SpawnedBrokerHolderTest fails on Windows
[ https://issues.apache.org/jira/browse/QPID-7945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16188681#comment-16188681 ] ASF subversion and git services commented on QPID-7945: --- Commit 8abda0619a91762581cb669a00174bc89a273c03 in qpid-broker-j's branch refs/heads/master from [~godfrer] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=8abda06 ] QPID-7945 : SpawnedBrokerHolder does not work well on windows > [Java Broker] SpawnedBrokerHolderTest fails on Windows > -- > > Key: QPID-7945 > URL: https://issues.apache.org/jira/browse/QPID-7945 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Rob Godfrey >Priority: Minor > > WIndows .bat files treat = as an argument separator so the sequence -prop > test.port=0 is treated not as two arguments "-prop", "test.port=0"; but > instead as three arguments "-prop", "test.port", "0". -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7945) [Java Broker] SpawnedBrokerHolderTest fails on Windows
Rob Godfrey created QPID-7945: - Summary: [Java Broker] SpawnedBrokerHolderTest fails on Windows Key: QPID-7945 URL: https://issues.apache.org/jira/browse/QPID-7945 Project: Qpid Issue Type: Bug Components: Java Broker Reporter: Rob Godfrey Priority: Minor WIndows .bat files treat = as an argument separator so the sequence -prop test.port=0 is treated not as two arguments "-prop", "test.port=0"; but instead as three arguments "-prop", "test.port", "0". -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-757) Qpid Dispatch does not compile under Ubuntu
[
https://issues.apache.org/jira/browse/DISPATCH-757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-757.
Resolution: Fixed
> Qpid Dispatch does not compile under Ubuntu
> ---
>
> Key: DISPATCH-757
> URL: https://issues.apache.org/jira/browse/DISPATCH-757
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> Got the following error message when compiling qpid-dispatch master on
> ubuntu:latest.
> The following is the compile error -
> {noformat}
> [ 66%] Building C object src/CMakeFiles/qpid-dispatch.dir/trace_mask.c.o
> [ 67%] Building C object
> src/CMakeFiles/qpid-dispatch.dir/http-libwebsockets.c.o
> /main/qpid-dispatch/src/http-libwebsockets.c: In function 'logger':
> /main/qpid-dispatch/src/http-libwebsockets.c:54:23: error: implicit
> declaration of function 'isspace' [-Werror=implicit-function-declaration]
> while (len > 1 && isspace(line[len-1])) { /* Strip trailing newline */
>^
> cc1: all warnings being treated as errors
> src/CMakeFiles/qpid-dispatch.dir/build.make:1184: recipe for target
> 'src/CMakeFiles/qpid-dispatch.dir/http-libwebsockets.c.o' failed
> make[2]: *** [src/CMakeFiles/qpid-dispatch.dir/http-libwebsockets.c.o] Error 1
> CMakeFiles/Makefile2:981: recipe for target
> 'src/CMakeFiles/qpid-dispatch.dir/all' failed
> make[1]: *** [src/CMakeFiles/qpid-dispatch.dir/all] Error 2
> make: *** [all] Error 2
> Makefile:138: recipe for target 'all' failed
> The command '/bin/sh -c cmake .. -DCMAKE_INSTALL_PREFIX=/usr && make install'
> returned a non-zero code: 2
> [gmurthy@localhost dockerfiles]$
> {noformat}
> The following is the docker file used
> {noformat}
> #
> # Licensed to the Apache Software Foundation (ASF) under one
> # or more contributor license agreements. See the NOTICE file
> # distributed with this work for additional information
> # regarding copyright ownership. The ASF licenses this file
> # to you under the Apache License, Version 2.0 (the
> # "License"); you may not use this file except in compliance
> # with the License. You may obtain a copy of the License at
> #
> # http://www.apache.org/licenses/LICENSE-2.0
> #
> # Unless required by applicable law or agreed to in writing,
> # software distributed under the License is distributed on an
> # "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> # KIND, either express or implied. See the License for the
> # specific language governing permissions and limitations
> # under the License.
> #
> # Gets the latest Ubuntu from dockerhub
> FROM ubuntu:latest
> MAINTAINER "dev@qpid.apache.org"
> # Install all the required packages. Some in this list were picked off from
> proton's INSTALL.md
> (https://github.com/apache/qpid-proton/blob/master/INSTALL.md) and the rest
> are from dispatch (https://github.com/apache/qpid-dispatch/blob/master/README)
> RUN apt-get update && apt-get -y install gcc cmake cmake-curses-gui uuid-dev
> libssl-dev libsasl2-2 libsasl2-dev sasl2-bin swig python-dev ruby-dev
> libperl-dev git make doxygen valgrind emacs libuv1 libuv1-dev
> # Create a main directory and clone the qpid-proton repo from github
> RUN mkdir /main && cd /main && git clone
> https://git-wip-us.apache.org/repos/asf/qpid-proton.git && cd
> /main/qpid-proton && mkdir /main/qpid-proton/build
> WORKDIR /main/qpid-proton/build
> # make and install proton
> RUN cmake .. -DSYSINSTALL_BINDINGS=ON -DCMAKE_INSTALL_PREFIX=/usr
> -DSYSINSTALL_PYTHON=ON && make install
> # download libwebsockets code from
> https://github.com/warmcat/libwebsockets/commits/v2.1-stable
> RUN cd /main && git clone --branch v2.1-stable
> https://github.com/warmcat/libwebsockets.git && mkdir
> /main/libwebsockets/build
> WORKDIR /main/libwebsockets/build
> RUN cmake .. && make install
> # Clone the qpid-dispatch git repo
> RUN cd /main && git clone
> https://git-wip-us.apache.org/repos/asf/qpid-dispatch.git && mkdir
> /main/qpid-dispatch/build
> WORKDIR /main/qpid-dispatch/build
> RUN cmake .. -DCMAKE_INSTALL_PREFIX=/usr && make install
> # Add site-packages to the PYTHONPATH environment variable. This is because
> Ubuntu does not list the site-packages folder in the sys.path
> ENV PYTHONPATH=/usr/lib/python2.7/site-packages
> # Uncomment the following line if you would like to run all the dispatch unit
> tests and system tests.
> # RUN ctest -VV
> # Start the dispatch router
> CMD ["qdrouterd"]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-757) Qpid Dispatch does not compile under Ubuntu
[
https://issues.apache.org/jira/browse/DISPATCH-757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16188679#comment-16188679
]
Ganesh Murthy commented on DISPATCH-757:
Using the docker file specified above, the source code compiles successfully
and all tests pass.
> Qpid Dispatch does not compile under Ubuntu
> ---
>
> Key: DISPATCH-757
> URL: https://issues.apache.org/jira/browse/DISPATCH-757
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Fix For: 1.0.0
>
>
> Got the following error message when compiling qpid-dispatch master on
> ubuntu:latest.
> The following is the compile error -
> {noformat}
> [ 66%] Building C object src/CMakeFiles/qpid-dispatch.dir/trace_mask.c.o
> [ 67%] Building C object
> src/CMakeFiles/qpid-dispatch.dir/http-libwebsockets.c.o
> /main/qpid-dispatch/src/http-libwebsockets.c: In function 'logger':
> /main/qpid-dispatch/src/http-libwebsockets.c:54:23: error: implicit
> declaration of function 'isspace' [-Werror=implicit-function-declaration]
> while (len > 1 && isspace(line[len-1])) { /* Strip trailing newline */
>^
> cc1: all warnings being treated as errors
> src/CMakeFiles/qpid-dispatch.dir/build.make:1184: recipe for target
> 'src/CMakeFiles/qpid-dispatch.dir/http-libwebsockets.c.o' failed
> make[2]: *** [src/CMakeFiles/qpid-dispatch.dir/http-libwebsockets.c.o] Error 1
> CMakeFiles/Makefile2:981: recipe for target
> 'src/CMakeFiles/qpid-dispatch.dir/all' failed
> make[1]: *** [src/CMakeFiles/qpid-dispatch.dir/all] Error 2
> make: *** [all] Error 2
> Makefile:138: recipe for target 'all' failed
> The command '/bin/sh -c cmake .. -DCMAKE_INSTALL_PREFIX=/usr && make install'
> returned a non-zero code: 2
> [gmurthy@localhost dockerfiles]$
> {noformat}
> The following is the docker file used
> {noformat}
> #
> # Licensed to the Apache Software Foundation (ASF) under one
> # or more contributor license agreements. See the NOTICE file
> # distributed with this work for additional information
> # regarding copyright ownership. The ASF licenses this file
> # to you under the Apache License, Version 2.0 (the
> # "License"); you may not use this file except in compliance
> # with the License. You may obtain a copy of the License at
> #
> # http://www.apache.org/licenses/LICENSE-2.0
> #
> # Unless required by applicable law or agreed to in writing,
> # software distributed under the License is distributed on an
> # "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> # KIND, either express or implied. See the License for the
> # specific language governing permissions and limitations
> # under the License.
> #
> # Gets the latest Ubuntu from dockerhub
> FROM ubuntu:latest
> MAINTAINER "dev@qpid.apache.org"
> # Install all the required packages. Some in this list were picked off from
> proton's INSTALL.md
> (https://github.com/apache/qpid-proton/blob/master/INSTALL.md) and the rest
> are from dispatch (https://github.com/apache/qpid-dispatch/blob/master/README)
> RUN apt-get update && apt-get -y install gcc cmake cmake-curses-gui uuid-dev
> libssl-dev libsasl2-2 libsasl2-dev sasl2-bin swig python-dev ruby-dev
> libperl-dev git make doxygen valgrind emacs libuv1 libuv1-dev
> # Create a main directory and clone the qpid-proton repo from github
> RUN mkdir /main && cd /main && git clone
> https://git-wip-us.apache.org/repos/asf/qpid-proton.git && cd
> /main/qpid-proton && mkdir /main/qpid-proton/build
> WORKDIR /main/qpid-proton/build
> # make and install proton
> RUN cmake .. -DSYSINSTALL_BINDINGS=ON -DCMAKE_INSTALL_PREFIX=/usr
> -DSYSINSTALL_PYTHON=ON && make install
> # download libwebsockets code from
> https://github.com/warmcat/libwebsockets/commits/v2.1-stable
> RUN cd /main && git clone --branch v2.1-stable
> https://github.com/warmcat/libwebsockets.git && mkdir
> /main/libwebsockets/build
> WORKDIR /main/libwebsockets/build
> RUN cmake .. && make install
> # Clone the qpid-dispatch git repo
> RUN cd /main && git clone
> https://git-wip-us.apache.org/repos/asf/qpid-dispatch.git && mkdir
> /main/qpid-dispatch/build
> WORKDIR /main/qpid-dispatch/build
> RUN cmake .. -DCMAKE_INSTALL_PREFIX=/usr && make install
> # Add site-packages to the PYTHONPATH environment variable. This is because
> Ubuntu does not list the site-packages folder in the sys.path
> ENV PYTHONPATH=/usr/lib/python2.7/site-packages
> # Uncomment the following line if you would like to run all the dispatch unit
> tests and system tests.
> # RUN ctest -VV
> # Start the dispatch router
> CMD ["qdrouterd"]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe
[jira] [Updated] (PROTON-1606) (Proton-J) Using Sasl needs to be optional
[
https://issues.apache.org/jira/browse/PROTON-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
tim taylor updated PROTON-1606:
---
Description:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging as
a CLIENT against our service (SERVER).
...
sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
...
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
was:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
...
sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
...
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
> (Proton-J) Using Sasl needs to be optional
> --
>
> Key: PROTON-1606
> URL: https://issues.apache.org/jira/browse/PROTON-1606
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.22.0
> Environment: N/A
>Reporter: tim taylor
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> In order for my application to use Proton-j for amqps messaging, the Sasl
> layer cannot be created by the global handler (IOHandler) at
> CONNECTION_LOCAL_OPEN time. The code below breaks our ability to use proton-j
> for amqps messaging as a CLIENT against our service (SERVER).
> ...
> sasl = transport.sasl();
> sasl.client();
> sasl.setMechanisms("ANONYMOUS");
> ...
> I need these three lines of code to be optional in the global handler, or for
> a new API that allows a transport implementation to undo creating the Sasl
> layer.
> Something like:
>
> Transport transport = event.getConnection().getTransport();
> transport.disableSasl();
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1349) C "proactor" implementation on windows
[ https://issues.apache.org/jira/browse/PROTON-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16188604#comment-16188604 ] ASF subversion and git services commented on PROTON-1349: - Commit b0a0633be32377c6720d8f7737ca07c182ff7f86 in qpid-proton's branch refs/heads/master from Clifford Jansen [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=b0a0633 ] PROTON-1349: Windows iocp reconnect_test fix, run io loop only once on topup > C "proactor" implementation on windows > -- > > Key: PROTON-1349 > URL: https://issues.apache.org/jira/browse/PROTON-1349 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: proton-c-0.18.0 > > Attachments: p1349_2.patch > > > Provide the Windows counterpart to the work in > https://issues.apache.org/jira/browse/PROTON-1344 > Including a thread safe inject. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-814) Killing qdrouterd process takes a long time
[ https://issues.apache.org/jira/browse/DISPATCH-814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-814. Resolution: Fixed Fix Version/s: 1.0.0 > Killing qdrouterd process takes a long time > --- > > Key: DISPATCH-814 > URL: https://issues.apache.org/jira/browse/DISPATCH-814 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine > Environment: This test runs in fedora 26 container. >Reporter: Irina Boverman > Fix For: 1.0.0 > > > Often killing router fails to complete: > ++ ps -C qdrouterd -o pid= > + pid=' 1455' > + kill 1455 > + set +e > + wait 1455 > Build timed out (after 30 minutes). Marking the build as failed. > Build was aborted -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-765) Three unit tests failing under travis on trusty
[
https://issues.apache.org/jira/browse/DISPATCH-765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-765.
Resolution: Fixed
The three tests mentioned in this JIRA are no longer failing
> Three unit tests failing under travis on trusty
> ---
>
> Key: DISPATCH-765
> URL: https://issues.apache.org/jira/browse/DISPATCH-765
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Tests
>Affects Versions: 1.0.0
> Environment: Travis Ubuntu Trusty
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Minor
> Fix For: 1.0.0
>
>
> The following unit tests are failing under travis -
> {noformat}
> system_tests_management (Failed)
> system_tests_multi_tenancy (Failed)
> system_tests_http (Failed)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (DISPATCH-470) Router terminated by itself while sitting idle
[ https://issues.apache.org/jira/browse/DISPATCH-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy closed DISPATCH-470. -- Resolution: Cannot Reproduce Fix Version/s: 1.0.0 > Router terminated by itself while sitting idle > -- > > Key: DISPATCH-470 > URL: https://issues.apache.org/jira/browse/DISPATCH-470 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.1 > Environment: Debian 8.3, Apache Qpid Proton 0.13.0 for drivers and > dependencies, Hardware: 8 CPUs, 61 GB RAM, 30 GB HDD each on 5 separate > machines >Reporter: Vishal Sharda > Fix For: 1.0.0 > > > We are running a network of 5 inter-connected routers each on a separate > host. One of the routers in this network terminated after running > successfully for 7+ days. The router was idle (not receiving/sending any > messages) when this happened. After analyzing the core dump, it turned out > to be something related to mutex lock in multithreading. > Here is the full bt: > Reading symbols from qpid-dispatch/qdrouterd...(no debugging symbols > found)...done. > [New LWP 4082] > [New LWP 4088] > [New LWP 4030] > [New LWP 4089] > [New LWP 4090] > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > Core was generated by `qdrouterd -c > /x/web/LIVE/switch-dr-network/configurator/qdrouterd.conf'. > Program terminated with signal SIGABRT, Aborted. > #0 0x7ffaaf7e6067 in __GI_raise (sig=sig@entry=6) at > ../nptl/sysdeps/unix/sysv/linux/raise.c:56 > 56../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. > (gdb) up > #1 0x7ffaaf7e7448 in __GI_abort () at abort.c:89 > 89abort.c: No such file or directory. > (gdb) up > #2 0x7ffaaf7df266 in __assert_fail_base ( > fmt=0x7ffaaf918238 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", > assertion=assertion@entry=0x7ffab0997baf "result == 0", > file=file@entry=0x7ffab0997b48 > "/home/anhtran/qpid-package/dispatch/qpid-dispatch-0.6.x-Vanilla/src/posix/threading.c", > line=line@entry=71, function=function@entry=0x7ffab0997cd1 "sys_mutex_lock") > at assert.c:92 > 92assert.c: No such file or directory. > (gdb) up > #3 0x7ffaaf7df312 in __GI___assert_fail (assertion=0x7ffab0997baf > "result == 0", > file=0x7ffab0997b48 > "/home/anhtran/qpid-package/dispatch/qpid-dispatch-0.6.x-Vanilla/src/posix/threading.c", > line=71, function=0x7ffab0997cd1 "sys_mutex_lock") at assert.c:101 > 101 in assert.c > (gdb) > #4 0x7ffab09802eb in sys_mutex_lock () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > (gdb) > #5 0x7ffab098863a in qdr_forward_deliver_CT () >from /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > (gdb) > #6 0x7ffab0989274 in qdr_forward_closest_CT () >from /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > (gdb) > #7 0x7ffab098dd98 in ?? () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > (gdb) > #8 0x7ffab098b45a in router_core_thread () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > (gdb) > #9 0x7ffab04f50a4 in start_thread (arg=0x7ffaad524700) at > pthread_create.c:309 > 309 pthread_create.c: No such file or directory. > (gdb) > #10 0x7ffaaf89987d in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 > 111 ../sysdeps/unix/sysv/linux/x86_64/clone.S: No such file or directory. > (gdb) > Initial frame selected; you cannot go up. > (gdb) -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1349) C "proactor" implementation on windows
[ https://issues.apache.org/jira/browse/PROTON-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16188518#comment-16188518 ] Chuck Rolke commented on PROTON-1349: - This patch fails to compile on Visual Studio 2012 but works OK on Visual Studio 2013. Is the intention to make it work on older Visual Studios (2012, 2010, 2008,...)? If not then an early fail in CMake would prevent misguided attempts to compile on those Visual Studio versions. > C "proactor" implementation on windows > -- > > Key: PROTON-1349 > URL: https://issues.apache.org/jira/browse/PROTON-1349 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: proton-c-0.18.0 > > Attachments: p1349_2.patch > > > Provide the Windows counterpart to the work in > https://issues.apache.org/jira/browse/PROTON-1344 > Including a thread safe inject. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1606) (Proton-J) Using Sasl needs to be optional
[
https://issues.apache.org/jira/browse/PROTON-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
tim taylor updated PROTON-1606:
---
Description:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
was:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
private void handleOpen(Reactor reactor, Event event)
{
sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
}
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
> (Proton-J) Using Sasl needs to be optional
> --
>
> Key: PROTON-1606
> URL: https://issues.apache.org/jira/browse/PROTON-1606
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.22.0
> Environment: N/A
>Reporter: tim taylor
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> In order for my application to use Proton-j for amqps messaging, the Sasl
> layer cannot be created by the global handler (IOHandler) at
> CONNECTION_LOCAL_OPEN time. The code below breaks our ability to use proton-j
> for amqps messaging against our service.
> sasl = transport.sasl();
> sasl.client();
> sasl.setMechanisms("ANONYMOUS");
> I need these three lines of code to be optional in the global handler, or for
> a new API that allows a transport implementation to undo creating the Sasl
> layer.
> Something like:
>
> Transport transport = event.getConnection().getTransport();
> transport.disableSasl();
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1606) (Proton-J) Using Sasl needs to be optional
[
https://issues.apache.org/jira/browse/PROTON-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
tim taylor updated PROTON-1606:
---
Description:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
...
sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
...
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
was:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
> (Proton-J) Using Sasl needs to be optional
> --
>
> Key: PROTON-1606
> URL: https://issues.apache.org/jira/browse/PROTON-1606
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.22.0
> Environment: N/A
>Reporter: tim taylor
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> In order for my application to use Proton-j for amqps messaging, the Sasl
> layer cannot be created by the global handler (IOHandler) at
> CONNECTION_LOCAL_OPEN time. The code below breaks our ability to use proton-j
> for amqps messaging against our service.
> ...
> sasl = transport.sasl();
> sasl.client();
> sasl.setMechanisms("ANONYMOUS");
> ...
> I need these three lines of code to be optional in the global handler, or for
> a new API that allows a transport implementation to undo creating the Sasl
> layer.
> Something like:
>
> Transport transport = event.getConnection().getTransport();
> transport.disableSasl();
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1606) (Proton-J) Using Sasl needs to be optional
[
https://issues.apache.org/jira/browse/PROTON-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
tim taylor updated PROTON-1606:
---
Description:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
private void handleOpen(Reactor reactor, Event event)
{
sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
}
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
was:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
private void handleOpen(Reactor reactor, Event event)
{
sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
}
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
> (Proton-J) Using Sasl needs to be optional
> --
>
> Key: PROTON-1606
> URL: https://issues.apache.org/jira/browse/PROTON-1606
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.22.0
> Environment: N/A
>Reporter: tim taylor
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> In order for my application to use Proton-j for amqps messaging, the Sasl
> layer cannot be created by the global handler (IOHandler) at
> CONNECTION_LOCAL_OPEN time. The code below breaks our ability to use proton-j
> for amqps messaging against our service.
> private void handleOpen(Reactor reactor, Event event)
> {
> sasl = transport.sasl();
> sasl.client();
> sasl.setMechanisms("ANONYMOUS");
> }
> I need these three lines of code to be optional in the global handler, or for
> a new API that allows a transport implementation to undo creating the Sasl
> layer.
> Something like:
>
> Transport transport = event.getConnection().getTransport();
> transport.disableSasl();
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1606) (Proton-J) Using Sasl needs to be optional
[
https://issues.apache.org/jira/browse/PROTON-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
tim taylor updated PROTON-1606:
---
Description:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
private void handleOpen(Reactor reactor, Event event)
{
sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
}
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
was:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
private void handleOpen(Reactor reactor, Event event)
{
sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
}
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
> (Proton-J) Using Sasl needs to be optional
> --
>
> Key: PROTON-1606
> URL: https://issues.apache.org/jira/browse/PROTON-1606
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.22.0
> Environment: N/A
>Reporter: tim taylor
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> In order for my application to use Proton-j for amqps messaging, the Sasl
> layer cannot be created by the global handler (IOHandler) at
> CONNECTION_LOCAL_OPEN time. The code below breaks our ability to use proton-j
> for amqps messaging against our service.
> private void handleOpen(Reactor reactor, Event event)
> {
> sasl = transport.sasl();
> sasl.client();
> sasl.setMechanisms("ANONYMOUS");
> }
> I need these three lines of code to be optional in the global handler, or for
> a new API that allows a transport implementation to undo creating the Sasl
> layer.
> Something like:
>
> Transport transport = event.getConnection().getTransport();
> transport.disableSasl();
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1606) (Proton-J) Using Sasl needs to be optional
[
https://issues.apache.org/jira/browse/PROTON-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
tim taylor updated PROTON-1606:
---
Description:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
private void handleOpen(Reactor reactor, Event event)
{
sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
}
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
was:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
private void handleOpen(Reactor reactor, Event event)
{
\n
sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
\n
}
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
> (Proton-J) Using Sasl needs to be optional
> --
>
> Key: PROTON-1606
> URL: https://issues.apache.org/jira/browse/PROTON-1606
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.22.0
> Environment: N/A
>Reporter: tim taylor
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> In order for my application to use Proton-j for amqps messaging, the Sasl
> layer cannot be created by the global handler (IOHandler) at
> CONNECTION_LOCAL_OPEN time. The code below breaks our ability to use proton-j
> for amqps messaging against our service.
> private void handleOpen(Reactor reactor, Event event)
> {
> sasl = transport.sasl();
> sasl.client();
> sasl.setMechanisms("ANONYMOUS");
> }
> I need these three lines of code to be optional in the global handler, or for
> a new API that allows a transport implementation to undo creating the Sasl
> layer.
> Something like:
>
> Transport transport = event.getConnection().getTransport();
> transport.disableSasl();
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1606) (Proton-J) Using Sasl needs to be optional
[
https://issues.apache.org/jira/browse/PROTON-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
tim taylor updated PROTON-1606:
---
Description:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
private void handleOpen(Reactor reactor, Event event)
{
\n
sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
\n
}
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
was:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
private void handleOpen(Reactor reactor, Event event)
{
...
Sasl sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
...
}
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
> (Proton-J) Using Sasl needs to be optional
> --
>
> Key: PROTON-1606
> URL: https://issues.apache.org/jira/browse/PROTON-1606
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.22.0
> Environment: N/A
>Reporter: tim taylor
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> In order for my application to use Proton-j for amqps messaging, the Sasl
> layer cannot be created by the global handler (IOHandler) at
> CONNECTION_LOCAL_OPEN time. The code below breaks our ability to use proton-j
> for amqps messaging against our service.
> private void handleOpen(Reactor reactor, Event event)
> {
> \n
> sasl = transport.sasl();
> sasl.client();
> sasl.setMechanisms("ANONYMOUS");
> \n
> }
> I need these three lines of code to be optional in the global handler, or for
> a new API that allows a transport implementation to undo creating the Sasl
> layer.
> Something like:
>
> Transport transport = event.getConnection().getTransport();
> transport.disableSasl();
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1606) (Proton-J) Using Sasl needs to be optional
[
https://issues.apache.org/jira/browse/PROTON-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
tim taylor updated PROTON-1606:
---
Description:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
private void handleOpen(Reactor reactor, Event event)
{
...
Sasl sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
...
}
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
was:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
private void handleOpen(Reactor reactor, Event event) {
...
Sasl sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
...
}
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
> (Proton-J) Using Sasl needs to be optional
> --
>
> Key: PROTON-1606
> URL: https://issues.apache.org/jira/browse/PROTON-1606
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.22.0
> Environment: N/A
>Reporter: tim taylor
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> In order for my application to use Proton-j for amqps messaging, the Sasl
> layer cannot be created by the global handler (IOHandler) at
> CONNECTION_LOCAL_OPEN time. The code below breaks our ability to use proton-j
> for amqps messaging against our service.
> private void handleOpen(Reactor reactor, Event event)
> {
> ...
> Sasl sasl = transport.sasl();
> sasl.client();
> sasl.setMechanisms("ANONYMOUS");
> ...
> }
> I need these three lines of code to be optional in the global handler, or for
> a new API that allows a transport implementation to undo creating the Sasl
> layer.
> Something like:
>
> Transport transport = event.getConnection().getTransport();
> transport.disableSasl();
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1606) (Proton-J) Using Sasl needs to be optional
[
https://issues.apache.org/jira/browse/PROTON-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
tim taylor updated PROTON-1606:
---
Description:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
private void handleOpen(Reactor reactor, Event event)
{
...
Sasl sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
...
}
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
was:
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
private void handleOpen(Reactor reactor, Event event)
{
...
Sasl sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
...
}
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
> (Proton-J) Using Sasl needs to be optional
> --
>
> Key: PROTON-1606
> URL: https://issues.apache.org/jira/browse/PROTON-1606
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Affects Versions: proton-j-0.22.0
> Environment: N/A
>Reporter: tim taylor
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> In order for my application to use Proton-j for amqps messaging, the Sasl
> layer cannot be created by the global handler (IOHandler) at
> CONNECTION_LOCAL_OPEN time. The code below breaks our ability to use proton-j
> for amqps messaging against our service.
> private void handleOpen(Reactor reactor, Event event)
> {
>
> ...
> Sasl sasl = transport.sasl();
> sasl.client();
> sasl.setMechanisms("ANONYMOUS");
> ...
> }
> I need these three lines of code to be optional in the global handler, or for
> a new API that allows a transport implementation to undo creating the Sasl
> layer.
> Something like:
>
> Transport transport = event.getConnection().getTransport();
> transport.disableSasl();
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1606) (Proton-J) Using Sasl needs to be optional
tim taylor created PROTON-1606:
--
Summary: (Proton-J) Using Sasl needs to be optional
Key: PROTON-1606
URL: https://issues.apache.org/jira/browse/PROTON-1606
Project: Qpid Proton
Issue Type: Improvement
Components: proton-j
Affects Versions: proton-j-0.22.0
Environment: N/A
Reporter: tim taylor
In order for my application to use Proton-j for amqps messaging, the Sasl layer
cannot be created by the global handler (IOHandler) at CONNECTION_LOCAL_OPEN
time. The code below breaks our ability to use proton-j for amqps messaging
against our service.
private void handleOpen(Reactor reactor, Event event) {
...
Sasl sasl = transport.sasl();
sasl.client();
sasl.setMechanisms("ANONYMOUS");
...
}
I need these three lines of code to be optional in the global handler, or for a
new API that allows a transport implementation to undo creating the Sasl layer.
Something like:
Transport transport = event.getConnection().getTransport();
transport.disableSasl();
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-834) Create config tool to create/read/update/delete router config files
[ https://issues.apache.org/jira/browse/DISPATCH-834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16188422#comment-16188422 ] ASF subversion and git services commented on DISPATCH-834: -- Commit f163d38eebf8a0da0b085383096a32253c6cca87 in qpid-dispatch's branch refs/heads/config-read-write from [~eallen] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=f163d38 ] DISPATCH-834 Added 'apply to all routers' option to logs. Added log icon > Create config tool to create/read/update/delete router config files > --- > > Key: DISPATCH-834 > URL: https://issues.apache.org/jira/browse/DISPATCH-834 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Console >Affects Versions: 0.8.0 >Reporter: Ernest Allen >Assignee: Ernest Allen > > Create a UI and supporting program that reads/updates/writes/deletes router > config files. > It should at least: > - read all config files in a directory and display a topology > - create new directories to store config files > - create connectors/listeners between routers with correct host:port > - allow creating/editing/deleting of external > listeners/connectors/sslProfiles/log sections > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-332) Defining queue's name as tomcat resource conflichts resource definition
Bernhard Seidl created QPIDJMS-332:
--
Summary: Defining queue's name as tomcat resource conflichts
resource definition
Key: QPIDJMS-332
URL: https://issues.apache.org/jira/browse/QPIDJMS-332
Project: Qpid JMS
Issue Type: Improvement
Components: qpid-jms-client
Affects Versions: 0.25.0
Reporter: Bernhard Seidl
Since a few days i am trying to define a queue resource in Tomcat's
context.xml. The attribute "name" defines the jndi name. Looking at
org.apache.qpid.jms.JmsDestination
the attribute is called "name", too. This seems to me as a naming conflict. I
tried to use the attribute "physicalName" due to the fact that some of the
classes are based on ActiveMQ. However I am not sure if I am missing a point
somewhere else:
This is my setup:
Context.xml
{code:xml}
{code}
Init-code using spring:
{code:java}
@Configuration
@EnableJms
public class MessagingConfiguration {
@Bean
public ConnectionFactory connectionFactory() throws NamingException {
ConnectionFactory connectionFactory = (new JndiTemplate())
.lookup("java:/comp/env/jms/ConnectionFactory",ConnectionFactory.class);
return connectionFactory;
}
@Bean
public DestinationResolver destinationResolver() {
JndiDestinationResolver jdr = new JndiDestinationResolver();
try {
// testing
Queue q =
jdr.getJndiTemplate().lookup("java:/comp/env/jms/queue", Queue.class);
System.out.println("A: " + q.getQueueName());
System.out.println("B: " + (new
JndiTemplate()).lookup("java:/comp/env/jms/queue",
Destination.class).getClass());
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
return jdr;
}
@Bean
public JmsTemplate jmsTemplate() throws NamingException {
JmsTemplate template = new JmsTemplate();
template.setConnectionFactory(connectionFactory());
template.setDestinationResolver(destinationResolver());
return template;
}
}
{code}
Running the code prints out:
{noformat}
...
A:
B: class org.apache.qpid.jms.JmsQueue
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7942) [Java Broker] AppenderUtilsTest does not work on Windows
[ https://issues.apache.org/jira/browse/QPID-7942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16188329#comment-16188329 ] ASF subversion and git services commented on QPID-7942: --- Commit 0e2f1e003e1e8d2e653453587de83d192991ca40 in qpid-broker-j's branch refs/heads/master from [~godfrer] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=0e2f1e0 ] QPID-7942 : [Java Broker] AppenderUtilsTest does not work on Windows ... and this time update the right test > [Java Broker] AppenderUtilsTest does not work on Windows > > > Key: QPID-7942 > URL: https://issues.apache.org/jira/browse/QPID-7942 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > > AppenderUtilsTest fails if it is unable to change the permissions on a newly > created temporary director so that it is not writable. It seems that it is > not possible to do so in Windows (10). The inability to do so does not > reflect any error in the Qpid code (perhaps the test could try a different > mechanism for creating a directory that cannot be written to?) and so the > test should not fail. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7937) [Java Broker] [AMQP1.0] Message grouping feature does not utilise group-id from the message properties
[
https://issues.apache.org/jira/browse/QPID-7937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16188314#comment-16188314
]
Keith Wall commented on QPID-7937:
--
Rob, I think your changes look good. I had a couple of comments, which (I
hope) will be uncontroversial. I have applied those in b9409b6.
> [Java Broker] [AMQP1.0] Message grouping feature does not utilise group-id
> from the message properties
> --
>
> Key: QPID-7937
> URL: https://issues.apache.org/jira/browse/QPID-7937
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.1
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> The AMQP 1.0 specification provides a {{group-id}} field within the immutable
> message properties to pass the message grouping key. When enabled, the
> message grouping feature should be utilising this field the key for message
> grouping purposes. Currently the implementation looks for an application
> header (behaviour inherited from the older protocols).
> As discussed here:
> http://qpid.2158936.n2.nabble.com/Consumer-affinity-JMSXGroupID-AMQP-1-0-tc7667309.html
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7937) [Java Broker] [AMQP1.0] Message grouping feature does not utilise group-id from the message properties
[
https://issues.apache.org/jira/browse/QPID-7937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall reassigned QPID-7937:
Assignee: Rob Godfrey (was: Keith Wall)
> [Java Broker] [AMQP1.0] Message grouping feature does not utilise group-id
> from the message properties
> --
>
> Key: QPID-7937
> URL: https://issues.apache.org/jira/browse/QPID-7937
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.1
>Reporter: Keith Wall
>Assignee: Rob Godfrey
> Fix For: qpid-java-broker-7.0.0
>
>
> The AMQP 1.0 specification provides a {{group-id}} field within the immutable
> message properties to pass the message grouping key. When enabled, the
> message grouping feature should be utilising this field the key for message
> grouping purposes. Currently the implementation looks for an application
> header (behaviour inherited from the older protocols).
> As discussed here:
> http://qpid.2158936.n2.nabble.com/Consumer-affinity-JMSXGroupID-AMQP-1-0-tc7667309.html
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7937) [Java Broker] [AMQP1.0] Message grouping feature does not utilise group-id from the message properties
[
https://issues.apache.org/jira/browse/QPID-7937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall reassigned QPID-7937:
Assignee: Keith Wall
> [Java Broker] [AMQP1.0] Message grouping feature does not utilise group-id
> from the message properties
> --
>
> Key: QPID-7937
> URL: https://issues.apache.org/jira/browse/QPID-7937
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.1
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> The AMQP 1.0 specification provides a {{group-id}} field within the immutable
> message properties to pass the message grouping key. When enabled, the
> message grouping feature should be utilising this field the key for message
> grouping purposes. Currently the implementation looks for an application
> header (behaviour inherited from the older protocols).
> As discussed here:
> http://qpid.2158936.n2.nabble.com/Consumer-affinity-JMSXGroupID-AMQP-1-0-tc7667309.html
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7937) [Java Broker] [AMQP1.0] Message grouping feature does not utilise group-id from the message properties
[
https://issues.apache.org/jira/browse/QPID-7937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7937:
-
Status: Reviewable (was: In Progress)
> [Java Broker] [AMQP1.0] Message grouping feature does not utilise group-id
> from the message properties
> --
>
> Key: QPID-7937
> URL: https://issues.apache.org/jira/browse/QPID-7937
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.1
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> The AMQP 1.0 specification provides a {{group-id}} field within the immutable
> message properties to pass the message grouping key. When enabled, the
> message grouping feature should be utilising this field the key for message
> grouping purposes. Currently the implementation looks for an application
> header (behaviour inherited from the older protocols).
> As discussed here:
> http://qpid.2158936.n2.nabble.com/Consumer-affinity-JMSXGroupID-AMQP-1-0-tc7667309.html
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7942) [Java Broker] AppenderUtilsTest does not work on Windows
[ https://issues.apache.org/jira/browse/QPID-7942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16188312#comment-16188312 ] ASF subversion and git services commented on QPID-7942: --- Commit 2978c12887fbe5b816911362003c98157d659d95 in qpid-broker-j's branch refs/heads/master from [~godfrer] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=2978c12 ] QPID-7942 - Fix typo > [Java Broker] AppenderUtilsTest does not work on Windows > > > Key: QPID-7942 > URL: https://issues.apache.org/jira/browse/QPID-7942 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > > AppenderUtilsTest fails if it is unable to change the permissions on a newly > created temporary director so that it is not writable. It seems that it is > not possible to do so in Windows (10). The inability to do so does not > reflect any error in the Qpid code (perhaps the test could try a different > mechanism for creating a directory that cannot be written to?) and so the > test should not fail. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7942) [Java Broker] AppenderUtilsTest does not work on Windows
[ https://issues.apache.org/jira/browse/QPID-7942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16188310#comment-16188310 ] ASF subversion and git services commented on QPID-7942: --- Commit 556fa10dc7279c2d60d14362da90163d20fcdefa in qpid-broker-j's branch refs/heads/master from [~godfrer] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=556fa10 ] QPID-7942 : [Java Broker] AppenderUtilsTest does not work on Windows assumeThat does not work on old-style (JUnit 3) test cases > [Java Broker] AppenderUtilsTest does not work on Windows > > > Key: QPID-7942 > URL: https://issues.apache.org/jira/browse/QPID-7942 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > > AppenderUtilsTest fails if it is unable to change the permissions on a newly > created temporary director so that it is not writable. It seems that it is > not possible to do so in Windows (10). The inability to do so does not > reflect any error in the Qpid code (perhaps the test could try a different > mechanism for creating a directory that cannot be written to?) and so the > test should not fail. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7937) [Java Broker] [AMQP1.0] Message grouping feature does not utilise group-id from the message properties
[
https://issues.apache.org/jira/browse/QPID-7937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16188294#comment-16188294
]
ASF subversion and git services commented on QPID-7937:
---
Commit b9409b6c6414c7bbd1a251e637953150264a9836 in qpid-broker-j's branch
refs/heads/master from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=b9409b6 ]
QPID-7937: [Java Broker] Rename Queue#messageGroupKey to
#messageGroupKeyOverride to emphasise that the attribute is now optional
* Corresponding UI, converter and upgrader changes.
* On update/converter remove messageGroupKey of JMSXGroupId so that default is
used
* Changed MessageGroupQueueTest to avoid using AMQSession.
> [Java Broker] [AMQP1.0] Message grouping feature does not utilise group-id
> from the message properties
> --
>
> Key: QPID-7937
> URL: https://issues.apache.org/jira/browse/QPID-7937
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.0, qpid-java-6.1
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> The AMQP 1.0 specification provides a {{group-id}} field within the immutable
> message properties to pass the message grouping key. When enabled, the
> message grouping feature should be utilising this field the key for message
> grouping purposes. Currently the implementation looks for an application
> header (behaviour inherited from the older protocols).
> As discussed here:
> http://qpid.2158936.n2.nabble.com/Consumer-affinity-JMSXGroupID-AMQP-1-0-tc7667309.html
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1605) Use a mutex instead of atomics for broader platform support
Justin Ross created PROTON-1605: --- Summary: Use a mutex instead of atomics for broader platform support Key: PROTON-1605 URL: https://issues.apache.org/jira/browse/PROTON-1605 Project: Qpid Proton Issue Type: Improvement Components: cpp-binding Reporter: Justin Ross Assignee: Alan Conway Fix For: proton-c-0.18.0 We currently make limited use of atomics for multithreaded IO, and some of our target platforms don't support atomics. Use mutexes instead. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1560) Cannot install qpid_proton-0.18.0.gem
[
https://issues.apache.org/jira/browse/PROTON-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16188180#comment-16188180
]
ASF subversion and git services commented on PROTON-1560:
-
Commit 9729f3bd954432c62039a0e3fb11a0cb144337ab in qpid-proton's branch
refs/heads/master from [~aconway]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=9729f3b ]
PROTON-1560: ruby: fix cmake test names
> Cannot install qpid_proton-0.18.0.gem
> -
>
> Key: PROTON-1560
> URL: https://issues.apache.org/jira/browse/PROTON-1560
> Project: Qpid Proton
> Issue Type: Bug
> Components: ruby-binding
>Reporter: Alan Conway
>Assignee: Alan Conway
> Fix For: proton-c-0.18.0
>
>
> Snapshot of master at commit 8c3ba5.
> When using these specific flags, compilation fails:
> CONFIGURE_ARGS='--with-cflags='\''-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
> -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4
> -grecord-gcc-switches -m64 -mtune=generic'\'' '
> + gem install -V --local --install-dir ./usr/share/gems --bindir ./usr/bin
> --force --document=ri,rdoc qpid_proton-0.18.0.gem
>
> gcc -I. -I/usr/include -I/usr/include/ruby/backward -I/usr/include -I.
> -DHAVE_PROTON_ENGINE_H -DHAVE_PROTON_MESSAGE_H -DHAVE_PROTON_SASL_H
> -DHAVE_PROTON_MESSENGER_H-fPIC -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
> -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4
> -grecord-gcc-switches -m64 -mtune=generic -DRUBY20 -m64 -o cproton.o -c
> cproton.c
> Linked Applications
> JBoss Issue Tracker
> Dashboards
> Projects
> Issues
> Boards
> Portfolio
> Create
> Help
> Administration
> User profile for Alan Conway
> AMQ ClientsIcon indicating the project type
> AMQ Clients
> A-MQ Clients
> Backlog
> Active sprints
> Releases
> Reports
> Issues
> Components
> Uploaded image for project: 'AMQ Clients'
> AMQ ClientsENTMQCL-530
> Cannot install qpid_proton-0.18.0.gem
> Edit
> Comment
> Assign
> More
> Ready for Dev
> Closed
> Export
> Details
> Type:
> Task
> Status:
> Ready for Triage (View Workflow)
> Priority:
> Major
> Resolution:
> Unresolved
> Affects Version/s:
> Future GA
> Fix Version/s:
> None
> Component/s:
> proton-c
> Labels:
> None
> Environment:
> RHEL 7, RPM Build
> Description
> Snapshot of master at commit 8c3ba5.
> When using these specific flags, compilation fails:
> CONFIGURE_ARGS='--with-cflags='\''-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
> -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4
> -grecord-gcc-switches -m64 -mtune=generic'\'' '
> + gem install -V --local --install-dir ./usr/share/gems --bindir ./usr/bin
> --force --document=ri,rdoc qpid_proton-0.18.0.gem
>
> gcc -I. -I/usr/include -I/usr/include/ruby/backward -I/usr/include -I.
> -DHAVE_PROTON_ENGINE_H -DHAVE_PROTON_MESSAGE_H -DHAVE_PROTON_SASL_H
> -DHAVE_PROTON_MESSENGER_H -fPIC -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
> -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4
> -grecord-gcc-switches -m64 -mtune=generic -DRUBY20 -m64 -o cproton.o -c
> cproton.c
>
> cproton.c:6540:12: warning: 'check_trace' defined but not used
> [-Wunused-function]
> static int check_trace(int x) {
> ^
> make: *** [cproton.o] Error 1
> ERROR: Error installing qpid_proton-0.18.0.gem:
> ERROR: Failed to build gem native extension.
> Building has failed. See above output for more information on the failure.
> Attachments
> Drop files to attach, or
> Activity
> All
> Comments
> Work Log
> History
> Activity
> Links Hierarchy
> Linked Cases
> There are no comments yet on this issue.
> Comment
> People
> Assignee:
> aconway Alan Conway
> Reporter:
> iboverma Irina Boverman
> Votes:
> 0 Vote for this issue
> Watchers:
> 1
> Start watching this issue
> Dates
> Created:
> 4 days ago
> Updated:
> 2 days ago
> Agile
> View on Board
>
> cproton.c:6540:12: warning: 'check_trace' defined but not used
> [-Wunused-function]
> static int check_trace(int x) {
> ^
> make: *** [cproton.o] Error 1
> ERROR: Error installing qpid_proton-0.18.0.gem:
> ERROR: Failed to build gem native extension.
> Building has failed. See above output for more information on the failure.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1604) Windows C++ prefers std::endl to newlines
[ https://issues.apache.org/jira/browse/PROTON-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16188059#comment-16188059 ] Andrew Stitcher commented on PROTON-1604: - Instead of blithely changing all "\n" character sequences it would make more sense to only replace the ones that actually need flushing. OR Probably better to just add std::flush in places where missing output is a problem. Also note that std::cerr flushes automatically in any case so doesn't need std::endl, only std::cout would need std::endl. > Windows C++ prefers std::endl to newlines > - > > Key: PROTON-1604 > URL: https://issues.apache.org/jira/browse/PROTON-1604 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding >Affects Versions: proton-c-0.18.0 > Environment: Visual Studio >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: proton-c-0.18.0 > > > Using C newline escaped char sequence can result in mysteriously missing > output. > Use std::endl instead of \\n. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-551) disconnect connections that do not complete initial protocol handshake within a given time
[ https://issues.apache.org/jira/browse/DISPATCH-551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reassigned DISPATCH-551: - Assignee: Ted Ross > disconnect connections that do not complete initial protocol handshake within > a given time > --- > > Key: DISPATCH-551 > URL: https://issues.apache.org/jira/browse/DISPATCH-551 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Gordon Sim >Assignee: Ted Ross > Fix For: 1.0.0 > > > Prevents lots of file handles being used without having to authenticate. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-785) Add accessor in C to obtain routing-protocol-version for an inter-router connection
[ https://issues.apache.org/jira/browse/DISPATCH-785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-785: -- Fix Version/s: (was: 1.0.0) 1.1.0 > Add accessor in C to obtain routing-protocol-version for an inter-router > connection > --- > > Key: DISPATCH-785 > URL: https://issues.apache.org/jira/browse/DISPATCH-785 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Routing Engine >Reporter: Ted Ross >Assignee: Ted Ross > Fix For: 1.1.0 > > > For backward compatibility, components in C will need access to the protocol > version of neighboring routers. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1397) 0.18.0 release tasks
[ https://issues.apache.org/jira/browse/PROTON-1397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16187890#comment-16187890 ] ASF subversion and git services commented on PROTON-1397: - Commit 732961703812096ccd912768ca023a376bead73b in qpid-proton's branch refs/heads/master from [~gemmellr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=7329617 ] PROTON-1397: give the release process notes an update > 0.18.0 release tasks > > > Key: PROTON-1397 > URL: https://issues.apache.org/jira/browse/PROTON-1397 > Project: Qpid Proton > Issue Type: Task > Components: proton-c, release >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: proton-c-0.18.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7932) [Java Broker, AMQP 1.0] Improve Error handling when decoding
[ https://issues.apache.org/jira/browse/QPID-7932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16187878#comment-16187878 ] ASF subversion and git services commented on QPID-7932: --- Commit a6a02baa7e5c85c391750c5147a37e9eae343b00 in qpid-broker-j's branch refs/heads/master from [~lorenz.quack] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=a6a02ba ] QPID-7932: [Java Broker, AMQP 1.0] Further decoding improvements > [Java Broker, AMQP 1.0] Improve Error handling when decoding > > > Key: QPID-7932 > URL: https://issues.apache.org/jira/browse/QPID-7932 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Lorenz Quack > Fix For: qpid-java-broker-7.0.0 > > > The AMQP 1.0 deserialization of composite types does currently not do proper > error handling. > This results in CONNECTION-FORCED errors when encountering a problem. > This should be improved to result in proper DECODE-ERROR. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7940) [Java Broker] JSON context substitution does not work with nested variables
[
https://issues.apache.org/jira/browse/QPID-7940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16187851#comment-16187851
]
Keith Wall commented on QPID-7940:
--
Change looks reasonable to me.
> [Java Broker] JSON context substitution does not work with nested variables
> ---
>
> Key: QPID-7940
> URL: https://issues.apache.org/jira/browse/QPID-7940
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: qpid-java-broker-7.0.0
>
>
> A context value of the form $\{json:FOO\} is intended to escape the value of
> FOO to be usable within a JSON string, however if the value of $\{FOO\}
> interpolates first into $\{BAR\} then the json substitution is not applied to
> the interpolated value of $\{BAR\}.
> Since $\{qpid.work_dir\} is now defined as defaulted to $\{QPID_WORK\} and
> the default for a JsonVirtualHostNode.getPreferenceStoreAttributes() contains
> "$\{json:qpid.work_dir\}", and a (Windows) directory is likely to contain
> characters needing escaping... The broker currently doesn't work on Windows
> with a JsonVirtualHostNode
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7940) [Java Broker] JSON context substitution does not work with nested variables
[
https://issues.apache.org/jira/browse/QPID-7940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall resolved QPID-7940.
--
Resolution: Fixed
> [Java Broker] JSON context substitution does not work with nested variables
> ---
>
> Key: QPID-7940
> URL: https://issues.apache.org/jira/browse/QPID-7940
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: qpid-java-broker-7.0.0
>
>
> A context value of the form $\{json:FOO\} is intended to escape the value of
> FOO to be usable within a JSON string, however if the value of $\{FOO\}
> interpolates first into $\{BAR\} then the json substitution is not applied to
> the interpolated value of $\{BAR\}.
> Since $\{qpid.work_dir\} is now defined as defaulted to $\{QPID_WORK\} and
> the default for a JsonVirtualHostNode.getPreferenceStoreAttributes() contains
> "$\{json:qpid.work_dir\}", and a (Windows) directory is likely to contain
> characters needing escaping... The broker currently doesn't work on Windows
> with a JsonVirtualHostNode
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7933) [Java Broker] Changes made to existing durable children of virtualhost not recorded to the configuration store after a virtualhost restart
[ https://issues.apache.org/jira/browse/QPID-7933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7933: - Fix Version/s: qpid-java-broker-7.0.0 > [Java Broker] Changes made to existing durable children of virtualhost not > recorded to the configuration store after a virtualhost restart > -- > > Key: QPID-7933 > URL: https://issues.apache.org/jira/browse/QPID-7933 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-broker-7.0.0 > > > If a *virtualhost* is stopped, the object's children are closed and evacuated > from memory. On restart, the children are recovered from the store. > However, the restart path AbstractVirtualHost#onRestart fails to reinstall > the StoreConfigurationChangeListener on the recovered children. The effect > of this is that subsequent changes made to *existing* durable children (for > instance, a queue's alert threshold) are not persisted to the configuration > store. > The persistence of newly added objects (or the deletion of existing objects) > is not affected. This is because the VirtualHost still has its > StoreConfigurationChangeListener intact. (The virtualhost is not closed > during a restart). > A restart at the virtualhostnode level does not suffer this problem. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7935) [Java Broker] [ACL] Allow legacy ACL rule set to specify a default result of defer
[
https://issues.apache.org/jira/browse/QPID-7935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7935:
-
Fix Version/s: qpid-java-broker-7.0.0
> [Java Broker] [ACL] Allow legacy ACL rule set to specify a default result of
> defer
> --
>
> Key: QPID-7935
> URL: https://issues.apache.org/jira/browse/QPID-7935
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> When access control providers are installed at both the Broker and
> VirtualHost, the one at the VirtualHost needs to DEFER if no decision is made
> about an access decision. This gives the Broker's access control provider
> the opportunity to make a decision instead.
> Currently, the legacy ACL file format supports a CONFIG directive that allows
> the default result of the ruleset to be configured as {{ALLOW}} or {{DENY}},
> but not {{DEFER}}. If no CONFIG directive is specified the default result is
> always {{DENY}}.
> If the user is using RuleBasedVirtualHostAccessControlProvider#loadFromFile
> to populate their virtualhost rule-set, the users has to additionally
> remember to reset the {{defaultResult}} to {{DEFER}} otherwise the
> co-operation between Broker/VirtualHost will be broken.
> If the legacy ACL file format were to allow a CONFIG directive specifying
> DEFER, then this would eliminate the extra step.
> The suggested changes:
> # Change the legacy ACL file format to allow CONFIG to specify a default
> result of DEFER.
> # Improve AbstractCommonRuleBasedAccessControlProvider#extractRules to that
> it writes a CONFIG directive within the default result, if it is not the
> default.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7938) [Java Broker] Closing messaging connection logs "Failed to register with selector for connection" at DEBUG
[ https://issues.apache.org/jira/browse/QPID-7938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7938: - Fix Version/s: Future > [Java Broker] Closing messaging connection logs "Failed to register with > selector for connection" at DEBUG > -- > > Key: QPID-7938 > URL: https://issues.apache.org/jira/browse/QPID-7938 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.0, qpid-java-6.1, qpid-java-broker-7.0.0 >Reporter: Keith Wall >Priority: Minor > Fix For: Future > > > At DEBUG level the following stack trace is logged at DEBUG when a connection > is closed. There is no known functional impact, but it is an annoyance. > 2017-09-26 15:49:55,569 DEBUG [Selector-Port-AMQP] (o.a.q.s.t.SelectorThread) > - Failed to register with selector for connection [NonBlockingConnection > /127.0.0.1:51605]. Connection is probably being closed by peer. > java.nio.channels.ClosedChannelException: null > at > java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:197) > at > org.apache.qpid.server.transport.SelectorThread$SelectionTask.processUnscheduledConnections(SelectorThread.java:150) > at > org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:333) > at > org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97) > at > org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:521) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7589) [Java Broker] Allow the creation of temporary addresses on the $management synthetic vhost for the purpose of replyTo
[ https://issues.apache.org/jira/browse/QPID-7589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7589: - Fix Version/s: Future > [Java Broker] Allow the creation of temporary addresses on the $management > synthetic vhost for the purpose of replyTo > - > > Key: QPID-7589 > URL: https://issues.apache.org/jira/browse/QPID-7589 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Fix For: Future > > > Allow temporary addresses (that can be received from but not sent to) to be > created in the $management synthetic vhost. Additionally have the management > node able to respond to these addresses when the replyTo is set to use them. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7943) [Java Broker] The result of the interpolation this: differs
[
https://issues.apache.org/jira/browse/QPID-7943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7943:
-
Fix Version/s: Future
> [Java Broker] The result of the interpolation this: differs
> ---
>
> Key: QPID-7943
> URL: https://issues.apache.org/jira/browse/QPID-7943
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Keith Wall
>Priority: Minor
> Fix For: Future
>
>
> The Broker's string resolution system
> {{org.apache.qpid.server.util.Strings#expand()}}} uses an
> {{OwnAttributeResolver}} to allow an object's attributes to be interpolated
> into string values. This is provided by the {{this:}} syntax.
> I have noticed that the value yielded by the expansion {{this: name>}} within a context variable varies depending on where the context
> variable is defined.
> Imagine a context variable {{foo}} set with the value "{{${this:bar\}}}".
> # If the context variable comes from the environment or from a managed
> context default, the {{this:}} resolves at the target object. (i.e.
> targetObject.getContextValue(String.class, "foo") yields a value equivalent
> to targetObject.getAttribute("bar")).
> # If the context variable is set on a ancestor object, the resolution takes
> place at the ancestor ie. (i.e. targetObject.getContextValue(String.class,
> "foo") yields a value equivalent to
> targetObject.getParent()...getAttribute("bar"})
> This behaviour surprises me. I don't think it leads to a current functional
> issue. I think all our existing usages of {{this:}} are within managed
> context defaults (fall into category 1).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7942) [Java Broker] AppenderUtilsTest does not work on Windows
[ https://issues.apache.org/jira/browse/QPID-7942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16187832#comment-16187832 ] ASF subversion and git services commented on QPID-7942: --- Commit af10b7e4b57f058ab94a439e0a899fe7f1f6a3b2 in qpid-broker-j's branch refs/heads/master from [~godfrer] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=af10b7e ] QPID-7942 : [Java Broker] AppenderUtilsTest does not work on Windows Address comments from [~gemmellr] > [Java Broker] AppenderUtilsTest does not work on Windows > > > Key: QPID-7942 > URL: https://issues.apache.org/jira/browse/QPID-7942 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > > AppenderUtilsTest fails if it is unable to change the permissions on a newly > created temporary director so that it is not writable. It seems that it is > not possible to do so in Windows (10). The inability to do so does not > reflect any error in the Qpid code (perhaps the test could try a different > mechanism for creating a directory that cannot be written to?) and so the > test should not fail. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7942) [Java Broker] AppenderUtilsTest does not work on Windows
[ https://issues.apache.org/jira/browse/QPID-7942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16187805#comment-16187805 ] Robbie Gemmell commented on QPID-7942: -- Won't the change mean it creates a directory but then doesn't delete it if it cant change the permission? Also, would using an assumption check to skip the remainder of the test be better than letting it succeed without actually testing anything? > [Java Broker] AppenderUtilsTest does not work on Windows > > > Key: QPID-7942 > URL: https://issues.apache.org/jira/browse/QPID-7942 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > > AppenderUtilsTest fails if it is unable to change the permissions on a newly > created temporary director so that it is not writable. It seems that it is > not possible to do so in Windows (10). The inability to do so does not > reflect any error in the Qpid code (perhaps the test could try a different > mechanism for creating a directory that cannot be written to?) and so the > test should not fail. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7944) [Java Broker] [AMQP1.0] Observing a message with a null object property cause 500 error to be sent to the browser
[
https://issues.apache.org/jira/browse/QPID-7944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7944:
-
Summary: [Java Broker] [AMQP1.0] Observing a message with a null object
property cause 500 error to be sent to the browser (was: [Java Broker]
[AMQP1.0] Observing a message with a null object property cause 500 )
> [Java Broker] [AMQP1.0] Observing a message with a null object property cause
> 500 error to be sent to the browser
> -
>
> Key: QPID-7944
> URL: https://issues.apache.org/jira/browse/QPID-7944
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Keith Wall
>Priority: Critical
> Fix For: qpid-java-broker-7.0.0
>
>
> # Start the Broker
> # Configured HTTPS
> # Send an JMS message from Qpid JMS Client with setObjectProperty("mynull",
> null)
> # Try to observe the message using Management (using HTTPS).
> The browser receives a 500 and the following is logged.
> {noformat}
> 2017-10-02 08:53:23,844 ERROR [qtp163439984-248]
> (o.a.q.s.m.p.f.ExceptionHandlingFilter) - Unexpected exception in servlet
> '/api/latest/queue/default/default/queue/getMessageContent':
> java.lang.NullPointerException: null
> at java.util.HashMap.merge(HashMap.java:1224)
> at java.util.stream.Collectors.lambda$toMap$58(Collectors.java:1320)
> at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> at
> org.apache.qpid.server.message.internal.InternalMessageHeader.(InternalMessageHeader.java:94)
> at
> org.apache.qpid.server.message.internal.InternalMessage.convert(InternalMessage.java:220)
> at
> org.apache.qpid.server.protocol.v1_0.MessageConverter_v1_0_to_Internal.convert(MessageConverter_v1_0_to_Internal.java:69)
> at
> org.apache.qpid.server.protocol.v1_0.MessageConverter_v1_0_to_Internal.convert(MessageConverter_v1_0_to_Internal.java:39)
> at
> org.apache.qpid.server.queue.AbstractQueue.createMessageContent(AbstractQueue.java:3308)
> at
> org.apache.qpid.server.queue.AbstractQueue.getMessageContent(AbstractQueue.java:3281)
> at
> org.apache.qpid.server.queue.StandardQueueImplWithAccessChecking.getMessageContent(StandardQueueImplWithAccessChecking.java:102)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.qpid.server.model.ConfiguredObjectMethodOperation.perform(ConfiguredObjectMethodOperation.java:125)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.doOperation(RestServlet.java:620)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.doGet(RestServlet.java:205)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet.doGet(AbstractServlet.java:122)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.service(RestServlet.java:365)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:841)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)
> at
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter$1.run(AuthenticationCheckFilter.java:157)
> at
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter$1.run(AuthenticationCheckFilter.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter.doFilterChainAs(AuthenticationCheckFilter.java:152)
> at
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter.doFilter(AuthenticationCheckFilter.java:122)
> at
> org.eclipse.
[jira] [Created] (QPID-7944) [Java Broker] [AMQP1.0] Observing a message with a null object property cause 500
Keith Wall created QPID-7944:
Summary: [Java Broker] [AMQP1.0] Observing a message with a null
object property cause 500
Key: QPID-7944
URL: https://issues.apache.org/jira/browse/QPID-7944
Project: Qpid
Issue Type: Bug
Components: Java Broker
Reporter: Keith Wall
Priority: Critical
# Start the Broker
# Configured HTTPS
# Send an JMS message from Qpid JMS Client with setObjectProperty("mynull",
null)
# Try to observe the message using Management (using HTTPS).
The browser receives a 500 and the following is logged.
{noformat}
2017-10-02 08:53:23,844 ERROR [qtp163439984-248]
(o.a.q.s.m.p.f.ExceptionHandlingFilter) - Unexpected exception in servlet
'/api/latest/queue/default/default/queue/getMessageContent':
java.lang.NullPointerException: null
at java.util.HashMap.merge(HashMap.java:1224)
at java.util.stream.Collectors.lambda$toMap$58(Collectors.java:1320)
at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169)
at java.util.Iterator.forEachRemaining(Iterator.java:116)
at
java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
at
java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at
java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
at
org.apache.qpid.server.message.internal.InternalMessageHeader.(InternalMessageHeader.java:94)
at
org.apache.qpid.server.message.internal.InternalMessage.convert(InternalMessage.java:220)
at
org.apache.qpid.server.protocol.v1_0.MessageConverter_v1_0_to_Internal.convert(MessageConverter_v1_0_to_Internal.java:69)
at
org.apache.qpid.server.protocol.v1_0.MessageConverter_v1_0_to_Internal.convert(MessageConverter_v1_0_to_Internal.java:39)
at
org.apache.qpid.server.queue.AbstractQueue.createMessageContent(AbstractQueue.java:3308)
at
org.apache.qpid.server.queue.AbstractQueue.getMessageContent(AbstractQueue.java:3281)
at
org.apache.qpid.server.queue.StandardQueueImplWithAccessChecking.getMessageContent(StandardQueueImplWithAccessChecking.java:102)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.qpid.server.model.ConfiguredObjectMethodOperation.perform(ConfiguredObjectMethodOperation.java:125)
at
org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.doOperation(RestServlet.java:620)
at
org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.doGet(RestServlet.java:205)
at
org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet.doGet(AbstractServlet.java:122)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at
org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.service(RestServlet.java:365)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at
org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:841)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)
at
org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter$1.run(AuthenticationCheckFilter.java:157)
at
org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter$1.run(AuthenticationCheckFilter.java:153)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at
org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter.doFilterChainAs(AuthenticationCheckFilter.java:152)
at
org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter.doFilter(AuthenticationCheckFilter.java:122)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1621)
at
org.apache.qpid.server.management.plugin.filter.LoggingFilter.doFilter(LoggingFilter.java:63)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1621)
at
org.apache.qpid.server.management.plugin.filter.ForbiddingTraceFilter.doFilter(ForbiddingTraceFilter.java:65)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1621)
at
org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:308)
[jira] [Updated] (QPID-7944) [Java Broker] [AMQP1.0] Observing a message with a null object property cause 500
[
https://issues.apache.org/jira/browse/QPID-7944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7944:
-
Fix Version/s: qpid-java-broker-7.0.0
> [Java Broker] [AMQP1.0] Observing a message with a null object property cause
> 500
> --
>
> Key: QPID-7944
> URL: https://issues.apache.org/jira/browse/QPID-7944
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Keith Wall
>Priority: Critical
> Fix For: qpid-java-broker-7.0.0
>
>
> # Start the Broker
> # Configured HTTPS
> # Send an JMS message from Qpid JMS Client with setObjectProperty("mynull",
> null)
> # Try to observe the message using Management (using HTTPS).
> The browser receives a 500 and the following is logged.
> {noformat}
> 2017-10-02 08:53:23,844 ERROR [qtp163439984-248]
> (o.a.q.s.m.p.f.ExceptionHandlingFilter) - Unexpected exception in servlet
> '/api/latest/queue/default/default/queue/getMessageContent':
> java.lang.NullPointerException: null
> at java.util.HashMap.merge(HashMap.java:1224)
> at java.util.stream.Collectors.lambda$toMap$58(Collectors.java:1320)
> at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> at
> java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> at
> org.apache.qpid.server.message.internal.InternalMessageHeader.(InternalMessageHeader.java:94)
> at
> org.apache.qpid.server.message.internal.InternalMessage.convert(InternalMessage.java:220)
> at
> org.apache.qpid.server.protocol.v1_0.MessageConverter_v1_0_to_Internal.convert(MessageConverter_v1_0_to_Internal.java:69)
> at
> org.apache.qpid.server.protocol.v1_0.MessageConverter_v1_0_to_Internal.convert(MessageConverter_v1_0_to_Internal.java:39)
> at
> org.apache.qpid.server.queue.AbstractQueue.createMessageContent(AbstractQueue.java:3308)
> at
> org.apache.qpid.server.queue.AbstractQueue.getMessageContent(AbstractQueue.java:3281)
> at
> org.apache.qpid.server.queue.StandardQueueImplWithAccessChecking.getMessageContent(StandardQueueImplWithAccessChecking.java:102)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.qpid.server.model.ConfiguredObjectMethodOperation.perform(ConfiguredObjectMethodOperation.java:125)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.doOperation(RestServlet.java:620)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.doGet(RestServlet.java:205)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet.doGet(AbstractServlet.java:122)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.service(RestServlet.java:365)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:841)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)
> at
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter$1.run(AuthenticationCheckFilter.java:157)
> at
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter$1.run(AuthenticationCheckFilter.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter.doFilterChainAs(AuthenticationCheckFilter.java:152)
> at
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter.doFilter(AuthenticationCheckFilter.java:122)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1621)
> at
> org.apache.qpid.server.management.plugin.filter.LoggingFilter.doFilter(LoggingFilter.java:63)
> at
> org.eclipse.jetty.servlet.ServletHandler$C
[jira] [Updated] (QPID-7943) [Java Broker] The result of the interpolation this: differs
[
https://issues.apache.org/jira/browse/QPID-7943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-7943:
-
Description:
The Broker's string resolution system
{{org.apache.qpid.server.util.Strings#expand()}}} uses an
{{OwnAttributeResolver}} to allow an object's attributes to be interpolated
into string values. This is provided by the {{this:}} syntax.
I have noticed that the value yielded by the expansion {{this:}} within a context variable varies depending on where the context
variable is defined.
Imagine a context variable {{foo}} set with the value "{{${this:bar\}}}".
# If the context variable comes from the environment or from a managed context
default, the {{this:}} resolves at the target object. (i.e.
targetObject.getContextValue(String.class, "foo") yields a value equivalent to
targetObject.getAttribute("bar")).
# If the context variable is set on a ancestor object, the resolution takes
place at the ancestor ie. (i.e. targetObject.getContextValue(String.class,
"foo") yields a value equivalent to
targetObject.getParent()...getAttribute("bar"})
This behaviour surprises me. I don't think it leads to a current functional
issue. I think all our existing usages of {{this:}} are within managed context
defaults (fall into category 1).
was:
The Broker's string resolution system
{{org.apache.qpid.server.util.Strings#expand()}}} uses an
{{OwnAttributeResolver}} to allow an object's attributes to be interpolated
into string values. This is provided by the {{this:}} syntax.
I have noticed that the value yielded by the expansion {{this:}} within a context variable varies depending on where the context
variable is defined.
Imagine a context variable foo set with the value "${this:bar}".
# If the context variable comes from the environment or from a managed context
default, the {{this:}} resolves at the target object. (i.e.
targetObject.getContextValue(String.class, "foo") yields a value equivalent to
targetObject.getAttribute("bar"}).
# If the context variable is set on a ancestor object, the resolution takes
place at the ancestor ie. (i.e. targetObject.getContextValue(String.class,
"foo") yields a value equivalent to
targetObject.getParent()...getAttribute("bar"})
This behaviour surprises me. I don't think it leads to a current functional
issue. I think all our existing usages of {{this:}} are within managed context
defaults (fall into category 1).
> [Java Broker] The result of the interpolation this: differs
> ---
>
> Key: QPID-7943
> URL: https://issues.apache.org/jira/browse/QPID-7943
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Keith Wall
>Priority: Minor
>
> The Broker's string resolution system
> {{org.apache.qpid.server.util.Strings#expand()}}} uses an
> {{OwnAttributeResolver}} to allow an object's attributes to be interpolated
> into string values. This is provided by the {{this:}} syntax.
> I have noticed that the value yielded by the expansion {{this: name>}} within a context variable varies depending on where the context
> variable is defined.
> Imagine a context variable {{foo}} set with the value "{{${this:bar\}}}".
> # If the context variable comes from the environment or from a managed
> context default, the {{this:}} resolves at the target object. (i.e.
> targetObject.getContextValue(String.class, "foo") yields a value equivalent
> to targetObject.getAttribute("bar")).
> # If the context variable is set on a ancestor object, the resolution takes
> place at the ancestor ie. (i.e. targetObject.getContextValue(String.class,
> "foo") yields a value equivalent to
> targetObject.getParent()...getAttribute("bar"})
> This behaviour surprises me. I don't think it leads to a current functional
> issue. I think all our existing usages of {{this:}} are within managed
> context defaults (fall into category 1).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7943) [Java Broker] The result of the interpolation this: differs
Keith Wall created QPID-7943:
Summary: [Java Broker] The result of the interpolation this:
differs
Key: QPID-7943
URL: https://issues.apache.org/jira/browse/QPID-7943
Project: Qpid
Issue Type: Bug
Components: Java Broker
Reporter: Keith Wall
Priority: Minor
The Broker's string resolution system
{{org.apache.qpid.server.util.Strings#expand()}}} uses an
{{OwnAttributeResolver}} to allow an object's attributes to be interpolated
into string values. This is provided by the {{this:}} syntax.
I have noticed that the value yielded by the expansion {{this:}} within a context variable varies depending on where the context
variable is defined.
Imagine a context variable foo set with the value "${this:bar}".
# If the context variable comes from the environment or from a managed context
default, the {{this:}} resolves at the target object. (i.e.
targetObject.getContextValue(String.class, "foo") yields a value equivalent to
targetObject.getAttribute("bar"}).
# If the context variable is set on a ancestor object, the resolution takes
place at the ancestor ie. (i.e. targetObject.getContextValue(String.class,
"foo") yields a value equivalent to
targetObject.getParent()...getAttribute("bar"})
This behaviour surprises me. I don't think it leads to a current functional
issue. I think all our existing usages of {{this:}} are within managed context
defaults (fall into category 1).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
