[jira] [Created] (DISPATCH-1120) Self tests using deprecated config attributes
Chuck Rolke created DISPATCH-1120:
-
Summary: Self tests using deprecated config attributes
Key: DISPATCH-1120
URL: https://issues.apache.org/jira/browse/DISPATCH-1120
Project: Qpid Dispatch
Issue Type: Bug
Affects Versions: 1.3.0
Reporter: Chuck Rolke
Assignee: Chuck Rolke
Warnings wind up in the ROUTER.out files making the search for true issues
harder.
{{2018-09-10 17:15:41.871607 -0400 AGENT (warning) Attribute 'verifyHostName'
of entity 'connector' has been deprecated. Use 'verifyHostname' instead}}
--
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-1119) Assert in qdr_del_link_ref in self test system_tests_multi_tenancy
Chuck Rolke created DISPATCH-1119:
-
Summary: Assert in qdr_del_link_ref in self test
system_tests_multi_tenancy
Key: DISPATCH-1119
URL: https://issues.apache.org/jira/browse/DISPATCH-1119
Project: Qpid Dispatch
Issue Type: Bug
Components: Routing Engine
Affects Versions: 1.3.0
Reporter: Chuck Rolke
{{qdrouterd: /home/chug/git/qpid-dispatch/src/router_core/router_core.c:441:
qdr_del_link_ref: Assertion `(*ref_list).size > 0' failed.}}
{{#0 0x7fe982b26feb in raise () from /lib64/libc.so.6}}
{{#1 0x7fe982b115c1 in abort () from /lib64/libc.so.6}}
{{#2 0x7fe982b11491 in __assert_fail_base.cold.0 () from /lib64/libc.so.6}}
{{#3 0x7fe982b1f752 in __assert_fail () from /lib64/libc.so.6}}
{{#4 0x7fe983de3559 in qdr_del_link_ref (ref_list=0x7fe96403c680,
link=0x7fe9580c1a60, cls=1) at
/home/chug/git/qpid-dispatch/src/router_core/router_core.c:441}}
{{#5 0x7fe983dd4b6c in qdr_link_cleanup_CT (core=0x237a6e0,
conn=0x7fe96403c5e0, link=0x7fe9580c1a60) at
/home/chug/git/qpid-dispatch/src/router_core/connections.c:856}}
{{#6 0x7fe983dd7b68 in qdr_link_inbound_detach_CT (core=0x237a6e0,
action=0x237d7a0, discard=false) at
/home/chug/git/qpid-dispatch/src/router_core/connections.c:1945}}
{{#7 0x7fe983de434d in router_core_thread (arg=0x237a6e0) at
/home/chug/git/qpid-dispatch/src/router_core/router_core_thread.c:83}}
{{#8 0x7fe983714594 in start_thread () from /lib64/libpthread.so.0}}
{{#9 0x7fe982bea0df in clone () from /lib64/libc.so.6}}
--
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-1081) Messages to multicast addresses are being released when no receivers attached
[
https://issues.apache.org/jira/browse/DISPATCH-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16611143#comment-16611143
]
Ganesh Murthy commented on DISPATCH-1081:
-
This is what the documentation must say -
When an unsettled message is sent to a multicast router address which has no
receivers, the router sends back a disposition of RELEASED
When an unsettled message is sent to a multicast router address which has one
or more receivers, the router sends back a disposition of SETTLED.
> Messages to multicast addresses are being released when no receivers attached
> -
>
> Key: DISPATCH-1081
> URL: https://issues.apache.org/jira/browse/DISPATCH-1081
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Alexander Rafferty
>Priority: Major
>
> When sending messages to a multicast address to which no consumers are
> attached, the router sends back a disposition of RELEASED. The expected
> behaviour is that all messages will be immediately settled by the ingress
> router with a disposition of ACCEPTED as per section 2.4.1 of the Dispatch
> router book:
> {quote}Multicast delivery is not reliable. If a producer sends an unsettled
> delivery, the ingress router shall settle the delivery with ACCEPTED
> disposition regardless of whether the message was delivered to any consumers.
> {quote}
> Is this a bug, or is this the expected behaviour? If this is the expected
> behaviour, can the router be configured to always accept messages to
> multicast addresses even where no consumers are actively listening?
--
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-1081) Messages to multicast addresses are being released when no receivers attached
[
https://issues.apache.org/jira/browse/DISPATCH-1081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16611030#comment-16611030
]
Ganesh Murthy commented on DISPATCH-1081:
-
The problem is with the documentation in this case. Although multicast does not
make any delivery guarantees, when no receivers are present for a multicasted
address, releasing the the message actually gives the sender more information
than simply accepting the message. If the message is released, the sender knows
for sure that the message did not get anywhere. I will fix the documentation
> Messages to multicast addresses are being released when no receivers attached
> -
>
> Key: DISPATCH-1081
> URL: https://issues.apache.org/jira/browse/DISPATCH-1081
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Alexander Rafferty
>Priority: Major
>
> When sending messages to a multicast address to which no consumers are
> attached, the router sends back a disposition of RELEASED. The expected
> behaviour is that all messages will be immediately settled by the ingress
> router with a disposition of ACCEPTED as per section 2.4.1 of the Dispatch
> router book:
> {quote}Multicast delivery is not reliable. If a producer sends an unsettled
> delivery, the ingress router shall settle the delivery with ACCEPTED
> disposition regardless of whether the message was delivered to any consumers.
> {quote}
> Is this a bug, or is this the expected behaviour? If this is the expected
> behaviour, can the router be configured to always accept messages to
> multicast addresses even where no consumers are actively listening?
--
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-1107) Need info for logs to help disambiguate router connections
[ https://issues.apache.org/jira/browse/DISPATCH-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy reassigned DISPATCH-1107: --- Assignee: Chuck Rolke > Need info for logs to help disambiguate router connections > -- > > Key: DISPATCH-1107 > URL: https://issues.apache.org/jira/browse/DISPATCH-1107 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node >Affects Versions: 1.3.0 >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Fix For: 1.4.0 > > > When connections are started by routers to other routers there is no reliable > way in the log files for telling the connections apart. Consider a pair of > routers where router A creates two connections and sends two Opens to router > B. A's log will show that connections [5] and [7] sent the Opens and B's log > will show that connections [4] and [6] received and replied to the Opens. But > there is no way to know if the connection pairs are '[A-5][B-4] and > [A-7][B-6]' or '[A-5][B-6] and [A-7][B-4]'. > A simple solution to expose this relationship is for the routers to embed the > _connid_ in the Open properties. Then the connection relationships between > the two routers could be resolved from either router log file. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1109) use serving host and port as defaults for connect screen in console served by router
[ https://issues.apache.org/jira/browse/DISPATCH-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-1109. Resolution: Fixed > use serving host and port as defaults for connect screen in console served by > router > > > Key: DISPATCH-1109 > URL: https://issues.apache.org/jira/browse/DISPATCH-1109 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Console >Reporter: Gordon Sim >Assignee: Ted Ross >Priority: Major > Fix For: 1.4.0 > > > If you have a router serving up the console, and you have authentication > enabled, then when you go to the url to retrieve the console it loads up the > connect screen (because it can't connect without username and password). > However the connection defaults to localhost:5673. It would be much nicer if > it could default to the host/port from which the console was itself loaded. -- 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-1109) use serving host and port as defaults for connect screen in console served by router
[ https://issues.apache.org/jira/browse/DISPATCH-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610929#comment-16610929 ] ASF subversion and git services commented on DISPATCH-1109: --- Commit 379036ee2ef02da40b515372e791df572a490554 in qpid-dispatch's branch refs/heads/master from [~tr...@redhat.com] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=379036e ] DISPATCH-1109 - Use window.location for default values in the connect form. > use serving host and port as defaults for connect screen in console served by > router > > > Key: DISPATCH-1109 > URL: https://issues.apache.org/jira/browse/DISPATCH-1109 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Console >Reporter: Gordon Sim >Assignee: Ted Ross >Priority: Major > Fix For: 1.4.0 > > > If you have a router serving up the console, and you have authentication > enabled, then when you go to the url to retrieve the console it loads up the > connect screen (because it can't connect without username and password). > However the connection defaults to localhost:5673. It would be much nicer if > it could default to the host/port from which the console was itself loaded. -- 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-1798) Installed example self-tests for proton
[ https://issues.apache.org/jira/browse/PROTON-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved PROTON-1798. - Resolution: Fixed > Installed example self-tests for proton > --- > > Key: PROTON-1798 > URL: https://issues.apache.org/jira/browse/PROTON-1798 > Project: Qpid Proton > Issue Type: Test >Affects Versions: proton-c-0.21.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Labels: testing > Fix For: proton-c-0.26.0 > > > Install test scripts so that self-tests can be run on an installed package, > without access to the source tree. These tests will be a separate install > group. > > Initially the tests will consist of automatically building and running > installed examples, in future we can add unit tests etc. to the installed set. -- 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-1798) Installable tests for proton
[ https://issues.apache.org/jira/browse/PROTON-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610876#comment-16610876 ] Alan Conway commented on PROTON-1798: - Marking resolved for c, c++ and ruby. New issues to finish this work for Go and python: PROTON-1931, PROTON-1932 > Installable tests for proton > > > Key: PROTON-1798 > URL: https://issues.apache.org/jira/browse/PROTON-1798 > Project: Qpid Proton > Issue Type: Test >Affects Versions: proton-c-0.21.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Labels: testing > Fix For: proton-c-0.26.0 > > > Install test scripts so that self-tests can be run on an installed package, > without access to the source tree. These tests will be a separate install > group. > > Initially the tests will consist of automatically building and running > installed examples, in future we can add unit tests etc. to the installed set. -- 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-1798) Installed example self-tests for proton
[ https://issues.apache.org/jira/browse/PROTON-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway updated PROTON-1798: Summary: Installed example self-tests for proton (was: Installable tests for proton) > Installed example self-tests for proton > --- > > Key: PROTON-1798 > URL: https://issues.apache.org/jira/browse/PROTON-1798 > Project: Qpid Proton > Issue Type: Test >Affects Versions: proton-c-0.21.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Labels: testing > Fix For: proton-c-0.26.0 > > > Install test scripts so that self-tests can be run on an installed package, > without access to the source tree. These tests will be a separate install > group. > > Initially the tests will consist of automatically building and running > installed examples, in future we can add unit tests etc. to the installed set. -- 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] [Comment Edited] (PROTON-1927) Python _reactor.py creates duplicate link names for senders/receivers
[ https://issues.apache.org/jira/browse/PROTON-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610871#comment-16610871 ] Robbie Gemmell edited comment on PROTON-1927 at 9/11/18 4:20 PM: - Ok, so that avoids the issue of creating two different receivers over the wire with the same name, but I'd say that is still a bug. If no name was given, and one is being generated, I don't think it should be generating the same name and returning the same receiver again, but rather a completely different name and returning an entirely new receiver. So to summarise, creating a sender and receiver with the same generated name is OK, though it would be nice to generate different ones (in qpid-jms we prefix the name with the use, e.g receiver, sender, coordinator). The real bug though is in two different calls to create a receiver (or similarly, sender?) generating the same name and returning the same receiver. was (Author: gemmellr): Ok, so that avoids the issue of creating two different receivers over the wire with the same name, but I'd say that is still a bug. If no name was given, and one is being generated, I don't think it should be generating the same name and returning the same reciever again, but rather a completely different name and returning an entirely new receiver. > Python _reactor.py creates duplicate link names for senders/receivers > - > > Key: PROTON-1927 > URL: https://issues.apache.org/jira/browse/PROTON-1927 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.24.0 >Reporter: Chuck Rolke >Priority: Major > > From DISPATCH-1114 > Creating a sender and a receiver in the same container produces duplicate > link names. Try python/examples/helloworld.py that executes: > event.container.create_receiver(conn, self.address) > event.container.create_sender(conn, self.address) > generates the same link name for each attach: > (M=a1b7d *1 ?3) chug@ratchet examples> PN_TRACE_FRM=1 ./helloworld.py > ... > [0x55a01066d9a0]:0 -> @attach(18) > [name="70ceeac8-50d8-4af2-9caf-20ef8700a7d3-examples", handle=0, role=true, > snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="examples", > durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, > timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0] > [0x55a01066d9a0]:0 -> @attach(18) > [name="70ceeac8-50d8-4af2-9caf-20ef8700a7d3-examples", handle=1, role=false, > snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, > timeout=0, dynamic=false], target=@target(41) [address="examples", durable=0, > timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=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-1927) Python _reactor.py creates duplicate link names for senders/receivers
[ https://issues.apache.org/jira/browse/PROTON-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610871#comment-16610871 ] Robbie Gemmell commented on PROTON-1927: Ok, so that avoids the issue of creating two different receivers over the wire with the same name, but I'd say that is still a bug. If no name was given, and one is being generated, I don't think it should be generating the same name and returning the same reciever again, but rather a completely different name and returning an entirely new receiver. > Python _reactor.py creates duplicate link names for senders/receivers > - > > Key: PROTON-1927 > URL: https://issues.apache.org/jira/browse/PROTON-1927 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.24.0 >Reporter: Chuck Rolke >Priority: Major > > From DISPATCH-1114 > Creating a sender and a receiver in the same container produces duplicate > link names. Try python/examples/helloworld.py that executes: > event.container.create_receiver(conn, self.address) > event.container.create_sender(conn, self.address) > generates the same link name for each attach: > (M=a1b7d *1 ?3) chug@ratchet examples> PN_TRACE_FRM=1 ./helloworld.py > ... > [0x55a01066d9a0]:0 -> @attach(18) > [name="70ceeac8-50d8-4af2-9caf-20ef8700a7d3-examples", handle=0, role=true, > snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="examples", > durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, > timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0] > [0x55a01066d9a0]:0 -> @attach(18) > [name="70ceeac8-50d8-4af2-9caf-20ef8700a7d3-examples", handle=1, role=false, > snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, > timeout=0, dynamic=false], target=@target(41) [address="examples", durable=0, > timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=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-1932) [python] installable python test
Alan Conway created PROTON-1932: --- Summary: [python] installable python test Key: PROTON-1932 URL: https://issues.apache.org/jira/browse/PROTON-1932 Project: Qpid Proton Issue Type: Test Components: python-binding Affects Versions: proton-c-0.25.0 Reporter: Alan Conway Update python examples for install self-testing in the same way as c, c++ and ruby examples were updated by PROTON-1798 - rename test driver to "testme" - servers print actual listening port not command-line port (may be 0) - test driver start servers on port 0, pass real port to client -- 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-1931) [go] installable go test package, simplified go build & test.
[ https://issues.apache.org/jira/browse/PROTON-1931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway updated PROTON-1931: Priority: Minor (was: Major) > [go] installable go test package, simplified go build & test. > - > > Key: PROTON-1931 > URL: https://issues.apache.org/jira/browse/PROTON-1931 > Project: Qpid Proton > Issue Type: Test > Components: go-binding >Affects Versions: proton-c-0.25.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Minor > > go testing is currently an awkward mix of Go native build tools and cmake. > - make go examples into a standard Go executable package. > - testme script will be simply `GOPATH=... go test > qpid.apache.org/proton_examples` > - make examples available via `go get` and on godoc.org > -- 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-1931) [go] installable go test package, simplified go build & test.
[ https://issues.apache.org/jira/browse/PROTON-1931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway updated PROTON-1931: Component/s: go-binding > [go] installable go test package, simplified go build & test. > - > > Key: PROTON-1931 > URL: https://issues.apache.org/jira/browse/PROTON-1931 > Project: Qpid Proton > Issue Type: Test > Components: go-binding >Affects Versions: proton-c-0.25.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Minor > > go testing is currently an awkward mix of Go native build tools and cmake. > - make go examples into a standard Go executable package. > - testme script will be simply `GOPATH=... go test > qpid.apache.org/proton_examples` > - make examples available via `go get` and on godoc.org > -- 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-1931) [go] installable go test package, simplified go build & test.
[ https://issues.apache.org/jira/browse/PROTON-1931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway updated PROTON-1931: Affects Version/s: proton-c-0.25.0 > [go] installable go test package, simplified go build & test. > - > > Key: PROTON-1931 > URL: https://issues.apache.org/jira/browse/PROTON-1931 > Project: Qpid Proton > Issue Type: Test > Components: go-binding >Affects Versions: proton-c-0.25.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Minor > > go testing is currently an awkward mix of Go native build tools and cmake. > - make go examples into a standard Go executable package. > - testme script will be simply `GOPATH=... go test > qpid.apache.org/proton_examples` > - make examples available via `go get` and on godoc.org > -- 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-1931) [go] installable go test package, simplified go build & test.
Alan Conway created PROTON-1931: --- Summary: [go] installable go test package, simplified go build & test. Key: PROTON-1931 URL: https://issues.apache.org/jira/browse/PROTON-1931 Project: Qpid Proton Issue Type: Test Reporter: Alan Conway Assignee: Alan Conway go testing is currently an awkward mix of Go native build tools and cmake. - make go examples into a standard Go executable package. - testme script will be simply `GOPATH=... go test qpid.apache.org/proton_examples` - make examples available via `go get` and on godoc.org -- 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-1798) Installable tests for proton
[ https://issues.apache.org/jira/browse/PROTON-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610854#comment-16610854 ] ASF subversion and git services commented on PROTON-1798: - Commit 393f8a67712d126f98b3a87e83fdafab57011239 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=393f8a6 ] PROTON-1798: [c, cpp, ruby] Installable tests for proton Tests can be executed from install for c, cpp, ruby. See tests/share/examples-README.md RUNTIME_CHECK=memcheck, helgrind are supported for normal builds. asan, tsan require a special library build so less likely to be useful for install tests. TODO: - python, go examples - non-example tests installed under share/pronton-VERSION/tests/ > Installable tests for proton > > > Key: PROTON-1798 > URL: https://issues.apache.org/jira/browse/PROTON-1798 > Project: Qpid Proton > Issue Type: Test >Affects Versions: proton-c-0.21.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Major > Labels: testing > Fix For: proton-c-0.26.0 > > > Install test scripts so that self-tests can be run on an installed package, > without access to the source tree. These tests will be a separate install > group. > > Initially the tests will consist of automatically building and running > installed examples, in future we can add unit tests etc. to the installed set. -- 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-1109) use serving host and port as defaults for connect screen in console served by router
[ https://issues.apache.org/jira/browse/DISPATCH-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-1109: --- Fix Version/s: 1.4.0 > use serving host and port as defaults for connect screen in console served by > router > > > Key: DISPATCH-1109 > URL: https://issues.apache.org/jira/browse/DISPATCH-1109 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Console >Reporter: Gordon Sim >Assignee: Ted Ross >Priority: Major > Fix For: 1.4.0 > > > If you have a router serving up the console, and you have authentication > enabled, then when you go to the url to retrieve the console it loads up the > connect screen (because it can't connect without username and password). > However the connection defaults to localhost:5673. It would be much nicer if > it could default to the host/port from which the console was itself loaded. -- 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
Speakers needed for Apache DC Roadshow
We need your help to make the Apache Washington DC Roadshow on Dec 4th a success. What do we need most? Speakers! We're bringing a unique DC flavor to this event by mixing Open Source Software with talks about Apache projects as well as OSS CyberSecurity, OSS in Government and and OSS Career advice. Please take a look at: http://www.apachecon.com/usroadshow18/ (Note: You are receiving this message because you are subscribed to one or more mailing lists at The Apache Software Foundation.) Rich, for the ApacheCon Planners -- rbo...@apache.org http://apachecon.com @ApacheCon - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1927) Python _reactor.py creates duplicate link names for senders/receivers
[ https://issues.apache.org/jira/browse/PROTON-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610759#comment-16610759 ] Ganesh Murthy commented on PROTON-1927: --- if you called "create_receiver(conn, self.address)" twice, or "create_sender(conn, self.address)" twice, the *second* call will not create a new sender or receiver since the previous call already did. For examplke r1 = .create_receiver(conn, self.address) r2 = .create_receiver(conn, self.address) In the above case r1 and r2 are the same. To create two distinct receivers you need to use the *name* parameter r1 = .create_receiver(conn, self.address, name="r1") r2 = .create_receiver(conn, self.address, name="r2") In this case r1 and r2 are two distinct receivers and the link names are distinct too. > Python _reactor.py creates duplicate link names for senders/receivers > - > > Key: PROTON-1927 > URL: https://issues.apache.org/jira/browse/PROTON-1927 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Affects Versions: proton-c-0.24.0 >Reporter: Chuck Rolke >Priority: Major > > From DISPATCH-1114 > Creating a sender and a receiver in the same container produces duplicate > link names. Try python/examples/helloworld.py that executes: > event.container.create_receiver(conn, self.address) > event.container.create_sender(conn, self.address) > generates the same link name for each attach: > (M=a1b7d *1 ?3) chug@ratchet examples> PN_TRACE_FRM=1 ./helloworld.py > ... > [0x55a01066d9a0]:0 -> @attach(18) > [name="70ceeac8-50d8-4af2-9caf-20ef8700a7d3-examples", handle=0, role=true, > snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="examples", > durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, > timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=0] > [0x55a01066d9a0]:0 -> @attach(18) > [name="70ceeac8-50d8-4af2-9caf-20ef8700a7d3-examples", handle=1, role=false, > snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, > timeout=0, dynamic=false], target=@target(41) [address="examples", durable=0, > timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=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-1544) go lang binding transaction support
[ https://issues.apache.org/jira/browse/PROTON-1544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway updated PROTON-1544: Priority: Minor (was: Major) > go lang binding transaction support > --- > > Key: PROTON-1544 > URL: https://issues.apache.org/jira/browse/PROTON-1544 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Reporter: ivy >Priority: Minor > > Does the go lang binding support AMQP transactions, If it does, is there any > documentation on how to use it. If not are there plans to support 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] (PROTON-1647) [go] support for crypto.tls connections
[ https://issues.apache.org/jira/browse/PROTON-1647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway updated PROTON-1647: Priority: Minor (was: Major) > [go] support for crypto.tls connections > --- > > Key: PROTON-1647 > URL: https://issues.apache.org/jira/browse/PROTON-1647 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Affects Versions: proton-c-0.18.0 >Reporter: Alan Conway >Assignee: Alan Conway >Priority: Minor > Labels: tls > > The electron and proton Go bindings do not expose proton's built-in SSL layer > because Go provides it's own TLS layer in the crypto.tls package which is > more portable, capable and familiar to Go programmers. > You can already use a tls.Conn with proton or electron, but there are several > points that should be cleaned up: > - when a TLS connection is in use set allow-insecure-mechs in proton-C > automatically > - make sure the AMQP virtual-host matches the TLS virtual-host by default > - provide access to the net.Conn used by an electron.Connection, which in > turn will give access to TLS details if the user needs them > - provide an example of using TLS (maybe with SASL PLAIN auth?) -- 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] [Comment Edited] (PROTON-1898) Memory leak related to sending
[ https://issues.apache.org/jira/browse/PROTON-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16605933#comment-16605933 ] Christoph Scheiber edited comment on PROTON-1898 at 9/11/18 9:51 AM: - Meanwhile I was running the application also under linux (ubuntu 18.04), unfortunately with the same result. The memory leak can be seen when sending and when using AtLeastOnce. Also I tried use a limited number of message instances only. Each worker (a single go routine) in my (daemon-like) application used only one message instance to send and was waiting until the message was settled by receiver. Then it was sending the next message. I was running 10-50 workers in parallel. This means there were never more than 10-50 message instances in use. However, this did not solve the issue. Hence, the leak must be related to delivery handling (or chunks on socket level?). Could be the same as discussed in QPID-8134 ... was (Author: scheiber): I just wanted to ask for the current state... And, is there any workaround? > Memory leak related to sending > -- > > Key: PROTON-1898 > URL: https://issues.apache.org/jira/browse/PROTON-1898 > Project: Qpid Proton > Issue Type: Bug > Components: go-binding >Affects Versions: proton-c-0.24.0 >Reporter: Christoph Scheiber >Assignee: Alan Conway >Priority: Major > > I started implementing a GO application using qpid electron. There is one > connection used to receive messages (at-least-once). It works nicely with low > memory consumption, multiple links and multiple go routines, 50 bytes > payload, up to 3000 msg/s > But as soon as the application starts sending messages (to reply over the > same connection) memory consumption is continuously growing up to 2GB where I > stopped. > Even if electron does not leave many options for wrong usage there might be > an issue in the application. > So I tried the qpid electron example > "https://github.com/apache/qpid-proton/blob/master/go/examples/electron/send.go";, > the same issue. > To reproduce it: > * use the sample program, I just added connection options for SASL PLAIN > * let it send 10 messages or more to one destination > My setup: > * windows 10 pro > * go1.10.2 windows/amd64 > * qpid 0.24.0-rc1 > * go files and lib build from same git repository clone and branch > * visual studio 2015, release build, no errors > * Broker: Solace VMR 8.11.0.1029 with different durable queues as source and > target > I tried also qpid proton 0.23.0 earlier, but saw the same problem. > I tried SendAsync and SendSync, both in 10-50 go routines in > parallel.Finally, with SendForget my worker routines were soon blocked and > did not come back. > Best regards > Christoph > -- 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] [Comment Edited] (QPID-8238) [Broker-J] Improve performance of asynchronous publishing of transient messages into topic exchange having queues bound using non-overlapping selectors
[
https://issues.apache.org/jira/browse/QPID-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610324#comment-16610324
]
Alex Rudyy edited comment on QPID-8238 at 9/11/18 9:07 AM:
---
Keith,
Thanks a lot for the review comments.
My changes for logback filter and fanout exchange routing functionality were
driven by jprofiler analysis indicating about performance being lost on
unnecessary {{Map}} object creation. I committed them against this JIRA as they
improve the performance a bit whilst routing the messages with fanout exchange
but the performance of other exchange implementation should improve as well.
Though, I am happy to revert the mentioned changes and commit them against
separate JIRAs.
As for exchange changes, they not only optimize the code but make it much
simpler. Effectively, the changed code converts the collection of
{{TopicMatcherResult}} got based on message routing key into a map where keys
are {{route destinations}} and values are {{routing/replacement keys}}. Before
my change the conversions was done by using intermediate map containing the
destination as a key and routing replacement key as a value. Than, multiple
maps (representing each {{TopicMatcherResult}} ) were merged into a single map.
My changes eliminated the need for intermediate map creation. I also do hope
that code is a bit simpler now. I left the old implementation untouched and
marked is as {{Deprecated}} in order to keep public methods unchanged as the
next version is minor release rather major one. (Though, I did not check
whether we made other breakable changes in the code in general. Perhaps,
keeping dead-code there is a waist). I am planning to merge committed changes
into 7.0 and do not want break backward compatibility there.
I liked Rob's idea of making {{FieldTable}} immutable and do on-demand
parsing. I will try to implement the corresponding changes as part of this
JIRA, however, making {{FieldTable}} immutable most likely will not have any
effect on performance and performance is the main concern for me right now. I
do not think I can port on-demand parsing changes into 7.0. Thus, I am
currently looking into other performance optimization alternatives. I have not
looked into on-demand parsing yet.
I played a bit with replacing of {{AMQShortStrings}} with java {{String}} in
{{BasicContentHeaderProperties}} (I have a patch a corresponding changes). My
performance tests did not revealed much performance improvements due to using
java {{String}} in {{BasicContentHeaderProperties}}. However, they did improve
the performance a bit. Potentially, making {{AMQShortStrings}} to be a wrapper
of {{String}} and replacing usage of {{AMQShortStrings}} with java {{String}}
where possible could be another refactoring worth doing.
The current routing code is very well tuned. I do not see any other routing
functionality to optimize. As a next steps I am going to add new topic
performance tests into existing perf test suite and look into making
{{FieldTable}} immutable and implementing on-demand parsing.
was (Author: alex.rufous):
Keith,
Thanks a lot for the review comments.
My changes for logback filter and fanout exchange routing functionality were
driven by jprofiler analysis indicating about performance being lost on
unnecessary {{Map}} object creation. I committed them against this JIRA as they
improve the performance a bit whilst routing the messages with fanout exchange
but the performance of other exchange implementation should improve as well.
Though, I am happy to revert the mentioned changes and commit them against
separate JIRAs.
As for exchange changes, they not only optimize the code but make it much
simpler. Effectively, the changed code converts the collection of
{{TopicMatcherResult}} got based on message routing key into a map where keys
are {{route destinations}} and values are {{routing/replacement keys}}. Before
my change the conversions was done by using intermediate map containing the
destination as a key and routing replacement key as a value. Than, multiple
maps (representing each {{TopicMatcherResult}} ) were merged into a single map.
My changes eliminated the need for intermediate map creation. I also do hope
that code is a bit simpler now. I left the old implementation untouched and
marked is as {{Deprecated}} in order to keep public methods unchanged as the
next version is minor release rather major one. (Though, I did not check
whether we made other breakable changes in the code in general. Perhaps,
keeping dead-code there is a waist). I am planning to merge committed changes
into 7.0 and do not want break backward compatibility there.
I liked Rob's idea of making {{FieldTable}} immutable and do on-demand
parsing. I will try to implement the corresponding changes as part of this
JIRA, however, making {{FieldTable}} im
[jira] [Comment Edited] (QPID-8238) [Broker-J] Improve performance of asynchronous publishing of transient messages into topic exchange having queues bound using non-overlapping selectors
[
https://issues.apache.org/jira/browse/QPID-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610324#comment-16610324
]
Alex Rudyy edited comment on QPID-8238 at 9/11/18 9:07 AM:
---
Keith,
Thanks a lot for the review comments.
My changes for logback filter and fanout exchange routing functionality were
driven by jprofiler analysis indicating about performance being lost on
unnecessary {{Map}} object creation. I committed them against this JIRA as they
improve the performance a bit whilst routing the messages with fanout exchange
but the performance of other exchange implementation should improve as well.
Though, I am happy to revert the mentioned changes and commit them against
separate JIRAs.
As for exchange changes, they not only optimize the code but make it much
simpler. Effectively, the changed code converts the collection of
{{TopicMatcherResult}} got based on message routing key into a map where keys
are {{route destinations}} and values are {{routing/replacement keys}}. Before
my change the conversions was done by using intermediate map containing the
destination as a key and routing replacement key as a value. Than, multiple
maps (representing each {{TopicMatcherResult}} ) were merged into a single map.
My changes eliminated the need for intermediate map creation. I also do hope
that code is a bit simpler now. I left the old implementation untouched and
marked is as {{Deprecated}} in order to keep public methods unchanged as the
next version is minor release rather major one. (Though, I did not check
whether we made other breakable changes in the code in general. Perhaps,
keeping dead-code there is a waist). I am planning to merge committed changes
into 7.0 and do not want break backward compatibility there.
I liked Rob's idea of making {{FieldTable}} immutable and do on-demand
parsing. I will try to implement the corresponding changes as part of this
JIRA, however, making {{FieldTable}} immutable most likely will not have any
effect on performance and performance is the main concern for me right now. I
do not think I can port on-demand parsing changes into 7.0. Thus, I am
currently looking into other performance optimization alternatives. I have not
looked into on-demand parsing yet.
I played a bit with replacing of {{AMQShortStrings}} with java {{String}} in
{{BasicContentHeaderProperties}} (I have a patch a corresponding changes). My
performance tests did not revealed much performance improvements due to using
java {{String}} in {{BasicContentHeaderProperties}}. However, they did improve
the performance a bit. Potentially, making {{AMQShortString}}s to be a wrapper
of {{String}} and replacing usage of {{AMQShortStrings}} with java {{String}}
where possible could be another refactoring worth doing.
The current routing code is very well tuned. I do not see any other routing
functionality to optimize. As a next steps I am going to add new topic
performance tests into existing perf test suite and look into making
{{FieldTable}} immutable and implementing on-demand parsing.
was (Author: alex.rufous):
Keith,
Thanks a lot for the review comments.
My changes for logback filter and fanout exchange routing functionality were
driven by jprofiler analysis indicating about performance being lost on
unnecessary {{Map}} object creation. I committed them against this JIRA as they
improve the performance a bit whilst routing the messages with fanout exchange
but the performance of other exchange implementation should improve as well.
Though, I am happy to revert the mentioned changes and commit them against
separate JIRAs.
As for exchange changes, they not only optimize the code but make it much
simpler. Effectively, the changed code converts the collection of
{{TopicMatcherResult}} got based on message routing key into a map where keys
are {{route destinations}} and values are {{routing/replacement keys}}. Before
my change the conversions was done by using intermediate map containing the
destination as a key and routing replacement key as a value. Than, multiple
maps (representing each {{TopicMatcherResult}} ) were merged into a single map.
My changes eliminated the need for intermediate map creation. I also do hope
that code is a bit simpler now. I left the old implementation untouched and
marked is as {{Deprecated}} in order to keep public methods unchanged as the
next version is minor release rather major one. (Though, I did not check
whether we made other breakable changes in the code in general. Perhaps,
keeping dead-code there is a waist). I am planning to merge committed changes
into 7.0 and do not want break backward compatibility there.
I liked Rob's idea of making {{FieldTable}} immutable and do on-demand
parsing. I will try to implement the corresponding changes as part of this
JIRA, however, making {{FieldTable}} im
[jira] [Commented] (QPID-8238) [Broker-J] Improve performance of asynchronous publishing of transient messages into topic exchange having queues bound using non-overlapping selectors
[
https://issues.apache.org/jira/browse/QPID-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610324#comment-16610324
]
Alex Rudyy commented on QPID-8238:
--
Keith,
Thanks a lot for the review comments.
My changes for logback filter and fanout exchange routing functionality were
driven by jprofiler analysis indicating about performance being lost on
unnecessary {{Map}} object creation. I committed them against this JIRA as they
improve the performance a bit whilst routing the messages with fanout exchange
but the performance of other exchange implementation should improve as well.
Though, I am happy to revert the mentioned changes and commit them against
separate JIRAs.
As for exchange changes, they not only optimize the code but make it much
simpler. Effectively, the changed code converts the collection of
{{TopicMatcherResult}} got based on message routing key into a map where keys
are {{route destinations}} and values are {{routing/replacement keys}}. Before
my change the conversions was done by using intermediate map containing the
destination as a key and routing replacement key as a value. Than, multiple
maps (representing each {{TopicMatcherResult}} ) were merged into a single map.
My changes eliminated the need for intermediate map creation. I also do hope
that code is a bit simpler now. I left the old implementation untouched and
marked is as {{Deprecated}} in order to keep public methods unchanged as the
next version is minor release rather major one. (Though, I did not check
whether we made other breakable changes in the code in general. Perhaps,
keeping dead-code there is a waist). I am planning to merge committed changes
into 7.0 and do not want break backward compatibility there.
I liked Rob's idea of making {{FieldTable}} immutable and do on-demand
parsing. I will try to implement the corresponding changes as part of this
JIRA, however, making {{FieldTable}} immutable most likely will not have any
effect on performance and performance is the main concern for me right now. I
do not think I can port on-demand parsing changes into 7.0. Thus, I am
currently looking into other performance optimization alternatives. I have not
looked into on-demand parsing yet.
I played a bit with replacing of {{AMQShortString}}s with java {{String}} in
{{BasicContentHeaderProperties}} (I have a patch a corresponding changes). My
performance tests did not revealed much performance improvements due to using
java {{String}} in {{BasicContentHeaderProperties}}. However, they did improve
the performance a bit. Potentially, making {{AMQShortString}}s to be a wrapper
of {{String}} and replacing usage of {{AMQShortString}}s with java {{String}}
where possible could be another refactoring worth doing.
The current routing code is very well tuned. I do not see any other routing
functionality to optimize. As a next steps I am going to add new topic
performance tests into existing perf test suite and look into making
{{FieldTable}} immutable and implementing on-demand parsing.
> [Broker-J] Improve performance of asynchronous publishing of transient
> messages into topic exchange having queues bound using non-overlapping
> selectors
>
>
> Key: QPID-8238
> URL: https://issues.apache.org/jira/browse/QPID-8238
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.7
>
> Attachments:
> 0001-QPID-8238-Use-java.lang.String-for-keys-and-values-i.patch
>
>
> The performance of asynchronous publishing of transient messages into topic
> exchange which routes messages into queues bound using non-overlapping
> selectors is 2-3 times slower than performance of 0.32 broker. The
> performance degradation is observed with AMQP 0.9, though, I suspect that the
> AMQP 0-10 protocol could be affected as well.
> I was running tests with 10 concurrent producers publishing messages on
> separate connections using the same routing key into 10 different queues
> (subscribers queues) bound to the exchange using non-overlapping selectors.
> My testing showed that performance of 7.0 broker for this particular use case
> was 2-3 times worse than performance of 0.32 broker.
> The following factors contributed to degradation of performance:
> • Copying data from direct memory into heap memory whilst decoding
> message headers. Due to this factor, the decoding of message headers is
> around twice slower. It seems it contributes around 70% to total performance
> degradation
> • The message routing algor
[jira] [Comment Edited] (QPID-8238) [Broker-J] Improve performance of asynchronous publishing of transient messages into topic exchange having queues bound using non-overlapping selectors
[
https://issues.apache.org/jira/browse/QPID-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610324#comment-16610324
]
Alex Rudyy edited comment on QPID-8238 at 9/11/18 9:06 AM:
---
Keith,
Thanks a lot for the review comments.
My changes for logback filter and fanout exchange routing functionality were
driven by jprofiler analysis indicating about performance being lost on
unnecessary {{Map}} object creation. I committed them against this JIRA as they
improve the performance a bit whilst routing the messages with fanout exchange
but the performance of other exchange implementation should improve as well.
Though, I am happy to revert the mentioned changes and commit them against
separate JIRAs.
As for exchange changes, they not only optimize the code but make it much
simpler. Effectively, the changed code converts the collection of
{{TopicMatcherResult}} got based on message routing key into a map where keys
are {{route destinations}} and values are {{routing/replacement keys}}. Before
my change the conversions was done by using intermediate map containing the
destination as a key and routing replacement key as a value. Than, multiple
maps (representing each {{TopicMatcherResult}} ) were merged into a single map.
My changes eliminated the need for intermediate map creation. I also do hope
that code is a bit simpler now. I left the old implementation untouched and
marked is as {{Deprecated}} in order to keep public methods unchanged as the
next version is minor release rather major one. (Though, I did not check
whether we made other breakable changes in the code in general. Perhaps,
keeping dead-code there is a waist). I am planning to merge committed changes
into 7.0 and do not want break backward compatibility there.
I liked Rob's idea of making {{FieldTable}} immutable and do on-demand
parsing. I will try to implement the corresponding changes as part of this
JIRA, however, making {{FieldTable}} immutable most likely will not have any
effect on performance and performance is the main concern for me right now. I
do not think I can port on-demand parsing changes into 7.0. Thus, I am
currently looking into other performance optimization alternatives. I have not
looked into on-demand parsing yet.
I played a bit with replacing of {{AMQShortStrings}} with java {{String}} in
{{BasicContentHeaderProperties}} (I have a patch a corresponding changes). My
performance tests did not revealed much performance improvements due to using
java {{String}} in {{BasicContentHeaderProperties}}. However, they did improve
the performance a bit. Potentially, making {{AMQShortString}}s to be a wrapper
of {{String}} and replacing usage of {{AMQShortString}}s with java {{String}}
where possible could be another refactoring worth doing.
The current routing code is very well tuned. I do not see any other routing
functionality to optimize. As a next steps I am going to add new topic
performance tests into existing perf test suite and look into making
{{FieldTable}} immutable and implementing on-demand parsing.
was (Author: alex.rufous):
Keith,
Thanks a lot for the review comments.
My changes for logback filter and fanout exchange routing functionality were
driven by jprofiler analysis indicating about performance being lost on
unnecessary {{Map}} object creation. I committed them against this JIRA as they
improve the performance a bit whilst routing the messages with fanout exchange
but the performance of other exchange implementation should improve as well.
Though, I am happy to revert the mentioned changes and commit them against
separate JIRAs.
As for exchange changes, they not only optimize the code but make it much
simpler. Effectively, the changed code converts the collection of
{{TopicMatcherResult}} got based on message routing key into a map where keys
are {{route destinations}} and values are {{routing/replacement keys}}. Before
my change the conversions was done by using intermediate map containing the
destination as a key and routing replacement key as a value. Than, multiple
maps (representing each {{TopicMatcherResult}} ) were merged into a single map.
My changes eliminated the need for intermediate map creation. I also do hope
that code is a bit simpler now. I left the old implementation untouched and
marked is as {{Deprecated}} in order to keep public methods unchanged as the
next version is minor release rather major one. (Though, I did not check
whether we made other breakable changes in the code in general. Perhaps,
keeping dead-code there is a waist). I am planning to merge committed changes
into 7.0 and do not want break backward compatibility there.
I liked Rob's idea of making {{FieldTable}} immutable and do on-demand
parsing. I will try to implement the corresponding changes as part of this
JIRA, however, making {{FieldTable}} im
[jira] [Commented] (QPID-8238) [Broker-J] Improve performance of asynchronous publishing of transient messages into topic exchange having queues bound using non-overlapping selectors
[
https://issues.apache.org/jira/browse/QPID-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610224#comment-16610224
]
Keith Wall commented on QPID-8238:
--
I think it would be better to separate the FieldTable optimisation and any
LOGBACK-1027 workaround performance improvements into separate JIRAs. This
would make it easier for reviewers to review and users to evaluate the risk of
taking a change (or not). At the moment the FieldTable changes which affects
*all* 0-x users are hidden under a Jira title that talks of topic exchange.
Conversely, the Jira body talks of a 0-9 performance degradation yet the code
change to the topic exchange impacts a shared 0-9, 0-10, 1.0 path. I would
suggest reverting the
[c30e8ae|https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=c30e8ae]
and
[8c58e38|https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=8c58e38]
from this JIRA.
On the {{FieldTable}} changes, I did like the idea expressed above to make the
FieldTables immutable. I was imagining turning FieldTable into an interface
with two implementations. One that accepts the ByteBuffer and one that adapts
a Java Map. The latter would be used in the BDB upgraders and the conversion
layer. I think this approach would make the implementation tidier and easier
to reason about. Separately, the idea to make the decoding of the short
strings within the FieldTable on-demand sounds appealing. This would benefit
any application that was setting many string properties on a message but only
using a subset for routing. Did you do any testing? (I did wonder if the
approach would also bring benefit to the strings in
BasicContentHeaderProperties - but that would be a separate optimisation).
On the topic exchange changes - could you add some commentary to help explain
your thinking behind this change to allow me to review efficiently.
The turbo filter changes looked reasonable.
> [Broker-J] Improve performance of asynchronous publishing of transient
> messages into topic exchange having queues bound using non-overlapping
> selectors
>
>
> Key: QPID-8238
> URL: https://issues.apache.org/jira/browse/QPID-8238
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.7
>
> Attachments:
> 0001-QPID-8238-Use-java.lang.String-for-keys-and-values-i.patch
>
>
> The performance of asynchronous publishing of transient messages into topic
> exchange which routes messages into queues bound using non-overlapping
> selectors is 2-3 times slower than performance of 0.32 broker. The
> performance degradation is observed with AMQP 0.9, though, I suspect that the
> AMQP 0-10 protocol could be affected as well.
> I was running tests with 10 concurrent producers publishing messages on
> separate connections using the same routing key into 10 different queues
> (subscribers queues) bound to the exchange using non-overlapping selectors.
> My testing showed that performance of 7.0 broker for this particular use case
> was 2-3 times worse than performance of 0.32 broker.
> The following factors contributed to degradation of performance:
> • Copying data from direct memory into heap memory whilst decoding
> message headers. Due to this factor, the decoding of message headers is
> around twice slower. It seems it contributes around 70% to total performance
> degradation
> • The message routing algorithm is slower due to need to support a new
> feature to route messages into bound exchanges (in addition to queues) using
> replacement routing key.
> • AMQ short strings caching contributes 5-10% to total performance
> degradation. The caching was added to manage heap space more efficiently.
> The numbers provided here could be inaccurate due instrumentation overhead
> whilst profiling the issue.
> Potentially, caching can be turned off but that will not improve performance
> much.
> On other hand, adding of additional caching of strings to amqp-short-strings
> would improve the performance a bit. Whilst evaluating selectors, the fields
> used in selector expressions are represented as java strings but they get
> converted every time into amqp-short-strings when looking up for message
> header values. If 10 queues are bound to the exchange using the same binding
> key, the selector expression is evaluated 10 times for the incoming message.
> Thus, all selector field names are get converted into amqp-short-strings 10
> times as well. It seems adding caching here can
[jira] [Comment Edited] (QPID-8238) [Broker-J] Improve performance of asynchronous publishing of transient messages into topic exchange having queues bound using non-overlapping selectors
[
https://issues.apache.org/jira/browse/QPID-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610224#comment-16610224
]
Keith Wall edited comment on QPID-8238 at 9/11/18 7:52 AM:
---
I think it would be better to separate the FieldTable optimisation and any
LOGBACK-1027 workaround performance improvements into separate JIRAs. This
would make it easier for reviewers to review and users to evaluate the risk of
taking a change (or not). At the moment the FieldTable changes which affects
*all* 0-x users are hidden under a Jira title that talks of topic exchange.
Conversely, the Jira body talks of a 0-9 performance degradation yet the code
change to the topic exchange impacts a shared 0-9, 0-10, 1.0 path. I would
suggest reverting the
[c30e8ae|https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=c30e8ae]
and
[8c58e38|https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=8c58e38]
from this JIRA.
On the {{FieldTable}} changes, I did like the idea expressed above to make the
FieldTables immutable. I was imagining turning FieldTable into an interface
with two implementations. One that accepts the ByteBuffer and one that adapts
a Java Map. The latter would be used in the BDB upgraders and the conversion
layer. I think this approach would make the implementation tidier and easier
to reason about. Separately, the idea to make the decoding of the short
strings within the FieldTable on-demand sounds appealing. This would benefit
any application that was setting many string properties on a message but only
using a subset for routing. Did you do any testing? (I did wonder if the
approach would also bring benefit to the strings in
BasicContentHeaderProperties - but that would be a separate optimisation).
On the topic exchange changes - could you add some commentary to help explain
your thinking behind this change to allow me to review efficiently.
The turbo filter changes looked reasonable.
was (Author: k-wall):
I think it would be better to separate the FieldTable optimisation and any
LOGBACK-1027 workaround performance improvements into separate JIRAs. This
would make it easier for reviewers to review and users to evaluate the risk of
taking a change (or not). At the moment the FieldTable changes which affects
*all* 0-x users are hidden under a Jira title that talks of topic exchange.
Conversely, the Jira body talks of a 0-9 performance degradation yet the code
change to the topic exchange impacts a shared 0-9, 0-10, 1.0 path. I would
suggest reverting the
[c30e8ae|https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=c30e8ae]
and
[8c58e38|https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=8c58e38]
from this JIRA.
On the {{FieldTable}} changes, I did like the idea expressed above to make the
FieldTables immutable. I was imagining turning FieldTable into an interface
with two implementations. One that accepts the ByteBuffer and one that adapts
a Java Map. The latter would be used in the BDB upgraders and the conversion
layer. I think this approach would make the implementation tidier and easier
to reason about. Separately, the idea to make the decoding of the short
strings within the FieldTable on-demand sounds appealing. This would benefit
any application that was setting many string properties on a message but only
using a subset for routing. Did you do any testing? (I did wonder if the
approach would also bring benefit to the strings in
BasicContentHeaderProperties - but that would be a separate optimisation).
On the topic exchange changes - could you add some commentary to help explain
your thinking behind this change to allow me to review efficiently.
The turbo filter changes looked reasonable.
> [Broker-J] Improve performance of asynchronous publishing of transient
> messages into topic exchange having queues bound using non-overlapping
> selectors
>
>
> Key: QPID-8238
> URL: https://issues.apache.org/jira/browse/QPID-8238
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.7
>
> Attachments:
> 0001-QPID-8238-Use-java.lang.String-for-keys-and-values-i.patch
>
>
> The performance of asynchronous publishing of transient messages into topic
> exchange which routes messages into queues bound using non-overlapping
> selectors is 2-3 times slower than performance of 0.32 broker. The
> performance degradation is observed with AMQP 0.9, though, I suspect that
