[jira] [Updated] (PROTON-1743) BlockingReceiver raises IndexError when accepting presettled messages
[ https://issues.apache.org/jira/browse/PROTON-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1743: Fix Version/s: (was: proton-c-0.20.0) proton-c-0.21.0 > BlockingReceiver raises IndexError when accepting presettled messages > - > > Key: PROTON-1743 > URL: https://issues.apache.org/jira/browse/PROTON-1743 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.19.0 >Reporter: Ken Giusti >Priority: Major > Fix For: proton-c-0.21.0 > > Attachments: testy.py > > > The following exception is raised by the attached reproducer when the > receiver attempts to accept a message: > > python ~/work/dispatch/qpid-dispatch/BUILD/testy.py > Hello World! > Traceback (most recent call last): > File "/home/kgiusti/work/dispatch/qpid-dispatch/BUILD/testy.py", line 34, > in > receiver.accept() > File "/home/kgiusti/PY27/lib/python2.7/site-packages/proton/utils.py", line > 158, in accept > self.settle(Delivery.ACCEPTED) > File "/home/kgiusti/PY27/lib/python2.7/site-packages/proton/utils.py", line > 172, in settle > self.fetcher.settle(state) > File "/home/kgiusti/PY27/lib/python2.7/site-packages/proton/utils.py", line > 122, in settle > delivery = self.unsettled.popleft() > IndexError: pop from an empty deque > > The issue is caused by having the receiver accept() a pre-settled message. > The real issue is that there is no way for the BlockingReceiver to know if > the message is pre-settled since the delivery corresponding to the received > message is not available to the receiver. Therefore it must call accept (or > reject, modify, etc) on each message. > Expected behavior - attempting to settle a pre-settled message should be > treated as a no-op. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1596) Add Cppcheck to standard build tooling
[ https://issues.apache.org/jira/browse/PROTON-1596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1596: Fix Version/s: (was: proton-c-0.20.0) proton-c-0.21.0 > Add Cppcheck to standard build tooling > -- > > Key: PROTON-1596 > URL: https://issues.apache.org/jira/browse/PROTON-1596 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Justin Ross >Priority: Major > Fix For: proton-c-0.21.0 > > > http://cppcheck.sourceforge.net/ -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1696) Go test of anonymous SASL fails if it can't find saslpasswd2
[ https://issues.apache.org/jira/browse/PROTON-1696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1696: Component/s: go-binding > Go test of anonymous SASL fails if it can't find saslpasswd2 > > > Key: PROTON-1696 > URL: https://issues.apache.org/jira/browse/PROTON-1696 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Affects Versions: proton-c-0.18.1 >Reporter: Andrew Stitcher >Assignee: Alan Conway >Priority: Major > Fix For: proton-c-0.20.0 > > > Even if extended SASL is not being tested. In this case it shouldn't even be > using saslpasswd2 to create an authentication database. Anonymous by its very > nature doesn't use an authentication db. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1745) [proton-c] PN_CONNECTION_BOUND event is emitted too soon
[
https://issues.apache.org/jira/browse/PROTON-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-1745:
Component/s: proton-c
> [proton-c] PN_CONNECTION_BOUND event is emitted too soon
>
>
> Key: PROTON-1745
> URL: https://issues.apache.org/jira/browse/PROTON-1745
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.20.0
> Environment: Fedora 27
>Reporter: Chuck Rolke
>Assignee: Cliff Jansen
>Priority: Major
> Labels: regression
> Fix For: proton-c-0.20.0
>
> Attachments: p1745_0.diff
>
>
> During a PN_CONNECTION_BOUND event proton socket information is not
> available. At PN_CONNECTION_REMOTE_OPEN the info is available.
> I instrumented an event loop in qpid-dispatch to log the event names as they
> are delivered and to log the result of creating a qd_connection rhost_port
> name. The source:
> {noformat}
> case PN_CONNECTION_BOUND:
> on_connection_bound(qd_server, e);
> // HACK ALERT
> pn_connection_t *pn_conn = pn_event_connection(e);
> qd_connection_t *qd_conn = pn_connection_get_context(pn_conn);
> set_rhost_port(pn_conn, qd_conn);
> qd_log(qd_server->log_source, QD_LOG_CRITICAL,
> "At end of connection bound the name is: %s",
> qd_connection_name(ctx));
> // END HACK ALERT
> break;
> case PN_CONNECTION_REMOTE_OPEN:
> {
> // HACK ALERT
> pn_connection_t *pn_conn = pn_event_connection(e);
> qd_connection_t *qd_conn = pn_connection_get_context(pn_conn);
> set_rhost_port(pn_conn, qd_conn);
> qd_log(qd_server->log_source, QD_LOG_CRITICAL,
> "At entry to remote open the name is: %s",
> qd_connection_name(ctx));
> /// END HACK ALERT
> {noformat}
>
> The log file shows:
> {noformat}
> 2018-01-17 12:38:35.224859 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_INIT (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224868 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_BOUND (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224890 -0500 SERVER (critical) At end of connection bound
> the name is: err: -6 (/home/chug/git/qpid-dispatch/src/server.c:887)
> 2018-01-17 12:38:35.224965 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_REMOTE_OPEN (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224971 -0500 SERVER (critical) At entry to remote open
> the name is: 127.0.0.1:46722
> (/home/chug/git/qpid-dispatch/src/server.c:895){noformat}
> The "err -6" is a snoop on the return result of getnameinfo(): EAI_FAMILY
> 'ai_family' not supported. I suspect it's because the returned socket is junk.
> The code works correctly in 0.19.0, commit fe3c3
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1745) [proton-c] PN_CONNECTION_BOUND event is emitted too soon
[
https://issues.apache.org/jira/browse/PROTON-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-1745:
Summary: [proton-c] PN_CONNECTION_BOUND event is emitted too soon (was:
[proton-c, regression] PN_CONNECTION_BOUND event is emitted too soon)
> [proton-c] PN_CONNECTION_BOUND event is emitted too soon
>
>
> Key: PROTON-1745
> URL: https://issues.apache.org/jira/browse/PROTON-1745
> Project: Qpid Proton
> Issue Type: Bug
>Affects Versions: proton-c-0.20.0
> Environment: Fedora 27
>Reporter: Chuck Rolke
>Assignee: Cliff Jansen
>Priority: Major
> Labels: regression
> Fix For: proton-c-0.20.0
>
> Attachments: p1745_0.diff
>
>
> During a PN_CONNECTION_BOUND event proton socket information is not
> available. At PN_CONNECTION_REMOTE_OPEN the info is available.
> I instrumented an event loop in qpid-dispatch to log the event names as they
> are delivered and to log the result of creating a qd_connection rhost_port
> name. The source:
> {noformat}
> case PN_CONNECTION_BOUND:
> on_connection_bound(qd_server, e);
> // HACK ALERT
> pn_connection_t *pn_conn = pn_event_connection(e);
> qd_connection_t *qd_conn = pn_connection_get_context(pn_conn);
> set_rhost_port(pn_conn, qd_conn);
> qd_log(qd_server->log_source, QD_LOG_CRITICAL,
> "At end of connection bound the name is: %s",
> qd_connection_name(ctx));
> // END HACK ALERT
> break;
> case PN_CONNECTION_REMOTE_OPEN:
> {
> // HACK ALERT
> pn_connection_t *pn_conn = pn_event_connection(e);
> qd_connection_t *qd_conn = pn_connection_get_context(pn_conn);
> set_rhost_port(pn_conn, qd_conn);
> qd_log(qd_server->log_source, QD_LOG_CRITICAL,
> "At entry to remote open the name is: %s",
> qd_connection_name(ctx));
> /// END HACK ALERT
> {noformat}
>
> The log file shows:
> {noformat}
> 2018-01-17 12:38:35.224859 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_INIT (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224868 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_BOUND (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224890 -0500 SERVER (critical) At end of connection bound
> the name is: err: -6 (/home/chug/git/qpid-dispatch/src/server.c:887)
> 2018-01-17 12:38:35.224965 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_REMOTE_OPEN (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224971 -0500 SERVER (critical) At entry to remote open
> the name is: 127.0.0.1:46722
> (/home/chug/git/qpid-dispatch/src/server.c:895){noformat}
> The "err -6" is a snoop on the return result of getnameinfo(): EAI_FAMILY
> 'ai_family' not supported. I suspect it's because the returned socket is junk.
> The code works correctly in 0.19.0, commit fe3c3
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1745) [proton-c] PN_CONNECTION_BOUND event is emitted too soon
[
https://issues.apache.org/jira/browse/PROTON-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-1745:
Labels: regression (was: )
> [proton-c] PN_CONNECTION_BOUND event is emitted too soon
>
>
> Key: PROTON-1745
> URL: https://issues.apache.org/jira/browse/PROTON-1745
> Project: Qpid Proton
> Issue Type: Bug
>Affects Versions: proton-c-0.20.0
> Environment: Fedora 27
>Reporter: Chuck Rolke
>Assignee: Cliff Jansen
>Priority: Major
> Labels: regression
> Fix For: proton-c-0.20.0
>
> Attachments: p1745_0.diff
>
>
> During a PN_CONNECTION_BOUND event proton socket information is not
> available. At PN_CONNECTION_REMOTE_OPEN the info is available.
> I instrumented an event loop in qpid-dispatch to log the event names as they
> are delivered and to log the result of creating a qd_connection rhost_port
> name. The source:
> {noformat}
> case PN_CONNECTION_BOUND:
> on_connection_bound(qd_server, e);
> // HACK ALERT
> pn_connection_t *pn_conn = pn_event_connection(e);
> qd_connection_t *qd_conn = pn_connection_get_context(pn_conn);
> set_rhost_port(pn_conn, qd_conn);
> qd_log(qd_server->log_source, QD_LOG_CRITICAL,
> "At end of connection bound the name is: %s",
> qd_connection_name(ctx));
> // END HACK ALERT
> break;
> case PN_CONNECTION_REMOTE_OPEN:
> {
> // HACK ALERT
> pn_connection_t *pn_conn = pn_event_connection(e);
> qd_connection_t *qd_conn = pn_connection_get_context(pn_conn);
> set_rhost_port(pn_conn, qd_conn);
> qd_log(qd_server->log_source, QD_LOG_CRITICAL,
> "At entry to remote open the name is: %s",
> qd_connection_name(ctx));
> /// END HACK ALERT
> {noformat}
>
> The log file shows:
> {noformat}
> 2018-01-17 12:38:35.224859 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_INIT (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224868 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_BOUND (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224890 -0500 SERVER (critical) At end of connection bound
> the name is: err: -6 (/home/chug/git/qpid-dispatch/src/server.c:887)
> 2018-01-17 12:38:35.224965 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_REMOTE_OPEN (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224971 -0500 SERVER (critical) At entry to remote open
> the name is: 127.0.0.1:46722
> (/home/chug/git/qpid-dispatch/src/server.c:895){noformat}
> The "err -6" is a snoop on the return result of getnameinfo(): EAI_FAMILY
> 'ai_family' not supported. I suspect it's because the returned socket is junk.
> The code works correctly in 0.19.0, commit fe3c3
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1634) Failures during shutdown in message repr
[
https://issues.apache.org/jira/browse/PROTON-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-1634:
Fix Version/s: (was: proton-c-0.20.0)
proton-c-0.21.0
> Failures during shutdown in message repr
>
>
> Key: PROTON-1634
> URL: https://issues.apache.org/jira/browse/PROTON-1634
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Reporter: Justin Ross
>Assignee: Justin Ross
>Priority: Major
> Labels: reproducer
> Fix For: proton-c-0.21.0
>
> Attachments: proton-python-destructor-error.tar.gz
>
>
> {noformat}
> [jross@localhost proton-python-destructor-error]$ cat test.py
> import content
> [jross@localhost proton-python-destructor-error]$ cat content.py
> from proton import Message
> messages = [Message(subject='s%d' % i, body='b%d' % i) for i in range(10)]
> [jross@localhost proton-python-destructor-error]$ python test.py
> Exception TypeError: "'NoneType' object is not callable" in failed> ignored
> Exception TypeError: "'NoneType' object is not callable" in failed> ignored
> Exception TypeError: "'NoneType' object is not callable" in failed> ignored
> Exception TypeError: "'NoneType' object is not callable" in failed> ignored
> Exception TypeError: "'NoneType' object is not callable" in failed> ignored
> Exception TypeError: "'NoneType' object is not callable" in failed> ignored
> Exception TypeError: "'NoneType' object is not callable" in failed> ignored
> Exception TypeError: "'NoneType' object is not callable" in failed> ignored
> Exception TypeError: "'NoneType' object is not callable" in failed> ignored
> Exception TypeError: "'NoneType' object is not callable" in failed> ignored
> {noformat}
> https://bugs.python.org/issue6294
> https://bugs.python.org/issue22836
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1671) Warn on conversions from the proton::returned type
[ https://issues.apache.org/jira/browse/PROTON-1671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1671: Fix Version/s: (was: proton-c-0.20.0) proton-c-0.21.0 > Warn on conversions from the proton::returned type > -- > > Key: PROTON-1671 > URL: https://issues.apache.org/jira/browse/PROTON-1671 > Project: Qpid Proton > Issue Type: Improvement > Components: cpp-binding >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Major > Fix For: proton-c-0.21.0 > > > Using the converted return type can easily result in thread-unsafe code. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1709) Python binding: ApplicationEvent causing memory growth
[
https://issues.apache.org/jira/browse/PROTON-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-1709:
Fix Version/s: (was: proton-c-0.20.0)
proton-c-0.21.0
> Python binding: ApplicationEvent causing memory growth
> --
>
> Key: PROTON-1709
> URL: https://issues.apache.org/jira/browse/PROTON-1709
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: proton-c-0.18.1
>Reporter: Xin Chen
>Assignee: Justin Ross
>Priority: Major
> Labels: leak
> Fix For: proton-c-0.21.0
>
>
> ApplicationEvent creates a new EventType object in the constructor. The
> EventType object adds itself to the TYPES dict always, even for the same
> typename. There is no way for the application to avoid this by providing an
> EventType object directly. Repro code below:
> {code:java}
> import threading
> from proton.reactor import Container, ApplicationEvent, EventInjector
> class Program:
> def __init__(self, injector):
> self.injector = injector
> def on_reactor_init(self, event):
> event.reactor.selectable(self.injector)
> def on_hello(self, event):
> print(event.subject)
> def on_done(self, event):
> event.subject.stop()
> e = EventInjector()
> r = Container(Program(e))
> t = threading.Thread(target=r.run)
> t.start()
> for i in range(1, 1000):
> e.trigger(ApplicationEvent("hello", subject=str(i)))
> e.trigger(ApplicationEvent("done", subject=r))
> t.join()
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1723) [proton-c] Building with sasl2-bin not installed results in test failure
[
https://issues.apache.org/jira/browse/PROTON-1723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-1723:
Fix Version/s: (was: proton-c-0.20.0)
proton-c-0.21.0
> [proton-c] Building with sasl2-bin not installed results in test failure
>
>
> Key: PROTON-1723
> URL: https://issues.apache.org/jira/browse/PROTON-1723
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
> Environment: Linux Mint 18.2
>Reporter: Timothy Bish
>Assignee: Justin Ross
>Priority: Trivial
> Fix For: proton-c-0.21.0
>
>
> Building the latest upstream code and running the tests results in a failed
> test "ruby-test-container" on my Ubuntu based machine. The INSTALL.md omits
> the need to install "sasl2-bin" which leads to the test failure. The install
> guide needs an update but also the test might be made to check for that an
> maybe offer a better diagnostic or just not run on platforms that are missing
> the required dependencies for that test.
> {noformat}
> timothy@OfficePC ~/temp/0.20.0/qpid-proton-0.19.0/build $ ctest -V -R
> ruby-test-container
> UpdateCTestConfiguration from
> :/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/DartConfiguration.tcl
> Parse Config
> file:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/DartConfiguration.tcl
> UpdateCTestConfiguration from
> :/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/DartConfiguration.tcl
> Parse Config
> file:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/DartConfiguration.tcl
> Test project /home/timothy/temp/0.20.0/qpid-proton-0.19.0/build
> Constructing a list of tests
> Done constructing a list of tests
> Checking test dependency graph...
> Checking test dependency graph end
> test 18
> Start 18: ruby-test-container
>
> 18: Test command: /usr/bin/python
> "/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/env.py" "--"
> "PATH=/home/timothy/.local/bin:/home/timothy/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/jvm/java-8-oracle/bin:/usr/lib/jvm/java-8-oracle/db/bin:/usr/lib/jvm/java-8-oracle/jre/bin:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/proton-c/bindings/ruby:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/proton-c"
>
> "RUBYLIB=:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/lib:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/spec:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/proton-c/bindings/ruby:/home/timothy/temp/0.20.0/qpid-proton-0.19.0/build/proton-c"
> "SASLPASSWD=SASLPASSWD_EXE-NOTFOUND" "RUBYOPT=-W0" "/usr/bin/ruby"
> "/home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb"
> "-v"
> 18: Test timeout computed to be: 1500
> 18: sh: 1: SASLPASSWD_EXE-NOTFOUND: not found
> 18:
> /home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb:282:in
> `make_user': undefined local variable or method `makepw_cmd' for
> # (NameError)
> 18: from
> /home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb:261:in
> `initialize'
> 18: from
> /home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb:284:in
> `new'
> 18: from
> /home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb:284:in
> `'
> 18: from
> /home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb:249:in
> `'
> 18: from
> /home/timothy/temp/0.20.0/qpid-proton-0.19.0/proton-c/bindings/ruby/tests/test_container.rb:221:in
> `'
> 1/1 Test #18: ruby-test-container ..***Failed0.08 sec
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1444) Use Python's etree for XML parsing
[ https://issues.apache.org/jira/browse/PROTON-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1444: Fix Version/s: (was: proton-c-0.20.0) proton-c-0.21.0 > Use Python's etree for XML parsing > -- > > Key: PROTON-1444 > URL: https://issues.apache.org/jira/browse/PROTON-1444 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Major > Fix For: proton-c-0.21.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-901) add authz support to auth service plugin
[ https://issues.apache.org/jira/browse/DISPATCH-901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16336464#comment-16336464 ] ASF subversion and git services commented on DISPATCH-901: -- Commit 84604e7fb5c9987dff271783b968d30331968328 in qpid-dispatch's branch refs/heads/master from [~gsim] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=84604e7 ] DISPATCH-901: allow PLAIN as well as SCRAM-SHA-1, for older platforms > add authz support to auth service plugin > > > Key: DISPATCH-901 > URL: https://issues.apache.org/jira/browse/DISPATCH-901 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Gordon Sim >Assignee: Gordon Sim >Priority: Major > > It would be more useful to have the auth service provide a set of permissions > for the user if successfully authenticated, rathe rthan having to define > these in config files for each router in a network. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8032) [AMQP1.0] AsyncAutoCommitTransaction optimisation
[
https://issues.apache.org/jira/browse/QPID-8032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16336456#comment-16336456
]
ASF subversion and git services commented on QPID-8032:
---
Commit a627b2742a893c9873483dee7c4ad1cb7d8428cd 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=a627b27 ]
QPID-8032 : [Broker-J][AMQP 1.0] Add protocol tests for receiving of multiple
messages
> [AMQP1.0] AsyncAutoCommitTransaction optimisation
> -
>
> Key: QPID-8032
> URL: https://issues.apache.org/jira/browse/QPID-8032
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.0.1
>
> Attachments:
> 0001-QPID-8032-Broker-J-AMQP-1.0-Use-asynchronous-transac.patch
>
>
> Some AMQP 1.0 messaging use-cases would benefit from the
> {{AsyncAutoCommitTransactions}} optimisation that is already in use on the
> older protocols.
> For instance, for a publisher sending persistent settled messages, currently
> each message is written to disk and sync before the next message is the
> buffer is processed,. With this optimisation, the syncs would be allowed to
> coalesce.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1174) Proton C encodes Open.channel-max 0 as a null and not as a uint.
[
https://issues.apache.org/jira/browse/PROTON-1174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16336432#comment-16336432
]
Chuck Rolke commented on PROTON-1174:
-
I'm pretty sure that the peer was AMQP.Net Lite. Lite is liberal about exposing
the AMQP objects in full making it easy (well, easier) to concoct arbitrary
AMQP frames.
> Proton C encodes Open.channel-max 0 as a null and not as a uint.
>
>
> Key: PROTON-1174
> URL: https://issues.apache.org/jira/browse/PROTON-1174
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.12.0
>Reporter: Chuck Rolke
>Assignee: Andrew Stitcher
>Priority: Major
> Labels: codec
> Fix For: proton-c-0.20.0
>
>
> A connection Open frame is created with the intent of limiting the peer to
> exactly one link.
> {noformat}
> pn_transport_set_channel_max(pn_trans, 0);
> {noformat}
> Proton encodes the frame with a null 0x40 going over the wire in the
> channel-max slot.
> A receiving application treats the value as 'default' and uses the spec
> default value of 65535. If the receiving application had received a 0x43
> (types:encoding uint:uint0) it would have used the intended channel max of 0.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1174) Proton C encodes Open.channel-max 0 as a null and not as a uint.
[
https://issues.apache.org/jira/browse/PROTON-1174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16336401#comment-16336401
]
Andrew Stitcher commented on PROTON-1174:
-
[~chug] can you confirm what AMQP lib the receiving app is using here:
As far as I can tell proton-c has a matching bug on receiving an OPEN frame. In
other words it will interpret no channel_max as meaning 0 upon receipt as well
as sending.
> Proton C encodes Open.channel-max 0 as a null and not as a uint.
>
>
> Key: PROTON-1174
> URL: https://issues.apache.org/jira/browse/PROTON-1174
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.12.0
>Reporter: Chuck Rolke
>Assignee: Andrew Stitcher
>Priority: Major
> Labels: codec
> Fix For: proton-c-0.20.0
>
>
> A connection Open frame is created with the intent of limiting the peer to
> exactly one link.
> {noformat}
> pn_transport_set_channel_max(pn_trans, 0);
> {noformat}
> Proton encodes the frame with a null 0x40 going over the wire in the
> channel-max slot.
> A receiving application treats the value as 'default' and uses the spec
> default value of 65535. If the receiving application had received a 0x43
> (types:encoding uint:uint0) it would have used the intended channel max of 0.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1719) Extend compiler coverage in Windows CI
[ https://issues.apache.org/jira/browse/PROTON-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Stitcher resolved PROTON-1719. - Resolution: Fixed > Extend compiler coverage in Windows CI > -- > > Key: PROTON-1719 > URL: https://issues.apache.org/jira/browse/PROTON-1719 > Project: Qpid Proton > Issue Type: Task > Components: proton-c >Reporter: Justin Ross >Assignee: Andrew Stitcher >Priority: Major > Fix For: proton-c-0.20.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1719) Extend compiler coverage in Windows CI
[ https://issues.apache.org/jira/browse/PROTON-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16336367#comment-16336367 ] ASF subversion and git services commented on PROTON-1719: - Commit 1af693c56d9040cad599c922b8f525dc48ba4084 in qpid-proton's branch refs/heads/master from [~astitcher] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=1af693c ] PROTON-1719: Extend Windows CI (Appveyor) compiler coverage - Compile using VS 2017, VS 2013, VS 2010 (these are the agreed supported VS versions) - Previously just compiled using VS 2013 > Extend compiler coverage in Windows CI > -- > > Key: PROTON-1719 > URL: https://issues.apache.org/jira/browse/PROTON-1719 > Project: Qpid Proton > Issue Type: Task > Components: proton-c >Reporter: Justin Ross >Assignee: Andrew Stitcher >Priority: Major > Fix For: proton-c-0.20.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-901) add authz support to auth service plugin
[ https://issues.apache.org/jira/browse/DISPATCH-901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16336360#comment-16336360 ] ASF subversion and git services commented on DISPATCH-901: -- Commit 7d32b0e85dc4e917f2df23ea527e478c3316c8d5 in qpid-dispatch's branch refs/heads/master from [~gsim] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=7d32b0e ] DISPATCH-901: revert previous commit (i.e. some extra debugging to help diagnose CI issue) This reverts commit 2e34afd3a46a141b3dd8451daaca96d11e471637. > add authz support to auth service plugin > > > Key: DISPATCH-901 > URL: https://issues.apache.org/jira/browse/DISPATCH-901 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Gordon Sim >Assignee: Gordon Sim >Priority: Major > > It would be more useful to have the auth service provide a set of permissions > for the user if successfully authenticated, rathe rthan having to define > these in config files for each router in a network. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1751) Various doc improvements
[ https://issues.apache.org/jira/browse/PROTON-1751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16336361#comment-16336361 ] ASF subversion and git services commented on PROTON-1751: - Commit 27e33752c9e684d84728f11aaea2327c5448d30e 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=27e3375 ] PROTON-1751: Document that accept doesn't work with transactions > Various doc improvements > > > Key: PROTON-1751 > URL: https://issues.apache.org/jira/browse/PROTON-1751 > Project: Qpid Proton > Issue Type: Improvement > Components: python-binding >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Major > Fix For: proton-c-0.20.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1751) Various doc improvements
Justin Ross created PROTON-1751: --- Summary: Various doc improvements Key: PROTON-1751 URL: https://issues.apache.org/jira/browse/PROTON-1751 Project: Qpid Proton Issue Type: Improvement Components: python-binding Reporter: Justin Ross Assignee: Justin Ross Fix For: proton-c-0.20.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1728) [proton-c] Reorganize the source tree now that Proton J is split off
[ https://issues.apache.org/jira/browse/PROTON-1728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1728: Fix Version/s: (was: proton-c-0.20.0) proton-c-0.21.0 > [proton-c] Reorganize the source tree now that Proton J is split off > > > Key: PROTON-1728 > URL: https://issues.apache.org/jira/browse/PROTON-1728 > Project: Qpid Proton > Issue Type: Task > Components: proton-c >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Major > Fix For: proton-c-0.21.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-342) installing into custom location doesn't work nicely (and is not properly documented)
[ https://issues.apache.org/jira/browse/PROTON-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-342: --- Fix Version/s: (was: proton-c-0.20.0) proton-c-0.22.0 > installing into custom location doesn't work nicely (and is not properly > documented) > > > Key: PROTON-342 > URL: https://issues.apache.org/jira/browse/PROTON-342 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 >Reporter: Gordon Sim >Assignee: Justin Ross >Priority: Major > Labels: docs > Fix For: proton-c-0.22.0 > > > The README suggests setting -DCMAKE_INSTALL_PREFIX when running cmake, it > does not mention setting DESTDIR when invoking make install. > If you don't set the DESTDIR on make install it will honour the > CMAKE_INSTALL_PREFIX for some parts of the installation (e.g. header files, > native libraries, pkg-config file etc) but the python bindings (and I assume > other bindings) will still install in the standard location which will fail > if you are not running as root. > However if you set DESTDIR then this alters the location of the headers, > libraries and pkg-config , which now install into > $DESTDIR/$CMAKE_INSTALL_PREFIX and the pkg-config file no longer has the > correct include or library paths in it. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-918) Improve router config consistency and metadata
[ https://issues.apache.org/jira/browse/DISPATCH-918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated DISPATCH-918: - Summary: Improve router config consistency and metadata (was: Improve router config consistency) > Improve router config consistency and metadata > -- > > Key: DISPATCH-918 > URL: https://issues.apache.org/jira/browse/DISPATCH-918 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Justin Ross >Assignee: Ganesh Murthy >Priority: Major > > Proposed changes from review. The items marked PRIO1 are more important. > All changes must be backward-compatible. > [https://docs.google.com/spreadsheets/d/14ugjxlc-ETYZXwN9eWD-D1YWrRAfydj9EJNmyUaZrD0/edit?usp=sharing] > This also includes flags we'd like to get added to the metadata so we can > generate better docs from it. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-918) Improve router config consistency
[ https://issues.apache.org/jira/browse/DISPATCH-918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated DISPATCH-918: - Description: Proposed changes from review. The items marked PRIO1 are more important. All changes must be backward-compatible. [https://docs.google.com/spreadsheets/d/14ugjxlc-ETYZXwN9eWD-D1YWrRAfydj9EJNmyUaZrD0/edit?usp=sharing] This also includes flags we'd like to get added to the metadata so we can generate better docs from it. was: Proposed changes from review. The items marked PRIO1 are more important. All changes must be backward-compatible. https://docs.google.com/spreadsheets/d/14ugjxlc-ETYZXwN9eWD-D1YWrRAfydj9EJNmyUaZrD0/edit?usp=sharing > Improve router config consistency > - > > Key: DISPATCH-918 > URL: https://issues.apache.org/jira/browse/DISPATCH-918 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Justin Ross >Assignee: Ganesh Murthy >Priority: Major > > Proposed changes from review. The items marked PRIO1 are more important. > All changes must be backward-compatible. > [https://docs.google.com/spreadsheets/d/14ugjxlc-ETYZXwN9eWD-D1YWrRAfydj9EJNmyUaZrD0/edit?usp=sharing] > This also includes flags we'd like to get added to the metadata so we can > generate better docs from it. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (PROTON-1629) [cpp] proton::container is not move constructible
[
https://issues.apache.org/jira/browse/PROTON-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross closed PROTON-1629.
---
> [cpp] proton::container is not move constructible
> -
>
> Key: PROTON-1629
> URL: https://issues.apache.org/jira/browse/PROTON-1629
> Project: Qpid Proton
> Issue Type: Improvement
> Components: cpp-binding
>Affects Versions: proton-c-0.18.0
> Environment: Linux, gcc (GCC) 7.0.1 20170409 (experimental), git tip
> at
> commit 72b7ea0508e94aae3e5d9470293bc5c7e8250a45 (upstream/master)
> PROTON-1592: [python] restore original tx_recv.py example
>Reporter: Jiri Daněk
>Assignee: Andrew Stitcher
>Priority: Minor
>
> Following C++11 code does not compile
> {code}
> auto handler = proton::messaging_handler();
> auto container = proton::container(handler); // container is not move
> constructible
> {code}
> Error from GCC is
> {noformat}
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/src/container_test.cpp:
> In function ‘int {anonymous}::test_container_schedule_multithreaded()’:
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/src/container_test.cpp:591:47:
> error: use of deleted function ‘proton::container::container(const
> proton::container&)’
> auto container = proton::container(handler); // container is not move
> constructible
>^
> In file included from
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/src/container_test.cpp:28:0:
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/include/proton/container.hpp:55:27:
> note: ‘proton::container::container(const proton::container&)’ is implicitly
> deleted because the default definition would be ill-formed:
> class PN_CPP_CLASS_EXTERN container {
>^
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/include/proton/container.hpp:55:27:
> error: use of deleted function ‘constexpr
> proton::internal::pn_unique_ptr::pn_unique_ptr(const
> proton::internal::pn_unique_ptr&)’
> In file included from
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/include/proton/connection_options.hpp:29:0,
> from
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/src/container_test.cpp:27:
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/include/proton/./internal/pn_unique_ptr.hpp:43:26:
> note: ‘constexpr
> proton::internal::pn_unique_ptr::pn_unique_ptr(const
> proton::internal::pn_unique_ptr&)’ is implicitly
> declared as deleted because
> ‘proton::internal::pn_unique_ptr’ declares a move
> constructor or move assignment operator
> template class pn_unique_ptr {
> ^
> make[3]: ***
> [proton-c/bindings/cpp/CMakeFiles/container_test.dir/build.make:63:
> proton-c/bindings/cpp/CMakeFiles/container_test.dir/src/container_test.cpp.o]
> Error 1
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1629) [cpp] proton::container is not move constructible
[
https://issues.apache.org/jira/browse/PROTON-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated PROTON-1629:
Fix Version/s: (was: proton-c-0.20.0)
> [cpp] proton::container is not move constructible
> -
>
> Key: PROTON-1629
> URL: https://issues.apache.org/jira/browse/PROTON-1629
> Project: Qpid Proton
> Issue Type: Improvement
> Components: cpp-binding
>Affects Versions: proton-c-0.18.0
> Environment: Linux, gcc (GCC) 7.0.1 20170409 (experimental), git tip
> at
> commit 72b7ea0508e94aae3e5d9470293bc5c7e8250a45 (upstream/master)
> PROTON-1592: [python] restore original tx_recv.py example
>Reporter: Jiri Daněk
>Assignee: Andrew Stitcher
>Priority: Minor
>
> Following C++11 code does not compile
> {code}
> auto handler = proton::messaging_handler();
> auto container = proton::container(handler); // container is not move
> constructible
> {code}
> Error from GCC is
> {noformat}
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/src/container_test.cpp:
> In function ‘int {anonymous}::test_container_schedule_multithreaded()’:
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/src/container_test.cpp:591:47:
> error: use of deleted function ‘proton::container::container(const
> proton::container&)’
> auto container = proton::container(handler); // container is not move
> constructible
>^
> In file included from
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/src/container_test.cpp:28:0:
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/include/proton/container.hpp:55:27:
> note: ‘proton::container::container(const proton::container&)’ is implicitly
> deleted because the default definition would be ill-formed:
> class PN_CPP_CLASS_EXTERN container {
>^
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/include/proton/container.hpp:55:27:
> error: use of deleted function ‘constexpr
> proton::internal::pn_unique_ptr::pn_unique_ptr(const
> proton::internal::pn_unique_ptr&)’
> In file included from
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/include/proton/connection_options.hpp:29:0,
> from
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/src/container_test.cpp:27:
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/include/proton/./internal/pn_unique_ptr.hpp:43:26:
> note: ‘constexpr
> proton::internal::pn_unique_ptr::pn_unique_ptr(const
> proton::internal::pn_unique_ptr&)’ is implicitly
> declared as deleted because
> ‘proton::internal::pn_unique_ptr’ declares a move
> constructor or move assignment operator
> template class pn_unique_ptr {
> ^
> make[3]: ***
> [proton-c/bindings/cpp/CMakeFiles/container_test.dir/build.make:63:
> proton-c/bindings/cpp/CMakeFiles/container_test.dir/src/container_test.cpp.o]
> Error 1
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-918) Improve router config consistency
Justin Ross created DISPATCH-918: Summary: Improve router config consistency Key: DISPATCH-918 URL: https://issues.apache.org/jira/browse/DISPATCH-918 Project: Qpid Dispatch Issue Type: Improvement Reporter: Justin Ross Proposed changes from review. The items marked PRIO1 are more important. All changes must be backward-compatible. https://docs.google.com/spreadsheets/d/14ugjxlc-ETYZXwN9eWD-D1YWrRAfydj9EJNmyUaZrD0/edit?usp=sharing -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-918) Improve router config consistency
[ https://issues.apache.org/jira/browse/DISPATCH-918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross reassigned DISPATCH-918: Assignee: Ganesh Murthy > Improve router config consistency > - > > Key: DISPATCH-918 > URL: https://issues.apache.org/jira/browse/DISPATCH-918 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Justin Ross >Assignee: Ganesh Murthy >Priority: Major > > Proposed changes from review. The items marked PRIO1 are more important. > All changes must be backward-compatible. > > https://docs.google.com/spreadsheets/d/14ugjxlc-ETYZXwN9eWD-D1YWrRAfydj9EJNmyUaZrD0/edit?usp=sharing -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-89) Model the legacy topic exchange behavior of qpidd
[
https://issues.apache.org/jira/browse/DISPATCH-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16336250#comment-16336250
]
ASF GitHub Bot commented on DISPATCH-89:
Github user ssorj commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/244#discussion_r163344546
--- Diff: python/qpid_dispatch/management/qdrouter.json ---
@@ -1126,6 +1126,106 @@
}
},
+"router.config.exchange": {
+"description":"[EXPERIMENTAL] Defines a topic exchange.",
+"extends": "configurationEntity",
+"operations": ["CREATE", "DELETE"],
+"attributes": {
+"address": {
--- End diff --
I think address on router.node should change to "addr". It's the only
outlier. The rest of the config is using "addr" consistently.
Side note: "address" for one address and "addr" for multiple addresses is
an automatic user gotcha. There is zero help for the user in those names.
And data point: The doc for "addr" on autoLink says it is just one address.
> Model the legacy topic exchange behavior of qpidd
> -
>
> Key: DISPATCH-89
> URL: https://issues.apache.org/jira/browse/DISPATCH-89
> Project: Qpid Dispatch
> Issue Type: New Feature
> Components: Routing Engine
>Affects Versions: 0.2
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
>
> With Qpidd, a user can define a binding from an Exchange to a target queue.
> The binding uses a key that is compared to a message's subject field. If the
> key matches, the message is routed to the target queue for that binding.
> It should be possible to emulate this behavior using the dispatch router.
> Example:
> User defines a mappings from a target address (the 'exchange') to a different
> target address(es) (the 'queue'). These mappings (the 'bindings') are driven
> by a pattern match against the inbound message's subject field.
> Messages arriving at the router from any link whose target address has
> bindings defined are not immediately routed. Prior to routing, the message's
> subject field is extracted and compared against each binding defined for the
> target. A list of new target addresses is created containing the target
> address from each binding that satisfied the pattern match. The message is
> then routed to each new target address.
> The pattern syntax should be the same 'dotted string' notation from qpidd,
> including '*' and "#' wildcarding.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #244: DISPATCH-89: Exchange Binding forwarder (ex...
Github user ssorj commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/244#discussion_r163344546
--- Diff: python/qpid_dispatch/management/qdrouter.json ---
@@ -1126,6 +1126,106 @@
}
},
+"router.config.exchange": {
+"description":"[EXPERIMENTAL] Defines a topic exchange.",
+"extends": "configurationEntity",
+"operations": ["CREATE", "DELETE"],
+"attributes": {
+"address": {
--- End diff --
I think address on router.node should change to "addr". It's the only
outlier. The rest of the config is using "addr" consistently.
Side note: "address" for one address and "addr" for multiple addresses is
an automatic user gotcha. There is zero help for the user in those names.
And data point: The doc for "addr" on autoLink says it is just one address.
---
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-89) Model the legacy topic exchange behavior of qpidd
[
https://issues.apache.org/jira/browse/DISPATCH-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16336200#comment-16336200
]
ASF GitHub Bot commented on DISPATCH-89:
Github user kgiusti commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/244#discussion_r163335294
--- Diff: python/qpid_dispatch/management/qdrouter.json ---
@@ -1126,6 +1126,106 @@
}
},
+"router.config.exchange": {
+"description":"[EXPERIMENTAL] Defines a topic exchange.",
+"extends": "configurationEntity",
+"operations": ["CREATE", "DELETE"],
+"attributes": {
+"address": {
--- End diff --
We haven't been very good at being consistent with naming: the router.node
itself has an "address" attribute, while the config.autoLink's address is
labeled with 'addr'.
There are a few attributes that have 'addr' as a prefix or a suffix to the
full name, e.g.:
addrCount, owningAddr, and externalAddr.
So we're already inconsistent to some degree. I'd favor using 'address' as
the attribute name for an entity that has a single address attribute, and use
the "Addr" for those entities with more than one address attribute. So
my opinion is to keep the 'address' as is.
However, I'm no UI expert by any means. Hmmm Let me see if I can
channel the Ghost of Steve Jobs and see what his reaction is
Don't be consistent - be Brave!!!
Oh, and you're holding that wrong
jk! ;D
> Model the legacy topic exchange behavior of qpidd
> -
>
> Key: DISPATCH-89
> URL: https://issues.apache.org/jira/browse/DISPATCH-89
> Project: Qpid Dispatch
> Issue Type: New Feature
> Components: Routing Engine
>Affects Versions: 0.2
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
>
> With Qpidd, a user can define a binding from an Exchange to a target queue.
> The binding uses a key that is compared to a message's subject field. If the
> key matches, the message is routed to the target queue for that binding.
> It should be possible to emulate this behavior using the dispatch router.
> Example:
> User defines a mappings from a target address (the 'exchange') to a different
> target address(es) (the 'queue'). These mappings (the 'bindings') are driven
> by a pattern match against the inbound message's subject field.
> Messages arriving at the router from any link whose target address has
> bindings defined are not immediately routed. Prior to routing, the message's
> subject field is extracted and compared against each binding defined for the
> target. A list of new target addresses is created containing the target
> address from each binding that satisfied the pattern match. The message is
> then routed to each new target address.
> The pattern syntax should be the same 'dotted string' notation from qpidd,
> including '*' and "#' wildcarding.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #244: DISPATCH-89: Exchange Binding forwarder (ex...
Github user kgiusti commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/244#discussion_r163335294
--- Diff: python/qpid_dispatch/management/qdrouter.json ---
@@ -1126,6 +1126,106 @@
}
},
+"router.config.exchange": {
+"description":"[EXPERIMENTAL] Defines a topic exchange.",
+"extends": "configurationEntity",
+"operations": ["CREATE", "DELETE"],
+"attributes": {
+"address": {
--- End diff --
We haven't been very good at being consistent with naming: the router.node
itself has an "address" attribute, while the config.autoLink's address is
labeled with 'addr'.
There are a few attributes that have 'addr' as a prefix or a suffix to the
full name, e.g.:
addrCount, owningAddr, and externalAddr.
So we're already inconsistent to some degree. I'd favor using 'address' as
the attribute name for an entity that has a single address attribute, and use
the "Addr" for those entities with more than one address attribute. So
my opinion is to keep the 'address' as is.
However, I'm no UI expert by any means. Hmmm Let me see if I can
channel the Ghost of Steve Jobs and see what his reaction is
Don't be consistent - be Brave!!!
Oh, and you're holding that wrong
jk! ;D
---
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1629) [cpp] proton::container is not move constructible
[
https://issues.apache.org/jira/browse/PROTON-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher resolved PROTON-1629.
-
Resolution: Not A Bug
> [cpp] proton::container is not move constructible
> -
>
> Key: PROTON-1629
> URL: https://issues.apache.org/jira/browse/PROTON-1629
> Project: Qpid Proton
> Issue Type: Improvement
> Components: cpp-binding
>Affects Versions: proton-c-0.18.0
> Environment: Linux, gcc (GCC) 7.0.1 20170409 (experimental), git tip
> at
> commit 72b7ea0508e94aae3e5d9470293bc5c7e8250a45 (upstream/master)
> PROTON-1592: [python] restore original tx_recv.py example
>Reporter: Jiri Daněk
>Assignee: Andrew Stitcher
>Priority: Minor
> Fix For: proton-c-0.20.0
>
>
> Following C++11 code does not compile
> {code}
> auto handler = proton::messaging_handler();
> auto container = proton::container(handler); // container is not move
> constructible
> {code}
> Error from GCC is
> {noformat}
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/src/container_test.cpp:
> In function ‘int {anonymous}::test_container_schedule_multithreaded()’:
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/src/container_test.cpp:591:47:
> error: use of deleted function ‘proton::container::container(const
> proton::container&)’
> auto container = proton::container(handler); // container is not move
> constructible
>^
> In file included from
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/src/container_test.cpp:28:0:
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/include/proton/container.hpp:55:27:
> note: ‘proton::container::container(const proton::container&)’ is implicitly
> deleted because the default definition would be ill-formed:
> class PN_CPP_CLASS_EXTERN container {
>^
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/include/proton/container.hpp:55:27:
> error: use of deleted function ‘constexpr
> proton::internal::pn_unique_ptr::pn_unique_ptr(const
> proton::internal::pn_unique_ptr&)’
> In file included from
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/include/proton/connection_options.hpp:29:0,
> from
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/src/container_test.cpp:27:
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/include/proton/./internal/pn_unique_ptr.hpp:43:26:
> note: ‘constexpr
> proton::internal::pn_unique_ptr::pn_unique_ptr(const
> proton::internal::pn_unique_ptr&)’ is implicitly
> declared as deleted because
> ‘proton::internal::pn_unique_ptr’ declares a move
> constructor or move assignment operator
> template class pn_unique_ptr {
> ^
> make[3]: ***
> [proton-c/bindings/cpp/CMakeFiles/container_test.dir/build.make:63:
> proton-c/bindings/cpp/CMakeFiles/container_test.dir/src/container_test.cpp.o]
> Error 1
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1629) [cpp] proton::container is not move constructible
[
https://issues.apache.org/jira/browse/PROTON-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16336171#comment-16336171
]
Andrew Stitcher commented on PROTON-1629:
-
If you want move construction you need to use {{auto&&}}
so the code snippet above would be:
{noformat}
auto&& handler = proton::messaging_handler();
auto&& container = proton::container(handler);
{noformat}
> [cpp] proton::container is not move constructible
> -
>
> Key: PROTON-1629
> URL: https://issues.apache.org/jira/browse/PROTON-1629
> Project: Qpid Proton
> Issue Type: Improvement
> Components: cpp-binding
>Affects Versions: proton-c-0.18.0
> Environment: Linux, gcc (GCC) 7.0.1 20170409 (experimental), git tip
> at
> commit 72b7ea0508e94aae3e5d9470293bc5c7e8250a45 (upstream/master)
> PROTON-1592: [python] restore original tx_recv.py example
>Reporter: Jiri Daněk
>Assignee: Andrew Stitcher
>Priority: Minor
> Fix For: proton-c-0.20.0
>
>
> Following C++11 code does not compile
> {code}
> auto handler = proton::messaging_handler();
> auto container = proton::container(handler); // container is not move
> constructible
> {code}
> Error from GCC is
> {noformat}
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/src/container_test.cpp:
> In function ‘int {anonymous}::test_container_schedule_multithreaded()’:
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/src/container_test.cpp:591:47:
> error: use of deleted function ‘proton::container::container(const
> proton::container&)’
> auto container = proton::container(handler); // container is not move
> constructible
>^
> In file included from
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/src/container_test.cpp:28:0:
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/include/proton/container.hpp:55:27:
> note: ‘proton::container::container(const proton::container&)’ is implicitly
> deleted because the default definition would be ill-formed:
> class PN_CPP_CLASS_EXTERN container {
>^
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/include/proton/container.hpp:55:27:
> error: use of deleted function ‘constexpr
> proton::internal::pn_unique_ptr::pn_unique_ptr(const
> proton::internal::pn_unique_ptr&)’
> In file included from
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/include/proton/connection_options.hpp:29:0,
> from
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/src/container_test.cpp:27:
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/include/proton/./internal/pn_unique_ptr.hpp:43:26:
> note: ‘constexpr
> proton::internal::pn_unique_ptr::pn_unique_ptr(const
> proton::internal::pn_unique_ptr&)’ is implicitly
> declared as deleted because
> ‘proton::internal::pn_unique_ptr’ declares a move
> constructor or move assignment operator
> template class pn_unique_ptr {
> ^
> make[3]: ***
> [proton-c/bindings/cpp/CMakeFiles/container_test.dir/build.make:63:
> proton-c/bindings/cpp/CMakeFiles/container_test.dir/src/container_test.cpp.o]
> Error 1
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1629) [cpp] proton::container is not move constructible
[
https://issues.apache.org/jira/browse/PROTON-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16336145#comment-16336145
]
Andrew Stitcher commented on PROTON-1629:
-
Actually the compile error is that there is not a *copy* assignment, and there
cannot be one because pn_unique_ptr can only be moved and never copied.
Why the compiler isn't trying to use a move assignment/constructor does not
appear obvious to me at this point - I shall think about it some more!
> [cpp] proton::container is not move constructible
> -
>
> Key: PROTON-1629
> URL: https://issues.apache.org/jira/browse/PROTON-1629
> Project: Qpid Proton
> Issue Type: Improvement
> Components: cpp-binding
>Affects Versions: proton-c-0.18.0
> Environment: Linux, gcc (GCC) 7.0.1 20170409 (experimental), git tip
> at
> commit 72b7ea0508e94aae3e5d9470293bc5c7e8250a45 (upstream/master)
> PROTON-1592: [python] restore original tx_recv.py example
>Reporter: Jiri Daněk
>Assignee: Andrew Stitcher
>Priority: Minor
> Fix For: proton-c-0.20.0
>
>
> Following C++11 code does not compile
> {code}
> auto handler = proton::messaging_handler();
> auto container = proton::container(handler); // container is not move
> constructible
> {code}
> Error from GCC is
> {noformat}
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/src/container_test.cpp:
> In function ‘int {anonymous}::test_container_schedule_multithreaded()’:
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/src/container_test.cpp:591:47:
> error: use of deleted function ‘proton::container::container(const
> proton::container&)’
> auto container = proton::container(handler); // container is not move
> constructible
>^
> In file included from
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/src/container_test.cpp:28:0:
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/include/proton/container.hpp:55:27:
> note: ‘proton::container::container(const proton::container&)’ is implicitly
> deleted because the default definition would be ill-formed:
> class PN_CPP_CLASS_EXTERN container {
>^
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/include/proton/container.hpp:55:27:
> error: use of deleted function ‘constexpr
> proton::internal::pn_unique_ptr::pn_unique_ptr(const
> proton::internal::pn_unique_ptr&)’
> In file included from
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/include/proton/connection_options.hpp:29:0,
> from
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/src/container_test.cpp:27:
> /home/jdanek/Work/repos/qpid-proton/proton-c/bindings/cpp/include/proton/./internal/pn_unique_ptr.hpp:43:26:
> note: ‘constexpr
> proton::internal::pn_unique_ptr::pn_unique_ptr(const
> proton::internal::pn_unique_ptr&)’ is implicitly
> declared as deleted because
> ‘proton::internal::pn_unique_ptr’ declares a move
> constructor or move assignment operator
> template class pn_unique_ptr {
> ^
> make[3]: ***
> [proton-c/bindings/cpp/CMakeFiles/container_test.dir/build.make:63:
> proton-c/bindings/cpp/CMakeFiles/container_test.dir/src/container_test.cpp.o]
> Error 1
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8062) [Broker-J][AMQP 1.0] Fix handling of routing errors when target destination cannot route received message
[
https://issues.apache.org/jira/browse/QPID-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16336132#comment-16336132
]
ASF subversion and git services commented on QPID-8062:
---
Commit 8cf9f1d31aef411f0fd20055e34d37de7c50098b 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=8cf9f1d ]
QPID-8062: [Broker-J][AMQP 1.0] Add more tests
> [Broker-J][AMQP 1.0] Fix handling of routing errors when target destination
> cannot route received message
> -
>
> Key: QPID-8062
> URL: https://issues.apache.org/jira/browse/QPID-8062
> Project: Qpid
> Issue Type: Bug
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.0.1
>
> Attachments:
> 0001-QPID-8062-Broker-J-AMQP-1.0-Move-responsibility-to-c.patch
>
>
> As per section "2.2.2 Routing Errors" of "Using the Anonymous Terminus for
> Message Routing Version 1.0":
> {quote}
> If the source of the link does not support the rejected outcome, or the
> message has already been settled by the sender, then the routing node MUST
> detach the link with an error. The error sent by the routing node MUST
> contain the error which would have been communicated in the detach sent on
> attempting to link directly to the address in the message’s to field.
> Additionally the info field of error MUST contain an entry with symbolic key
> delivery-tag and binary value of the delivery-tag of the message which caused
> the failure.
> {quote}
> The Broker-J does not handle the case when message is sent pre-settled and is
> rejected by the destination. We need to add the support for this behaviour.
> Additionally, if a pre-settled message is published within a transaction and
> cannot be routed by a queue/exchange/whatever then have the transactional
> resource
> logically mark the transaction as"rollback only" (i.e. failed)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-89) Model the legacy topic exchange behavior of qpidd
[
https://issues.apache.org/jira/browse/DISPATCH-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16336116#comment-16336116
]
ASF GitHub Bot commented on DISPATCH-89:
Github user ssorj commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/244#discussion_r163318304
--- Diff: python/qpid_dispatch/management/qdrouter.json ---
@@ -1126,6 +1126,106 @@
}
},
+"router.config.exchange": {
+"description":"[EXPERIMENTAL] Defines a topic exchange.",
+"extends": "configurationEntity",
+"operations": ["CREATE", "DELETE"],
+"attributes": {
+"address": {
--- End diff --
@kgiusti , maybe this should be "addr". That's the established name for
addresses in the config. (I prefer "address", but it's more important to avoid
two different names the same thing.)
> Model the legacy topic exchange behavior of qpidd
> -
>
> Key: DISPATCH-89
> URL: https://issues.apache.org/jira/browse/DISPATCH-89
> Project: Qpid Dispatch
> Issue Type: New Feature
> Components: Routing Engine
>Affects Versions: 0.2
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
>
> With Qpidd, a user can define a binding from an Exchange to a target queue.
> The binding uses a key that is compared to a message's subject field. If the
> key matches, the message is routed to the target queue for that binding.
> It should be possible to emulate this behavior using the dispatch router.
> Example:
> User defines a mappings from a target address (the 'exchange') to a different
> target address(es) (the 'queue'). These mappings (the 'bindings') are driven
> by a pattern match against the inbound message's subject field.
> Messages arriving at the router from any link whose target address has
> bindings defined are not immediately routed. Prior to routing, the message's
> subject field is extracted and compared against each binding defined for the
> target. A list of new target addresses is created containing the target
> address from each binding that satisfied the pattern match. The message is
> then routed to each new target address.
> The pattern syntax should be the same 'dotted string' notation from qpidd,
> including '*' and "#' wildcarding.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #244: DISPATCH-89: Exchange Binding forwarder (ex...
Github user ssorj commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/244#discussion_r163318304
--- Diff: python/qpid_dispatch/management/qdrouter.json ---
@@ -1126,6 +1126,106 @@
}
},
+"router.config.exchange": {
+"description":"[EXPERIMENTAL] Defines a topic exchange.",
+"extends": "configurationEntity",
+"operations": ["CREATE", "DELETE"],
+"attributes": {
+"address": {
--- End diff --
@kgiusti , maybe this should be "addr". That's the established name for
addresses in the config. (I prefer "address", but it's more important to avoid
two different names the same thing.)
---
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-1750) Create test for address info on inbound sockets
[ https://issues.apache.org/jira/browse/PROTON-1750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated PROTON-1750: Fix Version/s: proton-c-0.21.0 > Create test for address info on inbound sockets > --- > > Key: PROTON-1750 > URL: https://issues.apache.org/jira/browse/PROTON-1750 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: proton-c-0.20.0 >Reporter: Cliff Jansen >Priority: Minor > Fix For: proton-c-0.21.0 > > > PROTON-1745 fixed changed behavior required by qpid-dispatch. > It is thought that all proactors currently work correctly. Create test to > verify and prevent future regressions. > Also review if Doc needs corresponding updating. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-1745) [proton-c, regression] PN_CONNECTION_BOUND event is emitted too soon
[
https://issues.apache.org/jira/browse/PROTON-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross reassigned PROTON-1745:
---
Assignee: Cliff Jansen (was: Justin Ross)
> [proton-c, regression] PN_CONNECTION_BOUND event is emitted too soon
>
>
> Key: PROTON-1745
> URL: https://issues.apache.org/jira/browse/PROTON-1745
> Project: Qpid Proton
> Issue Type: Bug
>Affects Versions: proton-c-0.20.0
> Environment: Fedora 27
>Reporter: Chuck Rolke
>Assignee: Cliff Jansen
>Priority: Major
> Fix For: proton-c-0.20.0
>
> Attachments: p1745_0.diff
>
>
> During a PN_CONNECTION_BOUND event proton socket information is not
> available. At PN_CONNECTION_REMOTE_OPEN the info is available.
> I instrumented an event loop in qpid-dispatch to log the event names as they
> are delivered and to log the result of creating a qd_connection rhost_port
> name. The source:
> {noformat}
> case PN_CONNECTION_BOUND:
> on_connection_bound(qd_server, e);
> // HACK ALERT
> pn_connection_t *pn_conn = pn_event_connection(e);
> qd_connection_t *qd_conn = pn_connection_get_context(pn_conn);
> set_rhost_port(pn_conn, qd_conn);
> qd_log(qd_server->log_source, QD_LOG_CRITICAL,
> "At end of connection bound the name is: %s",
> qd_connection_name(ctx));
> // END HACK ALERT
> break;
> case PN_CONNECTION_REMOTE_OPEN:
> {
> // HACK ALERT
> pn_connection_t *pn_conn = pn_event_connection(e);
> qd_connection_t *qd_conn = pn_connection_get_context(pn_conn);
> set_rhost_port(pn_conn, qd_conn);
> qd_log(qd_server->log_source, QD_LOG_CRITICAL,
> "At entry to remote open the name is: %s",
> qd_connection_name(ctx));
> /// END HACK ALERT
> {noformat}
>
> The log file shows:
> {noformat}
> 2018-01-17 12:38:35.224859 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_INIT (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224868 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_BOUND (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224890 -0500 SERVER (critical) At end of connection bound
> the name is: err: -6 (/home/chug/git/qpid-dispatch/src/server.c:887)
> 2018-01-17 12:38:35.224965 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_REMOTE_OPEN (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224971 -0500 SERVER (critical) At entry to remote open
> the name is: 127.0.0.1:46722
> (/home/chug/git/qpid-dispatch/src/server.c:895){noformat}
> The "err -6" is a snoop on the return result of getnameinfo(): EAI_FAMILY
> 'ai_family' not supported. I suspect it's because the returned socket is junk.
> The code works correctly in 0.19.0, commit fe3c3
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (PROTON-1745) [proton-c, regression] PN_CONNECTION_BOUND event is emitted too soon
[
https://issues.apache.org/jira/browse/PROTON-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cliff Jansen resolved PROTON-1745.
--
Resolution: Fixed
Separate issue create for future test:
https://issues.apache.org/jira/browse/PROTON-1750
> [proton-c, regression] PN_CONNECTION_BOUND event is emitted too soon
>
>
> Key: PROTON-1745
> URL: https://issues.apache.org/jira/browse/PROTON-1745
> Project: Qpid Proton
> Issue Type: Bug
>Affects Versions: proton-c-0.20.0
> Environment: Fedora 27
>Reporter: Chuck Rolke
>Assignee: Justin Ross
>Priority: Major
> Fix For: proton-c-0.20.0
>
> Attachments: p1745_0.diff
>
>
> During a PN_CONNECTION_BOUND event proton socket information is not
> available. At PN_CONNECTION_REMOTE_OPEN the info is available.
> I instrumented an event loop in qpid-dispatch to log the event names as they
> are delivered and to log the result of creating a qd_connection rhost_port
> name. The source:
> {noformat}
> case PN_CONNECTION_BOUND:
> on_connection_bound(qd_server, e);
> // HACK ALERT
> pn_connection_t *pn_conn = pn_event_connection(e);
> qd_connection_t *qd_conn = pn_connection_get_context(pn_conn);
> set_rhost_port(pn_conn, qd_conn);
> qd_log(qd_server->log_source, QD_LOG_CRITICAL,
> "At end of connection bound the name is: %s",
> qd_connection_name(ctx));
> // END HACK ALERT
> break;
> case PN_CONNECTION_REMOTE_OPEN:
> {
> // HACK ALERT
> pn_connection_t *pn_conn = pn_event_connection(e);
> qd_connection_t *qd_conn = pn_connection_get_context(pn_conn);
> set_rhost_port(pn_conn, qd_conn);
> qd_log(qd_server->log_source, QD_LOG_CRITICAL,
> "At entry to remote open the name is: %s",
> qd_connection_name(ctx));
> /// END HACK ALERT
> {noformat}
>
> The log file shows:
> {noformat}
> 2018-01-17 12:38:35.224859 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_INIT (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224868 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_BOUND (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224890 -0500 SERVER (critical) At end of connection bound
> the name is: err: -6 (/home/chug/git/qpid-dispatch/src/server.c:887)
> 2018-01-17 12:38:35.224965 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_REMOTE_OPEN (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224971 -0500 SERVER (critical) At entry to remote open
> the name is: 127.0.0.1:46722
> (/home/chug/git/qpid-dispatch/src/server.c:895){noformat}
> The "err -6" is a snoop on the return result of getnameinfo(): EAI_FAMILY
> 'ai_family' not supported. I suspect it's because the returned socket is junk.
> The code works correctly in 0.19.0, commit fe3c3
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1750) Create test for address info on inbound sockets
Cliff Jansen created PROTON-1750: Summary: Create test for address info on inbound sockets Key: PROTON-1750 URL: https://issues.apache.org/jira/browse/PROTON-1750 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: proton-c-0.20.0 Reporter: Cliff Jansen PROTON-1745 fixed changed behavior required by qpid-dispatch. It is thought that all proactors currently work correctly. Create test to verify and prevent future regressions. Also review if Doc needs corresponding updating. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1745) [proton-c, regression] PN_CONNECTION_BOUND event is emitted too soon
[
https://issues.apache.org/jira/browse/PROTON-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16336087#comment-16336087
]
ASF subversion and git services commented on PROTON-1745:
-
Commit 37c59e9b0ab5cd4475beecae29ad173d33cb55bf in qpid-proton's branch
refs/heads/master from Clifford Jansen
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=37c59e9 ]
PROTON-1745: update address info on inbound connections before
PN_CONNECTION_BOUND event
> [proton-c, regression] PN_CONNECTION_BOUND event is emitted too soon
>
>
> Key: PROTON-1745
> URL: https://issues.apache.org/jira/browse/PROTON-1745
> Project: Qpid Proton
> Issue Type: Bug
>Affects Versions: proton-c-0.20.0
> Environment: Fedora 27
>Reporter: Chuck Rolke
>Assignee: Justin Ross
>Priority: Major
> Fix For: proton-c-0.20.0
>
> Attachments: p1745_0.diff
>
>
> During a PN_CONNECTION_BOUND event proton socket information is not
> available. At PN_CONNECTION_REMOTE_OPEN the info is available.
> I instrumented an event loop in qpid-dispatch to log the event names as they
> are delivered and to log the result of creating a qd_connection rhost_port
> name. The source:
> {noformat}
> case PN_CONNECTION_BOUND:
> on_connection_bound(qd_server, e);
> // HACK ALERT
> pn_connection_t *pn_conn = pn_event_connection(e);
> qd_connection_t *qd_conn = pn_connection_get_context(pn_conn);
> set_rhost_port(pn_conn, qd_conn);
> qd_log(qd_server->log_source, QD_LOG_CRITICAL,
> "At end of connection bound the name is: %s",
> qd_connection_name(ctx));
> // END HACK ALERT
> break;
> case PN_CONNECTION_REMOTE_OPEN:
> {
> // HACK ALERT
> pn_connection_t *pn_conn = pn_event_connection(e);
> qd_connection_t *qd_conn = pn_connection_get_context(pn_conn);
> set_rhost_port(pn_conn, qd_conn);
> qd_log(qd_server->log_source, QD_LOG_CRITICAL,
> "At entry to remote open the name is: %s",
> qd_connection_name(ctx));
> /// END HACK ALERT
> {noformat}
>
> The log file shows:
> {noformat}
> 2018-01-17 12:38:35.224859 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_INIT (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224868 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_BOUND (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224890 -0500 SERVER (critical) At end of connection bound
> the name is: err: -6 (/home/chug/git/qpid-dispatch/src/server.c:887)
> 2018-01-17 12:38:35.224965 -0500 SERVER (critical) * handle sees event:
> PN_CONNECTION_REMOTE_OPEN (/home/chug/git/qpid-dispatch/src/server.c:845)
> 2018-01-17 12:38:35.224971 -0500 SERVER (critical) At entry to remote open
> the name is: 127.0.0.1:46722
> (/home/chug/git/qpid-dispatch/src/server.c:895){noformat}
> The "err -6" is a snoop on the return result of getnameinfo(): EAI_FAMILY
> 'ai_family' not supported. I suspect it's because the returned socket is junk.
> The code works correctly in 0.19.0, commit fe3c3
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-8082) [Broker-J][AMQP 1.0] Clear unsettled map when receiving link is detached due to an error
[
https://issues.apache.org/jira/browse/QPID-8082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy closed QPID-8082.
Resolution: Invalid
The broker behaviour is spec compliant, as there is nothing more can be done
about the transfer. The broker settle the transfer in order to forget about it.
> [Broker-J][AMQP 1.0] Clear unsettled map when receiving link is detached due
> to an error
>
>
> Key: QPID-8082
> URL: https://issues.apache.org/jira/browse/QPID-8082
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.0.1
>
> Attachments:
> 0001-Broker-J-AMQP-1.0-Clear-unsettled-map-when-receiving.patch
>
>
> The link endpoint is destroyed when the link is detached with an error. Such
> link cannot be reattached. Thus, any unsettled deliveries can be safely
> cleared on the link endpoint.
> Clearing of unsettled deliveries should ensure that any undesired disposition
> will not be sent after closing the link as the state carried via such
> disposition should be ignored on peer as per section {{2.7.6 Disposition}} of
> AMQP specification
> {quote}
> The disposition performative MAY refer to deliveries on links that are no
> longer attached. As long as the links have not been closed or detached with
> an error then the deliveries are still “live” and the updated state MUST be
> applied.
> {quote}
> At the moment, the disposition may arrive from detached errant standard
> receiving link endpoint( after its close due to error), when transaction for
> the delivery is discharged (The delivery is settled with null state when
> transaction is rolled back). It does not look right to me to send such
> disposition, as it does not change anything on the peer
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-901) add authz support to auth service plugin
[ https://issues.apache.org/jira/browse/DISPATCH-901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16336045#comment-16336045 ] ASF subversion and git services commented on DISPATCH-901: -- Commit 2e34afd3a46a141b3dd8451daaca96d11e471637 in qpid-dispatch's branch refs/heads/master from [~gsim] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=2e34afd ] DISPATCH-901: some extra debugging to help diagnose CI issue > add authz support to auth service plugin > > > Key: DISPATCH-901 > URL: https://issues.apache.org/jira/browse/DISPATCH-901 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Gordon Sim >Assignee: Gordon Sim >Priority: Major > > It would be more useful to have the auth service provide a set of permissions > for the user if successfully authenticated, rathe rthan having to define > these in config files for each router in a network. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-89) Model the legacy topic exchange behavior of qpidd
[ https://issues.apache.org/jira/browse/DISPATCH-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16335939#comment-16335939 ] ASF GitHub Bot commented on DISPATCH-89: Github user kgiusti commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/244#discussion_r163282364 --- Diff: src/iterator.c --- @@ -909,3 +913,40 @@ void qd_iterator_get_view_cursor( ptr->cursor= iter->view_pointer.cursor; ptr->remaining = iter->view_pointer.remaining; } + + +qd_iterator_t *qd_iterator_clone(const qd_iterator_t *iter, unsigned char **data) --- End diff -- talk with ted to remove > Model the legacy topic exchange behavior of qpidd > - > > Key: DISPATCH-89 > URL: https://issues.apache.org/jira/browse/DISPATCH-89 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Routing Engine >Affects Versions: 0.2 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Major > > With Qpidd, a user can define a binding from an Exchange to a target queue. > The binding uses a key that is compared to a message's subject field. If the > key matches, the message is routed to the target queue for that binding. > It should be possible to emulate this behavior using the dispatch router. > Example: > User defines a mappings from a target address (the 'exchange') to a different > target address(es) (the 'queue'). These mappings (the 'bindings') are driven > by a pattern match against the inbound message's subject field. > Messages arriving at the router from any link whose target address has > bindings defined are not immediately routed. Prior to routing, the message's > subject field is extracted and compared against each binding defined for the > target. A list of new target addresses is created containing the target > address from each binding that satisfied the pattern match. The message is > then routed to each new target address. > The pattern syntax should be the same 'dotted string' notation from qpidd, > including '*' and "#' wildcarding. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #244: DISPATCH-89: Exchange Binding forwarder (ex...
Github user kgiusti commented on a diff in the pull request: https://github.com/apache/qpid-dispatch/pull/244#discussion_r163282364 --- Diff: src/iterator.c --- @@ -909,3 +913,40 @@ void qd_iterator_get_view_cursor( ptr->cursor= iter->view_pointer.cursor; ptr->remaining = iter->view_pointer.remaining; } + + +qd_iterator_t *qd_iterator_clone(const qd_iterator_t *iter, unsigned char **data) --- End diff -- talk with ted to remove --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-89) Model the legacy topic exchange behavior of qpidd
[
https://issues.apache.org/jira/browse/DISPATCH-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16335931#comment-16335931
]
ASF GitHub Bot commented on DISPATCH-89:
Github user kgiusti commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/244#discussion_r163280167
--- Diff: python/qpid_dispatch/management/qdrouter.json ---
@@ -1126,6 +1126,106 @@
}
},
+"router.config.exchange": {
+"description":"[EXPERIMENTAL] Defines a topic exchange.",
+"extends": "configurationEntity",
+"operations": ["CREATE", "DELETE"],
+"attributes": {
+"address": {
+"description": "The address of the exchange.",
+"type": "string",
+"create": true,
+"required": true
+},
+"phase": {
+"type": "integer",
+"description": "The address phase for the exchange.
Defaults to '0'.",
+"create": true,
+"required": false
+},
+"alternate": {
+"description": "The address to forward the message to
if no bindings are matched.",
+"type": "string",
+"create": true,
+"required": false
+},
+"alternatePhase": {
+"type": "integer",
+"description": "The address phase for the alternate
address. Defaults to '0'.",
+"create": true,
+"required": false
+},
+"matchMethod": {
+"description": "Key matching algorithm used. '0-10'
uses the legacy AMQP topic exchange wildcard match method as described in the
0-10 draft. 'mqtt' uses the MQTT topic filter wildcard match method.",
+"type": ["0-10", "mqtt"],
+"default": "0-10",
+"required": false,
+"create": true
+},
+"bindingCount": {
+"description": "The number of bindings associated with
this exchange.",
+"type": "integer",
+"create": false
+},
+"deliveriesReceived": {
+"description": "The total number of deliveries
received by this exchange.",
+"type": "integer",
+"create": false
+},
+"deliveriesDropped": {
+"description": "The total number of deliveries dropped
due to the lack of an outgoing subscription.",
+"type": "integer",
+"create": false
+},
+"deliveriesForwarded": {
+"description": "The total number of deliveries
forwarded via matched bindings.",
+"type": "integer",
+"create": false
+},
+"deliveriesAlternate": {
+"description": "The total number of deliveries
forwarded to the alternate exchange.",
+"type": "integer",
+"create": false
+}
+}
+},
+
+"router.config.binding": {
+"description":"[EXPERIMENTAL] Defines a keyed next hop binding
for an exchange.",
+"extends": "configurationEntity",
+"operations": ["CREATE", "DELETE"],
+"attributes": {
+"exchange": {
+"description": "The name of the exchange to bind.",
+"type": "string",
+"create": true,
+"required": true
+},
+"key": {
+"description": "Pattern to compare against incoming
message's topic. The key is a string of zero or more tokens and wildcards. The
format depends on the matchMethod configured for the exchange. For 0-10 each
token is delimited by the '.' character and wild-card token '*' matches a
single token and '#' matches zero or more tokens. For MQTT each token is
delimited by the '/' character and wildcard token '+' matches a single token
and '#' matches zero or more tokens at the end of the topic.",
+"type": "string",
+"create": true,
+"required": true
--- End diff --
not required update
[GitHub] qpid-dispatch pull request #244: DISPATCH-89: Exchange Binding forwarder (ex...
Github user kgiusti commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/244#discussion_r163280167
--- Diff: python/qpid_dispatch/management/qdrouter.json ---
@@ -1126,6 +1126,106 @@
}
},
+"router.config.exchange": {
+"description":"[EXPERIMENTAL] Defines a topic exchange.",
+"extends": "configurationEntity",
+"operations": ["CREATE", "DELETE"],
+"attributes": {
+"address": {
+"description": "The address of the exchange.",
+"type": "string",
+"create": true,
+"required": true
+},
+"phase": {
+"type": "integer",
+"description": "The address phase for the exchange.
Defaults to '0'.",
+"create": true,
+"required": false
+},
+"alternate": {
+"description": "The address to forward the message to
if no bindings are matched.",
+"type": "string",
+"create": true,
+"required": false
+},
+"alternatePhase": {
+"type": "integer",
+"description": "The address phase for the alternate
address. Defaults to '0'.",
+"create": true,
+"required": false
+},
+"matchMethod": {
+"description": "Key matching algorithm used. '0-10'
uses the legacy AMQP topic exchange wildcard match method as described in the
0-10 draft. 'mqtt' uses the MQTT topic filter wildcard match method.",
+"type": ["0-10", "mqtt"],
+"default": "0-10",
+"required": false,
+"create": true
+},
+"bindingCount": {
+"description": "The number of bindings associated with
this exchange.",
+"type": "integer",
+"create": false
+},
+"deliveriesReceived": {
+"description": "The total number of deliveries
received by this exchange.",
+"type": "integer",
+"create": false
+},
+"deliveriesDropped": {
+"description": "The total number of deliveries dropped
due to the lack of an outgoing subscription.",
+"type": "integer",
+"create": false
+},
+"deliveriesForwarded": {
+"description": "The total number of deliveries
forwarded via matched bindings.",
+"type": "integer",
+"create": false
+},
+"deliveriesAlternate": {
+"description": "The total number of deliveries
forwarded to the alternate exchange.",
+"type": "integer",
+"create": false
+}
+}
+},
+
+"router.config.binding": {
+"description":"[EXPERIMENTAL] Defines a keyed next hop binding
for an exchange.",
+"extends": "configurationEntity",
+"operations": ["CREATE", "DELETE"],
+"attributes": {
+"exchange": {
+"description": "The name of the exchange to bind.",
+"type": "string",
+"create": true,
+"required": true
+},
+"key": {
+"description": "Pattern to compare against incoming
message's topic. The key is a string of zero or more tokens and wildcards. The
format depends on the matchMethod configured for the exchange. For 0-10 each
token is delimited by the '.' character and wild-card token '*' matches a
single token and '#' matches zero or more tokens. For MQTT each token is
delimited by the '/' character and wildcard token '+' matches a single token
and '#' matches zero or more tokens at the end of the topic.",
+"type": "string",
+"create": true,
+"required": true
--- End diff --
not required update description to describe null key
---
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-89) Model the legacy topic exchange behavior of qpidd
[
https://issues.apache.org/jira/browse/DISPATCH-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16335924#comment-16335924
]
ASF GitHub Bot commented on DISPATCH-89:
Github user kgiusti commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/244#discussion_r163279263
--- Diff: python/qpid_dispatch/management/qdrouter.json ---
@@ -1126,6 +1126,106 @@
}
},
+"router.config.exchange": {
+"description":"[EXPERIMENTAL] Defines a topic exchange.",
+"extends": "configurationEntity",
+"operations": ["CREATE", "DELETE"],
+"attributes": {
+"address": {
+"description": "The address of the exchange.",
+"type": "string",
+"create": true,
+"required": true
+},
+"phase": {
+"type": "integer",
+"description": "The address phase for the exchange.
Defaults to '0'.",
+"create": true,
+"required": false
+},
+"alternate": {
+"description": "The address to forward the message to
if no bindings are matched.",
+"type": "string",
+"create": true,
+"required": false
+},
+"alternatePhase": {
+"type": "integer",
+"description": "The address phase for the alternate
address. Defaults to '0'.",
+"create": true,
+"required": false
+},
+"matchMethod": {
+"description": "Key matching algorithm used. '0-10'
uses the legacy AMQP topic exchange wildcard match method as described in the
0-10 draft. 'mqtt' uses the MQTT topic filter wildcard match method.",
+"type": ["0-10", "mqtt"],
+"default": "0-10",
+"required": false,
+"create": true
+},
+"bindingCount": {
+"description": "The number of bindings associated with
this exchange.",
+"type": "integer",
+"create": false
+},
+"deliveriesReceived": {
+"description": "The total number of deliveries
received by this exchange.",
+"type": "integer",
+"create": false
+},
+"deliveriesDropped": {
+"description": "The total number of deliveries dropped
due to the lack of an outgoing subscription.",
+"type": "integer",
+"create": false
+},
+"deliveriesForwarded": {
+"description": "The total number of deliveries
forwarded via matched bindings.",
--- End diff --
include alternate in description
> Model the legacy topic exchange behavior of qpidd
> -
>
> Key: DISPATCH-89
> URL: https://issues.apache.org/jira/browse/DISPATCH-89
> Project: Qpid Dispatch
> Issue Type: New Feature
> Components: Routing Engine
>Affects Versions: 0.2
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
>
> With Qpidd, a user can define a binding from an Exchange to a target queue.
> The binding uses a key that is compared to a message's subject field. If the
> key matches, the message is routed to the target queue for that binding.
> It should be possible to emulate this behavior using the dispatch router.
> Example:
> User defines a mappings from a target address (the 'exchange') to a different
> target address(es) (the 'queue'). These mappings (the 'bindings') are driven
> by a pattern match against the inbound message's subject field.
> Messages arriving at the router from any link whose target address has
> bindings defined are not immediately routed. Prior to routing, the message's
> subject field is extracted and compared against each binding defined for the
> target. A list of new target addresses is created containing the target
> address from each binding that satisfied the pattern match. The message is
> then routed to each new target address.
> The pattern syntax should be the same 'dotted string' notation from qpidd,
> including '*' and "#' wildcarding.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] qpid-dispatch pull request #244: DISPATCH-89: Exchange Binding forwarder (ex...
Github user kgiusti commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/244#discussion_r163279263
--- Diff: python/qpid_dispatch/management/qdrouter.json ---
@@ -1126,6 +1126,106 @@
}
},
+"router.config.exchange": {
+"description":"[EXPERIMENTAL] Defines a topic exchange.",
+"extends": "configurationEntity",
+"operations": ["CREATE", "DELETE"],
+"attributes": {
+"address": {
+"description": "The address of the exchange.",
+"type": "string",
+"create": true,
+"required": true
+},
+"phase": {
+"type": "integer",
+"description": "The address phase for the exchange.
Defaults to '0'.",
+"create": true,
+"required": false
+},
+"alternate": {
+"description": "The address to forward the message to
if no bindings are matched.",
+"type": "string",
+"create": true,
+"required": false
+},
+"alternatePhase": {
+"type": "integer",
+"description": "The address phase for the alternate
address. Defaults to '0'.",
+"create": true,
+"required": false
+},
+"matchMethod": {
+"description": "Key matching algorithm used. '0-10'
uses the legacy AMQP topic exchange wildcard match method as described in the
0-10 draft. 'mqtt' uses the MQTT topic filter wildcard match method.",
+"type": ["0-10", "mqtt"],
+"default": "0-10",
+"required": false,
+"create": true
+},
+"bindingCount": {
+"description": "The number of bindings associated with
this exchange.",
+"type": "integer",
+"create": false
+},
+"deliveriesReceived": {
+"description": "The total number of deliveries
received by this exchange.",
+"type": "integer",
+"create": false
+},
+"deliveriesDropped": {
+"description": "The total number of deliveries dropped
due to the lack of an outgoing subscription.",
+"type": "integer",
+"create": false
+},
+"deliveriesForwarded": {
+"description": "The total number of deliveries
forwarded via matched bindings.",
--- End diff --
include alternate in description
---
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-89) Model the legacy topic exchange behavior of qpidd
[
https://issues.apache.org/jira/browse/DISPATCH-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16335920#comment-16335920
]
ASF GitHub Bot commented on DISPATCH-89:
Github user kgiusti commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/244#discussion_r163277543
--- Diff: python/qpid_dispatch/management/qdrouter.json ---
@@ -1126,6 +1126,106 @@
}
},
+"router.config.exchange": {
+"description":"[EXPERIMENTAL] Defines a topic exchange.",
+"extends": "configurationEntity",
+"operations": ["CREATE", "DELETE"],
+"attributes": {
+"address": {
+"description": "The address of the exchange.",
+"type": "string",
+"create": true,
+"required": true
+},
+"phase": {
+"type": "integer",
+"description": "The address phase for the exchange.
Defaults to '0'.",
+"create": true,
+"required": false
+},
+"alternate": {
+"description": "The address to forward the message to
if no bindings are matched.",
+"type": "string",
+"create": true,
+"required": false
+},
+"alternatePhase": {
+"type": "integer",
+"description": "The address phase for the alternate
address. Defaults to '0'.",
+"create": true,
+"required": false
+},
+"matchMethod": {
+"description": "Key matching algorithm used. '0-10'
uses the legacy AMQP topic exchange wildcard match method as described in the
0-10 draft. 'mqtt' uses the MQTT topic filter wildcard match method.",
+"type": ["0-10", "mqtt"],
+"default": "0-10",
--- End diff --
also includes 0-9,8 etc? Need more general name.
> Model the legacy topic exchange behavior of qpidd
> -
>
> Key: DISPATCH-89
> URL: https://issues.apache.org/jira/browse/DISPATCH-89
> Project: Qpid Dispatch
> Issue Type: New Feature
> Components: Routing Engine
>Affects Versions: 0.2
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Major
>
> With Qpidd, a user can define a binding from an Exchange to a target queue.
> The binding uses a key that is compared to a message's subject field. If the
> key matches, the message is routed to the target queue for that binding.
> It should be possible to emulate this behavior using the dispatch router.
> Example:
> User defines a mappings from a target address (the 'exchange') to a different
> target address(es) (the 'queue'). These mappings (the 'bindings') are driven
> by a pattern match against the inbound message's subject field.
> Messages arriving at the router from any link whose target address has
> bindings defined are not immediately routed. Prior to routing, the message's
> subject field is extracted and compared against each binding defined for the
> target. A list of new target addresses is created containing the target
> address from each binding that satisfied the pattern match. The message is
> then routed to each new target address.
> The pattern syntax should be the same 'dotted string' notation from qpidd,
> including '*' and "#' wildcarding.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #244: DISPATCH-89: Exchange Binding forwarder (ex...
Github user kgiusti commented on a diff in the pull request:
https://github.com/apache/qpid-dispatch/pull/244#discussion_r163277543
--- Diff: python/qpid_dispatch/management/qdrouter.json ---
@@ -1126,6 +1126,106 @@
}
},
+"router.config.exchange": {
+"description":"[EXPERIMENTAL] Defines a topic exchange.",
+"extends": "configurationEntity",
+"operations": ["CREATE", "DELETE"],
+"attributes": {
+"address": {
+"description": "The address of the exchange.",
+"type": "string",
+"create": true,
+"required": true
+},
+"phase": {
+"type": "integer",
+"description": "The address phase for the exchange.
Defaults to '0'.",
+"create": true,
+"required": false
+},
+"alternate": {
+"description": "The address to forward the message to
if no bindings are matched.",
+"type": "string",
+"create": true,
+"required": false
+},
+"alternatePhase": {
+"type": "integer",
+"description": "The address phase for the alternate
address. Defaults to '0'.",
+"create": true,
+"required": false
+},
+"matchMethod": {
+"description": "Key matching algorithm used. '0-10'
uses the legacy AMQP topic exchange wildcard match method as described in the
0-10 draft. 'mqtt' uses the MQTT topic filter wildcard match method.",
+"type": ["0-10", "mqtt"],
+"default": "0-10",
--- End diff --
also includes 0-9,8 etc? Need more general name.
---
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-916) qdmanage get-attributes and get-operations not taking into account passed in type
[
https://issues.apache.org/jira/browse/DISPATCH-916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16335868#comment-16335868
]
ASF GitHub Bot commented on DISPATCH-916:
-
Github user kgiusti commented on the issue:
https://github.com/apache/qpid-dispatch/pull/246
Works for me.
> qdmanage get-attributes and get-operations not taking into account passed in
> type
> -
>
> Key: DISPATCH-916
> URL: https://issues.apache.org/jira/browse/DISPATCH-916
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Tools
>Affects Versions: 1.0.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.1.0
>
>
> {noformat}
> qdmanage get-attributes --type "org.apache.qpid.dispatch.sslProfile"{noformat}
> {color:#FF}the above command must return attributes of type sslProfile
> only but instead returns attributes of all types
> {color}
>
> {noformat}
> qdmanage get-operations --type "org.apache.qpid.dispatch.sslProfile"{noformat}
> This must return only operations of sslProfile but returns all operations of
> all types.
>
> The --type attribute must be honored
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch issue #246: DISPATCH-916 - Honor the type argument to qdmanage...
Github user kgiusti commented on the issue: https://github.com/apache/qpid-dispatch/pull/246 Works for me. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8032) [AMQP1.0] AsyncAutoCommitTransaction optimisation
[
https://issues.apache.org/jira/browse/QPID-8032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16335801#comment-16335801
]
ASF subversion and git services commented on QPID-8032:
---
Commit a1ed9978f756268fc86de8af02e5d7fad13a65a2 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=a1ed997 ]
QPID-8032 : [Broker-J][AMQP 1.0] Use asynchronous auto commit transaction for
non-transactional message dequeuing
> [AMQP1.0] AsyncAutoCommitTransaction optimisation
> -
>
> Key: QPID-8032
> URL: https://issues.apache.org/jira/browse/QPID-8032
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.0.1
>
> Attachments:
> 0001-QPID-8032-Broker-J-AMQP-1.0-Use-asynchronous-transac.patch
>
>
> Some AMQP 1.0 messaging use-cases would benefit from the
> {{AsyncAutoCommitTransactions}} optimisation that is already in use on the
> older protocols.
> For instance, for a publisher sending persistent settled messages, currently
> each message is written to disk and sync before the next message is the
> buffer is processed,. With this optimisation, the syncs would be allowed to
> coalesce.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6933) Factor out a JMS client neutral messaging test suite from system tests
[ https://issues.apache.org/jira/browse/QPID-6933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16335707#comment-16335707 ] ASF subversion and git services commented on QPID-6933: --- Commit bdad33cfc464077e205684b27945d58495d8c7a1 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=bdad33c ] QPID-6933: [System Tests] Remove client specific MaxDeliveryCountTest from broker-j after moving the test into the client source > Factor out a JMS client neutral messaging test suite from system tests > -- > > Key: QPID-6933 > URL: https://issues.apache.org/jira/browse/QPID-6933 > Project: Qpid > Issue Type: Improvement > Components: Java Tests >Reporter: Keith Wall >Assignee: Alex Rudyy >Priority: Major > > The existing system testsuite is in a poor state. > * It is poorly structured > * Mixes different types of test. i.e. messaging behaviour with those that > test features of the Java Broker (e.g. REST). > * Many of the tests refer directly to the implementation classes of the Qpid > Client 0-8..0-10 client meaning the tests cannot be run using the new client. > As a first step, we want to factor out a separate messaging system test suite: > * The tests in this suite will be JMS client neutral. > * Written in terms of JNDI/JMS client > * Configurations/Broker observations will be performed via a clean > Broker-neutral facade. For instance > ** a mechanism to cause the queue to be created of a particular type. > ** a mechanism to observe a queue depth. > * The tests will be classified by feature (to be defined) > * The classification system will be used to drive an exclusion feature (to be > defined). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8074) [Qpid JMS AMQP 0-x] Build framework to run JMS client system tests
[
https://issues.apache.org/jira/browse/QPID-8074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16335692#comment-16335692
]
ASF subversion and git services commented on QPID-8074:
---
Commit d81b86dc923a1fbe489046d250abf8dcee64160d in qpid-jms-amqp-0-x's branch
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms-amqp-0-x.git;h=d81b86d ]
QPID-8074: [JMS AMQP 0-x][System Tests] Move AMQP 0-x client specific
MaxDeliveryTest from broker-j
> [Qpid JMS AMQP 0-x] Build framework to run JMS client system tests
> --
>
> Key: QPID-8074
> URL: https://issues.apache.org/jira/browse/QPID-8074
> Project: Qpid
> Issue Type: Improvement
> Components: JMS AMQP 0-x
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
>
> A number of JMS AMQP 0-x client tests exist in Broker-J system test suite.
> We need to move those tests from Broker-J source tree into JMS AMQP 0-x
> sources. In order to do so, we need to build a new test framework which would
> allow us to start Broker-J (and potentially Cpp Broker) and run the system
> tests against the started broker.
> The test suite should use our virtualhost per test pattern. Check
> {{BrokerAdmin}} idea in broker system tests.
> One wrinkle would be Java 8 - the tests would need Java 8 to run, even though
> we want the client to remain Java 7 compatible.
> We could also write a broker admin allowing the tests to be run against the
> CPPBroker
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6933) Factor out a JMS client neutral messaging test suite from system tests
[ https://issues.apache.org/jira/browse/QPID-6933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16335621#comment-16335621 ] ASF subversion and git services commented on QPID-6933: --- Commit 28130e5eff80be4c171faac92df54a47cf9569f0 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=28130e5 ] QPID-6933: [System Tests] Fix MessageEncryptionTest > Factor out a JMS client neutral messaging test suite from system tests > -- > > Key: QPID-6933 > URL: https://issues.apache.org/jira/browse/QPID-6933 > Project: Qpid > Issue Type: Improvement > Components: Java Tests >Reporter: Keith Wall >Assignee: Alex Rudyy >Priority: Major > > The existing system testsuite is in a poor state. > * It is poorly structured > * Mixes different types of test. i.e. messaging behaviour with those that > test features of the Java Broker (e.g. REST). > * Many of the tests refer directly to the implementation classes of the Qpid > Client 0-8..0-10 client meaning the tests cannot be run using the new client. > As a first step, we want to factor out a separate messaging system test suite: > * The tests in this suite will be JMS client neutral. > * Written in terms of JNDI/JMS client > * Configurations/Broker observations will be performed via a clean > Broker-neutral facade. For instance > ** a mechanism to cause the queue to be created of a particular type. > ** a mechanism to observe a queue depth. > * The tests will be classified by feature (to be defined) > * The classification system will be used to drive an exclusion feature (to be > defined). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8074) [Qpid JMS AMQP 0-x] Build framework to run JMS client system tests
[
https://issues.apache.org/jira/browse/QPID-8074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16335605#comment-16335605
]
ASF subversion and git services commented on QPID-8074:
---
Commit fb5228740a12cf34c6b2ad4dcf4175f8abe170cb in qpid-jms-amqp-0-x's branch
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms-amqp-0-x.git;h=fb52287 ]
QPID-8074: [JMS AMQP 0-x][System Tests] Clean work directory only if it was not
cleaned before
> [Qpid JMS AMQP 0-x] Build framework to run JMS client system tests
> --
>
> Key: QPID-8074
> URL: https://issues.apache.org/jira/browse/QPID-8074
> Project: Qpid
> Issue Type: Improvement
> Components: JMS AMQP 0-x
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
>
> A number of JMS AMQP 0-x client tests exist in Broker-J system test suite.
> We need to move those tests from Broker-J source tree into JMS AMQP 0-x
> sources. In order to do so, we need to build a new test framework which would
> allow us to start Broker-J (and potentially Cpp Broker) and run the system
> tests against the started broker.
> The test suite should use our virtualhost per test pattern. Check
> {{BrokerAdmin}} idea in broker system tests.
> One wrinkle would be Java 8 - the tests would need Java 8 to run, even though
> we want the client to remain Java 7 compatible.
> We could also write a broker admin allowing the tests to be run against the
> CPPBroker
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8032) [AMQP1.0] AsyncAutoCommitTransaction optimisation
[
https://issues.apache.org/jira/browse/QPID-8032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-8032:
-
Status: Open (was: Reviewable)
> [AMQP1.0] AsyncAutoCommitTransaction optimisation
> -
>
> Key: QPID-8032
> URL: https://issues.apache.org/jira/browse/QPID-8032
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.0.1
>
> Attachments:
> 0001-QPID-8032-Broker-J-AMQP-1.0-Use-asynchronous-transac.patch
>
>
> Some AMQP 1.0 messaging use-cases would benefit from the
> {{AsyncAutoCommitTransactions}} optimisation that is already in use on the
> older protocols.
> For instance, for a publisher sending persistent settled messages, currently
> each message is written to disk and sync before the next message is the
> buffer is processed,. With this optimisation, the syncs would be allowed to
> coalesce.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8062) [Broker-J][AMQP 1.0] Fix handling of routing errors when target destination cannot route received message
[
https://issues.apache.org/jira/browse/QPID-8062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16335538#comment-16335538
]
Keith Wall commented on QPID-8062:
--
Changes look reasonable to me. Ready for back porting.
> [Broker-J][AMQP 1.0] Fix handling of routing errors when target destination
> cannot route received message
> -
>
> Key: QPID-8062
> URL: https://issues.apache.org/jira/browse/QPID-8062
> Project: Qpid
> Issue Type: Bug
>Affects Versions: qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Assignee: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.0.1
>
> Attachments:
> 0001-QPID-8062-Broker-J-AMQP-1.0-Move-responsibility-to-c.patch
>
>
> As per section "2.2.2 Routing Errors" of "Using the Anonymous Terminus for
> Message Routing Version 1.0":
> {quote}
> If the source of the link does not support the rejected outcome, or the
> message has already been settled by the sender, then the routing node MUST
> detach the link with an error. The error sent by the routing node MUST
> contain the error which would have been communicated in the detach sent on
> attempting to link directly to the address in the message’s to field.
> Additionally the info field of error MUST contain an entry with symbolic key
> delivery-tag and binary value of the delivery-tag of the message which caused
> the failure.
> {quote}
> The Broker-J does not handle the case when message is sent pre-settled and is
> rejected by the destination. We need to add the support for this behaviour.
> Additionally, if a pre-settled message is published within a transaction and
> cannot be routed by a queue/exchange/whatever then have the transactional
> resource
> logically mark the transaction as"rollback only" (i.e. failed)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
