[jira] [Commented] (PROTON-1517) SyncRequestResponse(BlockingConnection).call() fails with timeout
[ https://issues.apache.org/jira/browse/PROTON-1517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120798#comment-16120798 ] Justin Ross commented on PROTON-1517: - I can reproduce this problem, but near as I can tell, it's not a bug in the python binding really. With print debugging, I see a numeric correlation ID (intentionally) sent in the request to the qpidd agent, and I see a string correlation ID returned. Everything works with the patch because it makes the correlation ID a string in every instance. My theory is that the qpidd qmf code assumes and requires string correlation IDs, and implicitly converts to a string internally, but it's hard for me to tell from the C++ code. [~tr...@redhat.com], is that a reasonable theory? > SyncRequestResponse(BlockingConnection).call() fails with timeout > - > > Key: PROTON-1517 > URL: https://issues.apache.org/jira/browse/PROTON-1517 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.17.0 > Environment: macOS Sierra 10.12.5 > Python 3.6.1 >Reporter: aikchar >Assignee: Justin Ross > Labels: easyfix, patch > Fix For: proton-c-0.18.0 > > > Send a QMFv2 message using SyncRequestResponse.call(). The response times out. > h2. Repro > This repro uses the example from > https://qpid.apache.org/releases/qpid-proton-0.17.0/proton/python/examples/sync_client.py.html. > {noformat} > $ python > Python 3.6.1 (default, Apr 24 2017, 09:59:45) > [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> address = > >>> 'amqps://REDACTED_USERNAME:REDACTED_PASSWORD@REDACTED_IP_ADDR:5672/qmf.default.direct' > >>> from proton import Url > >>> url = Url(address) > >>> > >>> from proton.utils import SyncRequestResponse, BlockingConnection > >>> client = SyncRequestResponse(BlockingConnection(url, timeout=15, > >>> target='qmf.default.direct', sasl_enabled=True, allowed_mechs='PLAIN'), > >>> 'qmf.default.direct') > >>> > >>> content = {'_what': 'OBJECT', '_schema_id': {'_class_name': 'queue'}} > >>> properties = {'x-amqp-0-10.app-id': 'qmf2', 'qmf.opcode': > >>> '_query_request', 'method': 'request'} > >>> > >>> from proton import Message > >>> m = Message(reply_to=client.receiver.remote_source.address, > >>> address=address, body=content, properties=properties, subject='broker') > >>> r = client.call(m) > Traceback (most recent call last): > File "", line 1, in > File > "/Users/hamza.sheikh/virtualenvs/flight-test-py36/lib/python3.6/site-packages/proton/utils.py", > line 400, in call > self.connection.wait(wakeup, msg="Waiting for response") > File > "/Users/hamza.sheikh/virtualenvs/flight-test-py36/lib/python3.6/site-packages/proton/utils.py", > line 288, in wait > raise Timeout(txt) > proton.Timeout: Connection > amqps://REDACTED_USERNAME:REDACTED_PASSWORD@REDACTED_IP_ADDR:5672/qmf.default.direct > timed out: Waiting for response > >>> > {noformat} > h2. Patch > Patch is to make sure correlation_id is a string. > {noformat} > $ git diff > diff --git a/proton-c/bindings/python/proton/utils.py > b/proton-c/bindings/python/proton/utils.py > index 05ef80df..528ce338 100644 > --- a/proton-c/bindings/python/proton/utils.py > +++ b/proton-c/bindings/python/proton/utils.py > @@ -349,7 +349,7 @@ class SyncRequestResponse(IncomingMessageHandler): > if not self.address and not request.address: > raise ValueError("Request message has no address: %s" % request) > request.reply_to = self.reply_to > -request.correlation_id = correlation_id = self.correlation_id.next() > +request.correlation_id = correlation_id = > str(self.correlation_id.next()) > self.sender.send(request) > def wakeup(): > return self.response and (self.response.correlation_id == > correlation_id) > {noformat} > After applying the patch, the response does not time out. > {noformat} > $ python > Python 3.6.1 (default, Apr 24 2017, 09:59:45) > [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> address = > >>> 'amqps://REDACTED_USERNAME:REDACTED_PASSWORD@REDACTED_IP_ADDR:5672/qmf.default.direct' > >>> from proton import Url > >>> url = Url(address) > >>> > >>> from proton.utils import SyncRequestResponse, BlockingConnection > >>> client = SyncRequestResponse(BlockingConnection(url, timeout=15, > >>> target='qmf.default.direct', sasl_enabled=True, allowed_mechs='PLAIN'), > >>> 'qmf.default.direct') > >>> > >>> content = {'_what': 'OBJECT', '_schema_id': {'_class_name': 'queue'}} > >>> properties = {'x-amqp-0-10.app-id':
[jira] [Created] (PROTON-1534) Python client BlockingConnection fails cleanup on LinkDetached exception with socket in close_wait and straggling pipe
Cliff Jansen created PROTON-1534: Summary: Python client BlockingConnection fails cleanup on LinkDetached exception with socket in close_wait and straggling pipe Key: PROTON-1534 URL: https://issues.apache.org/jira/browse/PROTON-1534 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.17.0, 0.16.0, 0.15.0, 0.14.0, 0.13.0, 0.12.0, 0.11.0, 0.10, 0.9 Reporter: Cliff Jansen Assignee: Cliff Jansen Fix For: proton-c-0.18.0 goferd tries to clean up after an interrupted receive operation, but the LinkDetached exception is not cleared from the BlockingConnection and the underlying C reactor fails to progress through its cleanup mechanism. When BlockingConnection.close() is called, the code should muscle through to full resource cleanup. The application is no longer interested in reactor events or exceptions. -- 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-803) refuse attach to undefined addresses
[ https://issues.apache.org/jira/browse/DISPATCH-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120662#comment-16120662 ] ASF GitHub Bot commented on DISPATCH-803: - Github user ganeshmurthy commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/185#discussion_r132308131 --- Diff: python/qpid_dispatch/management/qdrouter.json --- @@ -504,6 +504,13 @@ "deprecated": true, "description": "(DEPRECATED) This value is no longer used in the router.", "create": true +}, +"defaultDistribution": { +"type": ["multicast", "closest", "balanced", "forbidden"], +"description": "Default forwarding treatment for any address without a specified treatment. multicast - one copy of each message delivered to all subscribers; closest - messages delivered to only the closest subscriber; balanced - messages delivered to one subscriber with load balanced across subscribers; linkBalanced - for link-routing, link attaches balanced across destinations; forbidden - this address is forbidden, link attaches to an address of forbidden distribution will be rejected.", --- End diff -- Removed linkBalanced from comment > refuse attach to undefined addresses > > > Key: DISPATCH-803 > URL: https://issues.apache.org/jira/browse/DISPATCH-803 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Gordon Sim >Assignee: Ganesh Murthy > Fix For: 1.0.0 > > > At present, if you attach to an address in the router whose semantics have > not been specifically defined, you get balanced message routing semantics. > It would be useful to be able to configure the router such that it would > refuse links whose source/target was not explicitly defined. E.g. by being > able to configure the default semantics to be of type 'invalid' (or anything > similar). (Being able to explicitly blacklist certain addresses might also be > nice, but is a more exotic use case I think). > Messages sent through an anonymous link to these 'invalid' addresses would be > rejected. > -- 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
[GitHub] qpid-dispatch pull request #185: DISPATCH-803 - The following changes were m...
Github user ganeshmurthy commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/185#discussion_r132308131 --- Diff: python/qpid_dispatch/management/qdrouter.json --- @@ -504,6 +504,13 @@ "deprecated": true, "description": "(DEPRECATED) This value is no longer used in the router.", "create": true +}, +"defaultDistribution": { +"type": ["multicast", "closest", "balanced", "forbidden"], +"description": "Default forwarding treatment for any address without a specified treatment. multicast - one copy of each message delivered to all subscribers; closest - messages delivered to only the closest subscriber; balanced - messages delivered to one subscriber with load balanced across subscribers; linkBalanced - for link-routing, link attaches balanced across destinations; forbidden - this address is forbidden, link attaches to an address of forbidden distribution will be rejected.", --- End diff -- Removed linkBalanced from comment --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Issue Comment Deleted] (DISPATCH-803) refuse attach to undefined addresses
[ https://issues.apache.org/jira/browse/DISPATCH-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway updated DISPATCH-803: - Comment: was deleted (was: I want to back up a bit, I think my suggestion was not right. The original requirement is to prevent auto-creation of addresses. This proposal sounds like the router will auto-create *forbidden* addresses which is quite different: Not auto-creating address X means client connecting/sending to X gets a 'not-found' error. Creating X with {distribution=forbidden} creates a permanently unusable address named X, which would have to be explicitly deleted or modified to use it later. We could make a special case meaning for defaultDistribution=forbidden but that is confusing. I think separate config is better: autoLink = True|False # default True autoCreateDistribution # default balanced With these two attributes we don't need "forbidden" for this JIRA (but can still introduce it later if we want to) Sorry for leading the conversation astray. ) > refuse attach to undefined addresses > > > Key: DISPATCH-803 > URL: https://issues.apache.org/jira/browse/DISPATCH-803 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Gordon Sim >Assignee: Ganesh Murthy > Fix For: 1.0.0 > > > At present, if you attach to an address in the router whose semantics have > not been specifically defined, you get balanced message routing semantics. > It would be useful to be able to configure the router such that it would > refuse links whose source/target was not explicitly defined. E.g. by being > able to configure the default semantics to be of type 'invalid' (or anything > similar). (Being able to explicitly blacklist certain addresses might also be > nice, but is a more exotic use case I think). > Messages sent through an anonymous link to these 'invalid' addresses would be > rejected. > -- 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-803) refuse attach to undefined addresses
[ https://issues.apache.org/jira/browse/DISPATCH-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120649#comment-16120649 ] Alan Conway commented on DISPATCH-803: -- [~gsim] et al. I retract my retraction. Ignore [#16120352] and carry on. Been on holiday too long. > refuse attach to undefined addresses > > > Key: DISPATCH-803 > URL: https://issues.apache.org/jira/browse/DISPATCH-803 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Gordon Sim >Assignee: Ganesh Murthy > Fix For: 1.0.0 > > > At present, if you attach to an address in the router whose semantics have > not been specifically defined, you get balanced message routing semantics. > It would be useful to be able to configure the router such that it would > refuse links whose source/target was not explicitly defined. E.g. by being > able to configure the default semantics to be of type 'invalid' (or anything > similar). (Being able to explicitly blacklist certain addresses might also be > nice, but is a more exotic use case I think). > Messages sent through an anonymous link to these 'invalid' addresses would be > rejected. > -- 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-7884) Python client should not raise exception on close() after stop.
[ https://issues.apache.org/jira/browse/QPID-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120592#comment-16120592 ] Alan Conway commented on QPID-7884: --- master origin/master origin/HEAD 7c968c8318f4c4a70fbe0ebbcdbe0a09d8cfbb3e Author: Alan Conway AuthorDate: Wed Aug 9 16:06:35 2017 -0400 Commit: Alan Conway CommitDate: Wed Aug 9 16:06:35 2017 -0400 Parent: 0c3c82b QPID-7809: Python 0-10 messaging driver does not handle heartbeat timeouts, "assert rcv.received < rcv.impending" occurs Merged: master py-deadlock-new Containing: master QUID-7884: Python client should not raise on close() after stop. The python client throws exceptions out of AMQP object methods (Connection, Session and Link objects) if the selector has been stopped, to prevent hanging (see QPID-7317 Deadlock on publish) However to be robust to shut-down order, the close() method should not throw an exception in this case, but should be a no-op. > Python client should not raise exception on close() after stop. > --- > > Key: QPID-7884 > URL: https://issues.apache.org/jira/browse/QPID-7884 > Project: Qpid > Issue Type: Bug > Components: Python Client >Affects Versions: qpid-python-1.36.0 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: qpid-python-1.37.0 > > > The python client throws exceptions out of AMQP object methods (Connection, > Session and Link objects) if the selector has been stopped, to prevent > hanging (see QPID-7317 Deadlock on publish) > However to be robust to shut-down order, the close() method should *not* > throw an exception in this case, but should be a no-op. -- 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] (PROTON-622) Add missing error check to pn_event_inspect
[ https://issues.apache.org/jira/browse/PROTON-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross closed PROTON-622. -- Resolution: Not A Problem > Add missing error check to pn_event_inspect > --- > > Key: PROTON-622 > URL: https://issues.apache.org/jira/browse/PROTON-622 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Bozo Dragojevic >Assignee: Justin Ross >Priority: Trivial > Labels: patch > Fix For: proton-c-0.18.0 > > Attachments: > 0002-PROTON-622-Add-missing-error-check-to-pn_event_inspe.patch > > > Found by XCode Analyze -- 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-622) Add missing error check to pn_event_inspect
[ https://issues.apache.org/jira/browse/PROTON-622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120585#comment-16120585 ] Justin Ross commented on PROTON-622: This code was refactored at some point, and it now includes the error check. https://github.com/apache/qpid-proton/blob/master/proton-c/src/core/event.c#L257 > Add missing error check to pn_event_inspect > --- > > Key: PROTON-622 > URL: https://issues.apache.org/jira/browse/PROTON-622 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Bozo Dragojevic >Assignee: Justin Ross >Priority: Trivial > Labels: patch > Fix For: proton-c-0.18.0 > > Attachments: > 0002-PROTON-622-Add-missing-error-check-to-pn_event_inspe.patch > > > Found by XCode Analyze -- 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-7317) Deadlock on publish
[ https://issues.apache.org/jira/browse/QPID-7317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120575#comment-16120575 ] ASF subversion and git services commented on QPID-7317: --- Commit 7c968c8318f4c4a70fbe0ebbcdbe0a09d8cfbb3e in qpid-python's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-python.git;h=7c968c8 ] QUID-7884: Python client should not raise on close() after stop. The python client throws exceptions out of AMQP object methods (Connection, Session and Link objects) if the selector has been stopped, to prevent hanging (see QPID-7317 Deadlock on publish) However to be robust to shut-down order, the close() method should not throw an exception in this case, but should be a no-op. > Deadlock on publish > --- > > Key: QPID-7317 > URL: https://issues.apache.org/jira/browse/QPID-7317 > Project: Qpid > Issue Type: Bug > Components: Python Client >Affects Versions: 0.32 > Environment: python-qpid-0.32-13.fc23.noarch >Reporter: Brian Bouterse >Assignee: Alan Conway > Fix For: qpid-python-1.36.0 > > Attachments: bad_child.py, bad_child.py, bt.txt, lsof.txt, > pystack.17806, spout-hang.py, spout-hang-trace.txt, taabt.txt, worker-stacks > > > When publishing a task with qpid.messaging it deadlocks and our application > cannot continue. This has not been a problem for several releases, but within > a few days recently, another Satellite developer and I both experienced the > issue on separate machines, different distros. He is using a MRG built > pacakge (not sure of version). I am using python-qpid-0.32-13.fc23. > Both deadlocked machines had core dumps taken on the deadlocked processes and > only show only 1 Qpid thread when I expect there to be 2. There are other > mongo threads, but those are idle as expected and not related. The traces > show our application calling into qpid.messaging to publish a message to the > message bus. > This problem happens intermittently, and in cases where message publish is > successful I've verified by core dump that there are the expected 2 threads > for Qpid. -- 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-7884) Python client should not raise exception on close() after stop.
Alan Conway created QPID-7884: - Summary: Python client should not raise exception on close() after stop. Key: QPID-7884 URL: https://issues.apache.org/jira/browse/QPID-7884 Project: Qpid Issue Type: Bug Components: Python Client Affects Versions: qpid-python-1.36.0 Reporter: Alan Conway Assignee: Alan Conway Fix For: qpid-python-1.37.0 The python client throws exceptions out of AMQP object methods (Connection, Session and Link objects) if the selector has been stopped, to prevent hanging (see QPID-7317 Deadlock on publish) However to be robust to shut-down order, the close() method should *not* throw an exception in this case, but should be a no-op. -- 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-7883) Python client should not raise exception on close() after stop.
Alan Conway created QPID-7883: - Summary: Python client should not raise exception on close() after stop. Key: QPID-7883 URL: https://issues.apache.org/jira/browse/QPID-7883 Project: Qpid Issue Type: Bug Components: Python Client Affects Versions: qpid-python-1.36.0 Reporter: Alan Conway Assignee: Alan Conway Fix For: qpid-python-1.37.0 The python client throws exceptions out of AMQP object methods (Connection, Session and Link objects) if the selector has been stopped, to prevent hanging (see QPID-7317 Deadlock on publish) However to be robust to shut-down order, the close() method should *not* throw an exception in this case, but should be a no-op. -- 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-7768) Problem building on Fedora rawhide
[ https://issues.apache.org/jira/browse/QPID-7768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120517#comment-16120517 ] Irina Boverman commented on QPID-7768: -- And here: [ 64%] Built target receiver make[2]: *** [src/CMakeFiles/qpidbroker.dir/build.make:3234: src/CMakeFiles/qpidbroker.dir/qpid/broker/Selector.cpp.o] Error 1 [ 66%] Building CXX object src/tests/CMakeFiles/qpid-topic-publisher.dir/qpid-topic-publisher.cpp.o cd /foo/cpp/cpp-vpath/src/tests && /usr/bin/c++ -DBOOST_TEST_DYN_LINK -DXQ_EFFECTIVE_BOOLEAN_VALUE_HPP -I/foo/cpp/src -I/foo/cpp/src/../include -I/foo/cpp/cpp-vpath/src -I/foo/cpp/cpp-vpath/src/../include -isystem /usr/include/nss3 -isystem /usr/include/nspr4 -I/foo/usr/include -I/foo/cpp/src/tests -fvisibility-inlines-hidden -Werror -pedantic -Wall -Wextra -Wno-shadow -Wpointer-arith -Wcast-qual -Wcast-align -Wno-long-long -Wvolatile-register-var -Winvalid-pch -Wno-system-headers -Woverloaded-virtual -Wno-deprecated-declarations -Wno-implicit-fallthrough -O2 -g -DNDEBUG -pthread -Wno-variadic-macros -o CMakeFiles/qpid-topic-publisher.dir/qpid-topic-publisher.cpp.o -c /foo/cpp/src/tests/qpid-topic-publisher.cpp /foo/cpp/src/qpid/broker/SelectorExpression.cpp: In member function 'qpid::broker::Expression* qpid::broker::Parse::parseExactNumeric(const qpid::broker::Token&, bool)': /foo/cpp/src/qpid/broker/SelectorExpression.cpp:1041:13: error: '*((void*)& s +17)' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (s[1]=='b' || s[1]=='B') { /foo/cpp/src/qpid/broker/SelectorExpression.cpp: In member function 'qpid::broker::Expression* qpid::broker::Parse::orExpression(qpid::broker::Tokeniser&)': /foo/cpp/src/qpid/broker/SelectorExpression.cpp:1041:13: error: '*((void*)& s +17)' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (s[1]=='b' || s[1]=='B') { /foo/cpp/src/qpid/broker/SelectorExpression.cpp:1041:13: error: '*((void*)& s +17)' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (s[1]=='b' || s[1]=='B') { /foo/cpp/src/qpid/broker/SelectorExpression.cpp:1041:13: error: '*((void*)& s +17)' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (s[1]=='b' || s[1]=='B') { /foo/cpp/src/qpid/broker/SelectorExpression.cpp:1041:13: error: '*((void*)& s +17)' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (s[1]=='b' || s[1]=='B') { /foo/cpp/src/qpid/broker/SelectorExpression.cpp:1041:13: error: '*((void*)& s +17)' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (s[1]=='b' || s[1]=='B') { /foo/cpp/src/qpid/broker/SelectorExpression.cpp: In member function 'qpid::broker::Expression* qpid::broker::Parse::unaryArithExpression(qpid::broker::Tokeniser&)': /foo/cpp/src/qpid/broker/SelectorExpression.cpp:1041:13: error: '*((void*)& s +17)' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (s[1]=='b' || s[1]=='B') { /foo/cpp/src/qpid/broker/SelectorExpression.cpp:1041:13: error: '*((void*)& s +17)' may be used uninitialized in this function [-Werror=maybe-uninitialized] if (s[1]=='b' || s[1]=='B') { cc1plus: all warnings being treated as errors make[2]: *** [src/CMakeFiles/qpidbroker.dir/build.make:3258: src/CMakeFiles/qpidbroker.dir/qpid/broker/SelectorExpression.cpp.o] Error 1 > Problem building on Fedora rawhide > -- > > Key: QPID-7768 > URL: https://issues.apache.org/jira/browse/QPID-7768 > Project: Qpid > Issue Type: Bug > Components: C++ Build >Affects Versions: qpid-cpp-1.36.0 > Environment: [ 78%] Building CXX object > src/CMakeFiles/qpidbroker.dir/qpid/broker/SessionAdapter.cpp.o > cd /builddir/build/BUILD/qpid-cpp-1.36.0/src && /usr/bin/c++ > -DXQ_EFFECTIVE_BOOLEAN_VALUE_HPP -Dqpidbroker_EXPORTS > -I/builddir/build/BUILD/qpid-cpp-1.36.0/src > -I/builddir/build/BUILD/qpid-cpp-1.36.0/src/../include -I/usr/include/nss3 > -I/usr/include/nspr4 -std=c++11 -Wno-implicit-fallthrough > -Wno-deprecated-declarations -O2 -g -pipe -Wall -Werror=format-security > -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong > --param=ssp-buffer-size=4 -grecord-gcc-switches > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic > -fvisibility-inlines-hidden -Werror -pedantic -Wall -Wextra -Wno-shadow > -Wpointer-arith -Wcast-qual -Wcast-align -Wno-long-long > -Wvolatile-register-var -Winvalid-pch -Wno-system-headers > -Woverloaded-virtual -Wno-error=deprecated-declarations -O2 -g -DNDEBUG -fPIC > -pthread -o CMakeFiles/qpidbroker.dir/qpid/broker/SessionAdapter.cpp.o -c > /builddir/build/BUILD/qpid-cpp-1.36.0/src/qpid/broker/SessionAdapter.cpp > In file included from > /builddir/build/BUILD/qpid-cpp-1.36.0/src/qpid/broker/SelectorT
[jira] [Assigned] (QPID-7768) Problem building on Fedora rawhide
[ https://issues.apache.org/jira/browse/QPID-7768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross reassigned QPID-7768: - Assignee: Justin Ross > Problem building on Fedora rawhide > -- > > Key: QPID-7768 > URL: https://issues.apache.org/jira/browse/QPID-7768 > Project: Qpid > Issue Type: Bug > Components: C++ Build >Affects Versions: qpid-cpp-1.36.0 > Environment: [ 78%] Building CXX object > src/CMakeFiles/qpidbroker.dir/qpid/broker/SessionAdapter.cpp.o > cd /builddir/build/BUILD/qpid-cpp-1.36.0/src && /usr/bin/c++ > -DXQ_EFFECTIVE_BOOLEAN_VALUE_HPP -Dqpidbroker_EXPORTS > -I/builddir/build/BUILD/qpid-cpp-1.36.0/src > -I/builddir/build/BUILD/qpid-cpp-1.36.0/src/../include -I/usr/include/nss3 > -I/usr/include/nspr4 -std=c++11 -Wno-implicit-fallthrough > -Wno-deprecated-declarations -O2 -g -pipe -Wall -Werror=format-security > -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong > --param=ssp-buffer-size=4 -grecord-gcc-switches > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic > -fvisibility-inlines-hidden -Werror -pedantic -Wall -Wextra -Wno-shadow > -Wpointer-arith -Wcast-qual -Wcast-align -Wno-long-long > -Wvolatile-register-var -Winvalid-pch -Wno-system-headers > -Woverloaded-virtual -Wno-error=deprecated-declarations -O2 -g -DNDEBUG -fPIC > -pthread -o CMakeFiles/qpidbroker.dir/qpid/broker/SessionAdapter.cpp.o -c > /builddir/build/BUILD/qpid-cpp-1.36.0/src/qpid/broker/SessionAdapter.cpp > In file included from > /builddir/build/BUILD/qpid-cpp-1.36.0/src/qpid/broker/SelectorToken.cpp:22:0: > /builddir/build/BUILD/qpid-cpp-1.36.0/src/qpid/broker/SelectorToken.h: In > member function 'const qpid::broker::Token& > qpid::broker::Tokeniser::nextToken()': > /builddir/build/BUILD/qpid-cpp-1.36.0/src/qpid/broker/SelectorToken.h:67:8: > error: '.qpid::broker::Token::type' may be used uninitialized in > this function [-Werror=maybe-uninitialized] > struct Token { > ^ > cc1plus: all warnings being treated as errors > make[2]: *** [src/CMakeFiles/qpidbroker.dir/build.make:3282: > src/CMakeFiles/qpidbroker.dir/qpid/broker/SelectorToken.cpp.o] Error 1 >Reporter: Irina Boverman >Assignee: Justin Ross > -- 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-803) refuse attach to undefined addresses
[ https://issues.apache.org/jira/browse/DISPATCH-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120513#comment-16120513 ] Gordon Sim commented on DISPATCH-803: - [~aconway]: > The original requirement is to prevent auto-creation of addresses. This > proposal sounds like the router will auto-create forbidden addresses which is > quite different I think the requirement is simply that clients get some visible error signaled when trying to use an address for which no semantics have been configured. At present this is handled by treating such addresses as balanced. I don't personally view this as auto-creating the addresses, just as a way of inferring the semantics if none have been explicitly configured. I'm not sure how your suggested config works. Are the two option - autoLink & autoCreateDistribution -scoped to the router? or a given address? For the latter, I don't think that helps with the original requirement, unless you come up with some special prefix that matches anything for which there is no more specific match. For thr former, I don't understand what autLink would do. In the former, the autoCreateDistribution is effectively just a different name for defaultDistribution, and personally I find defaultDistribution a bit more obvious. > refuse attach to undefined addresses > > > Key: DISPATCH-803 > URL: https://issues.apache.org/jira/browse/DISPATCH-803 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Gordon Sim >Assignee: Ganesh Murthy > Fix For: 1.0.0 > > > At present, if you attach to an address in the router whose semantics have > not been specifically defined, you get balanced message routing semantics. > It would be useful to be able to configure the router such that it would > refuse links whose source/target was not explicitly defined. E.g. by being > able to configure the default semantics to be of type 'invalid' (or anything > similar). (Being able to explicitly blacklist certain addresses might also be > nice, but is a more exotic use case I think). > Messages sent through an anonymous link to these 'invalid' addresses would be > rejected. > -- 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-803) refuse attach to undefined addresses
[ https://issues.apache.org/jira/browse/DISPATCH-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120503#comment-16120503 ] ASF GitHub Bot commented on DISPATCH-803: - Github user grs commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/185#discussion_r132281323 --- Diff: src/router_core/transfer.c --- @@ -634,6 +634,23 @@ static void qdr_link_forward_CT(qdr_core_t *core, qdr_link_t *link, qdr_delivery addr->deliveries_ingress++; link->total_deliveries++; } +// +// There is no address that we can send this delivery to, which means the addr was not found in our hastable. This +// can be because there were no receivers or because the address was not defined in the config file. +// If the treatment for such addresses is set to be forbidden, we send back a rejected disposition and detach the link +// +else if (core->qd->treatment == QD_TREATMENT_LINK_FORBIDDEN) { +dlv->disposition = PN_REJECTED; +dlv->error = qdr_error("qd:forbidden", "Sending deliveries to this address is forbidden"); --- End diff -- Or perhaps even better would be amqp:not-found, since we are really saying that this is not a recognised address? > refuse attach to undefined addresses > > > Key: DISPATCH-803 > URL: https://issues.apache.org/jira/browse/DISPATCH-803 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Gordon Sim >Assignee: Ganesh Murthy > Fix For: 1.0.0 > > > At present, if you attach to an address in the router whose semantics have > not been specifically defined, you get balanced message routing semantics. > It would be useful to be able to configure the router such that it would > refuse links whose source/target was not explicitly defined. E.g. by being > able to configure the default semantics to be of type 'invalid' (or anything > similar). (Being able to explicitly blacklist certain addresses might also be > nice, but is a more exotic use case I think). > Messages sent through an anonymous link to these 'invalid' addresses would be > rejected. > -- 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
[GitHub] qpid-dispatch pull request #185: DISPATCH-803 - The following changes were m...
Github user grs commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/185#discussion_r132281323 --- Diff: src/router_core/transfer.c --- @@ -634,6 +634,23 @@ static void qdr_link_forward_CT(qdr_core_t *core, qdr_link_t *link, qdr_delivery addr->deliveries_ingress++; link->total_deliveries++; } +// +// There is no address that we can send this delivery to, which means the addr was not found in our hastable. This +// can be because there were no receivers or because the address was not defined in the config file. +// If the treatment for such addresses is set to be forbidden, we send back a rejected disposition and detach the link +// +else if (core->qd->treatment == QD_TREATMENT_LINK_FORBIDDEN) { +dlv->disposition = PN_REJECTED; +dlv->error = qdr_error("qd:forbidden", "Sending deliveries to this address is forbidden"); --- End diff -- Or perhaps even better would be amqp:not-found, since we are really saying that this is not a recognised address? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-803) refuse attach to undefined addresses
[ https://issues.apache.org/jira/browse/DISPATCH-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120497#comment-16120497 ] ASF GitHub Bot commented on DISPATCH-803: - Github user grs commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/185#discussion_r132280889 --- Diff: python/qpid_dispatch/management/qdrouter.json --- @@ -504,6 +504,13 @@ "deprecated": true, "description": "(DEPRECATED) This value is no longer used in the router.", "create": true +}, +"defaultDistribution": { +"type": ["multicast", "closest", "balanced", "forbidden"], +"description": "Default forwarding treatment for any address without a specified treatment. multicast - one copy of each message delivered to all subscribers; closest - messages delivered to only the closest subscriber; balanced - messages delivered to one subscriber with load balanced across subscribers; linkBalanced - for link-routing, link attaches balanced across destinations; forbidden - this address is forbidden, link attaches to an address of forbidden distribution will be rejected.", --- End diff -- linkBalanced should be removed from the comment > refuse attach to undefined addresses > > > Key: DISPATCH-803 > URL: https://issues.apache.org/jira/browse/DISPATCH-803 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Gordon Sim >Assignee: Ganesh Murthy > Fix For: 1.0.0 > > > At present, if you attach to an address in the router whose semantics have > not been specifically defined, you get balanced message routing semantics. > It would be useful to be able to configure the router such that it would > refuse links whose source/target was not explicitly defined. E.g. by being > able to configure the default semantics to be of type 'invalid' (or anything > similar). (Being able to explicitly blacklist certain addresses might also be > nice, but is a more exotic use case I think). > Messages sent through an anonymous link to these 'invalid' addresses would be > rejected. > -- 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
[GitHub] qpid-dispatch pull request #185: DISPATCH-803 - The following changes were m...
Github user grs commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/185#discussion_r132280889 --- Diff: python/qpid_dispatch/management/qdrouter.json --- @@ -504,6 +504,13 @@ "deprecated": true, "description": "(DEPRECATED) This value is no longer used in the router.", "create": true +}, +"defaultDistribution": { +"type": ["multicast", "closest", "balanced", "forbidden"], +"description": "Default forwarding treatment for any address without a specified treatment. multicast - one copy of each message delivered to all subscribers; closest - messages delivered to only the closest subscriber; balanced - messages delivered to one subscriber with load balanced across subscribers; linkBalanced - for link-routing, link attaches balanced across destinations; forbidden - this address is forbidden, link attaches to an address of forbidden distribution will be rejected.", --- End diff -- linkBalanced should be removed from the comment --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-785) pn_code is missing one error code
[ https://issues.apache.org/jira/browse/PROTON-785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross resolved PROTON-785. Resolution: Fixed > pn_code is missing one error code > - > > Key: PROTON-785 > URL: https://issues.apache.org/jira/browse/PROTON-785 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.7, 0.8 > Environment: Linux >Reporter: Andreas Welchlin >Assignee: Justin Ross >Priority: Trivial > Fix For: proton-c-0.18.0 > > Original Estimate: 1h > Remaining Estimate: 1h > > In error.c there is one error code missing in function pn_code: > const char *pn_code(int code) > { > switch (code) > { > case 0: return ""; > case PN_EOS: return "PN_EOS"; > case PN_ERR: return "PN_ERR"; > case PN_OVERFLOW: return "PN_OVERFLOW"; > case PN_UNDERFLOW: return "PN_UNDERFLOW"; > case PN_STATE_ERR: return "PN_STATE_ERR"; > case PN_ARG_ERR: return "PN_ARG_ERR"; > case PN_TIMEOUT: return "PN_TIMEOUT"; > case PN_INTR: return "PN_INTR"; > default: return ""; > } > } > There should also be: > case PN_INPROGRESS: return "PN_INPROGRESS"; -- 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-785) pn_code is missing one error code
[ https://issues.apache.org/jira/browse/PROTON-785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120482#comment-16120482 ] ASF subversion and git services commented on PROTON-785: Commit 4d25d88f5c96165c7c6aa24c28d214ad599caff8 in qpid-proton's branch refs/heads/master from [~jr...@redhat.com] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=4d25d88 ] PROTON-785: Add missing error code > pn_code is missing one error code > - > > Key: PROTON-785 > URL: https://issues.apache.org/jira/browse/PROTON-785 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.7, 0.8 > Environment: Linux >Reporter: Andreas Welchlin >Assignee: Justin Ross >Priority: Trivial > Fix For: proton-c-0.18.0 > > Original Estimate: 1h > Remaining Estimate: 1h > > In error.c there is one error code missing in function pn_code: > const char *pn_code(int code) > { > switch (code) > { > case 0: return ""; > case PN_EOS: return "PN_EOS"; > case PN_ERR: return "PN_ERR"; > case PN_OVERFLOW: return "PN_OVERFLOW"; > case PN_UNDERFLOW: return "PN_UNDERFLOW"; > case PN_STATE_ERR: return "PN_STATE_ERR"; > case PN_ARG_ERR: return "PN_ARG_ERR"; > case PN_TIMEOUT: return "PN_TIMEOUT"; > case PN_INTR: return "PN_INTR"; > default: return ""; > } > } > There should also be: > case PN_INPROGRESS: return "PN_INPROGRESS"; -- 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-803) refuse attach to undefined addresses
[ https://issues.apache.org/jira/browse/DISPATCH-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120463#comment-16120463 ] ASF GitHub Bot commented on DISPATCH-803: - Github user ganeshmurthy commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/185#discussion_r132275399 --- Diff: src/dispatch_private.h --- @@ -52,6 +52,7 @@ struct qd_dispatch_t { qd_connection_manager_t *connection_manager; qd_policy_t *policy; void*dl_handle; +qd_address_treatment_t treatment; --- End diff -- Changed treatment to default_treatment > refuse attach to undefined addresses > > > Key: DISPATCH-803 > URL: https://issues.apache.org/jira/browse/DISPATCH-803 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Gordon Sim >Assignee: Ganesh Murthy > Fix For: 1.0.0 > > > At present, if you attach to an address in the router whose semantics have > not been specifically defined, you get balanced message routing semantics. > It would be useful to be able to configure the router such that it would > refuse links whose source/target was not explicitly defined. E.g. by being > able to configure the default semantics to be of type 'invalid' (or anything > similar). (Being able to explicitly blacklist certain addresses might also be > nice, but is a more exotic use case I think). > Messages sent through an anonymous link to these 'invalid' addresses would be > rejected. > -- 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
[GitHub] qpid-dispatch pull request #185: DISPATCH-803 - The following changes were m...
Github user ganeshmurthy commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/185#discussion_r132275399 --- Diff: src/dispatch_private.h --- @@ -52,6 +52,7 @@ struct qd_dispatch_t { qd_connection_manager_t *connection_manager; qd_policy_t *policy; void*dl_handle; +qd_address_treatment_t treatment; --- End diff -- Changed treatment to default_treatment --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-803) refuse attach to undefined addresses
[ https://issues.apache.org/jira/browse/DISPATCH-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120462#comment-16120462 ] ASF GitHub Bot commented on DISPATCH-803: - Github user ganeshmurthy commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/185#discussion_r132275310 --- Diff: include/qpid/dispatch/router.h --- @@ -42,7 +42,8 @@ typedef enum { QD_TREATMENT_MULTICAST_ONCE = 1, QD_TREATMENT_ANYCAST_CLOSEST = 2, QD_TREATMENT_ANYCAST_BALANCED = 3, -QD_TREATMENT_LINK_BALANCED= 4 +QD_TREATMENT_LINK_BALANCED= 4, +QD_TREATMENT_LINK_FORBIDDEN = 5 --- End diff -- Changed QD_TREATMENT_LINK_FORBIDDEN to QD_TREATMENT_FORBIDDEN > refuse attach to undefined addresses > > > Key: DISPATCH-803 > URL: https://issues.apache.org/jira/browse/DISPATCH-803 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Gordon Sim >Assignee: Ganesh Murthy > Fix For: 1.0.0 > > > At present, if you attach to an address in the router whose semantics have > not been specifically defined, you get balanced message routing semantics. > It would be useful to be able to configure the router such that it would > refuse links whose source/target was not explicitly defined. E.g. by being > able to configure the default semantics to be of type 'invalid' (or anything > similar). (Being able to explicitly blacklist certain addresses might also be > nice, but is a more exotic use case I think). > Messages sent through an anonymous link to these 'invalid' addresses would be > rejected. > -- 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
[GitHub] qpid-dispatch pull request #185: DISPATCH-803 - The following changes were m...
Github user ganeshmurthy commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/185#discussion_r132275310 --- Diff: include/qpid/dispatch/router.h --- @@ -42,7 +42,8 @@ typedef enum { QD_TREATMENT_MULTICAST_ONCE = 1, QD_TREATMENT_ANYCAST_CLOSEST = 2, QD_TREATMENT_ANYCAST_BALANCED = 3, -QD_TREATMENT_LINK_BALANCED= 4 +QD_TREATMENT_LINK_BALANCED= 4, +QD_TREATMENT_LINK_FORBIDDEN = 5 --- End diff -- Changed QD_TREATMENT_LINK_FORBIDDEN to QD_TREATMENT_FORBIDDEN --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1072) Proton build fails if epydoc is installed
[ https://issues.apache.org/jira/browse/PROTON-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120455#comment-16120455 ] Justin Ross commented on PROTON-1072: - This doesn't reproduce for me, on F23 or F26. [~ganeshmurthy], is this still an issue for you? > Proton build fails if epydoc is installed > - > > Key: PROTON-1072 > URL: https://issues.apache.org/jira/browse/PROTON-1072 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.11.0 >Reporter: Ganesh Murthy >Assignee: Justin Ross > Fix For: proton-c-0.18.0 > > > Steps to reproduce > Get the latest proton from master. > Install epydoc on your system (dnf -y install epydoc (I did this on Docker > using Fedora 23 environment)) > Now run the proton build > You will see the following error - > CMake Warning (dev) at proton-c/bindings/python/CMakeLists.txt:87 > (add_custom_target): >Syntax error in cmake code at > /main/qpid-proton/proton-c/bindings/python/CMakeLists.txt:91 >when parsing string > ${SWIG_MODULE_${cproton}_REAL_NAME >syntax error, unexpected $end, expecting } (34) >Policy CMP0010 is not set: Bad variable reference syntax is an error. Run >"cmake --help-policy CMP0010" for policy details. Use the cmake_policy >command to set the policy and suppress this warning. > This warning is for project developers. Use -Wno-dev to suppress 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] (DISPATCH-803) refuse attach to undefined addresses
[ https://issues.apache.org/jira/browse/DISPATCH-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120385#comment-16120385 ] ASF GitHub Bot commented on DISPATCH-803: - Github user ted-ross commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/185#discussion_r132261405 --- Diff: src/router_core/transfer.c --- @@ -634,6 +634,23 @@ static void qdr_link_forward_CT(qdr_core_t *core, qdr_link_t *link, qdr_delivery addr->deliveries_ingress++; link->total_deliveries++; } +// +// There is no address that we can send this delivery to, which means the addr was not found in our hastable. This +// can be because there were no receivers or because the address was not defined in the config file. +// If the treatment for such addresses is set to be forbidden, we send back a rejected disposition and detach the link +// +else if (core->qd->treatment == QD_TREATMENT_LINK_FORBIDDEN) { +dlv->disposition = PN_REJECTED; +dlv->error = qdr_error("qd:forbidden", "Sending deliveries to this address is forbidden"); --- End diff -- You should be using one of the AMQP-specified error conditions that is in the amqp.[ch] files. It seems that the appropriate error condition is "amqp:not-allowed", not "forbidden" (which is an error code only for the management protocol). > refuse attach to undefined addresses > > > Key: DISPATCH-803 > URL: https://issues.apache.org/jira/browse/DISPATCH-803 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Gordon Sim >Assignee: Ganesh Murthy > Fix For: 1.0.0 > > > At present, if you attach to an address in the router whose semantics have > not been specifically defined, you get balanced message routing semantics. > It would be useful to be able to configure the router such that it would > refuse links whose source/target was not explicitly defined. E.g. by being > able to configure the default semantics to be of type 'invalid' (or anything > similar). (Being able to explicitly blacklist certain addresses might also be > nice, but is a more exotic use case I think). > Messages sent through an anonymous link to these 'invalid' addresses would be > rejected. > -- 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-803) refuse attach to undefined addresses
[ https://issues.apache.org/jira/browse/DISPATCH-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120386#comment-16120386 ] ASF GitHub Bot commented on DISPATCH-803: - Github user ted-ross commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/185#discussion_r132259033 --- Diff: include/qpid/dispatch/router.h --- @@ -42,7 +42,8 @@ typedef enum { QD_TREATMENT_MULTICAST_ONCE = 1, QD_TREATMENT_ANYCAST_CLOSEST = 2, QD_TREATMENT_ANYCAST_BALANCED = 3, -QD_TREATMENT_LINK_BALANCED= 4 +QD_TREATMENT_LINK_BALANCED= 4, +QD_TREATMENT_LINK_FORBIDDEN = 5 --- End diff -- This constant should not have "_LINK_" in it. That implies that this is only for link-routing. You should rename it "QD_TREATMENT_FORBIDDEN" because this feature is not relevant for link-routing. > refuse attach to undefined addresses > > > Key: DISPATCH-803 > URL: https://issues.apache.org/jira/browse/DISPATCH-803 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Gordon Sim >Assignee: Ganesh Murthy > Fix For: 1.0.0 > > > At present, if you attach to an address in the router whose semantics have > not been specifically defined, you get balanced message routing semantics. > It would be useful to be able to configure the router such that it would > refuse links whose source/target was not explicitly defined. E.g. by being > able to configure the default semantics to be of type 'invalid' (or anything > similar). (Being able to explicitly blacklist certain addresses might also be > nice, but is a more exotic use case I think). > Messages sent through an anonymous link to these 'invalid' addresses would be > rejected. > -- 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-803) refuse attach to undefined addresses
[ https://issues.apache.org/jira/browse/DISPATCH-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120384#comment-16120384 ] ASF GitHub Bot commented on DISPATCH-803: - Github user ted-ross commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/185#discussion_r132260270 --- Diff: src/router_core/connections.c --- @@ -1300,9 +1310,15 @@ static void qdr_link_inbound_first_attach_CT(qdr_core_t *core, qdr_action_t *act // // This link has a target address // -bool link_route; -qdr_address_t *addr = qdr_lookup_terminus_address_CT(core, dir, conn, target, true, true, &link_route); -if (!addr) { +bool link_route; +bool forbidden; +qdr_address_t *addr = qdr_lookup_terminus_address_CT(core, dir, conn, target, true, true, &link_route, &forbidden); +if (forbidden) { +qdr_link_outbound_detach_CT(core, link, 0, QDR_CONDITION_FORBIDDEN, true); --- End diff -- Does this do the right thing protocol-wise? Does the router send an attach with NULL terminus followed by a detach? > refuse attach to undefined addresses > > > Key: DISPATCH-803 > URL: https://issues.apache.org/jira/browse/DISPATCH-803 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Gordon Sim >Assignee: Ganesh Murthy > Fix For: 1.0.0 > > > At present, if you attach to an address in the router whose semantics have > not been specifically defined, you get balanced message routing semantics. > It would be useful to be able to configure the router such that it would > refuse links whose source/target was not explicitly defined. E.g. by being > able to configure the default semantics to be of type 'invalid' (or anything > similar). (Being able to explicitly blacklist certain addresses might also be > nice, but is a more exotic use case I think). > Messages sent through an anonymous link to these 'invalid' addresses would be > rejected. > -- 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-803) refuse attach to undefined addresses
[ https://issues.apache.org/jira/browse/DISPATCH-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120383#comment-16120383 ] ASF GitHub Bot commented on DISPATCH-803: - Github user ted-ross commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/185#discussion_r132259545 --- Diff: src/dispatch_private.h --- @@ -52,6 +52,7 @@ struct qd_dispatch_t { qd_connection_manager_t *connection_manager; qd_policy_t *policy; void*dl_handle; +qd_address_treatment_t treatment; --- End diff -- Shouldn't this be called default_treatment? > refuse attach to undefined addresses > > > Key: DISPATCH-803 > URL: https://issues.apache.org/jira/browse/DISPATCH-803 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Gordon Sim >Assignee: Ganesh Murthy > Fix For: 1.0.0 > > > At present, if you attach to an address in the router whose semantics have > not been specifically defined, you get balanced message routing semantics. > It would be useful to be able to configure the router such that it would > refuse links whose source/target was not explicitly defined. E.g. by being > able to configure the default semantics to be of type 'invalid' (or anything > similar). (Being able to explicitly blacklist certain addresses might also be > nice, but is a more exotic use case I think). > Messages sent through an anonymous link to these 'invalid' addresses would be > rejected. > -- 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
[GitHub] qpid-dispatch pull request #185: DISPATCH-803 - The following changes were m...
Github user ted-ross commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/185#discussion_r132259033 --- Diff: include/qpid/dispatch/router.h --- @@ -42,7 +42,8 @@ typedef enum { QD_TREATMENT_MULTICAST_ONCE = 1, QD_TREATMENT_ANYCAST_CLOSEST = 2, QD_TREATMENT_ANYCAST_BALANCED = 3, -QD_TREATMENT_LINK_BALANCED= 4 +QD_TREATMENT_LINK_BALANCED= 4, +QD_TREATMENT_LINK_FORBIDDEN = 5 --- End diff -- This constant should not have "_LINK_" in it. That implies that this is only for link-routing. You should rename it "QD_TREATMENT_FORBIDDEN" because this feature is not relevant for link-routing. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #185: DISPATCH-803 - The following changes were m...
Github user ted-ross commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/185#discussion_r132259545 --- Diff: src/dispatch_private.h --- @@ -52,6 +52,7 @@ struct qd_dispatch_t { qd_connection_manager_t *connection_manager; qd_policy_t *policy; void*dl_handle; +qd_address_treatment_t treatment; --- End diff -- Shouldn't this be called default_treatment? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #185: DISPATCH-803 - The following changes were m...
Github user ted-ross commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/185#discussion_r132261405 --- Diff: src/router_core/transfer.c --- @@ -634,6 +634,23 @@ static void qdr_link_forward_CT(qdr_core_t *core, qdr_link_t *link, qdr_delivery addr->deliveries_ingress++; link->total_deliveries++; } +// +// There is no address that we can send this delivery to, which means the addr was not found in our hastable. This +// can be because there were no receivers or because the address was not defined in the config file. +// If the treatment for such addresses is set to be forbidden, we send back a rejected disposition and detach the link +// +else if (core->qd->treatment == QD_TREATMENT_LINK_FORBIDDEN) { +dlv->disposition = PN_REJECTED; +dlv->error = qdr_error("qd:forbidden", "Sending deliveries to this address is forbidden"); --- End diff -- You should be using one of the AMQP-specified error conditions that is in the amqp.[ch] files. It seems that the appropriate error condition is "amqp:not-allowed", not "forbidden" (which is an error code only for the management protocol). --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #185: DISPATCH-803 - The following changes were m...
Github user ted-ross commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/185#discussion_r132260270 --- Diff: src/router_core/connections.c --- @@ -1300,9 +1310,15 @@ static void qdr_link_inbound_first_attach_CT(qdr_core_t *core, qdr_action_t *act // // This link has a target address // -bool link_route; -qdr_address_t *addr = qdr_lookup_terminus_address_CT(core, dir, conn, target, true, true, &link_route); -if (!addr) { +bool link_route; +bool forbidden; +qdr_address_t *addr = qdr_lookup_terminus_address_CT(core, dir, conn, target, true, true, &link_route, &forbidden); +if (forbidden) { +qdr_link_outbound_detach_CT(core, link, 0, QDR_CONDITION_FORBIDDEN, true); --- End diff -- Does this do the right thing protocol-wise? Does the router send an attach with NULL terminus followed by a detach? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-731) Support wildcard tenant vhosts in address prefix configuration
[ https://issues.apache.org/jira/browse/DISPATCH-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120358#comment-16120358 ] ASF subversion and git services commented on DISPATCH-731: -- Commit e87c87a087a17ef3d3cc4fddb7f58bfe7ed6853a in qpid-dispatch's branch refs/heads/master from Kenneth Giusti [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=e87c87a ] DISPATCH-731: fix an iterator leak > Support wildcard tenant vhosts in address prefix configuration > -- > > Key: DISPATCH-731 > URL: https://issues.apache.org/jira/browse/DISPATCH-731 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Management Agent >Affects Versions: 0.7.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Minor > Fix For: 1.0.0 > > > When specifying address prefix patterns it should be possible to use a > wildcard match for the vhost. Example: > address { > prefix: a_prefix # matches current vhost (from open frame) > } > address { > prefix: /my-vhost.com/other_prefix # matched only if vhost=my-vhost > } > address { > prefix: /*.#.domain1.com/prefix_3 # matched if vhost ends with > domain1.com > } > address { > prefix: /my.vhost.*.com/prefix_4 #matched if vhost starts with > 'my.vhost', has a single wildcard component, and ends with '.com' > } > Or something like that, I think. -- 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-731) Support wildcard tenant vhosts in address prefix configuration
[ https://issues.apache.org/jira/browse/DISPATCH-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120353#comment-16120353 ] ASF subversion and git services commented on DISPATCH-731: -- Commit 704fc281d8cb44d0d8145fca8e9310b88239aa7f in qpid-dispatch's branch refs/heads/master from Kenneth Giusti [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=704fc28 ] Merge branch 'master' into DISPATCH-731 > Support wildcard tenant vhosts in address prefix configuration > -- > > Key: DISPATCH-731 > URL: https://issues.apache.org/jira/browse/DISPATCH-731 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Management Agent >Affects Versions: 0.7.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Minor > Fix For: 1.0.0 > > > When specifying address prefix patterns it should be possible to use a > wildcard match for the vhost. Example: > address { > prefix: a_prefix # matches current vhost (from open frame) > } > address { > prefix: /my-vhost.com/other_prefix # matched only if vhost=my-vhost > } > address { > prefix: /*.#.domain1.com/prefix_3 # matched if vhost ends with > domain1.com > } > address { > prefix: /my.vhost.*.com/prefix_4 #matched if vhost starts with > 'my.vhost', has a single wildcard component, and ends with '.com' > } > Or something like that, I think. -- 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-731) Support wildcard tenant vhosts in address prefix configuration
[ https://issues.apache.org/jira/browse/DISPATCH-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120357#comment-16120357 ] ASF subversion and git services commented on DISPATCH-731: -- Commit 2c80f10877c2837af48244ff0315a12f7042eda3 in qpid-dispatch's branch refs/heads/master from Kenneth Giusti [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=2c80f10 ] DISPATCH-731: add functional tests > Support wildcard tenant vhosts in address prefix configuration > -- > > Key: DISPATCH-731 > URL: https://issues.apache.org/jira/browse/DISPATCH-731 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Management Agent >Affects Versions: 0.7.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Minor > Fix For: 1.0.0 > > > When specifying address prefix patterns it should be possible to use a > wildcard match for the vhost. Example: > address { > prefix: a_prefix # matches current vhost (from open frame) > } > address { > prefix: /my-vhost.com/other_prefix # matched only if vhost=my-vhost > } > address { > prefix: /*.#.domain1.com/prefix_3 # matched if vhost ends with > domain1.com > } > address { > prefix: /my.vhost.*.com/prefix_4 #matched if vhost starts with > 'my.vhost', has a single wildcard component, and ends with '.com' > } > Or something like that, I think. -- 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-731) Support wildcard tenant vhosts in address prefix configuration
[ https://issues.apache.org/jira/browse/DISPATCH-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120359#comment-16120359 ] ASF subversion and git services commented on DISPATCH-731: -- Commit 043c5ccf8c51786afb0baee6ca00e7816cfcdf9e in qpid-dispatch's branch refs/heads/master from Kenneth Giusti [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=043c5cc ] Merge branch 'DISPATCH-731' This closes #181 > Support wildcard tenant vhosts in address prefix configuration > -- > > Key: DISPATCH-731 > URL: https://issues.apache.org/jira/browse/DISPATCH-731 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Management Agent >Affects Versions: 0.7.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Minor > Fix For: 1.0.0 > > > When specifying address prefix patterns it should be possible to use a > wildcard match for the vhost. Example: > address { > prefix: a_prefix # matches current vhost (from open frame) > } > address { > prefix: /my-vhost.com/other_prefix # matched only if vhost=my-vhost > } > address { > prefix: /*.#.domain1.com/prefix_3 # matched if vhost ends with > domain1.com > } > address { > prefix: /my.vhost.*.com/prefix_4 #matched if vhost starts with > 'my.vhost', has a single wildcard component, and ends with '.com' > } > Or something like that, I think. -- 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-731) Support wildcard tenant vhosts in address prefix configuration
[ https://issues.apache.org/jira/browse/DISPATCH-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120355#comment-16120355 ] ASF subversion and git services commented on DISPATCH-731: -- Commit 778a9dd1f07389ca682469d31ad6834ecbea6612 in qpid-dispatch's branch refs/heads/master from Kenneth Giusti [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=778a9dd ] Merge branch 'master' into DISPATCH-731 > Support wildcard tenant vhosts in address prefix configuration > -- > > Key: DISPATCH-731 > URL: https://issues.apache.org/jira/browse/DISPATCH-731 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Management Agent >Affects Versions: 0.7.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Minor > Fix For: 1.0.0 > > > When specifying address prefix patterns it should be possible to use a > wildcard match for the vhost. Example: > address { > prefix: a_prefix # matches current vhost (from open frame) > } > address { > prefix: /my-vhost.com/other_prefix # matched only if vhost=my-vhost > } > address { > prefix: /*.#.domain1.com/prefix_3 # matched if vhost ends with > domain1.com > } > address { > prefix: /my.vhost.*.com/prefix_4 #matched if vhost starts with > 'my.vhost', has a single wildcard component, and ends with '.com' > } > Or something like that, I think. -- 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-803) refuse attach to undefined addresses
[ https://issues.apache.org/jira/browse/DISPATCH-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120352#comment-16120352 ] Alan Conway commented on DISPATCH-803: -- I want to back up a bit, I think my suggestion was not right. The original requirement is to prevent auto-creation of addresses. This proposal sounds like the router will auto-create *forbidden* addresses which is quite different: Not auto-creating address X means client connecting/sending to X gets a 'not-found' error. Creating X with {distribution=forbidden} creates a permanently unusable address named X, which would have to be explicitly deleted or modified to use it later. We could make a special case meaning for defaultDistribution=forbidden but that is confusing. I think separate config is better: autoLink = True|False # default True autoCreateDistribution # default balanced With these two attributes we don't need "forbidden" for this JIRA (but can still introduce it later if we want to) Sorry for leading the conversation astray. > refuse attach to undefined addresses > > > Key: DISPATCH-803 > URL: https://issues.apache.org/jira/browse/DISPATCH-803 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Gordon Sim >Assignee: Ganesh Murthy > Fix For: 1.0.0 > > > At present, if you attach to an address in the router whose semantics have > not been specifically defined, you get balanced message routing semantics. > It would be useful to be able to configure the router such that it would > refuse links whose source/target was not explicitly defined. E.g. by being > able to configure the default semantics to be of type 'invalid' (or anything > similar). (Being able to explicitly blacklist certain addresses might also be > nice, but is a more exotic use case I think). > Messages sent through an anonymous link to these 'invalid' addresses would be > rejected. > -- 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-731) Support wildcard tenant vhosts in address prefix configuration
[ https://issues.apache.org/jira/browse/DISPATCH-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120354#comment-16120354 ] ASF subversion and git services commented on DISPATCH-731: -- Commit 492ef7d4f3b22a62adf93614aa666383d0c5178b in qpid-dispatch's branch refs/heads/master from Kenneth Giusti [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=492ef7d ] DISPATCH-731: support wildcard configured addresses > Support wildcard tenant vhosts in address prefix configuration > -- > > Key: DISPATCH-731 > URL: https://issues.apache.org/jira/browse/DISPATCH-731 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Management Agent >Affects Versions: 0.7.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Minor > Fix For: 1.0.0 > > > When specifying address prefix patterns it should be possible to use a > wildcard match for the vhost. Example: > address { > prefix: a_prefix # matches current vhost (from open frame) > } > address { > prefix: /my-vhost.com/other_prefix # matched only if vhost=my-vhost > } > address { > prefix: /*.#.domain1.com/prefix_3 # matched if vhost ends with > domain1.com > } > address { > prefix: /my.vhost.*.com/prefix_4 #matched if vhost starts with > 'my.vhost', has a single wildcard component, and ends with '.com' > } > Or something like that, I think. -- 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-731) Support wildcard tenant vhosts in address prefix configuration
[ https://issues.apache.org/jira/browse/DISPATCH-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120356#comment-16120356 ] ASF subversion and git services commented on DISPATCH-731: -- Commit f6dab30fbeba609b227c1ed8eab5911428f10257 in qpid-dispatch's branch refs/heads/master from Kenneth Giusti [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=f6dab30 ] DISPATCH-731: add parse tree unit tests > Support wildcard tenant vhosts in address prefix configuration > -- > > Key: DISPATCH-731 > URL: https://issues.apache.org/jira/browse/DISPATCH-731 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Management Agent >Affects Versions: 0.7.0 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Minor > Fix For: 1.0.0 > > > When specifying address prefix patterns it should be possible to use a > wildcard match for the vhost. Example: > address { > prefix: a_prefix # matches current vhost (from open frame) > } > address { > prefix: /my-vhost.com/other_prefix # matched only if vhost=my-vhost > } > address { > prefix: /*.#.domain1.com/prefix_3 # matched if vhost ends with > domain1.com > } > address { > prefix: /my.vhost.*.com/prefix_4 #matched if vhost starts with > 'my.vhost', has a single wildcard component, and ends with '.com' > } > Or something like that, I think. -- 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
[GitHub] qpid-dispatch pull request #181: Dispatch 731- configure wildcard addresses
Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/181 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-803) refuse attach to undefined addresses
[ https://issues.apache.org/jira/browse/DISPATCH-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120344#comment-16120344 ] ASF GitHub Bot commented on DISPATCH-803: - GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/185 DISPATCH-803 - The following changes were made to support forbidden d… …istribution 1. Added a new attribute to the router entity called called defaultDistribution which defaults to balanced but can be set to forbidden 2. Attaches to forbidden addresses are rejected and the link is detached 3. Anonymous senders sending to forbidden addresses will be sent back a disposition of PN_REJECTED but link will not be closed 4. Added system test system_tests_default_distribution.py to test the above cases You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-803 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/185.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #185 commit 6ddee464d11e570fdfe8f2599e1587c3f4fc0c42 Author: Ganesh Murthy Date: 2017-08-09T17:41:08Z DISPATCH-803 - The following changes were made to support forbidden distribution 1. Added a new attribute to the router entity called called defaultDistribution which defaults to balanced but can be set to forbidden 2. Attaches to forbidden addresses are rejected and the link is detached 3. Anonymous senders sending to forbidden addresses will be sent back a disposition of PN_REJECTED but link will not be closed 4. Added system test system_tests_default_distribution.py to test the above cases > refuse attach to undefined addresses > > > Key: DISPATCH-803 > URL: https://issues.apache.org/jira/browse/DISPATCH-803 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Gordon Sim >Assignee: Ganesh Murthy > Fix For: 1.0.0 > > > At present, if you attach to an address in the router whose semantics have > not been specifically defined, you get balanced message routing semantics. > It would be useful to be able to configure the router such that it would > refuse links whose source/target was not explicitly defined. E.g. by being > able to configure the default semantics to be of type 'invalid' (or anything > similar). (Being able to explicitly blacklist certain addresses might also be > nice, but is a more exotic use case I think). > Messages sent through an anonymous link to these 'invalid' addresses would be > rejected. > -- 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
[GitHub] qpid-dispatch pull request #185: DISPATCH-803 - The following changes were m...
GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/185 DISPATCH-803 - The following changes were made to support forbidden d⦠â¦istribution 1. Added a new attribute to the router entity called called defaultDistribution which defaults to balanced but can be set to forbidden 2. Attaches to forbidden addresses are rejected and the link is detached 3. Anonymous senders sending to forbidden addresses will be sent back a disposition of PN_REJECTED but link will not be closed 4. Added system test system_tests_default_distribution.py to test the above cases You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-803 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/185.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #185 commit 6ddee464d11e570fdfe8f2599e1587c3f4fc0c42 Author: Ganesh Murthy Date: 2017-08-09T17:41:08Z DISPATCH-803 - The following changes were made to support forbidden distribution 1. Added a new attribute to the router entity called called defaultDistribution which defaults to balanced but can be set to forbidden 2. Attaches to forbidden addresses are rejected and the link is detached 3. Anonymous senders sending to forbidden addresses will be sent back a disposition of PN_REJECTED but link will not be closed 4. Added system test system_tests_default_distribution.py to test the above cases --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7860) [cpp] Build produces deprecation warnings on recent Fedora
[ https://issues.apache.org/jira/browse/QPID-7860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross reassigned QPID-7860: - Assignee: Justin Ross > [cpp] Build produces deprecation warnings on recent Fedora > -- > > Key: QPID-7860 > URL: https://issues.apache.org/jira/browse/QPID-7860 > Project: Qpid > Issue Type: Bug > Components: C++ Broker, C++ Client >Affects Versions: qpid-cpp-1.36.0 > Environment: Fedora 25 >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Minor > Labels: patch > Fix For: 1.37.0 > > Attachments: swig-deprecation.patch > > > {noformat} > -- Found SWIG: /usr/bin/swig (found version "3.0.11") > -- Found PythonLibs: /usr/lib64/libpython2.7.so (found version "2.7.13") > -- Found Perl: /usr/bin/perl (found version "5.24.1") > -- Found PerlLibs: /usr/lib64/libperl.so (found version "5.24.1") > -- Building Python bindings > CMake Deprecation Warning at /usr/share/cmake/Modules/UseSWIG.cmake:226 > (message): > SWIG_ADD_MODULE is deprecated. Use SWIG_ADD_LIBRARY instead. > Call Stack (most recent call first): > bindings/qpid/python/CMakeLists.txt:35 (swig_add_module) > CMake Deprecation Warning at /usr/share/cmake/Modules/UseSWIG.cmake:226 > (message): > SWIG_ADD_MODULE is deprecated. Use SWIG_ADD_LIBRARY instead. > Call Stack (most recent call first): > bindings/qmf2/python/CMakeLists.txt:35 (swig_add_module) > -- Building Ruby bindings > CMake Deprecation Warning at /usr/share/cmake/Modules/UseSWIG.cmake:226 > (message): > SWIG_ADD_MODULE is deprecated. Use SWIG_ADD_LIBRARY instead. > Call Stack (most recent call first): > bindings/qpid/ruby/CMakeLists.txt:48 (swig_add_module) > CMake Deprecation Warning at /usr/share/cmake/Modules/UseSWIG.cmake:226 > (message): > SWIG_ADD_MODULE is deprecated. Use SWIG_ADD_LIBRARY instead. > Call Stack (most recent call first): > bindings/qmf2/ruby/CMakeLists.txt:39 (swig_add_module) > -- Building Perl bindings > CMake Deprecation Warning at /usr/share/cmake/Modules/UseSWIG.cmake:226 > (message): > SWIG_ADD_MODULE is deprecated. Use SWIG_ADD_LIBRARY instead. > Call Stack (most recent call first): > bindings/qpid/perl/CMakeLists.txt:31 (swig_add_module) > -- Configuring done > -- Generating done > -- Build files have been written to: /home/jross/code/qpid-cpp/bld > {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] [Updated] (PROTON-749) Refactor Proton C transport code
[ https://issues.apache.org/jira/browse/PROTON-749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-749: --- Fix Version/s: (was: proton-c-0.19.0) proton-c-0.18.0 > Refactor Proton C transport code > > > Key: PROTON-749 > URL: https://issues.apache.org/jira/browse/PROTON-749 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.9 >Reporter: Andrew Stitcher >Assignee: Alan Conway > Labels: api > Fix For: proton-c-0.18.0 > > > The proton-c transport code is refactored to improve a bunch of things: > - Some slimming and simplification of the transport code. > - More understandable control flow. > - Less obscure holding of the transport layer state. > - Allowing a proton server to automatically configure itself for the protocol > layers used by attaching clients. > - Limited new APIs, but some exiting APIs deprecated -- 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] [Reopened] (PROTON-1278) [Proton-c] Closing connection in proton::handler puts connection in TIME_WAIT state
[ https://issues.apache.org/jira/browse/PROTON-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway reopened PROTON-1278: - > [Proton-c] Closing connection in proton::handler puts connection in TIME_WAIT > state > --- > > Key: PROTON-1278 > URL: https://issues.apache.org/jira/browse/PROTON-1278 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding, proton-c >Affects Versions: 0.12.2 >Reporter: Adel Boutros >Assignee: Justin Ross > Labels: reproducer > Fix For: proton-c-0.18.0 > > Attachments: ConnectionTimeWaitState.cpp, Wireshark output.png > > > You can check > [Nabble|http://qpid.2158936.n2.nabble.com/Java-Broker-6-0-1-AMQP-random-errors-when-sending-messages-using-Proton-c-0-12-2-td7648822.html] > for more details. -- 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-749) Refactor Proton C transport code
[ https://issues.apache.org/jira/browse/PROTON-749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved PROTON-749. Resolution: Fixed > Refactor Proton C transport code > > > Key: PROTON-749 > URL: https://issues.apache.org/jira/browse/PROTON-749 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.9 >Reporter: Andrew Stitcher >Assignee: Alan Conway > Labels: api > Fix For: proton-c-0.19.0 > > > The proton-c transport code is refactored to improve a bunch of things: > - Some slimming and simplification of the transport code. > - More understandable control flow. > - Less obscure holding of the transport layer state. > - Allowing a proton server to automatically configure itself for the protocol > layers used by attaching clients. > - Limited new APIs, but some exiting APIs deprecated -- 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-1176) Core dump if reactor creation fails
[ https://issues.apache.org/jira/browse/PROTON-1176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120236#comment-16120236 ] Alan Conway commented on PROTON-1176: - [~jr...@redhat.com] I don't think this has changed, probably it's the first time someone's tried the out-of-fds case. Should be simple to fix. > Core dump if reactor creation fails > --- > > Key: PROTON-1176 > URL: https://issues.apache.org/jira/browse/PROTON-1176 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: 0.12.0 >Reporter: Cliff Jansen >Assignee: Alan Conway > Labels: crash > Fix For: proton-c-0.18.0 > > > If a BlockingConnection fails creating a reactor from Proton-C, the wrapper > constructor for the container fails on a null "impl" value, causing a core > dump rather than an exception. > This can happen if the process runs out of file descriptors and cannot > allocate the self-pipes needed by the reactor. > Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1319165 -- 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] (PROTON-1278) [Proton-c] Closing connection in proton::handler puts connection in TIME_WAIT state
[ https://issues.apache.org/jira/browse/PROTON-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway closed PROTON-1278. --- Resolution: Won't Fix > [Proton-c] Closing connection in proton::handler puts connection in TIME_WAIT > state > --- > > Key: PROTON-1278 > URL: https://issues.apache.org/jira/browse/PROTON-1278 > Project: Qpid Proton > Issue Type: Bug > Components: cpp-binding, proton-c >Affects Versions: 0.12.2 >Reporter: Adel Boutros >Assignee: Justin Ross > Labels: reproducer > Fix For: proton-c-0.18.0 > > Attachments: ConnectionTimeWaitState.cpp, Wireshark output.png > > > You can check > [Nabble|http://qpid.2158936.n2.nabble.com/Java-Broker-6-0-1-AMQP-random-errors-when-sending-messages-using-Proton-c-0-12-2-td7648822.html] > for more details. -- 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-1533) Swig deprecation warnings with recent versions of cmake
[ https://issues.apache.org/jira/browse/PROTON-1533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross resolved PROTON-1533. - Resolution: Fixed > Swig deprecation warnings with recent versions of cmake > --- > > Key: PROTON-1533 > URL: https://issues.apache.org/jira/browse/PROTON-1533 > Project: Qpid Proton > Issue Type: Bug > Components: build > Environment: Fedora 25, 26 > Cmake 3.8+ >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Minor > Fix For: proton-c-0.18.0 > > > Same output as described in https://issues.apache.org/jira/browse/QPID-7860 -- 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-1533) Swig deprecation warnings with recent versions of cmake
[ https://issues.apache.org/jira/browse/PROTON-1533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120201#comment-16120201 ] ASF GitHub Bot commented on PROTON-1533: Github user ssorj closed the pull request at: https://github.com/apache/qpid-proton/pull/115 > Swig deprecation warnings with recent versions of cmake > --- > > Key: PROTON-1533 > URL: https://issues.apache.org/jira/browse/PROTON-1533 > Project: Qpid Proton > Issue Type: Bug > Components: build > Environment: Fedora 25, 26 > Cmake 3.8+ >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Minor > Fix For: proton-c-0.18.0 > > > Same output as described in https://issues.apache.org/jira/browse/QPID-7860 -- 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
[GitHub] qpid-proton pull request #115: PROTON-1533: Fix swig deprecation warnings
Github user ssorj closed the pull request at: https://github.com/apache/qpid-proton/pull/115 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7867) Authentication using expired certificate
[ https://issues.apache.org/jira/browse/QPID-7867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-7867. -- Resolution: Fixed Assignee: (was: Keith Wall) > Authentication using expired certificate > > > Key: QPID-7867 > URL: https://issues.apache.org/jira/browse/QPID-7867 > Project: Qpid > Issue Type: New Feature > Components: Java Broker >Affects Versions: qpid-java-broker-7.0.0 > Environment: * qpid-jms-client version 0.23.0 > * java qpid broker 7.0.0 >Reporter: Martin Krasa > Fix For: qpid-java-broker-7.0.0 > > > Using qpid-jms-client version 0.23.0 and (as of July 17 2017) expired > self-signed certificate (Valid until: Sat Dec 17 10:46:56 CET 2016) user can > _successfully authenticate_ against the java qpid broker 7.0.0 > {code:title=extract from Java broker log file|borderStyle=solid} 2017-07-14 > 16:34:58,022 INFO [Broker-Config] (q.m.c.open) - [con:0(/XXX.XX.XX.XX:54268)] > CON-1001 : Open : Destination : amqps(XXX.XX.XX.XXX:10202) : Protocol Version > : 1.0 : SSL 2017-07-14 16:34:58,093 INFO [IO-/172.23.38.21:54268] > (q.m.c.open) - [con:0(ACCOUNT_NAME@/XXX.XX.XX.XX:54268/default)] CON-1001 : > Open : Destination : amqps(XXX.XX.XX.XXX:10202) : Protocol Version : 1.0 : > SSL : Client ID : ID:6303ba8b-2055-49e5-9bf8-80336865a672:1 : Client Version > : 0.23.0 : Client Product : QpidJMS 2017-07-14 16:34:58,124 INFO > [IO-/XXX.XX.XX.XX:54268] (q.m.c.create) - > [con:0(ACCOUNT_NAME@/XXX.XX.XX.XX:54268/default)/ch:0] CHN-1001 : Create > 2017-07-14 16:34:58,155 INFO [IO-/XXX.XX.XX.XX:54268] (q.m.c.create) - > [con:0(ACCOUNT_NAME@/XXX.XX.XX.XX:54268/default)/ch:1] CHN-1001 : Create > {code} {color:blue}*NOTE:* The same behaviour rings true with expired node > certificate{color} -- 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-1533) Swig deprecation warnings with recent versions of cmake
[ https://issues.apache.org/jira/browse/PROTON-1533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120196#comment-16120196 ] ASF subversion and git services commented on PROTON-1533: - Commit bdac005a999ffded075eafc61877515edf236b38 in qpid-proton's branch refs/heads/master from [~jr...@redhat.com] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=bdac005 ] PROTON-1533: Fix swig deprecation warnings > Swig deprecation warnings with recent versions of cmake > --- > > Key: PROTON-1533 > URL: https://issues.apache.org/jira/browse/PROTON-1533 > Project: Qpid Proton > Issue Type: Bug > Components: build > Environment: Fedora 25, 26 > Cmake 3.8+ >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Minor > Fix For: proton-c-0.18.0 > > > Same output as described in https://issues.apache.org/jira/browse/QPID-7860 -- 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-7867) Authentication using expired certificate
[ https://issues.apache.org/jira/browse/QPID-7867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120191#comment-16120191 ] ASF subversion and git services commented on QPID-7867: --- Commit f267226ab091ce1ff08bec9f42e8be9ac66019b0 in qpid-broker-j's branch refs/heads/master from Oleksandr Rudyy [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=f267226 ] QPID-7867: [Java Broker] Address review comments > Authentication using expired certificate > > > Key: QPID-7867 > URL: https://issues.apache.org/jira/browse/QPID-7867 > Project: Qpid > Issue Type: New Feature > Components: Java Broker >Affects Versions: qpid-java-broker-7.0.0 > Environment: * qpid-jms-client version 0.23.0 > * java qpid broker 7.0.0 >Reporter: Martin Krasa >Assignee: Keith Wall > Fix For: qpid-java-broker-7.0.0 > > > Using qpid-jms-client version 0.23.0 and (as of July 17 2017) expired > self-signed certificate (Valid until: Sat Dec 17 10:46:56 CET 2016) user can > _successfully authenticate_ against the java qpid broker 7.0.0 > {code:title=extract from Java broker log file|borderStyle=solid} 2017-07-14 > 16:34:58,022 INFO [Broker-Config] (q.m.c.open) - [con:0(/XXX.XX.XX.XX:54268)] > CON-1001 : Open : Destination : amqps(XXX.XX.XX.XXX:10202) : Protocol Version > : 1.0 : SSL 2017-07-14 16:34:58,093 INFO [IO-/172.23.38.21:54268] > (q.m.c.open) - [con:0(ACCOUNT_NAME@/XXX.XX.XX.XX:54268/default)] CON-1001 : > Open : Destination : amqps(XXX.XX.XX.XXX:10202) : Protocol Version : 1.0 : > SSL : Client ID : ID:6303ba8b-2055-49e5-9bf8-80336865a672:1 : Client Version > : 0.23.0 : Client Product : QpidJMS 2017-07-14 16:34:58,124 INFO > [IO-/XXX.XX.XX.XX:54268] (q.m.c.create) - > [con:0(ACCOUNT_NAME@/XXX.XX.XX.XX:54268/default)/ch:0] CHN-1001 : Create > 2017-07-14 16:34:58,155 INFO [IO-/XXX.XX.XX.XX:54268] (q.m.c.create) - > [con:0(ACCOUNT_NAME@/XXX.XX.XX.XX:54268/default)/ch:1] CHN-1001 : Create > {code} {color:blue}*NOTE:* The same behaviour rings true with expired node > certificate{color} -- 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-7867) Authentication using expired certificate
[ https://issues.apache.org/jira/browse/QPID-7867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120186#comment-16120186 ] Alex Rudyy commented on QPID-7867: -- I reviewed the changes. Here are my comments about minor issues # # It looks like that constant {{PEERS_ONLY}} was moved from interface {{FileTrustStore}} into interface {{TrustStore}} by mistake. Only {{FileTrustStore}} has managed attribute {{peersOnly}}. Thus, the constant with an attribute name should be declared in {{FileTrustStore}} rather in its parent # Abstract method {{AbstrauctTrustore#getTrustManagersInternal()}} is declared protected but its visibility is changed to public in inherited classes {{FileTrustStoreImpl}}, {{ManagedPeerCertificateTrustStoreImpl}}, {{NonJavaTrustStoreImpl}} and {{SiteSpecificTrustStoreImpl}} > Authentication using expired certificate > > > Key: QPID-7867 > URL: https://issues.apache.org/jira/browse/QPID-7867 > Project: Qpid > Issue Type: New Feature > Components: Java Broker >Affects Versions: qpid-java-broker-7.0.0 > Environment: * qpid-jms-client version 0.23.0 > * java qpid broker 7.0.0 >Reporter: Martin Krasa >Assignee: Keith Wall > Fix For: qpid-java-broker-7.0.0 > > > Using qpid-jms-client version 0.23.0 and (as of July 17 2017) expired > self-signed certificate (Valid until: Sat Dec 17 10:46:56 CET 2016) user can > _successfully authenticate_ against the java qpid broker 7.0.0 > {code:title=extract from Java broker log file|borderStyle=solid} 2017-07-14 > 16:34:58,022 INFO [Broker-Config] (q.m.c.open) - [con:0(/XXX.XX.XX.XX:54268)] > CON-1001 : Open : Destination : amqps(XXX.XX.XX.XXX:10202) : Protocol Version > : 1.0 : SSL 2017-07-14 16:34:58,093 INFO [IO-/172.23.38.21:54268] > (q.m.c.open) - [con:0(ACCOUNT_NAME@/XXX.XX.XX.XX:54268/default)] CON-1001 : > Open : Destination : amqps(XXX.XX.XX.XXX:10202) : Protocol Version : 1.0 : > SSL : Client ID : ID:6303ba8b-2055-49e5-9bf8-80336865a672:1 : Client Version > : 0.23.0 : Client Product : QpidJMS 2017-07-14 16:34:58,124 INFO > [IO-/XXX.XX.XX.XX:54268] (q.m.c.create) - > [con:0(ACCOUNT_NAME@/XXX.XX.XX.XX:54268/default)/ch:0] CHN-1001 : Create > 2017-07-14 16:34:58,155 INFO [IO-/XXX.XX.XX.XX:54268] (q.m.c.create) - > [con:0(ACCOUNT_NAME@/XXX.XX.XX.XX:54268/default)/ch:1] CHN-1001 : Create > {code} {color:blue}*NOTE:* The same behaviour rings true with expired node > certificate{color} -- 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] (QPIDJMS-313) Message#getBody does not throw when attempting to read a BytesMessage as String.class
[ https://issues.apache.org/jira/browse/QPIDJMS-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120144#comment-16120144 ] Jiri Danek commented on QPIDJMS-313: Agreed. I've reported that as ARTEMIS-1341. > Message#getBody does not throw when attempting to read a BytesMessage as > String.class > - > > Key: QPIDJMS-313 > URL: https://issues.apache.org/jira/browse/QPIDJMS-313 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.23.0, 0.24.0 >Reporter: Jiri Danek >Priority: Minor > > Consider the ActiveMQ Artemis test > {{org.apache.activemq.artemis.tests.integration.jms.jms2client.BodyTest#testBodyConversion}} > adapted to run through multiple JMS ConnectionFactories in turn. This test > passes with Core JMS client, is skipped (or should be skipped) with ActiveMQ > OpenWire client (that is a JMS 1.1 client) and fails with qpid-jms client. > {noformat} > BytesMessage bytesMessage = sess.createBytesMessage(); > producer.send(bytesMessage); > Message msg = cons.receiveNoWait(); > assertNotNull(msg); > try { > msg.getBody(String.class); > fail("Exception expected"); > } catch (MessageFormatException e) { > } > {noformat} > The failing line is the {{fail("Exception expected");}}, because qpid-jms > does not throw {{MessageFormatException}} where it is supposed to. > According to https://docs.oracle.com/javaee/7/api/javax/jms/Message.html. "If > the message is a BytesMessage then this parameter must be set to byte[].class > (or java.lang.Object.class). This method will reset the BytesMessage before > and after use." ... "Throws: MessageFormatException" ... "if the message body > cannot be assigned to the specified type." -- 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] (QPIDJMS-313) Message#getBody does not throw when attempting to read a BytesMessage as String.class
[ https://issues.apache.org/jira/browse/QPIDJMS-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120138#comment-16120138 ] Timothy Bish commented on QPIDJMS-313: -- Give the initial source of the test I'd assert that the Artemis JMS client is probably in violation of the spec if it is throwing the exception when there is no body. > Message#getBody does not throw when attempting to read a BytesMessage as > String.class > - > > Key: QPIDJMS-313 > URL: https://issues.apache.org/jira/browse/QPIDJMS-313 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.23.0, 0.24.0 >Reporter: Jiri Danek >Priority: Minor > > Consider the ActiveMQ Artemis test > {{org.apache.activemq.artemis.tests.integration.jms.jms2client.BodyTest#testBodyConversion}} > adapted to run through multiple JMS ConnectionFactories in turn. This test > passes with Core JMS client, is skipped (or should be skipped) with ActiveMQ > OpenWire client (that is a JMS 1.1 client) and fails with qpid-jms client. > {noformat} > BytesMessage bytesMessage = sess.createBytesMessage(); > producer.send(bytesMessage); > Message msg = cons.receiveNoWait(); > assertNotNull(msg); > try { > msg.getBody(String.class); > fail("Exception expected"); > } catch (MessageFormatException e) { > } > {noformat} > The failing line is the {{fail("Exception expected");}}, because qpid-jms > does not throw {{MessageFormatException}} where it is supposed to. > According to https://docs.oracle.com/javaee/7/api/javax/jms/Message.html. "If > the message is a BytesMessage then this parameter must be set to byte[].class > (or java.lang.Object.class). This method will reset the BytesMessage before > and after use." ... "Throws: MessageFormatException" ... "if the message body > cannot be assigned to the specified type." -- 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] (QPIDJMS-313) Message#getBody does not throw when attempting to read a BytesMessage as String.class
[ https://issues.apache.org/jira/browse/QPIDJMS-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120132#comment-16120132 ] Jiri Danek commented on QPIDJMS-313: Oh, I haven't read the whole document. Thanks. > Message#getBody does not throw when attempting to read a BytesMessage as > String.class > - > > Key: QPIDJMS-313 > URL: https://issues.apache.org/jira/browse/QPIDJMS-313 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.23.0, 0.24.0 >Reporter: Jiri Danek >Priority: Minor > > Consider the ActiveMQ Artemis test > {{org.apache.activemq.artemis.tests.integration.jms.jms2client.BodyTest#testBodyConversion}} > adapted to run through multiple JMS ConnectionFactories in turn. This test > passes with Core JMS client, is skipped (or should be skipped) with ActiveMQ > OpenWire client (that is a JMS 1.1 client) and fails with qpid-jms client. > {noformat} > BytesMessage bytesMessage = sess.createBytesMessage(); > producer.send(bytesMessage); > Message msg = cons.receiveNoWait(); > assertNotNull(msg); > try { > msg.getBody(String.class); > fail("Exception expected"); > } catch (MessageFormatException e) { > } > {noformat} > The failing line is the {{fail("Exception expected");}}, because qpid-jms > does not throw {{MessageFormatException}} where it is supposed to. > According to https://docs.oracle.com/javaee/7/api/javax/jms/Message.html. "If > the message is a BytesMessage then this parameter must be set to byte[].class > (or java.lang.Object.class). This method will reset the BytesMessage before > and after use." ... "Throws: MessageFormatException" ... "if the message body > cannot be assigned to the specified type." -- 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] (QPIDJMS-313) Message#getBody does not throw when attempting to read a BytesMessage as String.class
[ https://issues.apache.org/jira/browse/QPIDJMS-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiri Danek closed QPIDJMS-313. -- Resolution: Invalid > Message#getBody does not throw when attempting to read a BytesMessage as > String.class > - > > Key: QPIDJMS-313 > URL: https://issues.apache.org/jira/browse/QPIDJMS-313 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.23.0, 0.24.0 >Reporter: Jiri Danek >Priority: Minor > > Consider the ActiveMQ Artemis test > {{org.apache.activemq.artemis.tests.integration.jms.jms2client.BodyTest#testBodyConversion}} > adapted to run through multiple JMS ConnectionFactories in turn. This test > passes with Core JMS client, is skipped (or should be skipped) with ActiveMQ > OpenWire client (that is a JMS 1.1 client) and fails with qpid-jms client. > {noformat} > BytesMessage bytesMessage = sess.createBytesMessage(); > producer.send(bytesMessage); > Message msg = cons.receiveNoWait(); > assertNotNull(msg); > try { > msg.getBody(String.class); > fail("Exception expected"); > } catch (MessageFormatException e) { > } > {noformat} > The failing line is the {{fail("Exception expected");}}, because qpid-jms > does not throw {{MessageFormatException}} where it is supposed to. > According to https://docs.oracle.com/javaee/7/api/javax/jms/Message.html. "If > the message is a BytesMessage then this parameter must be set to byte[].class > (or java.lang.Object.class). This method will reset the BytesMessage before > and after use." ... "Throws: MessageFormatException" ... "if the message body > cannot be assigned to the specified type." -- 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] (QPIDJMS-313) Message#getBody does not throw when attempting to read a BytesMessage as String.class
[ https://issues.apache.org/jira/browse/QPIDJMS-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiri Danek updated QPIDJMS-313: --- Affects Version/s: 0.24.0 > Message#getBody does not throw when attempting to read a BytesMessage as > String.class > - > > Key: QPIDJMS-313 > URL: https://issues.apache.org/jira/browse/QPIDJMS-313 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.23.0, 0.24.0 >Reporter: Jiri Danek >Priority: Minor > > Consider the ActiveMQ Artemis test > {{org.apache.activemq.artemis.tests.integration.jms.jms2client.BodyTest#testBodyConversion}} > adapted to run through multiple JMS ConnectionFactories in turn. This test > passes with Core JMS client, is skipped (or should be skipped) with ActiveMQ > OpenWire client (that is a JMS 1.1 client) and fails with qpid-jms client. > {noformat} > BytesMessage bytesMessage = sess.createBytesMessage(); > producer.send(bytesMessage); > Message msg = cons.receiveNoWait(); > assertNotNull(msg); > try { > msg.getBody(String.class); > fail("Exception expected"); > } catch (MessageFormatException e) { > } > {noformat} > The failing line is the {{fail("Exception expected");}}, because qpid-jms > does not throw {{MessageFormatException}} where it is supposed to. > According to https://docs.oracle.com/javaee/7/api/javax/jms/Message.html. "If > the message is a BytesMessage then this parameter must be set to byte[].class > (or java.lang.Object.class). This method will reset the BytesMessage before > and after use." ... "Throws: MessageFormatException" ... "if the message body > cannot be assigned to the specified type." -- 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] (QPIDJMS-313) Message#getBody does not throw when attempting to read a BytesMessage as String.class
[ https://issues.apache.org/jira/browse/QPIDJMS-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120126#comment-16120126 ] Timothy Bish commented on QPIDJMS-313: -- Ah, so then your assumption of the result is incorrect then, if you read the Message API you will see that the bullet point below the one you quoted says: {quote} f the message is a TextMessage, ObjectMessage, MapMessage or BytesMessage and the message has no body, then the above does not apply and this parameter may be set to any type; the returned value will always be null. {quote} > Message#getBody does not throw when attempting to read a BytesMessage as > String.class > - > > Key: QPIDJMS-313 > URL: https://issues.apache.org/jira/browse/QPIDJMS-313 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.23.0 >Reporter: Jiri Danek >Priority: Minor > > Consider the ActiveMQ Artemis test > {{org.apache.activemq.artemis.tests.integration.jms.jms2client.BodyTest#testBodyConversion}} > adapted to run through multiple JMS ConnectionFactories in turn. This test > passes with Core JMS client, is skipped (or should be skipped) with ActiveMQ > OpenWire client (that is a JMS 1.1 client) and fails with qpid-jms client. > {noformat} > BytesMessage bytesMessage = sess.createBytesMessage(); > producer.send(bytesMessage); > Message msg = cons.receiveNoWait(); > assertNotNull(msg); > try { > msg.getBody(String.class); > fail("Exception expected"); > } catch (MessageFormatException e) { > } > {noformat} > The failing line is the {{fail("Exception expected");}}, because qpid-jms > does not throw {{MessageFormatException}} where it is supposed to. > According to https://docs.oracle.com/javaee/7/api/javax/jms/Message.html. "If > the message is a BytesMessage then this parameter must be set to byte[].class > (or java.lang.Object.class). This method will reset the BytesMessage before > and after use." ... "Throws: MessageFormatException" ... "if the message body > cannot be assigned to the specified type." -- 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] [Reopened] (QPIDJMS-313) Message#getBody does not throw when attempting to read a BytesMessage as String.class
[ https://issues.apache.org/jira/browse/QPIDJMS-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiri Danek reopened QPIDJMS-313: > Message#getBody does not throw when attempting to read a BytesMessage as > String.class > - > > Key: QPIDJMS-313 > URL: https://issues.apache.org/jira/browse/QPIDJMS-313 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.23.0 >Reporter: Jiri Danek >Priority: Minor > > Consider the ActiveMQ Artemis test > {{org.apache.activemq.artemis.tests.integration.jms.jms2client.BodyTest#testBodyConversion}} > adapted to run through multiple JMS ConnectionFactories in turn. This test > passes with Core JMS client, is skipped (or should be skipped) with ActiveMQ > OpenWire client (that is a JMS 1.1 client) and fails with qpid-jms client. > {noformat} > BytesMessage bytesMessage = sess.createBytesMessage(); > producer.send(bytesMessage); > Message msg = cons.receiveNoWait(); > assertNotNull(msg); > try { > msg.getBody(String.class); > fail("Exception expected"); > } catch (MessageFormatException e) { > } > {noformat} > The failing line is the {{fail("Exception expected");}}, because qpid-jms > does not throw {{MessageFormatException}} where it is supposed to. > According to https://docs.oracle.com/javaee/7/api/javax/jms/Message.html. "If > the message is a BytesMessage then this parameter must be set to byte[].class > (or java.lang.Object.class). This method will reset the BytesMessage before > and after use." ... "Throws: MessageFormatException" ... "if the message body > cannot be assigned to the specified type." -- 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] (QPIDJMS-313) Message#getBody does not throw when attempting to read a BytesMessage as String.class
[ https://issues.apache.org/jira/browse/QPIDJMS-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120121#comment-16120121 ] Jiri Danek commented on QPIDJMS-313: Thanks for investigating. The difference between what I have and what the Qpid JMS test suite has is essentially this {code} diff --git a/qpid-jms-client/src/test/java/org/apache/qpid/jms/message/JmsBytesMessageTest.java b/qpid-jms-client/src/test/java/org/apache/qpid/jms/message/JmsBytesMessageTest.java index d56c533c..330f1208 100644 --- a/qpid-jms-client/src/test/java/org/apache/qpid/jms/message/JmsBytesMessageTest.java +++ b/qpid-jms-client/src/test/java/org/apache/qpid/jms/message/JmsBytesMessageTest.java @@ -968,8 +968,6 @@ public class JmsBytesMessageTest { public void testGetBodyThrowsMessageFormatException() throws JMSException { JmsBytesMessage bytesMessage = factory.createBytesMessage(); bytesMessage.setStringProperty("property", "value"); -bytesMessage.writeByte((byte) 1); -bytesMessage.writeInt(22); try { bytesMessage.getBody(StringBuffer.class); {code} If I remove the two lines (do not set any content of the message) then the Qpid JMS suite starts failing. > Message#getBody does not throw when attempting to read a BytesMessage as > String.class > - > > Key: QPIDJMS-313 > URL: https://issues.apache.org/jira/browse/QPIDJMS-313 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.23.0 >Reporter: Jiri Danek >Priority: Minor > > Consider the ActiveMQ Artemis test > {{org.apache.activemq.artemis.tests.integration.jms.jms2client.BodyTest#testBodyConversion}} > adapted to run through multiple JMS ConnectionFactories in turn. This test > passes with Core JMS client, is skipped (or should be skipped) with ActiveMQ > OpenWire client (that is a JMS 1.1 client) and fails with qpid-jms client. > {noformat} > BytesMessage bytesMessage = sess.createBytesMessage(); > producer.send(bytesMessage); > Message msg = cons.receiveNoWait(); > assertNotNull(msg); > try { > msg.getBody(String.class); > fail("Exception expected"); > } catch (MessageFormatException e) { > } > {noformat} > The failing line is the {{fail("Exception expected");}}, because qpid-jms > does not throw {{MessageFormatException}} where it is supposed to. > According to https://docs.oracle.com/javaee/7/api/javax/jms/Message.html. "If > the message is a BytesMessage then this parameter must be set to byte[].class > (or java.lang.Object.class). This method will reset the BytesMessage before > and after use." ... "Throws: MessageFormatException" ... "if the message body > cannot be assigned to the specified type." -- 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-1533) Swig deprecation warnings with recent versions of cmake
[ https://issues.apache.org/jira/browse/PROTON-1533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120120#comment-16120120 ] ASF GitHub Bot commented on PROTON-1533: Github user astitcher commented on a diff in the pull request: https://github.com/apache/qpid-proton/pull/115#discussion_r132225370 --- Diff: proton-c/bindings/php/CMakeLists.txt --- @@ -34,7 +34,7 @@ list(APPEND SWIG_MODULE_cproton_EXTRA_DEPS ${CMAKE_SOURCE_DIR}/proton-c/include/proton/cproton.i ${PROTON_HEADERS} ) -swig_add_module(cproton php ${CMAKE_CURRENT_SOURCE_DIR}/php.i) +swig_add_library(cproton LANGUAGE php SOURCES ${CMAKE_CURRENT_SOURCE_DIR}/php.i) --- End diff -- Not directly related to your change, but I think the ${CMAKE_CURRENT_SOURCE_DIR} is extraneous here and is different from all the other uses of swig_add_library in the other bindings. > Swig deprecation warnings with recent versions of cmake > --- > > Key: PROTON-1533 > URL: https://issues.apache.org/jira/browse/PROTON-1533 > Project: Qpid Proton > Issue Type: Bug > Components: build > Environment: Fedora 25, 26 > Cmake 3.8+ >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Minor > Fix For: proton-c-0.18.0 > > > Same output as described in https://issues.apache.org/jira/browse/QPID-7860 -- 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
[GitHub] qpid-proton pull request #115: PROTON-1533: Fix swig deprecation warnings
Github user astitcher commented on a diff in the pull request: https://github.com/apache/qpid-proton/pull/115#discussion_r132225370 --- Diff: proton-c/bindings/php/CMakeLists.txt --- @@ -34,7 +34,7 @@ list(APPEND SWIG_MODULE_cproton_EXTRA_DEPS ${CMAKE_SOURCE_DIR}/proton-c/include/proton/cproton.i ${PROTON_HEADERS} ) -swig_add_module(cproton php ${CMAKE_CURRENT_SOURCE_DIR}/php.i) +swig_add_library(cproton LANGUAGE php SOURCES ${CMAKE_CURRENT_SOURCE_DIR}/php.i) --- End diff -- Not directly related to your change, but I think the ${CMAKE_CURRENT_SOURCE_DIR} is extraneous here and is different from all the other uses of swig_add_library in the other bindings. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-584) Proton-c transport reserves large buffers for brief use
[ https://issues.apache.org/jira/browse/PROTON-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120099#comment-16120099 ] Alan Conway commented on PROTON-584: Not necessary but need to think carefully about how/when to reduce the buffer size. Re-allocating a buffer for each message is expensive, so keeping a buffer that is "big enough for most messages" is a performance win. The buffer also can hold more than one frame, and reading/writing multiple frames in a single read is an important performance win. The current scheme works well for streams of messages that don't have "exceptionallly large" outlier messages - so the trick will be to shrink buffers that have grown because of one "exceptionally large" message without penalizing the "normal sized" message stream by with very small reads or frequent re-allocations. What are the stats for your message traffic? How much do "exceptional" messages diverge from "normal" messages in size? Would a statically configured min/normal-max settings work (never reduce below min, if you go over normal-max shrink back to normal-max ASAP)? Adaptive schemes based on past traffic/buffer-size/max-read might also be worth considering. > Proton-c transport reserves large buffers for brief use > --- > > Key: PROTON-584 > URL: https://issues.apache.org/jira/browse/PROTON-584 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.8 >Reporter: Cliff Jansen >Assignee: Alan Conway > Labels: perf > Fix For: proton-c-0.19.0 > > > When processing transfer frames for incoming messages, Proton requires a > temporary buffer holding the whole transfer frame briefly in contiguous space > in the transport before moving it to the engine proper which holds the > content in a separate memory area. > pn_transport_capacity grows the buffer in the non-ssl case > (transport->input_buf), and openssl.c largely duplicates the code (including > the comment about "no limit") for ssl->inbuf for ssl connections. > Either way, a large message will trigger reserving a similarly large buffer > for the rest of the life of the connection. > Is it necessary for the transport to buffer the whole message body and hang > on to that memory? -- 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] (QPIDJMS-313) Message#getBody does not throw when attempting to read a BytesMessage as String.class
[ https://issues.apache.org/jira/browse/QPIDJMS-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish closed QPIDJMS-313. Resolution: Not A Problem This is already tested to work but I've added a few other variations that show it works in the client test suite. I'd recommend checking your tests. If you can supply a reproducer test for the Qpid JMS suite feel free to reopen. > Message#getBody does not throw when attempting to read a BytesMessage as > String.class > - > > Key: QPIDJMS-313 > URL: https://issues.apache.org/jira/browse/QPIDJMS-313 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.23.0 >Reporter: Jiri Danek >Priority: Minor > > Consider the ActiveMQ Artemis test > {{org.apache.activemq.artemis.tests.integration.jms.jms2client.BodyTest#testBodyConversion}} > adapted to run through multiple JMS ConnectionFactories in turn. This test > passes with Core JMS client, is skipped (or should be skipped) with ActiveMQ > OpenWire client (that is a JMS 1.1 client) and fails with qpid-jms client. > {noformat} > BytesMessage bytesMessage = sess.createBytesMessage(); > producer.send(bytesMessage); > Message msg = cons.receiveNoWait(); > assertNotNull(msg); > try { > msg.getBody(String.class); > fail("Exception expected"); > } catch (MessageFormatException e) { > } > {noformat} > The failing line is the {{fail("Exception expected");}}, because qpid-jms > does not throw {{MessageFormatException}} where it is supposed to. > According to https://docs.oracle.com/javaee/7/api/javax/jms/Message.html. "If > the message is a BytesMessage then this parameter must be set to byte[].class > (or java.lang.Object.class). This method will reset the BytesMessage before > and after use." ... "Throws: MessageFormatException" ... "if the message body > cannot be assigned to the specified type." -- 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] (QPIDJMS-313) Message#getBody does not throw when attempting to read a BytesMessage as String.class
[ https://issues.apache.org/jira/browse/QPIDJMS-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120078#comment-16120078 ] ASF subversion and git services commented on QPIDJMS-313: - Commit ab5f463366acf2547725b0043003d8b8168f46bf in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=ab5f463 ] QPIDJMS-313 Add some additional tests to show the issue is not valid Add a few more tests that check in different contexts that the getBody method does throw when expected. > Message#getBody does not throw when attempting to read a BytesMessage as > String.class > - > > Key: QPIDJMS-313 > URL: https://issues.apache.org/jira/browse/QPIDJMS-313 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.23.0 >Reporter: Jiri Danek >Priority: Minor > > Consider the ActiveMQ Artemis test > {{org.apache.activemq.artemis.tests.integration.jms.jms2client.BodyTest#testBodyConversion}} > adapted to run through multiple JMS ConnectionFactories in turn. This test > passes with Core JMS client, is skipped (or should be skipped) with ActiveMQ > OpenWire client (that is a JMS 1.1 client) and fails with qpid-jms client. > {noformat} > BytesMessage bytesMessage = sess.createBytesMessage(); > producer.send(bytesMessage); > Message msg = cons.receiveNoWait(); > assertNotNull(msg); > try { > msg.getBody(String.class); > fail("Exception expected"); > } catch (MessageFormatException e) { > } > {noformat} > The failing line is the {{fail("Exception expected");}}, because qpid-jms > does not throw {{MessageFormatException}} where it is supposed to. > According to https://docs.oracle.com/javaee/7/api/javax/jms/Message.html. "If > the message is a BytesMessage then this parameter must be set to byte[].class > (or java.lang.Object.class). This method will reset the BytesMessage before > and after use." ... "Throws: MessageFormatException" ... "if the message body > cannot be assigned to the specified type." -- 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-1519) qpid_proton 0.17.0 Ruby gem does not work with Ruby 2.4.1
[ https://issues.apache.org/jira/browse/PROTON-1519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16120072#comment-16120072 ] Alan Conway commented on PROTON-1519: - Thanks for this - just back from vacation hence late response. Will get your PR in and take a look at travis setup - you are correct that it was never properly set up for ruby version tests. > qpid_proton 0.17.0 Ruby gem does not work with Ruby 2.4.1 > - > > Key: PROTON-1519 > URL: https://issues.apache.org/jira/browse/PROTON-1519 > Project: Qpid Proton > Issue Type: Bug > Components: ruby-binding >Affects Versions: 0.17.0 > Environment: Ruby 2.4.1 on macOS Sierra 10.12.5 >Reporter: Jason Frey >Assignee: Justin Ross > Labels: patch > > qpid_proton 0.17.0 was built successfully from source with > {code} > > cmake -DCMAKE_INSTALL_PREFIX=/usr/local -DLIB_INSTALL_DIR=/usr/local/lib > > make install > {code} > Installing the gem with Ruby 2.4.1 from rubygems.org was successful > {code} > > gem install qpid_proton > Building native extensions. This could take a while... > Successfully installed qpid_proton-0.17.0 > 1 gem installed > {code} > However, using the gem fails with: "RuntimeError: entry exists for Integer" > {code} > > irb > [1] pry(main)> RUBY_DESCRIPTION > => "ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-darwin15]" > [2] pry(main)> require 'qpid_proton' > /Users/jfrey/.gem/ruby/2.4.1/gems/qpid_proton-0.17.0/lib/codec/mapping.rb:99: > warning: constant ::Fixnum is deprecated > /Users/jfrey/.gem/ruby/2.4.1/gems/qpid_proton-0.17.0/lib/codec/mapping.rb:99: > warning: constant ::Bignum is deprecated > RuntimeError: entry exists for Integer > from (qpid_proton-0.17.0) lib/codec/mapping.rb:55:in `block in initialize' > (qpid_proton-0.17.0) lib/codec/mapping.rb:54:in `each' > (qpid_proton-0.17.0) lib/codec/mapping.rb:54:in `initialize' > (qpid_proton-0.17.0) lib/codec/mapping.rb:99:in `new' > (qpid_proton-0.17.0) lib/codec/mapping.rb:99:in `' > (qpid_proton-0.17.0) lib/codec/mapping.rb:20:in `' > (ruby-2.4.1) lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:68:in > `require' > (ruby-2.4.1) lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:68:in > `require' > (qpid_proton-0.17.0) lib/qpid_proton.rb:54:in `' > (ruby-2.4.1) lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:133:in > `require' > (ruby-2.4.1) lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:133:in > `rescue in require' > (ruby-2.4.1) lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:40:in > `require' > (pry):1:in `' > {code} > Note that the above steps are all successful with Ruby 2.3.3 > {code} > > irb > [1] pry(main)> RUBY_DESCRIPTION > => "ruby 2.3.3p222 (2016-11-21 revision 56859) [x86_64-darwin15]" > [2] pry(main)> require 'qpid_proton' > => true > [3] pry(main)> Qpid::Proton > => Qpid::Proton > {code} -- 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] (QPIDJMS-312) Exception is not thrown when user attempts to create context with invalid session mode value
[ https://issues.apache.org/jira/browse/QPIDJMS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16119930#comment-16119930 ] ASF subversion and git services commented on QPIDJMS-312: - Commit d4d318d5592d270282326a38a47b1e893dd44784 in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=d4d318d ] QPIDJMS-312 Add check for session mode range Update JmsContext with missing check for session mode range > Exception is not thrown when user attempts to create context with invalid > session mode value > > > Key: QPIDJMS-312 > URL: https://issues.apache.org/jira/browse/QPIDJMS-312 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.24.0 >Reporter: Jiri Danek >Priority: Trivial > Fix For: 0.25.0 > > > Consider Apache ActiveMQ Artemis tests > {{org.apache.activemq.artemis.tests.integration.jms.jms2client.JmsContextTest#testInvalidSessionModesValueMinusOne}} > and {{#testInvalidSessionModesValue4}} (in the same class). > When it is adapted to run with multiple JMS clients, or when run from the > standalone reproducer at > https://github.com/jdanekrh/jms-reproducers/blob/master/src/test/java/org/apache/activemq/artemis/tests/integration/jms/jms2client/JmsContextTest.java > (the standalone reproducer requires a running broker to connect to), the test > passes with Core, is skipped on OpenWire (because that is not a JMS 2.0 > client) and fails on AMQP protocol (with qpid-jms-client as the JMS library): > {noformat} >@Test(expected = JMSRuntimeException.class) >public void testInvalidSessionModesValueMinusOne() { > context.createContext(-1); >} >@Test(expected = JMSRuntimeException.class) >public void testInvalidSessionModesValue4() { > context.createContext(4); >} > {noformat} > with exception > {noformat} > java.lang.AssertionError: Expected exception: > javax.jms.JMSRuntimeException > {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] [Resolved] (QPIDJMS-312) Exception is not thrown when user attempts to create context with invalid session mode value
[ https://issues.apache.org/jira/browse/QPIDJMS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-312. -- Resolution: Fixed Assignee: Timothy Bish Fix Version/s: 0.25.0 > Exception is not thrown when user attempts to create context with invalid > session mode value > > > Key: QPIDJMS-312 > URL: https://issues.apache.org/jira/browse/QPIDJMS-312 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.24.0 >Reporter: Jiri Danek >Assignee: Timothy Bish >Priority: Trivial > Fix For: 0.25.0 > > > Consider Apache ActiveMQ Artemis tests > {{org.apache.activemq.artemis.tests.integration.jms.jms2client.JmsContextTest#testInvalidSessionModesValueMinusOne}} > and {{#testInvalidSessionModesValue4}} (in the same class). > When it is adapted to run with multiple JMS clients, or when run from the > standalone reproducer at > https://github.com/jdanekrh/jms-reproducers/blob/master/src/test/java/org/apache/activemq/artemis/tests/integration/jms/jms2client/JmsContextTest.java > (the standalone reproducer requires a running broker to connect to), the test > passes with Core, is skipped on OpenWire (because that is not a JMS 2.0 > client) and fails on AMQP protocol (with qpid-jms-client as the JMS library): > {noformat} >@Test(expected = JMSRuntimeException.class) >public void testInvalidSessionModesValueMinusOne() { > context.createContext(-1); >} >@Test(expected = JMSRuntimeException.class) >public void testInvalidSessionModesValue4() { > context.createContext(4); >} > {noformat} > with exception > {noformat} > java.lang.AssertionError: Expected exception: > javax.jms.JMSRuntimeException > {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] [Updated] (QPIDJMS-312) Exception is not thrown when user attempts to create context with invalid session mode value
[ https://issues.apache.org/jira/browse/QPIDJMS-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated QPIDJMS-312: - Affects Version/s: (was: 0.23.0) 0.24.0 > Exception is not thrown when user attempts to create context with invalid > session mode value > > > Key: QPIDJMS-312 > URL: https://issues.apache.org/jira/browse/QPIDJMS-312 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.24.0 >Reporter: Jiri Danek >Priority: Trivial > > Consider Apache ActiveMQ Artemis tests > {{org.apache.activemq.artemis.tests.integration.jms.jms2client.JmsContextTest#testInvalidSessionModesValueMinusOne}} > and {{#testInvalidSessionModesValue4}} (in the same class). > When it is adapted to run with multiple JMS clients, or when run from the > standalone reproducer at > https://github.com/jdanekrh/jms-reproducers/blob/master/src/test/java/org/apache/activemq/artemis/tests/integration/jms/jms2client/JmsContextTest.java > (the standalone reproducer requires a running broker to connect to), the test > passes with Core, is skipped on OpenWire (because that is not a JMS 2.0 > client) and fails on AMQP protocol (with qpid-jms-client as the JMS library): > {noformat} >@Test(expected = JMSRuntimeException.class) >public void testInvalidSessionModesValueMinusOne() { > context.createContext(-1); >} >@Test(expected = JMSRuntimeException.class) >public void testInvalidSessionModesValue4() { > context.createContext(4); >} > {noformat} > with exception > {noformat} > java.lang.AssertionError: Expected exception: > javax.jms.JMSRuntimeException > {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-7434) Mature the AMQP message conversion layer (headers and content)
[ https://issues.apache.org/jira/browse/QPID-7434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16119900#comment-16119900 ] ASF subversion and git services commented on QPID-7434: --- Commit 20c9c58c9469abd6398f16644c5b0e5c751a06dc in qpid-broker-j's branch refs/heads/master from [~alex.rufous] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=20c9c58 ] QPID-7434: [Java Broker] Improve AMQP 0-8 to 1.0 content conversion and unit tests > Mature the AMQP message conversion layer (headers and content) > -- > > Key: QPID-7434 > URL: https://issues.apache.org/jira/browse/QPID-7434 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Assignee: Lorenz Quack > Fix For: qpid-java-broker-7.0.0 > > > There are a number of gaps in our message converters that mean some message > are not converted with complete fidelity (particularly in the treatment of > application headers), and where complete fidelity cannot be acheived we need > sensible rules, uniformly implemented to decide how aspects degrade. > For instance, for AMQP 0-8..0-10 allow application headers whose values were > complex types (e.g. map). AMQP 1.0 disallows this. What should the > behaviour be? Should the header be dropped? > Another instance is the length and constituency of the keys of application > headers. AMQP 0-8..0-10 have a protocol restriction of 255 UTF8 bytes. AMQP > has supports longer strings. Also AMQP 0-9 says further restricts the key to > be formed like a Java identifier. -- 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-7434) Mature the AMQP message conversion layer (headers and content)
[ https://issues.apache.org/jira/browse/QPID-7434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16119901#comment-16119901 ] ASF subversion and git services commented on QPID-7434: --- Commit 13c9e7e668f9c09c796981135433099a6946f2e4 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=13c9e7e ] QPID-7434: [Java Broker] Improve AMQP 0-10 to 1.0 content conversion and add unit tests > Mature the AMQP message conversion layer (headers and content) > -- > > Key: QPID-7434 > URL: https://issues.apache.org/jira/browse/QPID-7434 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Assignee: Lorenz Quack > Fix For: qpid-java-broker-7.0.0 > > > There are a number of gaps in our message converters that mean some message > are not converted with complete fidelity (particularly in the treatment of > application headers), and where complete fidelity cannot be acheived we need > sensible rules, uniformly implemented to decide how aspects degrade. > For instance, for AMQP 0-8..0-10 allow application headers whose values were > complex types (e.g. map). AMQP 1.0 disallows this. What should the > behaviour be? Should the header be dropped? > Another instance is the length and constituency of the keys of application > headers. AMQP 0-8..0-10 have a protocol restriction of 255 UTF8 bytes. AMQP > has supports longer strings. Also AMQP 0-9 says further restricts the key to > be formed like a Java identifier. -- 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-313) Message#getBody does not throw when attempting to read a BytesMessage as String.class
Jiri Danek created QPIDJMS-313: -- Summary: Message#getBody does not throw when attempting to read a BytesMessage as String.class Key: QPIDJMS-313 URL: https://issues.apache.org/jira/browse/QPIDJMS-313 Project: Qpid JMS Issue Type: Bug Components: qpid-jms-client Affects Versions: 0.23.0 Reporter: Jiri Danek Priority: Minor Consider the ActiveMQ Artemis test {{org.apache.activemq.artemis.tests.integration.jms.jms2client.BodyTest#testBodyConversion}} adapted to run through multiple JMS ConnectionFactories in turn. This test passes with Core JMS client, is skipped (or should be skipped) with ActiveMQ OpenWire client (that is a JMS 1.1 client) and fails with qpid-jms client. {noformat} BytesMessage bytesMessage = sess.createBytesMessage(); producer.send(bytesMessage); Message msg = cons.receiveNoWait(); assertNotNull(msg); try { msg.getBody(String.class); fail("Exception expected"); } catch (MessageFormatException e) { } {noformat} The failing line is the {{fail("Exception expected");}}, because qpid-jms does not throw {{MessageFormatException}} where it is supposed to. According to https://docs.oracle.com/javaee/7/api/javax/jms/Message.html. "If the message is a BytesMessage then this parameter must be set to byte[].class (or java.lang.Object.class). This method will reset the BytesMessage before and after use." ... "Throws: MessageFormatException" ... "if the message body cannot be assigned to the specified type." -- 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-1533) Swig deprecation warnings with recent versions of cmake
[ https://issues.apache.org/jira/browse/PROTON-1533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16119815#comment-16119815 ] ASF GitHub Bot commented on PROTON-1533: GitHub user ssorj opened a pull request: https://github.com/apache/qpid-proton/pull/115 PROTON-1533: Fix swig deprecation warnings For review You can merge this pull request into a Git repository by running: $ git pull https://github.com/ssorj/qpid-proton master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton/pull/115.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #115 commit 7fa4bf7be0f7e5cf6e43683a3294675df908f46c Author: Justin Ross Date: 2017-08-08T23:49:31Z Use swig_add_library instead of the now deprecated swig_add_module; provide a fallback impl commit 5c2b1529e610171172565eb802cec8102a9e48be Author: Justin Ross Date: 2017-08-09T00:07:42Z Correct a cmake test expression commit 04c07670a445ceb7188a56070c5141e8bded56a0 Author: Justin Ross Date: 2017-08-09T12:02:24Z Remove extraneous macro definition > Swig deprecation warnings with recent versions of cmake > --- > > Key: PROTON-1533 > URL: https://issues.apache.org/jira/browse/PROTON-1533 > Project: Qpid Proton > Issue Type: Bug > Components: build > Environment: Fedora 25, 26 > Cmake 3.8+ >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Minor > Fix For: proton-c-0.18.0 > > > Same output as described in https://issues.apache.org/jira/browse/QPID-7860 -- 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
[GitHub] qpid-proton pull request #115: PROTON-1533: Fix swig deprecation warnings
GitHub user ssorj opened a pull request: https://github.com/apache/qpid-proton/pull/115 PROTON-1533: Fix swig deprecation warnings For review You can merge this pull request into a Git repository by running: $ git pull https://github.com/ssorj/qpid-proton master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-proton/pull/115.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #115 commit 7fa4bf7be0f7e5cf6e43683a3294675df908f46c Author: Justin Ross Date: 2017-08-08T23:49:31Z Use swig_add_library instead of the now deprecated swig_add_module; provide a fallback impl commit 5c2b1529e610171172565eb802cec8102a9e48be Author: Justin Ross Date: 2017-08-09T00:07:42Z Correct a cmake test expression commit 04c07670a445ceb7188a56070c5141e8bded56a0 Author: Justin Ross Date: 2017-08-09T12:02:24Z Remove extraneous macro definition --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1533) Swig deprecation warnings with recent versions of cmake
Justin Ross created PROTON-1533: --- Summary: Swig deprecation warnings with recent versions of cmake Key: PROTON-1533 URL: https://issues.apache.org/jira/browse/PROTON-1533 Project: Qpid Proton Issue Type: Bug Components: build Environment: Fedora 25, 26 Cmake 3.8+ Reporter: Justin Ross Assignee: Justin Ross Priority: Minor Fix For: proton-c-0.18.0 Same output as described in https://issues.apache.org/jira/browse/QPID-7860 -- 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-1477) Problem building qpid-proton 0.17.0 in Fedora rawhide
[ https://issues.apache.org/jira/browse/PROTON-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross reassigned PROTON-1477: --- Assignee: Justin Ross > Problem building qpid-proton 0.17.0 in Fedora rawhide > - > > Key: PROTON-1477 > URL: https://issues.apache.org/jira/browse/PROTON-1477 > Project: Qpid Proton > Issue Type: Bug > Components: build > Environment: x86_64 >Reporter: Irina Boverman >Assignee: Justin Ross > > [ 39%] Swig source > cd /builddir/build/BUILD/qpid-proton-0.17.0/proton-c/bindings/perl && > /usr/bin/cmake -E make_directory > /builddir/build/BUILD/qpid-proton-0.17.0/proton-c/bindings/perl > make[2]: Leaving directory '/builddir/build/BUILD/qpid-proton-0.17.0' > cd /builddir/build/BUILD/qpid-proton-0.17.0/proton-c/bindings/perl && > /usr/bin/swig -perl -outdir > /builddir/build/BUILD/qpid-proton-0.17.0/proton-c/bindings/perl -shadow > -I/builddir/build/BUILD/qpid-proton-0.17.0/proton-c/src > -I/builddir/build/BUILD/qpid-proton-0.17.0/proton-c/include -I/usr/include > -I/usr/lib64/perl5/CORE -o > /builddir/build/BUILD/qpid-proton-0.17.0/proton-c/bindings/perl/perlPERL_wrap.c > /builddir/build/BUILD/qpid-proton-0.17.0/proton-c/bindings/perl/perl.i > make[2]: Leaving directory '/builddir/build/BUILD/qpid-proton-0.17.0' > cc1plus: error: -Wformat-security ignored without -Wformat > [-Werror=format-security] > cc1plus: all warnings being treated as errors > make[2]: *** > [proton-c/bindings/cpp/CMakeFiles/qpid-proton-cpp.dir/build.make:66: > proton-c/bindings/cpp/CMakeFiles/qpid-proton-cpp.dir/src/binary.cpp.o] Error 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] [Resolved] (QPID-7878) [Java Broker] [Windows start batch file] Add command line option to pause if start-up fails.
[ https://issues.apache.org/jira/browse/QPID-7878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-7878. -- Resolution: Fixed The changes look reasonable to me > [Java Broker] [Windows start batch file] Add command line option to pause if > start-up fails. > > > Key: QPID-7878 > URL: https://issues.apache.org/jira/browse/QPID-7878 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Assignee: Keith Wall >Priority: Trivial > > The {{qpid-server.bat}} batch file may be called from the Windows start menu > or Windows short-cut. If the Broker fails to start (unset JAVA_HOME or wrong > JVM version), currently the command window associated with the batch file > closes before the contents of the window can be read. This frustrates users > trying to diagnose problems. > An option 'run' command line option could be added to instruct the batch > script pause if the java or the broker report a non-zero exit status. The > run command line option is a private concern the the batch file and not > passed to Qpid proper. -- 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] (QPID-7882) SSL related tests fail on IBM JDK profile when run with Qpid JMS Client
[ https://issues.apache.org/jira/browse/QPID-7882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall closed QPID-7882. Resolution: Invalid > SSL related tests fail on IBM JDK profile when run with Qpid JMS Client > --- > > Key: QPID-7882 > URL: https://issues.apache.org/jira/browse/QPID-7882 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Keith Wall > Fix For: Future > > > Running with the command: > {code} > mvn clean verify -DfailIfNoTests=false > -DXmaven.surefire.debug="-Dcom.ibm.jsse2.overrideDefaultTLS=true" -P > java-mms.1-0 -DenableAmqp1-0 > "-Dprofile.specific.excludes=JavaTransientExcludes Java10BrokenTestsExcludes > Java10Excludes Java10UninvestigatedTestsExcludes IBMJDKExcludes" > {code} > I see the following failures: > Failed tests: > > SSLTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testClientCertMissingWhilstWanting:468->missingClientCertWhileNeedingOrWantingTestImpl:529 > Connection failed, unexpected exception thrown > > ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationManagerOnSSLPort:88 > Should be able to create a connection to the SSL port: Received fatal alert: > handshake_failure > > ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationManagerUsernameAsCN:306 > Should be able to create a connection to the SSL port: Received fatal alert: > handshake_failure > > ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationManagerUsernameAsDN:350 > Should be able to create a connection to the SSL port: Received fatal alert: > handshake_failure > > ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationWithPeersOnlyTrustStore:201->externalAuthenticationWithPeersOnlyTrustStoreTestImpl:256 > Client's validation against the broker's multi store manager unexpectedly > failed, when configured store was expected to allow. > > ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationWithRegularAndPeersOnlyTrustStores:210->externalAuthenticationWithPeersOnlyTrustStoreTestImpl:256 > Client's validation against the broker's multi store manager unexpectedly > failed, when configured store was expected to allow. > Tests in error: > > SSLTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testCreateSSLConnectionUsingConnectionURLParams:107->QpidBrokerTestCase.getConnectionWithOptions:281 > » JMS > > SSLTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testCreateSSLConnectionUsingConnectionURLParamsTrustStoreOnly:433->QpidBrokerTestCase.getConnectionWithOptions:281 > » JMS > > SSLTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testCreateSSLandTCPonSamePort:563->QpidBrokerTestCase.getConnectionWithOptions:281 > » JMS > > AmqpManagementTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testInvokeSecureOperation:658 > » JMS -- 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-7882) SSL related tests fail on IBM JDK profile when run with Qpid JMS Client
[ https://issues.apache.org/jira/browse/QPID-7882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16119765#comment-16119765 ] Keith Wall commented on QPID-7882: -- Invalid. I had failed to set -Dcom.ibm.jsse2.overrideDefaultTLS=true to make all TLS protocols available (I had left an X in my mvn command line). > SSL related tests fail on IBM JDK profile when run with Qpid JMS Client > --- > > Key: QPID-7882 > URL: https://issues.apache.org/jira/browse/QPID-7882 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Keith Wall > Fix For: Future > > > Running with the command: > {code} > mvn clean verify -DfailIfNoTests=false > -DXmaven.surefire.debug="-Dcom.ibm.jsse2.overrideDefaultTLS=true" -P > java-mms.1-0 -DenableAmqp1-0 > "-Dprofile.specific.excludes=JavaTransientExcludes Java10BrokenTestsExcludes > Java10Excludes Java10UninvestigatedTestsExcludes IBMJDKExcludes" > {code} > I see the following failures: > Failed tests: > > SSLTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testClientCertMissingWhilstWanting:468->missingClientCertWhileNeedingOrWantingTestImpl:529 > Connection failed, unexpected exception thrown > > ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationManagerOnSSLPort:88 > Should be able to create a connection to the SSL port: Received fatal alert: > handshake_failure > > ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationManagerUsernameAsCN:306 > Should be able to create a connection to the SSL port: Received fatal alert: > handshake_failure > > ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationManagerUsernameAsDN:350 > Should be able to create a connection to the SSL port: Received fatal alert: > handshake_failure > > ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationWithPeersOnlyTrustStore:201->externalAuthenticationWithPeersOnlyTrustStoreTestImpl:256 > Client's validation against the broker's multi store manager unexpectedly > failed, when configured store was expected to allow. > > ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationWithRegularAndPeersOnlyTrustStores:210->externalAuthenticationWithPeersOnlyTrustStoreTestImpl:256 > Client's validation against the broker's multi store manager unexpectedly > failed, when configured store was expected to allow. > Tests in error: > > SSLTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testCreateSSLConnectionUsingConnectionURLParams:107->QpidBrokerTestCase.getConnectionWithOptions:281 > » JMS > > SSLTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testCreateSSLConnectionUsingConnectionURLParamsTrustStoreOnly:433->QpidBrokerTestCase.getConnectionWithOptions:281 > » JMS > > SSLTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testCreateSSLandTCPonSamePort:563->QpidBrokerTestCase.getConnectionWithOptions:281 > » JMS > > AmqpManagementTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testInvokeSecureOperation:658 > » JMS -- 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-7882) SSL related tests fail on IBM JDK profile when run with Qpid JMS Client
[ https://issues.apache.org/jira/browse/QPID-7882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7882: - Component/s: Java Broker > SSL related tests fail on IBM JDK profile when run with Qpid JMS Client > --- > > Key: QPID-7882 > URL: https://issues.apache.org/jira/browse/QPID-7882 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Keith Wall > Fix For: Future > > > Running with the command: > {code} > mvn clean verify -DfailIfNoTests=false > -DXmaven.surefire.debug="-Dcom.ibm.jsse2.overrideDefaultTLS=true" -P > java-mms.1-0 -DenableAmqp1-0 > "-Dprofile.specific.excludes=JavaTransientExcludes Java10BrokenTestsExcludes > Java10Excludes Java10UninvestigatedTestsExcludes IBMJDKExcludes" > {code} > I see the following failures: > Failed tests: > > SSLTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testClientCertMissingWhilstWanting:468->missingClientCertWhileNeedingOrWantingTestImpl:529 > Connection failed, unexpected exception thrown > > ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationManagerOnSSLPort:88 > Should be able to create a connection to the SSL port: Received fatal alert: > handshake_failure > > ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationManagerUsernameAsCN:306 > Should be able to create a connection to the SSL port: Received fatal alert: > handshake_failure > > ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationManagerUsernameAsDN:350 > Should be able to create a connection to the SSL port: Received fatal alert: > handshake_failure > > ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationWithPeersOnlyTrustStore:201->externalAuthenticationWithPeersOnlyTrustStoreTestImpl:256 > Client's validation against the broker's multi store manager unexpectedly > failed, when configured store was expected to allow. > > ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationWithRegularAndPeersOnlyTrustStores:210->externalAuthenticationWithPeersOnlyTrustStoreTestImpl:256 > Client's validation against the broker's multi store manager unexpectedly > failed, when configured store was expected to allow. > Tests in error: > > SSLTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testCreateSSLConnectionUsingConnectionURLParams:107->QpidBrokerTestCase.getConnectionWithOptions:281 > » JMS > > SSLTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testCreateSSLConnectionUsingConnectionURLParamsTrustStoreOnly:433->QpidBrokerTestCase.getConnectionWithOptions:281 > » JMS > > SSLTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testCreateSSLandTCPonSamePort:563->QpidBrokerTestCase.getConnectionWithOptions:281 > » JMS > > AmqpManagementTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testInvokeSecureOperation:658 > » JMS -- 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-7882) SSL related tests fail on IBM JDK profile when run with Qpid JMS Client
Keith Wall created QPID-7882: Summary: SSL related tests fail on IBM JDK profile when run with Qpid JMS Client Key: QPID-7882 URL: https://issues.apache.org/jira/browse/QPID-7882 Project: Qpid Issue Type: Bug Reporter: Keith Wall Fix For: Future Running with the command: {code} mvn clean verify -DfailIfNoTests=false -DXmaven.surefire.debug="-Dcom.ibm.jsse2.overrideDefaultTLS=true" -P java-mms.1-0 -DenableAmqp1-0 "-Dprofile.specific.excludes=JavaTransientExcludes Java10BrokenTestsExcludes Java10Excludes Java10UninvestigatedTestsExcludes IBMJDKExcludes" {code} I see the following failures: Failed tests: SSLTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testClientCertMissingWhilstWanting:468->missingClientCertWhileNeedingOrWantingTestImpl:529 Connection failed, unexpected exception thrown ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationManagerOnSSLPort:88 Should be able to create a connection to the SSL port: Received fatal alert: handshake_failure ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationManagerUsernameAsCN:306 Should be able to create a connection to the SSL port: Received fatal alert: handshake_failure ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationManagerUsernameAsDN:350 Should be able to create a connection to the SSL port: Received fatal alert: handshake_failure ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationWithPeersOnlyTrustStore:201->externalAuthenticationWithPeersOnlyTrustStoreTestImpl:256 Client's validation against the broker's multi store manager unexpectedly failed, when configured store was expected to allow. ExternalAuthenticationTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testExternalAuthenticationWithRegularAndPeersOnlyTrustStores:210->externalAuthenticationWithPeersOnlyTrustStoreTestImpl:256 Client's validation against the broker's multi store manager unexpectedly failed, when configured store was expected to allow. Tests in error: SSLTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testCreateSSLConnectionUsingConnectionURLParams:107->QpidBrokerTestCase.getConnectionWithOptions:281 » JMS SSLTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testCreateSSLConnectionUsingConnectionURLParamsTrustStoreOnly:433->QpidBrokerTestCase.getConnectionWithOptions:281 » JMS SSLTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testCreateSSLandTCPonSamePort:563->QpidBrokerTestCase.getConnectionWithOptions:281 » JMS AmqpManagementTest>QpidTestCase.run:165->QpidBrokerTestCase.runBare:91->QpidTestCase.runTest:181->testInvokeSecureOperation:658 » JMS -- 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
[ANNOUNCE] Apache Qpid JMS 0.24.0 released
The Apache Qpid (http://qpid.apache.org) community is pleased to announce the immediate availability of Apache Qpid JMS 0.24.0. This is the latest release of our newer JMS client supporting the Advanced Message Queuing Protocol 1.0 (AMQP 1.0, ISO/IEC 19464, http://www.amqp.org), based around the Apache Qpid Proton protocol engine and implementing the AMQP JMS Mapping as it evolves at OASIS. The release is available now from our website: http://qpid.apache.org/download.html Binaries are also available via Maven Central: http://qpid.apache.org/maven.html Release notes can be found at: http://qpid.apache.org/releases/qpid-jms-0.24.0/release-notes.html Thanks to all involved, Robbie - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7879) [Java Broker] Keystore improvements
[ https://issues.apache.org/jira/browse/QPID-7879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7879: - Fix Version/s: Future > [Java Broker] Keystore improvements > --- > > Key: QPID-7879 > URL: https://issues.apache.org/jira/browse/QPID-7879 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Priority: Minor > Fix For: Future > > > The keystore model and UI should expose subject alternative names (SANs) to > help operators trying to diagnose TLS certificate problems. > Also for the FileTrustStore the model does not make it clear which of the > certificates contained within will be used to identify the TLS server (you > just have to know that it is the certificate identified by the alias, or the > first certificate in the store). -- 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-6960) BDB HA limits message size to je.rep.maxMessageSize (which was inadvertently lowered in qpid-java-6.0)
[ https://issues.apache.org/jira/browse/QPID-6960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-6960: - Fix Version/s: Future > BDB HA limits message size to je.rep.maxMessageSize (which was inadvertently > lowered in qpid-java-6.0) > -- > > Key: QPID-6960 > URL: https://issues.apache.org/jira/browse/QPID-6960 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.30, 0.32, qpid-java-6.0 >Reporter: Keith Wall > Fix For: Future > > > If I create a Java Broker BDB HA group and publish a message whose payload + > overhead exceeds {{je.rep.maxMessageSize}}, the replicas log the following > exception. On qpid-java-v6.0, the replica doesn't fail but instead slowly > spins, seemingly continually retrying repeating the same log message. > {{je.rep.maxMessageSize}} is not overridden by Qpid, so it takes its default > value 0. 0 is interpreted by JE to mean {{je.maxMemory /2}}. QPID-6751 > reduced the size of {{je.maxMemory}} from 5% of JVM's heap to 2%. This means > that in qpid-java-v6.0, the default maximum message size will be 2% of > default JVM heap size (0.5GB) = 10MB. For comparison, in 0.32 with default > heap of 2GB gave a maximum message size of 50MB. > Users can work around this issue by raising {{je.rep.maxMessageSize}}. This > can be done from the Java Broker command line (-prop), or from QPID_OPTS > environment variable. > {noformat} > com.sleepycat.je.EnvironmentFailureException: (JE 5.0.104) Message op: Entry > Body size: 32557779 is too large. maxSizeAllowed: 21126184 > If a larger value is needed, set the 'je.rep.maxMessageSize' parameter. > UNEXPECTED_STATE: Unexpected internal state, may have side effects. > at > com.sleepycat.je.EnvironmentFailureException.unexpectedState(EnvironmentFailureException.java:426) > at > com.sleepycat.je.rep.utilint.BinaryProtocol.read(BinaryProtocol.java:469) > at > com.sleepycat.je.rep.impl.node.Replica.doRunReplicaLoopInternalWork(Replica.java:466) > at > com.sleepycat.je.rep.impl.node.Replica.runReplicaLoopInternal(Replica.java:397) > at > com.sleepycat.je.rep.impl.node.Replica.runReplicaLoop(Replica.java:332) > at > com.sleepycat.je.rep.impl.node.RepNode.run(RepNode.java:1506) > {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-7867) Authentication using expired certificate
[ https://issues.apache.org/jira/browse/QPID-7867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16119543#comment-16119543 ] Keith Wall commented on QPID-7867: -- I found the following resources useful when working on the IBM JDK test failures (addressed by efb35e5). https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.security.component.80.doc/security-component/jsse2Docs/knowndiffsun.html https://www.ibm.com/support/knowledgecenter/en/SSYKE2_8.0.0/com.ibm.java.security.component.80.doc/security-component/jsse2Docs/debug.html With regard to the change made to {{TrustAnchorValidatingTrustManager.java}} by efb35e5, I was unable to find an authoritative source that states that the peer certificate must appear in the store passed to {{PKIXBuilderParameters}} but I was able to find a number of examples of this usage style online (some with comments regarding working around IBM JDK 'issues'). "Beginning Cryptography with Java", Hook, 2005 also illustrates the same pattern. > Authentication using expired certificate > > > Key: QPID-7867 > URL: https://issues.apache.org/jira/browse/QPID-7867 > Project: Qpid > Issue Type: New Feature > Components: Java Broker >Affects Versions: qpid-java-broker-7.0.0 > Environment: * qpid-jms-client version 0.23.0 > * java qpid broker 7.0.0 >Reporter: Martin Krasa >Assignee: Keith Wall > Fix For: qpid-java-broker-7.0.0 > > > Using qpid-jms-client version 0.23.0 and (as of July 17 2017) expired > self-signed certificate (Valid until: Sat Dec 17 10:46:56 CET 2016) user can > _successfully authenticate_ against the java qpid broker 7.0.0 > {code:title=extract from Java broker log file|borderStyle=solid} 2017-07-14 > 16:34:58,022 INFO [Broker-Config] (q.m.c.open) - [con:0(/XXX.XX.XX.XX:54268)] > CON-1001 : Open : Destination : amqps(XXX.XX.XX.XXX:10202) : Protocol Version > : 1.0 : SSL 2017-07-14 16:34:58,093 INFO [IO-/172.23.38.21:54268] > (q.m.c.open) - [con:0(ACCOUNT_NAME@/XXX.XX.XX.XX:54268/default)] CON-1001 : > Open : Destination : amqps(XXX.XX.XX.XXX:10202) : Protocol Version : 1.0 : > SSL : Client ID : ID:6303ba8b-2055-49e5-9bf8-80336865a672:1 : Client Version > : 0.23.0 : Client Product : QpidJMS 2017-07-14 16:34:58,124 INFO > [IO-/XXX.XX.XX.XX:54268] (q.m.c.create) - > [con:0(ACCOUNT_NAME@/XXX.XX.XX.XX:54268/default)/ch:0] CHN-1001 : Create > 2017-07-14 16:34:58,155 INFO [IO-/XXX.XX.XX.XX:54268] (q.m.c.create) - > [con:0(ACCOUNT_NAME@/XXX.XX.XX.XX:54268/default)/ch:1] CHN-1001 : Create > {code} {color:blue}*NOTE:* The same behaviour rings true with expired node > certificate{color} -- 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-312) Exception is not thrown when user attempts to create context with invalid session mode value
Jiri Danek created QPIDJMS-312: -- Summary: Exception is not thrown when user attempts to create context with invalid session mode value Key: QPIDJMS-312 URL: https://issues.apache.org/jira/browse/QPIDJMS-312 Project: Qpid JMS Issue Type: Bug Components: qpid-jms-client Affects Versions: 0.23.0 Reporter: Jiri Danek Priority: Trivial Consider Apache ActiveMQ Artemis tests {{org.apache.activemq.artemis.tests.integration.jms.jms2client.JmsContextTest#testInvalidSessionModesValueMinusOne}} and {{#testInvalidSessionModesValue4}} (in the same class). When it is adapted to run with multiple JMS clients, or when run from the standalone reproducer at https://github.com/jdanekrh/jms-reproducers/blob/master/src/test/java/org/apache/activemq/artemis/tests/integration/jms/jms2client/JmsContextTest.java (the standalone reproducer requires a running broker to connect to), the test passes with Core, is skipped on OpenWire (because that is not a JMS 2.0 client) and fails on AMQP protocol (with qpid-jms-client as the JMS library): {noformat} @Test(expected = JMSRuntimeException.class) public void testInvalidSessionModesValueMinusOne() { context.createContext(-1); } @Test(expected = JMSRuntimeException.class) public void testInvalidSessionModesValue4() { context.createContext(4); } {noformat} with exception {noformat} java.lang.AssertionError: Expected exception: javax.jms.JMSRuntimeException {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] [Updated] (QPID-7881) [Java Broker] [WMC] Expose broker restart operation through Management Console.
[ https://issues.apache.org/jira/browse/QPID-7881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7881: - Description: Give the user of the web management console convenient access to the restart broker operation (already exposed by the REST API). This is useful as some configuration changes require a restart to be applied. was: Give the user's of the web management console convenient access to the restart broker operation already exposed by the REST API. This is useful as some configuration changes require a restart to be applied. > [Java Broker] [WMC] Expose broker restart operation through Management > Console. > --- > > Key: QPID-7881 > URL: https://issues.apache.org/jira/browse/QPID-7881 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Priority: Minor > Fix For: qpid-java-broker-7.0.0 > > > Give the user of the web management console convenient access to the restart > broker operation (already exposed by the REST API). This is useful as some > configuration changes require a restart to be applied. -- 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
Re: proton server (azure SB) limit the incoming_window=5000
Thanks Gordon for looking into my query. It makes sense what u said, however i am still searching for a reason of flow control and limited batch size. As per your suggestion i tried increasing the link-credit to 10k, 100k, but that doesn't change much. my understanding of prefetch was that its number of packets not the number of bytes (i confirmed this by reducing the prefetch to 2 and then i see only 1 pkt per bulk message (half of the window size)). The size of the each pkt is roughly 900B, and as u can see that i am not able to read more than 12 pkts per batch in the complete logs below. So looking back yes the size of 12x900B is greater than 5KB, so the heading may need correction - it looks like 2x of that which is 10kb. would appreciate if someone can suggest some more knobs i should play to figure out where this limit of 10kb is coming from ? client advertised incoming_window is incoming-window=2147483647 <(214)%20748-3647> see the complete logs, as u can see the bulk size is limited to 12 pkts, where the link credit remains at , after every bulk. [0xb58380]: -> SASL [0xb58380]: <- SASL [0xb58380]:0 <- @sasl-mechanisms(64) [sasl-server-mechanisms=@PN_SYMBOL[:MSSBCBS, :PLAIN, :ANONYMOUS, :EXTERNAL]] [0xb58380]:0 -> @sasl-init(65) [mechanism=:PLAIN, initial-response=b"\x0"] [0xb58380]:0 <- @sasl-outcome(68) [code=0, additional-data=b"Welcome!"] [0xb58380]: -> AMQP [0xb58380]:0 -> @open(16) [container-id="bc599ddc-74df-46b0-800c-401aed27f321", hostname=" nebhubsb.servicebus.windows.net", channel-max=32767] [0xb58380]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647, outgoing-window=2147483647] [0xb58380]:0 -> @attach(18) [name="bc599ddc-74df-46b0-800c-401aed27f321-kukatopic/Subscriptions/kukasub", handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="kukatopic/Subscriptions/kukasub", durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0] [0xb58380]:0 -> @flow(19) [incoming-window=2147483647, next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0, link-credit=1, drain=false] [0xb58380]: <- AMQP [0xb58380]:0 <- @open(16) [container-id="fa8f5d5577be485ebd7f5ebdbdfd9ca1_G13", max-frame-size=65536, channel-max=4999, idle-time-out=24] [0xb58380]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=1, incoming-window=5000, outgoing-window=2147483647, handle-max=255] [0xb58380]:0 <- @attach(18) [name="bc599ddc-74df-46b0-800c-401aed27f321-kukatopic/Subscriptions/kukasub", handle=0, role=false, rcv-settle-mode=1, source=@source(40) [address="kukatopic/Subscriptions/kukasub", durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=266240] [0xb58380]:0 <- @transfer(20) [handle=0, delivery-id=0, delivery-tag=b"\x06\xa8\xb3\xf9\x94\x1b\x09H\xa0\xc7\xf2\x11\xd7I\xa9\x12", message-format=0, more=false, batchable=true] (1250) "\x00Sp\xc0\x0b\x05@ @p\x05&\\x00@R\x02\x00Sq\xc1\x01\x00\x00Sr\xc1\\x06\xa3\x13x-opt-enqueued-time\x83\x00\x00\x01]\xc0\x92\xc7\x0a\xa3\x15x-opt-sequence-number\x81\x00\x00\x00\x00\x009\xc9\x15\xa3\x12x-opt-locked-until\x83\x00\x00\x01]\xc5\xb4\xa5)\x00St\xc1\xef\x06\xa1\x1biothub-connection-device-id\xa1)S-1-5-21-1936340646-3222415949-3237289474\xa1\x1diothub-connection-auth-method\xa1K{"scope":"hub","type":"sas","issuer":"iothub","acceptingIpFilterRule":null}\xa1$iothub-connection-auth-generation-id\xa1\x12636327363635593852\x00Su\xb0\x00\x00\x03o{"AssetId": {"type": "KR C", "eid": "S-1-5-21-1936340646-3222415949-3237289474"}, "AssetUpdateHdr": {"timestamp": "2017-08-08T06:40:29.4663961Z", "iteration": 467375, "update_type": "AssetAttributes"}, "parentId": "88eeb6e55ae548de97576e16d5289050", "AssetMonitoredItems": {"AXIS_ACT": {"A1": {"units": "Double", "value": 7.35237932}, "A3": {"units": "Double", "value": 97.599472}, "A2": {"units": "Double", "value": -88.2291565}, "A5": {"units": "Double", "value": 80"... (truncated) [0xb58380]:0 <- @transfer(20) [handle=0, delivery-id=1, delivery-tag=b"P\xb1\x94N9\x18\x0bD\xb6\x00[cr#\x1d\xab", message-format=0, more=false, batchable=true] (1245) "\x00Sp\xc0\x0b\x05@@p\x05&\\x00@R\x02\x00Sq\xc1\x01\x00\x00Sr\xc1\\x06\xa3\x13x-opt-enqueued-time\x83\x00\x00\x01]\xc0\x92\xcb\x04\xa3\x15x-opt-sequence-number\x81\x00\x00\x00\x00\x009\xc9\x16\xa3\x12x-opt-locked-until\x83\x00\x00\x01]\xc5\xb4\xa5)\x00St\xc1\xef\x06\xa1\x1biothub-connection-device-id\xa1)S-1-5-21-1936340646-3222415949-3237289474\xa1\x1diothub-connection-auth-method\xa1K{"scope":"hub","type":"sas","issuer":"iothub","acceptingIpFilterRule":null}\xa1$iothub-connection-auth-generation-id\xa1\x12636327363635593852\x00Su\xb0\x00\x00\x03j{"AssetId": {"type": "KR C", "eid": "S-1-5-21-1936340646-3222415949-3237289474"}, "AssetUpdateHdr": {"timestamp": "2017-08-08T06:40:30.4976526Z", "iteration": 467376, "update_type": "AssetAttrib