[jira] [Updated] (DISPATCH-598) Router crash when calling sender and session close methods in onLinkFLow()
[ https://issues.apache.org/jira/browse/DISPATCH-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy updated DISPATCH-598: --- Priority: Blocker (was: Major) > Router crash when calling sender and session close methods in onLinkFLow() > -- > > Key: DISPATCH-598 > URL: https://issues.apache.org/jira/browse/DISPATCH-598 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.7.0 > Environment: Centos 7. Java 1.8 >Reporter: Rohan Mars >Priority: Blocker > Fix For: 0.8.0 > > Attachments: test-app-reactor-core.tar.gz > > > Closing session/connection in sender onLinkFlow() causes router to crash -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-598) Router crash when calling sender and session close methods in onLinkFLow()
[ https://issues.apache.org/jira/browse/DISPATCH-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15754850#comment-15754850 ] Ganesh Murthy commented on DISPATCH-598: The router crashes because the PN_LINK_REMOTE_CLOSE and PN_SESSION_REMOTE_CLOSE events come in on the same collector loop. Setting this as a blocker for 0.8 > Router crash when calling sender and session close methods in onLinkFLow() > -- > > Key: DISPATCH-598 > URL: https://issues.apache.org/jira/browse/DISPATCH-598 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.7.0 > Environment: Centos 7. Java 1.8 >Reporter: Rohan Mars > Fix For: 0.8.0 > > Attachments: test-app-reactor-core.tar.gz > > > Closing session/connection in sender onLinkFlow() causes router to crash -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-596) error is lost from rejected state in relayed disposition
[
https://issues.apache.org/jira/browse/DISPATCH-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-596.
Resolution: Fixed
> error is lost from rejected state in relayed disposition
>
>
> Key: DISPATCH-596
> URL: https://issues.apache.org/jira/browse/DISPATCH-596
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 0.7.0
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
> Attachments: reject.py
>
>
> {noformat}
> [0x55d7cde663a0]: -> SASL
> [0x55d7cde663a0]: <- SASL
> [0x55d7cde663a0]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
> [0x55d7cde663a0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS,
> initial-response=b"anonymous@localhost.localdomain"]
> [0x55d7cde663a0]:0 <- @sasl-outcome(68) [code=0]
> [0x55d7cde663a0]: -> AMQP
> [0x55d7cde663a0]:0 -> @open(16)
> [container-id="4308de22-4121-49bc-bac4-8ee05bf1504e", hostname="localhost",
> channel-max=32767]
> [0x55d7cde663a0]:0 -> @begin(17) [next-outgoing-id=0,
> incoming-window=2147483647, outgoing-window=2147483647]
> [0x55d7cde663a0]:0 -> @attach(18)
> [name="4308de22-4121-49bc-bac4-8ee05bf1504e-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]
> [0x55d7cde663a0]:0 -> @attach(18)
> [name="4308de22-4121-49bc-bac4-8ee05bf1504e-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]
> [0x55d7cde663a0]:0 -> @flow(19) [incoming-window=2147483647,
> next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0,
> link-credit=10, drain=false]
> [0x55d7cde663a0]: <- AMQP
> [0x55d7cde663a0]:0 <- @open(16) [container-id="Router.A",
> max-frame-size=16384, channel-max=32767, idle-time-out=8000,
> offered-capabilities=:"ANONYMOUS-RELAY",
> properties={:product="qpid-dispatch-router", :version="0.8.0"}]
> [0x55d7cde663a0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=0,
> incoming-window=100, outgoing-window=2147483647]
> [0x55d7cde663a0]:0 <- @attach(18)
> [name="4308de22-4121-49bc-bac4-8ee05bf1504e-examples", handle=0, role=false,
> 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]
> [0x55d7cde663a0]:0 <- @attach(18)
> [name="4308de22-4121-49bc-bac4-8ee05bf1504e-examples", handle=1, role=true,
> 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]
> [0x55d7cde663a0]:0 <- @flow(19) [next-incoming-id=0, incoming-window=100,
> next-outgoing-id=0, outgoing-window=2147483647, handle=1, delivery-count=0,
> link-credit=250, drain=false]
> [0x55d7cde663a0]:0 -> @transfer(20) [handle=1, delivery-id=0,
> delivery-tag=b"1", message-format=0, settled=false, more=false] (78)
> "\x00Sp\xd0\x00\x00\x00\x0b\x00\x00\x00\x05BP\x04@BR\x00\x00Ss\xd0\x00\x00\x00"\x00\x00\x00\x0d\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@R\x00@\x00Sw\xa1\x0cHello
> World!"
> [0x55d7cde663a0]:0 <- @transfer(20) [handle=0, delivery-id=0,
> delivery-tag=b"\x07\x00\x00\x00\x00\x00\x00\x00", message-format=0,
> settled=false, more=false] (78)
> "\x00Sp\xd0\x00\x00\x00\x0b\x00\x00\x00\x05BP\x04@BR\x00\x00Ss\xd0\x00\x00\x00"\x00\x00\x00\x0d\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@R\x00@\x00Sw\xa1\x0cHello
> World!"
> Rejecting delivery: Hello World!
> [0x55d7cde663a0]:0 -> @disposition(21) [role=true, first=0, last=0,
> settled=true, state=@rejected(37) [error=@error(29)
> [condition=:"amqp:internal-error", description="you were out of luck this
> time!"]]]
> receiver sends disposition with rejected containing and error...
> [0x55d7cde663a0]:0 <- @flow(19) [next-incoming-id=1, incoming-window=100,
> next-outgoing-id=1, outgoing-window=2147483647, handle=1, delivery-count=1,
> link-credit=250, drain=false]
> [0x55d7cde663a0]:0 <- @disposition(21) [role=true, first=0, last=0,
> settled=true, state=@rejected(37) []]
> Message was rejected: None
> disposition that gets relayed back to sender no longer has the error
> information
> [0x55d7cde663a0]:0 -> @close(24) []
> [0x55d7cde663a0]: -> EOS
> [0x55d7cde663a0]:0 <- @close(24) []
> [0x55d7cde663a0]: <- EOS
> {noformat}
--
This message was sent by
[jira] [Assigned] (DISPATCH-598) Router crash when calling sender and session close methods in onLinkFLow()
[ https://issues.apache.org/jira/browse/DISPATCH-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy reassigned DISPATCH-598: -- Assignee: Ganesh Murthy > Router crash when calling sender and session close methods in onLinkFLow() > -- > > Key: DISPATCH-598 > URL: https://issues.apache.org/jira/browse/DISPATCH-598 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.7.0 > Environment: Centos 7. Java 1.8 >Reporter: Rohan Mars >Assignee: Ganesh Murthy >Priority: Blocker > Fix For: 0.8.0 > > Attachments: test-app-reactor-core.tar.gz > > > Closing session/connection in sender onLinkFlow() causes router to crash -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-595) dispositions propagated after link detach on link route
[
https://issues.apache.org/jira/browse/DISPATCH-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-595.
Resolution: Fixed
> dispositions propagated after link detach on link route
> ---
>
> Key: DISPATCH-595
> URL: https://issues.apache.org/jira/browse/DISPATCH-595
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 0.8.0
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> We have a subscriber that is link routed through router to a broker. If the
> subscriber detaches immediately after accepting a message, the
> acknowledgement of that message is only relaye dto the broker after the
> relaying of the link detach. This means the message is left on the queue,
> though the subscriber had explicitly accepted it.
> {noformat}
> Tue Dec 13 17:43:52 2016 AGENT (warning) routerId is deprecated, use id
> instead
> Tue Dec 13 17:43:52 2016 SERVER (warning) HTTP support is not available
> Tue Dec 13 17:43:52 2016 SERVER (info) Container Name: Router.A
> Tue Dec 13 17:43:52 2016 ROUTER (info) Router started in Standalone mode
> Tue Dec 13 17:43:52 2016 ROUTER_CORE (info) Router Core thread running.
> 0/Router.A
> Tue Dec 13 17:43:52 2016 ROUTER_CORE (info) In-process subscription
> M/$management
> Tue Dec 13 17:43:52 2016 AGENT (info) Activating management agent on
> $_management_internal
> Tue Dec 13 17:43:52 2016 ROUTER_CORE (info) In-process subscription
> L/$management
> Tue Dec 13 17:43:52 2016 ROUTER_CORE (info) In-process subscription
> L/$_management_internal
> Tue Dec 13 17:43:52 2016 CONN_MGR (info) Configured Listener: 0.0.0.0:5672
> proto=any, role=normal
> Tue Dec 13 17:43:52 2016 CONN_MGR (info) Configured Connector: 0.0.0.0:5673
> proto=any, role=route-container
> Tue Dec 13 17:43:52 2016 POLICY (info) Policy configured maxConnections:
> 65535, policyDir: '', access rules enabled: 'false'
> Tue Dec 13 17:43:52 2016 POLICY (info) Policy fallback defaultVhost is
> defined: '$default'
> Tue Dec 13 17:43:52 2016 SERVER (info) Operational, 4 Threads Running
> [0x7f4764006fd0]: -> SASL
> [0x7f4764006fd0]: <- SASL
> [0x7f4764006fd0]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:PLAIN, :ANONYMOUS]]
> [0x7f4764006fd0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS,
> initial-response=b"anonymous@localhost.localdomain"]
> [0x7f4764006fd0]:0 <- @sasl-outcome(68) [code=0]
> [0x7f4764006fd0]: -> AMQP
> [0x7f4764006fd0]:0 -> @open(16) [container-id="Router.A", hostname="0.0.0.0",
> max-frame-size=16384, channel-max=32767, idle-time-out=8000,
> offered-capabilities=:"ANONYMOUS-RELAY",
> properties={:product="qpid-dispatch-router", :version="0.8.0"}]
> [0x7f4764006fd0]: <- AMQP
> [0x7f4764006fd0]:0 <- @open(16) [container-id="0.0.0.0",
> max-frame-size=4294967295, channel-max=65535, idle-time-out=3,
> offered-capabilities=@PN_SYMBOL[:"sole-connection-for-container",
> :"DELAYED_DELIVERY"], properties={:product="apache-activemq-artemis",
> :version="1.6.0-SNAPSHOT"}]
> Tue Dec 13 17:43:53 2016 ROUTER_CORE (info) Link Route Activated
> 'linkRoute/0' on connection redirect
> Tue Dec 13 17:43:53 2016 ROUTER_CORE (info) Link Route Activated
> 'linkRoute/1' on connection redirect
> [0x7f4760006b70]: <- SASL
> [0x7f4760006b70]: -> SASL
> [0x7f4760006b70]:0 -> @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS, :"DIGEST-MD5", :PLAIN]]
> [0x7f4760006b70]:0 <- @sasl-init(65) [mechanism=:ANONYMOUS,
> initial-response=b"anonymous@localhost.localdomain"]
> [0x7f4760006b70]:0 -> @sasl-outcome(68) [code=0]
> [0x7f4760006b70]: <- AMQP
> [0x7f4760006b70]:0 <- @open(16) [container-id="myclient",
> hostname="localhost", channel-max=32767]
> [0x7f4760006b70]:0 <- @begin(17) [next-outgoing-id=0,
> incoming-window=2147483647, outgoing-window=2147483647]
> [0x7f4760006b70]:0 <- @attach(18) [name="mysubscription", handle=0,
> role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> [address="test", durable=2, expiry-policy=:never, timeout=0, dynamic=false,
> capabilities=:topic], target=@target(41) [durable=0, timeout=0,
> dynamic=false], initial-delivery-count=0]
> [0x7f4760006b70]:0 <- @flow(19) [incoming-window=2147483647,
> next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0,
> link-credit=10, drain=false]
> [0x7f4760006b70]: -> AMQP
> [0x7f4760006b70]:0 -> @open(16) [container-id="Router.A",
> max-frame-size=16384, channel-max=32767, idle-time-out=8000,
> offered-capabilities=:"ANONYMOUS-RELAY",
> properties={:product="qpid-dispatch-router", :version="0.8.0"}]
> [0x7f4760006b70]:0 -> @begin(17) [remote-channel=0, next-outgoing-id=0,
> incoming-window=100, outgoing-window=2147483647]
> [0x7f4764006fd0]:0 -> @begin(17) [next-outgoing-id=0, incoming-
[jira] [Resolved] (DISPATCH-557) High connection rates cause problems in the Python management agent
[ https://issues.apache.org/jira/browse/DISPATCH-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-557. Resolution: Fixed > High connection rates cause problems in the Python management agent > --- > > Key: DISPATCH-557 > URL: https://issues.apache.org/jira/browse/DISPATCH-557 > Project: Qpid Dispatch > Issue Type: Bug > Components: Management Agent >Affects Versions: 0.7.0 >Reporter: Ted Ross >Assignee: Ganesh Murthy >Priority: Critical > Fix For: 0.8.0 > > > Since connection entities are the only non-configuration (spontaneously > occurring) entities that are still managed by the Python agent, high rates of > opening and closing connections causes large CPU overhead in the agent. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-603) address resource leak
[ https://issues.apache.org/jira/browse/DISPATCH-603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy reassigned DISPATCH-603: -- Assignee: Ganesh Murthy > address resource leak > - > > Key: DISPATCH-603 > URL: https://issues.apache.org/jira/browse/DISPATCH-603 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.7.0 > Environment: Centos 7, JDK 8 >Reporter: Rohan Mars >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: test-app-address-leak.tar > > > A multi-node router mesh will leak addresses, causing a memory increase. > The test case attached can reproduce the problem. > The addresses that are leaked are temporary reply addresses. > See the README for instructions on how to run. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-599) Link routing : messages is not transferred if sender detach link immediately
[ https://issues.apache.org/jira/browse/DISPATCH-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy updated DISPATCH-599: --- Fix Version/s: 0.8.0 > Link routing : messages is not transferred if sender detach link immediately > > > Key: DISPATCH-599 > URL: https://issues.apache.org/jira/browse/DISPATCH-599 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.8.0 >Reporter: Paolo Patierno >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > > Hi, > using link routing, if the sender sends a message and detach the link > immediately after that, the message isn't transferred to the receiver (just > dropped by the router ?). Following what I see from log : > [0x7fd30803e4c0]:0 <- @transfer(20) [handle=3, delivery-id=1, > delivery-tag=b"1", message-format=0] (66) > "\x00Sp\xc0\x06\x05B@@@C\x00Sr\xc1\x15\x04\xa3\x05x-qosT\x00\xa3\x08x-retainB\x00Ss\xc0\x0e\x03T\xff@\xa1\x08my_topic\x00Su\xa0\x05Hello" > [0x7fd30803e4c0]:0 <- @detach(22) [handle=3, closed=true] > [0x7fd30803e4c0]:0 <- @close(24) [] > [0x7fd30803e4c0]: <- EOS > [0x7fd30803e4c0]:0 -> @close(24) [] > [0x7fd308021780]:1 -> @detach(22) [handle=0, closed=true] > [0x7fd30803e4c0]: -> EOS > It doesn't happen with message routing. > Thanks, > Paolo. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-599) Link routing : messages is not transferred if sender detach link immediately
[ https://issues.apache.org/jira/browse/DISPATCH-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy reassigned DISPATCH-599: -- Assignee: Ganesh Murthy > Link routing : messages is not transferred if sender detach link immediately > > > Key: DISPATCH-599 > URL: https://issues.apache.org/jira/browse/DISPATCH-599 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.8.0 >Reporter: Paolo Patierno >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > > Hi, > using link routing, if the sender sends a message and detach the link > immediately after that, the message isn't transferred to the receiver (just > dropped by the router ?). Following what I see from log : > [0x7fd30803e4c0]:0 <- @transfer(20) [handle=3, delivery-id=1, > delivery-tag=b"1", message-format=0] (66) > "\x00Sp\xc0\x06\x05B@@@C\x00Sr\xc1\x15\x04\xa3\x05x-qosT\x00\xa3\x08x-retainB\x00Ss\xc0\x0e\x03T\xff@\xa1\x08my_topic\x00Su\xa0\x05Hello" > [0x7fd30803e4c0]:0 <- @detach(22) [handle=3, closed=true] > [0x7fd30803e4c0]:0 <- @close(24) [] > [0x7fd30803e4c0]: <- EOS > [0x7fd30803e4c0]:0 -> @close(24) [] > [0x7fd308021780]:1 -> @detach(22) [handle=0, closed=true] > [0x7fd30803e4c0]: -> EOS > It doesn't happen with message routing. > Thanks, > Paolo. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (DISPATCH-599) Link routing : messages is not transferred if sender detach link immediately
[ https://issues.apache.org/jira/browse/DISPATCH-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy closed DISPATCH-599. -- Resolution: Cannot Reproduce The fix to DISPATCH-595 fixed this issue. Please re-open if you still see this issue after testing with latest master. > Link routing : messages is not transferred if sender detach link immediately > > > Key: DISPATCH-599 > URL: https://issues.apache.org/jira/browse/DISPATCH-599 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.8.0 >Reporter: Paolo Patierno >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > > Hi, > using link routing, if the sender sends a message and detach the link > immediately after that, the message isn't transferred to the receiver (just > dropped by the router ?). Following what I see from log : > [0x7fd30803e4c0]:0 <- @transfer(20) [handle=3, delivery-id=1, > delivery-tag=b"1", message-format=0] (66) > "\x00Sp\xc0\x06\x05B@@@C\x00Sr\xc1\x15\x04\xa3\x05x-qosT\x00\xa3\x08x-retainB\x00Ss\xc0\x0e\x03T\xff@\xa1\x08my_topic\x00Su\xa0\x05Hello" > [0x7fd30803e4c0]:0 <- @detach(22) [handle=3, closed=true] > [0x7fd30803e4c0]:0 <- @close(24) [] > [0x7fd30803e4c0]: <- EOS > [0x7fd30803e4c0]:0 -> @close(24) [] > [0x7fd308021780]:1 -> @detach(22) [handle=0, closed=true] > [0x7fd30803e4c0]: -> EOS > It doesn't happen with message routing. > Thanks, > Paolo. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-608) Links not cleaned up when a close is sent without being preceeded by a detach and end
Ganesh Murthy created DISPATCH-608: -- Summary: Links not cleaned up when a close is sent without being preceeded by a detach and end Key: DISPATCH-608 URL: https://issues.apache.org/jira/browse/DISPATCH-608 Project: Qpid Dispatch Issue Type: Bug Components: Container Affects Versions: 0.7.0 Reporter: Ganesh Murthy Assignee: Ganesh Murthy There are memory leaks of qd_dispatch_t objects when close is sent without being proceeded by a detach and end frames -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-608) Links not cleaned up when a close is sent without being preceeded by a detach and end
[ https://issues.apache.org/jira/browse/DISPATCH-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy updated DISPATCH-608: --- Fix Version/s: 0.8.0 > Links not cleaned up when a close is sent without being preceeded by a detach > and end > - > > Key: DISPATCH-608 > URL: https://issues.apache.org/jira/browse/DISPATCH-608 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 0.7.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > > There are memory leaks of qd_dispatch_t objects when close is sent without > being proceeded by a detach and end frames -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-609) Name attribute is duplicated in QUERY response
[ https://issues.apache.org/jira/browse/DISPATCH-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-609. Resolution: Fixed Fix Version/s: 0.8.0 > Name attribute is duplicated in QUERY response > -- > > Key: DISPATCH-609 > URL: https://issues.apache.org/jira/browse/DISPATCH-609 > Project: Qpid Dispatch > Issue Type: Bug > Components: Management Agent >Affects Versions: 0.8.0 >Reporter: Ernest Allen >Assignee: Ganesh Murthy >Priority: Minor > Fix For: 0.8.0 > > > When a management QUERY contains an attribute list, and that list contains a > "name" attribute, the response contains two name attributes -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-605) Memory Leak with multple sender/receivers in one session
[ https://issues.apache.org/jira/browse/DISPATCH-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-605. Resolution: Fixed Assignee: Ganesh Murthy Most of the delivery leaks have been fixed as additional fixes to DISPATCH-582 > Memory Leak with multple sender/receivers in one session > > > Key: DISPATCH-605 > URL: https://issues.apache.org/jira/browse/DISPATCH-605 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.7.0 > Environment: Centos 7, JDK 8 >Reporter: Rohan Mars >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: test-app-memory-leak.tar > > > Running multiple sender/receivers in a single connection appears to leak a > considerable amount of memory. Mostly qdr_delivery_t objects it appears. > The test creates 10 senders/receivers for each connection. With 5 connections > created in each sender/receiver process. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-344) memory growth after repeated calls from qdstat -m
[
https://issues.apache.org/jira/browse/DISPATCH-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy updated DISPATCH-344:
---
Description:
0. version of dispatch code is 0.6.0 RC3
1. bring up a router
2. do not attach any clients, except...
3. ...repeatedly invoke qdstat -m on the router
result:
After 1000 calls from "qdstat -m", top shows that router memory has grown by
4947968 bytes. The output from "qdstat -m" accounts for about 63% of that, or
318 bytes.
Here are the data types that increased, according to qdstat, ordered from
largest to smallest.
Um. This table looked really nice when it was in a fixed-width font.
{noformat}
type size total total increase increase
beforeafter structs bytes
=
qd_log_entry_t 2104112 1040 928 1952512
qd_buffer_t536 80 11201040 557440
qd_field_iterator_t128 192 12801088 139264
qdr_delivery_t 136 64 512 448 60928
qdr_connection_t 216 64 320 256 55296
qdr_field_t40 192 12801088 43520
qd_connection_t224 64 256 192 43008
qd_message_content_t 640 1680 64 40960
qd_message_t 128 192 512 320 40960
qdpn_connector_t 600 1664 48 28800
qdr_general_work_t 64 64 512 448 28672
qdr_connection_work_t 56 64 512 448 25088
qd_composite_t 112 64 256 192 21504
qdr_link_t 264 1680 64 16896
qd_composed_field_t64 64 256 192 12288
qdr_terminus_t 64 64 256 192 12288
qdr_delivery_ref_t 24 64 512 448 10752
qdr_link_ref_t 24 64 512 448 10752
qd_parsed_field_t 80 128 256 128 10240
qdr_action_t 160 256 320 64 10240
qd_link_t 48 64 256 1929216
qdr_error_t240 320 3207680
qd_deferred_call_t 32 64 256 1926144
{noformat}
grand total increase from qdstat:318
grand total increase from top: 4947968
Here is the script I used
This input window is breaking some lines. >:-(
#! /bin/bash
echo "NOTE: router should already be running."
INSTALL_ROOT=${SHACKLETON_ROOT}/install
PROTON_INSTALL_DIR=${INSTALL_ROOT}/proton
DISPATCH_INSTALL_DIR=${INSTALL_ROOT}/dispatch
QDSTAT=${DISPATCH_INSTALL_DIR}/bin/qdstat
export LD_LIBRARY_PATH=${DISPATCH_INSTALL_DIR}/lib64:${PROTON_INSTALL_DIR}/lib64
export
PYTHONPATH=${DISPATCH_INSTALL_DIR}/lib/qpid-dispatch/python:${DISPATCH_INSTALL_DIR}/lib/python2.7/site-packages:${PROTON_INSTALL_DIR}/lib64/proton/bindings/python
ROUTER_PID=`ps -aef | grep qdrouterd | grep -v grep | awk '{print $2}'`
count=1
while [ $count -lt 1001 ]
do
echo "==="
echo "TEST $count"
echo "==="
count=$(( $count + 1 ))
top -b -n 1 -p ${ROUTER_PID}
${QDSTAT} -m
sleep 3
done
was:
0. version of dispatch code is 0.6.0 RC3
1. bring up a router
2. do not attach any clients, except...
3. ...repeatedly invoke qdstat -m on the router
result:
After 1000 calls from "qdstat -m", top shows that router memory has grown by
4947968 bytes. The output from "qdstat -m" accounts for about 63% of that, or
318 bytes.
Here are the data types that increased, according to qdstat, ordered from
largest to smallest.
Um. This table looked really nice when it was in a fixed-width font.
type size total total increase increase
beforeafter structs bytes
=
qd_log_entry_t 2104112 1040 928 1952512
qd_buffer_t536 80 11201040 557440
qd_field_iterator_t128 192 12801088 139264
qdr_delivery_t 136 64 512 448 60928
qdr_connection_t 216 64 320 256 55296
qdr_field_t40 192
[jira] [Assigned] (DISPATCH-344) memory growth after repeated calls from qdstat -m
[
https://issues.apache.org/jira/browse/DISPATCH-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy reassigned DISPATCH-344:
--
Assignee: Ganesh Murthy
> memory growth after repeated calls from qdstat -m
> -
>
> Key: DISPATCH-344
> URL: https://issues.apache.org/jira/browse/DISPATCH-344
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Affects Versions: 0.6.0
>Reporter: michael goulish
>Assignee: Ganesh Murthy
>
> 0. version of dispatch code is 0.6.0 RC3
> 1. bring up a router
> 2. do not attach any clients, except...
> 3. ...repeatedly invoke qdstat -m on the router
> result:
> After 1000 calls from "qdstat -m", top shows that router memory has grown by
> 4947968 bytes. The output from "qdstat -m" accounts for about 63% of that,
> or 318 bytes.
> Here are the data types that increased, according to qdstat, ordered from
> largest to smallest.
> Um. This table looked really nice when it was in a fixed-width font.
> {noformat}
> type size total total increase
> increasebeforeafter structs bytes
>
> =
> qd_log_entry_t 2104112 1040 928 1952512
> qd_buffer_t536 80 11201040 557440
> qd_field_iterator_t128 192 12801088 139264
> qdr_delivery_t 136 64 512 448 60928
> qdr_connection_t 216 64 320 256 55296
> qdr_field_t40 192 12801088 43520
> qd_connection_t224 64 256 192 43008
> qd_message_content_t 640 1680 64 40960
> qd_message_t 128 192 512 320 40960
> qdpn_connector_t 600 1664 48 28800
> qdr_general_work_t 64 64 512 448 28672
> qdr_connection_work_t 56 64 512 448 25088
> qd_composite_t 112 64 256 192 21504
> qdr_link_t 264 1680 64 16896
> qd_composed_field_t64 64 256 192 12288
> qdr_terminus_t 64 64 256 192 12288
> qdr_delivery_ref_t 24 64 512 448 10752
> qdr_link_ref_t 24 64 512 448 10752
> qd_parsed_field_t 80 128 256 128 10240
> qdr_action_t 160 256 320 64 10240
> qd_link_t 48 64 256 1929216
> qdr_error_t240 320 3207680
> qd_deferred_call_t 32 64 256 1926144
> {noformat}
> grand total increase from qdstat:318
> grand total increase from top: 4947968
> Here is the script I used
> This input window is breaking some lines. >:-(
> #! /bin/bash
> echo "NOTE: router should already be running."
> INSTALL_ROOT=${SHACKLETON_ROOT}/install
> PROTON_INSTALL_DIR=${INSTALL_ROOT}/proton
> DISPATCH_INSTALL_DIR=${INSTALL_ROOT}/dispatch
> QDSTAT=${DISPATCH_INSTALL_DIR}/bin/qdstat
> export
> LD_LIBRARY_PATH=${DISPATCH_INSTALL_DIR}/lib64:${PROTON_INSTALL_DIR}/lib64
> export
> PYTHONPATH=${DISPATCH_INSTALL_DIR}/lib/qpid-dispatch/python:${DISPATCH_INSTALL_DIR}/lib/python2.7/site-packages:${PROTON_INSTALL_DIR}/lib64/proton/bindings/python
> ROUTER_PID=`ps -aef | grep qdrouterd | grep -v grep | awk '{print $2}'`
> count=1
> while [ $count -lt 1001 ]
> do
> echo "==="
> echo "TEST $count"
> echo "==="
> count=$(( $count + 1 ))
> top -b -n 1 -p ${ROUTER_PID}
> ${QDSTAT} -m
> sleep 3
> done
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-344) memory growth after repeated calls from qdstat -m
[
https://issues.apache.org/jira/browse/DISPATCH-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15824184#comment-15824184
]
Ganesh Murthy commented on DISPATCH-344:
Ran the script to execute qdstat -m 1000 times and the memory of the router
stayed at 548076. This problem might have been fixed with all the other mem
leak fixes we have done in master. Marking this issue as fixed.
> memory growth after repeated calls from qdstat -m
> -
>
> Key: DISPATCH-344
> URL: https://issues.apache.org/jira/browse/DISPATCH-344
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Affects Versions: 0.6.0
>Reporter: michael goulish
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> 0. version of dispatch code is 0.6.0 RC3
> 1. bring up a router
> 2. do not attach any clients, except...
> 3. ...repeatedly invoke qdstat -m on the router
> result:
> After 1000 calls from "qdstat -m", top shows that router memory has grown by
> 4947968 bytes. The output from "qdstat -m" accounts for about 63% of that,
> or 318 bytes.
> Here are the data types that increased, according to qdstat, ordered from
> largest to smallest.
> Um. This table looked really nice when it was in a fixed-width font.
> {noformat}
> type size total total increase
> increasebeforeafter structs bytes
>
> =
> qd_log_entry_t 2104112 1040 928 1952512
> qd_buffer_t536 80 11201040 557440
> qd_field_iterator_t128 192 12801088 139264
> qdr_delivery_t 136 64 512 448 60928
> qdr_connection_t 216 64 320 256 55296
> qdr_field_t40 192 12801088 43520
> qd_connection_t224 64 256 192 43008
> qd_message_content_t 640 1680 64 40960
> qd_message_t 128 192 512 320 40960
> qdpn_connector_t 600 1664 48 28800
> qdr_general_work_t 64 64 512 448 28672
> qdr_connection_work_t 56 64 512 448 25088
> qd_composite_t 112 64 256 192 21504
> qdr_link_t 264 1680 64 16896
> qd_composed_field_t64 64 256 192 12288
> qdr_terminus_t 64 64 256 192 12288
> qdr_delivery_ref_t 24 64 512 448 10752
> qdr_link_ref_t 24 64 512 448 10752
> qd_parsed_field_t 80 128 256 128 10240
> qdr_action_t 160 256 320 64 10240
> qd_link_t 48 64 256 1929216
> qdr_error_t240 320 3207680
> qd_deferred_call_t 32 64 256 1926144
> {noformat}
> grand total increase from qdstat:318
> grand total increase from top: 4947968
> Here is the script I used
> This input window is breaking some lines. >:-(
> #! /bin/bash
> echo "NOTE: router should already be running."
> INSTALL_ROOT=${SHACKLETON_ROOT}/install
> PROTON_INSTALL_DIR=${INSTALL_ROOT}/proton
> DISPATCH_INSTALL_DIR=${INSTALL_ROOT}/dispatch
> QDSTAT=${DISPATCH_INSTALL_DIR}/bin/qdstat
> export
> LD_LIBRARY_PATH=${DISPATCH_INSTALL_DIR}/lib64:${PROTON_INSTALL_DIR}/lib64
> export
> PYTHONPATH=${DISPATCH_INSTALL_DIR}/lib/qpid-dispatch/python:${DISPATCH_INSTALL_DIR}/lib/python2.7/site-packages:${PROTON_INSTALL_DIR}/lib64/proton/bindings/python
> ROUTER_PID=`ps -aef | grep qdrouterd | grep -v grep | awk '{print $2}'`
> count=1
> while [ $count -lt 1001 ]
> do
> echo "==="
> echo "TEST $count"
> echo "==="
> count=$(( $count + 1 ))
> top -b -n 1 -p ${ROUTER_PID}
> ${QDSTAT} -m
> sleep 3
> done
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-344) memory growth after repeated calls from qdstat -m
[
https://issues.apache.org/jira/browse/DISPATCH-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-344.
Resolution: Fixed
Fix Version/s: 0.8.0
> memory growth after repeated calls from qdstat -m
> -
>
> Key: DISPATCH-344
> URL: https://issues.apache.org/jira/browse/DISPATCH-344
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Affects Versions: 0.6.0
>Reporter: michael goulish
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> 0. version of dispatch code is 0.6.0 RC3
> 1. bring up a router
> 2. do not attach any clients, except...
> 3. ...repeatedly invoke qdstat -m on the router
> result:
> After 1000 calls from "qdstat -m", top shows that router memory has grown by
> 4947968 bytes. The output from "qdstat -m" accounts for about 63% of that,
> or 318 bytes.
> Here are the data types that increased, according to qdstat, ordered from
> largest to smallest.
> Um. This table looked really nice when it was in a fixed-width font.
> {noformat}
> type size total total increase
> increasebeforeafter structs bytes
>
> =
> qd_log_entry_t 2104112 1040 928 1952512
> qd_buffer_t536 80 11201040 557440
> qd_field_iterator_t128 192 12801088 139264
> qdr_delivery_t 136 64 512 448 60928
> qdr_connection_t 216 64 320 256 55296
> qdr_field_t40 192 12801088 43520
> qd_connection_t224 64 256 192 43008
> qd_message_content_t 640 1680 64 40960
> qd_message_t 128 192 512 320 40960
> qdpn_connector_t 600 1664 48 28800
> qdr_general_work_t 64 64 512 448 28672
> qdr_connection_work_t 56 64 512 448 25088
> qd_composite_t 112 64 256 192 21504
> qdr_link_t 264 1680 64 16896
> qd_composed_field_t64 64 256 192 12288
> qdr_terminus_t 64 64 256 192 12288
> qdr_delivery_ref_t 24 64 512 448 10752
> qdr_link_ref_t 24 64 512 448 10752
> qd_parsed_field_t 80 128 256 128 10240
> qdr_action_t 160 256 320 64 10240
> qd_link_t 48 64 256 1929216
> qdr_error_t240 320 3207680
> qd_deferred_call_t 32 64 256 1926144
> {noformat}
> grand total increase from qdstat:318
> grand total increase from top: 4947968
> Here is the script I used
> This input window is breaking some lines. >:-(
> #! /bin/bash
> echo "NOTE: router should already be running."
> INSTALL_ROOT=${SHACKLETON_ROOT}/install
> PROTON_INSTALL_DIR=${INSTALL_ROOT}/proton
> DISPATCH_INSTALL_DIR=${INSTALL_ROOT}/dispatch
> QDSTAT=${DISPATCH_INSTALL_DIR}/bin/qdstat
> export
> LD_LIBRARY_PATH=${DISPATCH_INSTALL_DIR}/lib64:${PROTON_INSTALL_DIR}/lib64
> export
> PYTHONPATH=${DISPATCH_INSTALL_DIR}/lib/qpid-dispatch/python:${DISPATCH_INSTALL_DIR}/lib/python2.7/site-packages:${PROTON_INSTALL_DIR}/lib64/proton/bindings/python
> ROUTER_PID=`ps -aef | grep qdrouterd | grep -v grep | awk '{print $2}'`
> count=1
> while [ $count -lt 1001 ]
> do
> echo "==="
> echo "TEST $count"
> echo "==="
> count=$(( $count + 1 ))
> top -b -n 1 -p ${ROUTER_PID}
> ${QDSTAT} -m
> sleep 3
> done
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-355) query fails with what seems to be the error of a previous command
[
https://issues.apache.org/jira/browse/DISPATCH-355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-355.
Resolution: Fixed
Fix Version/s: 0.8.0
> query fails with what seems to be the error of a previous command
> -
>
> Key: DISPATCH-355
> URL: https://issues.apache.org/jira/browse/DISPATCH-355
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Management Agent
>Affects Versions: 0.6.0
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> {noformat}
> Fri May 27 16:21:22 2016 AGENT (error) Error dispatching
> Message(address=None, properties={'operation': 'CREATE', 'type': 'connector',
> 'name': '0.0.0.0:5'}, body={'type': 'connector', 'role': 'inter-router',
> 'addr': '0.0.0.0', 'name': '0.0.0.0:5', 'port': '5'},
> reply_to='amqp:/_topo/0/Router.C/temp.tZCTJxxyEVLIxe2', correlation_id='6'):
> org.apache.qpid.dispatch.connector: Duplicate value 'connector/0.0.0.0:5'
> for unique attribute 'identity'
> Traceback (most recent call last):
> File
> "/home/gordon/projects/dispatch/installs/master/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 770, in receive
> status, body = self.handle(request)
> File
> "/home/gordon/projects/dispatch/installs/master/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 793, in handle
> return self.create(request)
> File
> "/home/gordon/projects/dispatch/installs/master/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 834, in create
> return (CREATED, self._create(attributes).attributes)
> File
> "/home/gordon/projects/dispatch/installs/master/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 809, in _create
> self.entities.add_implementation(cimplementation, entity)
> File
> "/home/gordon/projects/dispatch/installs/master/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 518, in add_implementation
> self._add_implementation(implementation, adapter=adapter)
> File
> "/home/gordon/projects/dispatch/installs/master/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 515, in _add_implementation
> self.add(adapter)
> File
> "/home/gordon/projects/dispatch/installs/master/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 504, in add
> self.schema.validate_full(chain(iter([entity]), iter(self.entities)))
> File
> "/home/gordon/projects/dispatch/installs/master/lib/qpid-dispatch/python/qpid_dispatch_internal/management/qdrouter.py",
> line 59, in validate_full
> super(QdSchema, self).validate_all(entities
> Fri May 27 16:21:22 2016 AGENT (error) Error dispatching
> Message(address=None, properties={'operation': 'QUERY', 'entityType':
> 'connector'}, body={'attributeNames': ['identity', 'name', 'addr', 'port',
> 'role']}, reply_to='amqp:/_topo/0/Router.C/temp.tZCTJxxyEVLIxe2',
> correlation_id='7'): org.apache.qpid.dispatch.connection: Duplicate value
> 'connection/0.0.0.0:5' for unique attribute 'identity'
> Traceback (most recent call last):
> File
> "/home/gordon/projects/dispatch/installs/master/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 768, in receive
> self.entities.refresh_from_c()
> File
> "/home/gordon/projects/dispatch/installs/master/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 569, in refresh_from_c
> self._add_implementation(CImplementation(self.qd, entity_type, pointer))
> File
> "/home/gordon/projects/dispatch/installs/master/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 515, in _add_implementation
> self.add(adapter)
> File
> "/home/gordon/projects/dispatch/installs/master/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 504, in add
> self.schema.validate_full(chain(iter([entity]), iter(self.entities)))
> File
> "/home/gordon/projects/dispatch/installs/master/lib/qpid-dispatch/python/qpid_dispatch_internal/management/qdrouter.py",
> line 59, in validate_full
> super(QdSchema, self).validate_all(entities, **kwargs)
> File
> "/home/gordon/projects/dispatch/installs/master/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 616, in validate_all
> check_singleton=check_singleton)
> File
> "/home/gordon/projects/dispatch/installs/master/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 593, in validate_entity
> check_singleton=check_singleton)
> File
> "/home/gordon/projects/dispatch/installs/master/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
[jira] [Assigned] (DISPATCH-351) Crash after a sequence of qdmanage operations creating and destroying listener and connector
[
https://issues.apache.org/jira/browse/DISPATCH-351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy reassigned DISPATCH-351:
--
Assignee: Ganesh Murthy
> Crash after a sequence of qdmanage operations creating and destroying
> listener and connector
>
>
> Key: DISPATCH-351
> URL: https://issues.apache.org/jira/browse/DISPATCH-351
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Router Node
>Affects Versions: 0.6.0
> Environment: RHEL 6.8x
> Git tip at commit 87d0a406c6 "DISPATCH-339 - [From Ganesh Murthy] Properly
> handle default values for host/addr."
>Reporter: Jiri Danek
>Assignee: Ganesh Murthy
> Attachments: commands.bash, core.6635.backtrace, core.6635.bz2
>
>
> Start up {{qdrouterd}} with the default config and run the (uncommented)
> commands in {{commands.bash}}. Router crashes.
> {noformat}
> $ local/sbin/qdrouterd -c local/etc/qpid-dispatch/qdrouterd.conf
> Thu May 26 13:16:49 2016 SERVER (info) Container Name: Router.A
> Thu May 26 13:16:49 2016 ROUTER (info) Router started in Standalone mode
> Thu May 26 13:16:49 2016 ROUTER_CORE (info) Router Core thread running.
> 0/Router.A
> Thu May 26 13:16:49 2016 ROUTER_CORE (info) In-process subscription
> M/$management
> Thu May 26 13:16:49 2016 ROUTER_CORE (info) In-process subscription
> L/$management
> Thu May 26 13:16:49 2016 AGENT (info) Activating management agent on
> $_management_internal
> Thu May 26 13:16:49 2016 ROUTER_CORE (info) In-process subscription
> L/$_management_internal
> Thu May 26 13:16:49 2016 DISPLAYNAME (info) Activating DisplayNameService on
> $displayname
> Thu May 26 13:16:49 2016 ROUTER_CORE (info) In-process subscription
> L/$displayname
> Thu May 26 13:16:49 2016 CONN_MGR (info) Configured Listener: 0.0.0.0:amqp
> proto=any role=normal
> Thu May 26 13:16:49 2016 POLICY (info) Policy configured maximumConnections:
> 0, policyFolder: '', access rules enabled: 'false'
> Thu May 26 13:16:49 2016 POLICY (info) Policy fallback defaultApplication is
> disabled
> Thu May 26 13:16:49 2016 SERVER (info) Operational, 4 Threads Running
> Thu May 26 13:16:58 2016 CONN_MGR (info) Configured Connector: 0.0.0.0:20021
> proto=any role=normal
> Thu May 26 13:16:59 2016 CONN_MGR (info) Configured Listener: 0.0.0.0:20021
> proto=any role=normal
> Thu May 26 13:16:59 2016 AGENT (error) Error dispatching
> Message(address=None, properties={'operation': 'CREATE', 'type':
> 'org.apache.qpid.dispatch.listener', 'name': 'eaconn1'}, body={'host':
> '0.0.0.0', 'type': 'org.apache.qpid.dispatch.listener', 'port': '20021',
> 'name': 'eaconn1'}, reply_to='amqp:/_topo/0/Router.A/temp.ozFLn7K3UkHpXm+',
> correlation_id=1L): org.apache.qpid.dispatch.connector: Duplicate value
> 'eaconn1' for unique attribute 'name'
> Traceback (most recent call last):
> File
> "/home/vagrant/local/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 786, in receive
> status, body = self.handle(request)
> File
> "/home/vagrant/local/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 809, in handle
> return self.create(request)
> File
> "/home/vagrant/local/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 850, in create
> return (CREATED, self._create(attributes).attributes)
> File
> "/home/vagrant/local/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 825, in _create
> self.entities.add_implementation(cimplementation, entity)
> File
> "/home/vagrant/local/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 534, in add_implementation
> self._add_implementation(implementation, adapter=adapter)
> File
> "/home/vagrant/local/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 531, in _add_implementation
> self.add(adapter)
> File
> "/home/vagrant/local/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 520, in add
> self.schema.validate_full(chain(iter([entity]), iter(self.entities)))
> File
> "/home/vagrant/local/lib/qpid-dispatch/python/qpid_dispatch_internal/management/qdrouter.py",
> line 59, in validate_full
> super(QdSchema, self).validate_all(entities, **kwargs)
> File
> "/home/vagrant/local/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 597, in validate_all
> check_singleton=check_singleton)
> File "/home/vagrant/local/lib/qpid-dispatch/pytho
> Thu May 26 13:16:59 2016 CONN_MGR (info) Configured Listener: 0.0.0.0:20021
> proto=any role=normal
> Thu May 26 13:16:59 2016 DRIVER (error) bind: Address already in use
> Segmentation fault (core dumped)
> {noformat}
--
This messa
[jira] [Updated] (DISPATCH-610) crash in qdr_link_cleanup_CT
[ https://issues.apache.org/jira/browse/DISPATCH-610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy updated DISPATCH-610: --- Attachment: test-app-memory-leak.tar > crash in qdr_link_cleanup_CT > > > Key: DISPATCH-610 > URL: https://issues.apache.org/jira/browse/DISPATCH-610 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.7.0 > Environment: Centos 7, JDK 1.8 >Reporter: Rohan Mars > Fix For: 0.8.0 > > Attachments: test-app-memory-leak.tar > > > A client sends a message to a server, which then the responds back to the > client via its replyTo location. When settlement is delayed to after the > server response message it shows up a crash pretty quickly in the test > program supplied. > Running on Centos VM with 4 CPU's 12Gb Ram. > (gdb) where > #0 0x7f6b6a5815f7 in raise () from /lib64/libc.so.6 > #1 0x7f6b6a582ce8 in abort () from /lib64/libc.so.6 > #2 0x7f6b6a57a566 in __assert_fail_base () from /lib64/libc.so.6 > #3 0x7f6b6a57a612 in __assert_fail () from /lib64/libc.so.6 > #4 0x7f6b6b5b00f7 in qdr_delivery_decref_CT (core=0xd2c550, > dlv=0x7f6b48441be0) > at /home/centos/qpid-dispatch/src/router_core/transfer.c:435 > #5 0x7f6b6b5a1e41 in qdr_link_cleanup_CT (core=0xd2c550, > conn=0x7f6b5046bca0, link=0x7f6b500297e0) > at /home/centos/qpid-dispatch/src/router_core/connections.c:648 > #6 0x7f6b6b5a32fd in qdr_connection_closed_CT (core=0xd2c550, > action=0x7f6b545d7760, discard=false) > at /home/centos/qpid-dispatch/src/router_core/connections.c:1128 > #7 0x7f6b6b5aaebb in router_core_thread (arg=0xd2c550) > at /home/centos/qpid-dispatch/src/router_core/router_core_thread.c:83 > #8 0x7f6b6b0e7dc5 in start_thread () from /lib64/libpthread.so.0 > #9 0x7f6b6a642ced in clone () from /lib64/libc.so.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-610) crash in qdr_link_cleanup_CT
[ https://issues.apache.org/jira/browse/DISPATCH-610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy reassigned DISPATCH-610: -- Assignee: Ganesh Murthy > crash in qdr_link_cleanup_CT > > > Key: DISPATCH-610 > URL: https://issues.apache.org/jira/browse/DISPATCH-610 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.7.0 > Environment: Centos 7, JDK 1.8 >Reporter: Rohan Mars >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: test-app-memory-leak.tar > > > A client sends a message to a server, which then the responds back to the > client via its replyTo location. When settlement is delayed to after the > server response message it shows up a crash pretty quickly in the test > program supplied. > Running on Centos VM with 4 CPU's 12Gb Ram. > (gdb) where > #0 0x7f6b6a5815f7 in raise () from /lib64/libc.so.6 > #1 0x7f6b6a582ce8 in abort () from /lib64/libc.so.6 > #2 0x7f6b6a57a566 in __assert_fail_base () from /lib64/libc.so.6 > #3 0x7f6b6a57a612 in __assert_fail () from /lib64/libc.so.6 > #4 0x7f6b6b5b00f7 in qdr_delivery_decref_CT (core=0xd2c550, > dlv=0x7f6b48441be0) > at /home/centos/qpid-dispatch/src/router_core/transfer.c:435 > #5 0x7f6b6b5a1e41 in qdr_link_cleanup_CT (core=0xd2c550, > conn=0x7f6b5046bca0, link=0x7f6b500297e0) > at /home/centos/qpid-dispatch/src/router_core/connections.c:648 > #6 0x7f6b6b5a32fd in qdr_connection_closed_CT (core=0xd2c550, > action=0x7f6b545d7760, discard=false) > at /home/centos/qpid-dispatch/src/router_core/connections.c:1128 > #7 0x7f6b6b5aaebb in router_core_thread (arg=0xd2c550) > at /home/centos/qpid-dispatch/src/router_core/router_core_thread.c:83 > #8 0x7f6b6b0e7dc5 in start_thread () from /lib64/libpthread.so.0 > #9 0x7f6b6a642ced in clone () from /lib64/libc.so.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-610) crash in qdr_link_cleanup_CT
[ https://issues.apache.org/jira/browse/DISPATCH-610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-610. Resolution: Fixed > crash in qdr_link_cleanup_CT > > > Key: DISPATCH-610 > URL: https://issues.apache.org/jira/browse/DISPATCH-610 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.7.0 > Environment: Centos 7, JDK 1.8 >Reporter: Rohan Mars >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: test-app-memory-leak.tar > > > A client sends a message to a server, which then the responds back to the > client via its replyTo location. When settlement is delayed to after the > server response message it shows up a crash pretty quickly in the test > program supplied. > Running on Centos VM with 4 CPU's 12Gb Ram. > (gdb) where > #0 0x7f6b6a5815f7 in raise () from /lib64/libc.so.6 > #1 0x7f6b6a582ce8 in abort () from /lib64/libc.so.6 > #2 0x7f6b6a57a566 in __assert_fail_base () from /lib64/libc.so.6 > #3 0x7f6b6a57a612 in __assert_fail () from /lib64/libc.so.6 > #4 0x7f6b6b5b00f7 in qdr_delivery_decref_CT (core=0xd2c550, > dlv=0x7f6b48441be0) > at /home/centos/qpid-dispatch/src/router_core/transfer.c:435 > #5 0x7f6b6b5a1e41 in qdr_link_cleanup_CT (core=0xd2c550, > conn=0x7f6b5046bca0, link=0x7f6b500297e0) > at /home/centos/qpid-dispatch/src/router_core/connections.c:648 > #6 0x7f6b6b5a32fd in qdr_connection_closed_CT (core=0xd2c550, > action=0x7f6b545d7760, discard=false) > at /home/centos/qpid-dispatch/src/router_core/connections.c:1128 > #7 0x7f6b6b5aaebb in router_core_thread (arg=0xd2c550) > at /home/centos/qpid-dispatch/src/router_core/router_core_thread.c:83 > #8 0x7f6b6b0e7dc5 in start_thread () from /lib64/libpthread.so.0 > #9 0x7f6b6a642ced in clone () from /lib64/libc.so.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (DISPATCH-216) system_tests_protocol_family fails on systems with no IPv6
[
https://issues.apache.org/jira/browse/DISPATCH-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy reopened DISPATCH-216:
> system_tests_protocol_family fails on systems with no IPv6
> --
>
> Key: DISPATCH-216
> URL: https://issues.apache.org/jira/browse/DISPATCH-216
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Tests
>Affects Versions: 0.5
>Reporter: Chuck Rolke
>Assignee: Ganesh Murthy
> Fix For: 0.6.0
>
>
> The test assumes IPv6 and fails without it.
> To disable IPv6 temporarily on Fedora:
> {noformat}
> sudo sh -c 'echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6'
> {noformat}
> To test for IPv6 in Python
> {noformat}
> import socket
> if socket.has_ipv6:
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-216) system_tests_protocol_family fails on systems with no IPv6
[
https://issues.apache.org/jira/browse/DISPATCH-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-216.
Resolution: Fixed
Fix Version/s: (was: 0.6.0)
0.8.0
Added is_ipv6_enabled to system_test.py to selectively skip certain tests if
IPv6 is not enabled.
> system_tests_protocol_family fails on systems with no IPv6
> --
>
> Key: DISPATCH-216
> URL: https://issues.apache.org/jira/browse/DISPATCH-216
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Tests
>Affects Versions: 0.5
>Reporter: Chuck Rolke
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> The test assumes IPv6 and fails without it.
> To disable IPv6 temporarily on Fedora:
> {noformat}
> sudo sh -c 'echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6'
> {noformat}
> To test for IPv6 in Python
> {noformat}
> import socket
> if socket.has_ipv6:
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-608) Links not cleaned up when a close is sent without being preceeded by a detach and end
[ https://issues.apache.org/jira/browse/DISPATCH-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-608. Resolution: Fixed > Links not cleaned up when a close is sent without being preceeded by a detach > and end > - > > Key: DISPATCH-608 > URL: https://issues.apache.org/jira/browse/DISPATCH-608 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 0.7.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > > There are memory leaks of qd_dispatch_t objects when close is sent without > being proceeded by a detach and end frames -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-633) Creating connectors and addresses returns success codes of two different types.
Ganesh Murthy created DISPATCH-633:
--
Summary: Creating connectors and addresses returns success codes
of two different types.
Key: DISPATCH-633
URL: https://issues.apache.org/jira/browse/DISPATCH-633
Project: Qpid Dispatch
Issue Type: Bug
Components: Container
Affects Versions: 0.7.0
Reporter: Ganesh Murthy
Assignee: Ganesh Murthy
Fix For: 0.8.0
When trying to create a connector in dispatch using Qpid JMS, the returned
status code 200 is of type
Object statusCodeValue = replyMessage.getObjectProperty("statusCode");
statusCodeValue is instanceof java.lang.Long
When trying to create an address, the returned code is of type
org.apache.qpid.proton.amqp.UnsignedInteger
The dispatch router must return consistent int value status codes in both cases
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-633) Creating connectors and addresses returns success codes of two different types.
[
https://issues.apache.org/jira/browse/DISPATCH-633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy updated DISPATCH-633:
---
Description:
When trying to create a connector in dispatch using Qpid JMS, the returned
status code 200 is of type
Object statusCodeValue = replyMessage.getObjectProperty("statusCode");
statusCodeValue is instanceof java.lang.Long
When trying to create an address, the returned code is of type
org.apache.qpid.proton.amqp.UnsignedInteger
The dispatch router must consistently return AMQP int status codes in both
cases which will translate to java.lang.Integer on the java side.
was:
When trying to create a connector in dispatch using Qpid JMS, the returned
status code 200 is of type
Object statusCodeValue = replyMessage.getObjectProperty("statusCode");
statusCodeValue is instanceof java.lang.Long
When trying to create an address, the returned code is of type
org.apache.qpid.proton.amqp.UnsignedInteger
The dispatch router must return consistent int value status codes in both cases
> Creating connectors and addresses returns success codes of two different
> types.
> ---
>
> Key: DISPATCH-633
> URL: https://issues.apache.org/jira/browse/DISPATCH-633
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 0.7.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> When trying to create a connector in dispatch using Qpid JMS, the returned
> status code 200 is of type
> Object statusCodeValue = replyMessage.getObjectProperty("statusCode");
> statusCodeValue is instanceof java.lang.Long
> When trying to create an address, the returned code is of type
> org.apache.qpid.proton.amqp.UnsignedInteger
> The dispatch router must consistently return AMQP int status codes in both
> cases which will translate to java.lang.Integer on the java side.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-635) The Ubuntu CI tests that involve two routers are failing
Ganesh Murthy created DISPATCH-635: -- Summary: The Ubuntu CI tests that involve two routers are failing Key: DISPATCH-635 URL: https://issues.apache.org/jira/browse/DISPATCH-635 Project: Qpid Dispatch Issue Type: Bug Components: Container, Tests Affects Versions: 0.8.0 Reporter: Ganesh Murthy Assignee: Ganesh Murthy Fix For: 0.8.0 Any dispatch system test that involves two routers communicating with each other are failing. This is happening only when CI is running on Ubuntu The reason for the failure is that one router is unable to find a pertinent connector connection information when querying its connections. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-635) The Ubuntu CI tests that involve two routers are failing
[ https://issues.apache.org/jira/browse/DISPATCH-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-635. Resolution: Fixed > The Ubuntu CI tests that involve two routers are failing > > > Key: DISPATCH-635 > URL: https://issues.apache.org/jira/browse/DISPATCH-635 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container, Tests >Affects Versions: 0.8.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > > Any dispatch system test that involves two routers communicating with each > other are failing. This is happening only when CI is running on Ubuntu > The reason for the failure is that one router is unable to find a pertinent > connector connection information when querying its connections. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-633) Creating connectors and addresses returns success codes of two different types.
[
https://issues.apache.org/jira/browse/DISPATCH-633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-633.
Resolution: Fixed
> Creating connectors and addresses returns success codes of two different
> types.
> ---
>
> Key: DISPATCH-633
> URL: https://issues.apache.org/jira/browse/DISPATCH-633
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 0.7.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> When trying to create a connector in dispatch using Qpid JMS, the returned
> status code 200 is of type
> Object statusCodeValue = replyMessage.getObjectProperty("statusCode");
> statusCodeValue is instanceof java.lang.Long
> When trying to create an address, the returned code is of type
> org.apache.qpid.proton.amqp.UnsignedInteger
> The dispatch router must consistently return AMQP int status codes in both
> cases which will translate to java.lang.Integer on the java side.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-636) README claims qpid-proton-c-devel >= 0.13 is required; however, cmake complains with 0.14
[
https://issues.apache.org/jira/browse/DISPATCH-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy reassigned DISPATCH-636:
--
Assignee: Ganesh Murthy
> README claims qpid-proton-c-devel >= 0.13 is required; however, cmake
> complains with 0.14
> -
>
> Key: DISPATCH-636
> URL: https://issues.apache.org/jira/browse/DISPATCH-636
> Project: Qpid Dispatch
> Issue Type: Bug
>Reporter: Eric Sammons
>Assignee: Ganesh Murthy
>
> Attempting to follow the readme to clone, build, and install dispatch-router
> results in a cmake error.
> {quote}
> $ cat /etc/redhat-release
> CentOS Linux release 7.3.1611 (Core)
> $ cmake ..
> CMake Error at CMakeLists.txt:103 (find_package):
> Could not find a configuration file for package "Proton" that is compatible
> with requested version "0.15".
> The following configuration files were considered but not accepted:
> /usr/lib64/cmake/Proton/ProtonConfig.cmake, version: 0.14.0
> /lib64/cmake/Proton/ProtonConfig.cmake, version: 0.14.0
> -- Configuring incomplete, errors occurred!
> See also "/home/dispatch/qpid-dispatch/my_build/CMakeFiles/CMakeOutput.log".
> $ rpm -q qpid-proton-c-devel
> qpid-proton-c-devel-0.14.0-2.el7.x86_64
> {quote}
> This seems to conflict with the documented README and will pose problems on
> platforms where qpid-proton-c-devel >= 0.15 is not yet available.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-636) README claims qpid-proton-c-devel >= 0.13 is required; however, cmake complains with 0.14
[
https://issues.apache.org/jira/browse/DISPATCH-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15872018#comment-15872018
]
Ganesh Murthy commented on DISPATCH-636:
The CMakeLists.txt states that to build dispatch, Proton 0.15 is required as
seen below -
{noformat}
find_package(Proton 0.15 REQUIRED)
{noformat}
I fixed the README file to reflect the above -
{noformat}
- qpid-proton-c-devel (0.15 or later)
- python-qpid-proton (0.15 or later)
{noformat}
> README claims qpid-proton-c-devel >= 0.13 is required; however, cmake
> complains with 0.14
> -
>
> Key: DISPATCH-636
> URL: https://issues.apache.org/jira/browse/DISPATCH-636
> Project: Qpid Dispatch
> Issue Type: Bug
>Reporter: Eric Sammons
>
> Attempting to follow the readme to clone, build, and install dispatch-router
> results in a cmake error.
> {quote}
> $ cat /etc/redhat-release
> CentOS Linux release 7.3.1611 (Core)
> $ cmake ..
> CMake Error at CMakeLists.txt:103 (find_package):
> Could not find a configuration file for package "Proton" that is compatible
> with requested version "0.15".
> The following configuration files were considered but not accepted:
> /usr/lib64/cmake/Proton/ProtonConfig.cmake, version: 0.14.0
> /lib64/cmake/Proton/ProtonConfig.cmake, version: 0.14.0
> -- Configuring incomplete, errors occurred!
> See also "/home/dispatch/qpid-dispatch/my_build/CMakeFiles/CMakeOutput.log".
> $ rpm -q qpid-proton-c-devel
> qpid-proton-c-devel-0.14.0-2.el7.x86_64
> {quote}
> This seems to conflict with the documented README and will pose problems on
> platforms where qpid-proton-c-devel >= 0.15 is not yet available.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-636) README claims qpid-proton-c-devel >= 0.13 is required; however, cmake complains with 0.14
[
https://issues.apache.org/jira/browse/DISPATCH-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy updated DISPATCH-636:
---
Fix Version/s: 0.8.0
> README claims qpid-proton-c-devel >= 0.13 is required; however, cmake
> complains with 0.14
> -
>
> Key: DISPATCH-636
> URL: https://issues.apache.org/jira/browse/DISPATCH-636
> Project: Qpid Dispatch
> Issue Type: Bug
>Reporter: Eric Sammons
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> Attempting to follow the readme to clone, build, and install dispatch-router
> results in a cmake error.
> {quote}
> $ cat /etc/redhat-release
> CentOS Linux release 7.3.1611 (Core)
> $ cmake ..
> CMake Error at CMakeLists.txt:103 (find_package):
> Could not find a configuration file for package "Proton" that is compatible
> with requested version "0.15".
> The following configuration files were considered but not accepted:
> /usr/lib64/cmake/Proton/ProtonConfig.cmake, version: 0.14.0
> /lib64/cmake/Proton/ProtonConfig.cmake, version: 0.14.0
> -- Configuring incomplete, errors occurred!
> See also "/home/dispatch/qpid-dispatch/my_build/CMakeFiles/CMakeOutput.log".
> $ rpm -q qpid-proton-c-devel
> qpid-proton-c-devel-0.14.0-2.el7.x86_64
> {quote}
> This seems to conflict with the documented README and will pose problems on
> platforms where qpid-proton-c-devel >= 0.15 is not yet available.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-637) system_tests_sasl_plain and system_tests_deprecated fail when cyrus-sasl-plain is not installed
[ https://issues.apache.org/jira/browse/DISPATCH-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy reassigned DISPATCH-637: -- Assignee: Ganesh Murthy > system_tests_sasl_plain and system_tests_deprecated fail when > cyrus-sasl-plain is not installed > --- > > Key: DISPATCH-637 > URL: https://issues.apache.org/jira/browse/DISPATCH-637 > Project: Qpid Dispatch > Issue Type: Bug >Reporter: Eric Sammons >Assignee: Ganesh Murthy > > The current readme for dispatch and qpid-proton do not mention a dependency > on cyrus-sasl-plain; however, with out the cyrus-sasl-plain package the > system_tests_sasl_plain and system_tests_deprecated tests will fail. > README should mention this dependency. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-637) system_tests_sasl_plain and system_tests_deprecated fail when cyrus-sasl-plain is not installed
[ https://issues.apache.org/jira/browse/DISPATCH-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-637. Resolution: Fixed Fix Version/s: 0.8.0 > system_tests_sasl_plain and system_tests_deprecated fail when > cyrus-sasl-plain is not installed > --- > > Key: DISPATCH-637 > URL: https://issues.apache.org/jira/browse/DISPATCH-637 > Project: Qpid Dispatch > Issue Type: Bug >Reporter: Eric Sammons >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > > The current readme for dispatch and qpid-proton do not mention a dependency > on cyrus-sasl-plain; however, with out the cyrus-sasl-plain package the > system_tests_sasl_plain and system_tests_deprecated tests will fail. > README should mention this dependency. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-640) containerId field conflics with the connector name
[
https://issues.apache.org/jira/browse/DISPATCH-640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy reassigned DISPATCH-640:
--
Assignee: Ganesh Murthy
> containerId field conflics with the connector name
> --
>
> Key: DISPATCH-640
> URL: https://issues.apache.org/jira/browse/DISPATCH-640
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Router Node
>Affects Versions: 0.7.0
> Environment: rhel6x,i rhel7x
>Reporter: Matej Lesko
>Assignee: Ganesh Murthy
>
> Using this configuration with the JAMQ7 (with container_id "dtest") a problem
> appears when a name is specified for the connector.
> In this case linkRoutes are not established to the broker.
> Commenting out a _name_ attribute in _connector_ entity linkRouting works as
> expected.
> {noformat}
> router {
> mode: standalone
> id: Router.A
> }
> listener {
> host: 0.0.0.0
> port: amqp
> authenticatePeer: no
> saslMechanisms: ANONYMOUS
> }
> connector {
> name: broker
> host: MY-HOST
> role: route-container
> port: amqp
> }
> address {
> prefix: jms.queue
> waypoint: yes
> distribution: balanced
> }
> linkRoute {
> name: myqueueIn
> dir: in
> prefix: jms.queue.myqueue
> connection: broker
> containerId: dtest
> }
> linkRoute {
> name: myqueueOut
> dir: out
> prefix: jms.queue.myqueue
> connection: broker
> containerId: dtest
> }
> log {
> module: MESSAGE
> enable: debug
> timestamp: yes
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-597) Log enhancements
[
https://issues.apache.org/jira/browse/DISPATCH-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy reassigned DISPATCH-597:
--
Assignee: Ganesh Murthy (was: Ted Ross)
> Log enhancements
>
>
> Key: DISPATCH-597
> URL: https://issues.apache.org/jira/browse/DISPATCH-597
> Project: Qpid Dispatch
> Issue Type: Improvement
> Components: Container
>Affects Versions: 0.7.0
>Reporter: Shibi Sudhakaran
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> Print information at INFO level into log that could be used for diagnosing
> router health.
> 1. Millisecond precision timestamp
> 2. Avoid logging message body.
> 3. Capability to configure application properties to be logged (messageId,
> correlationId, creationTime , application custom properties) etc
> Sample Entries (log level : INFO)
>
> => Mon 2016-09-26 11:31:44.050750 -0700 ROUTER_HELLO (info) SENT:
> HELLO(id=Router.A.0 area=0 inst=1474860067 seen=['Router.A.1', 'Router.A.2',
> 'Router.A.3', 'Router.A.4’])
> => Mon 2016-09-26 14:15:58.088754 -0700 MESSAGE (info) Sending Message{
> message-id='' correlation-id=''
> creation-time='2016-09-26 14:15:58.084 -0700' application properties='[Key:
> request-creation-time => Value: 1474924558078]' } on link
> => Mon 2016-09-26 14:15:20.547178 -0700 MESSAGE (info) Received Message{
> message-id='' correlation-id=''
> creation-time='2016-09-26 14:15:20.542 -0700' application properties='[Key:
> request-creation-time => Value: 1474924520539]'} on link
> => Mon 2016-09-26 09:40:00.149567 -0700 ROUTER_LS (info) Computed costs:
> {'Router.A.0': 1, 'Router.A.2': 1, 'Router.A.3': 1, 'Router.A.4': 1}
> => Mon 2016-09-26 14:23:07.376756 -0700 ROUTER (info) Router started in
> Interior mode, area=0 id=Router.A.1
> => Mon 2016-09-26 14:23:07.408136 -0700 CONN_MGR (info) Configured Listener:
> 0.0.0.0:5671 proto=any role=normal
> => Mon 2016-09-26 14:14:57.520917 -0700 SERVER (info) Accepting incoming
> connection from to
> => Mon 2016-09-26 14:23:07.376471 -0700 SERVER (info) Container Name:
> Router.A.1
> => Mon 2016-09-26 14:23:07.439250 -0700 SERVER (info) Connecting to
>
> => Mon 2016-09-26 14:23:07.447536 -0700 SERVER (info) [1]:Client SSL socket
> created.
> => Mon 2016-09-26 14:15:12.310692 -0700 SERVER (info) [8783]:SSL socket freed
> => Mon 2016-09-26 14:23:03.059884 -0700 SERVER (info) Shut Down
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-643) Duplicate log messages show up on normal AMQP close
Ganesh Murthy created DISPATCH-643:
--
Summary: Duplicate log messages show up on normal AMQP close
Key: DISPATCH-643
URL: https://issues.apache.org/jira/browse/DISPATCH-643
Project: Qpid Dispatch
Issue Type: Bug
Components: Container
Affects Versions: 0.7.0
Reporter: Ganesh Murthy
Assignee: Ganesh Murthy
Fix For: 0.8.0
When running the Qpid JMS Hello World example, duplicate link abort log
messages show up -
{noformat}
Mon Feb 27 16:19:44 2017 CONTAINER (notice) Aborting link
'qpid-jms:sender:ID:f5bcbc8f-e085-4b10-9e1f-fac72c23c64b:1:1:1:queue' due to
parent connection end
Mon Feb 27 16:19:44 2017 CONTAINER (notice) Aborting link
'qpid-jms:receiver:ID:f5bcbc8f-e085-4b10-9e1f-fac72c23c64b:1:1:1:queue' due to
parent connection end
Mon Feb 27 16:19:44 2017 CONTAINER (notice) Aborting link
'qpid-jms:sender:ID:f5bcbc8f-e085-4b10-9e1f-fac72c23c64b:1:1:1:queue' due to
parent connection end
Mon Feb 27 16:19:44 2017 CONTAINER (notice) Aborting link
'qpid-jms:receiver:ID:f5bcbc8f-e085-4b10-9e1f-fac72c23c64b:1:1:1:queue' due to
parent connection end
{noformat}
Notice above that the sender:ID log is showing up twice.
These log messages should not show up on normal AMQP close.
These log messages should show up only on abrupt socket close without AMQP
close.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-643) Duplicate log messages show up on normal AMQP close
[
https://issues.apache.org/jira/browse/DISPATCH-643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-643.
Resolution: Fixed
> Duplicate log messages show up on normal AMQP close
> ---
>
> Key: DISPATCH-643
> URL: https://issues.apache.org/jira/browse/DISPATCH-643
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 0.7.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> When running the Qpid JMS Hello World example, duplicate link abort log
> messages show up -
> {noformat}
> Mon Feb 27 16:19:44 2017 CONTAINER (notice) Aborting link
> 'qpid-jms:sender:ID:f5bcbc8f-e085-4b10-9e1f-fac72c23c64b:1:1:1:queue' due to
> parent connection end
> Mon Feb 27 16:19:44 2017 CONTAINER (notice) Aborting link
> 'qpid-jms:receiver:ID:f5bcbc8f-e085-4b10-9e1f-fac72c23c64b:1:1:1:queue' due
> to parent connection end
> Mon Feb 27 16:19:44 2017 CONTAINER (notice) Aborting link
> 'qpid-jms:sender:ID:f5bcbc8f-e085-4b10-9e1f-fac72c23c64b:1:1:1:queue' due to
> parent connection end
> Mon Feb 27 16:19:44 2017 CONTAINER (notice) Aborting link
> 'qpid-jms:receiver:ID:f5bcbc8f-e085-4b10-9e1f-fac72c23c64b:1:1:1:queue' due
> to parent connection end
> {noformat}
> Notice above that the sender:ID log is showing up twice.
> These log messages should not show up on normal AMQP close.
> These log messages should show up only on abrupt socket close without AMQP
> close.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-623) Unreachable code (qd_field_iterator_free after a return statement) detected on Solaris
[ https://issues.apache.org/jira/browse/DISPATCH-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-623. Resolution: Fixed Assignee: Ganesh Murthy Fix Version/s: 0.8.0 Patch from Adel Boutros applied to code base. > Unreachable code (qd_field_iterator_free after a return statement) detected > on Solaris > -- > > Key: DISPATCH-623 > URL: https://issues.apache.org/jira/browse/DISPATCH-623 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Adel Boutros >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: > 0013-Unreachable-code-qd_field_iterator_free-after-a-retu.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-641) Make containerId attribute work with clients
[
https://issues.apache.org/jira/browse/DISPATCH-641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15890393#comment-15890393
]
Ganesh Murthy commented on DISPATCH-641:
When you declare a linkRoute like this -
{noformat}
linkRoute {
prefix: myqueue
containerId: xxx
dir: in
}
{noformat}
The containerId specified in a link route is the target containerId to which a
client attach will be forwarded. When the client attaches with a target
address, this address is matched to see if the prefix matches the prefix
specified in the link route. If it matches, the router tries to find the
container to forward the attach to. If it successfully finds a container with
containerId xxx (say this is a broker), it forwards that attach to the broker.
If no container with the containerId exists, the attach cannot be forwarded
anywhere and hence you will see a "No route to destination" error
In your Scenario B, the client containerId (which is xxx in your case) is
immaterial and ignored. The containerId specified in the link route is always
the target container to which the attach frame will be forwarded to. So, what
you are asking in Scenario B is not possible.
Please let me know if you have questions.
> Make containerId attribute work with clients
>
>
> Key: DISPATCH-641
> URL: https://issues.apache.org/jira/browse/DISPATCH-641
> Project: Qpid Dispatch
> Issue Type: Improvement
> Components: Router Node
>Affects Versions: 0.7.0
>Reporter: Matej Lesko
>
> During verification of issue
> https://issues.apache.org/jira/browse/DISPATCH-628
> I found out that when I set this _containerId_ in the clients, router can see
> it but it can not route it.
> E.g. I have sender with the _containerId_ "xxx" and autoLink entity with the
> _containerId_ "xxx" ->
> this autoLink does not activate in this scenario.
> Simply said when I have sender/receiver with the _containerId_ set and
> matching the _containerId_ attribute in the configuration file, it does
> *not* accept the connection. e.g. _linkRoute_ usage ends with the "Link
> error: No route to the destination node".
> Possible configuration to use(same applies for _autoLink_ entities)
> {noformat}
> router {
> mode: standalone
> id: Router.A
> }
> listener {
> host: 0.0.0.0
> port: amqp
> authenticatePeer: no
> saslMechanisms: ANONYMOUS
> }
> connector {
> name: broker
> host: MY-HOST
> role: route-container
> port: amqp
> }
> address {
> prefix: jms.queue
> waypoint: yes
> distribution: balanced
> }
> linkRoute {
> name: myqueueIn
> dir: in
> prefix: jms.queue.myqueue
> connection: broker
> containerId: dtest
> }
> linkRoute {
> name: myqueueOut
> dir: out
> prefix: jms.queue.myqueue
> connection: broker
> containerId: dtest
> }
> log {
> module: MESSAGE
> enable: debug
> timestamp: yes
> }
> {noformat}
> Right now, router works only as described e.g. here
> [https://issues.apache.org/jira/browse/DISPATCH-640|DISPATCH-640]
> In such a case, it is important to set a *name* (aka container_id) for the
> broker, matching the value of _containerId_ attribute of the chosen
> linkRoute/autoLink entity. Then all messages are routed to this broker,
> ignoring the value of _container_id_ of the actual client itself.
> Request is that this value would be used to "specify" which clients would
> actually be allowed to make a connection to the broker.
> Usages:
> Scenario A:
> 1. Client has containerId=xxx, address="myqueue"
> 2. linkRoute has containerId=yyy, prefix="myqueue"
> resolution: connection won't be established, not matching containerId
> Scenario B:
> 1. Client has containerId=xxx, address="myqueue"
> 2. linkRoute has containerId=xxx, prefix="myqueue"
> resolution: connection will be established, client sends messages to the
> broker
> As described in
> [https://issues.apache.org/jira/browse/DISPATCH-639|DISPATCH-639] ->
> "if there is a container field, use it otherwise use the connection_field to
> specify the connection to use."
> This could be elevated to the use case, where an condition as:
> "if there is container field and also connection_field specified, demand
> matching containerId from the client"
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-641) Make containerId attribute work with clients
[
https://issues.apache.org/jira/browse/DISPATCH-641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-641.
Resolution: Won't Fix
Fix Version/s: 0.8.0
> Make containerId attribute work with clients
>
>
> Key: DISPATCH-641
> URL: https://issues.apache.org/jira/browse/DISPATCH-641
> Project: Qpid Dispatch
> Issue Type: Improvement
> Components: Router Node
>Affects Versions: 0.7.0
>Reporter: Matej Lesko
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> During verification of issue
> https://issues.apache.org/jira/browse/DISPATCH-628
> I found out that when I set this _containerId_ in the clients, router can see
> it but it can not route it.
> E.g. I have sender with the _containerId_ "xxx" and autoLink entity with the
> _containerId_ "xxx" ->
> this autoLink does not activate in this scenario.
> Simply said when I have sender/receiver with the _containerId_ set and
> matching the _containerId_ attribute in the configuration file, it does
> *not* accept the connection. e.g. _linkRoute_ usage ends with the "Link
> error: No route to the destination node".
> Possible configuration to use(same applies for _autoLink_ entities)
> {noformat}
> router {
> mode: standalone
> id: Router.A
> }
> listener {
> host: 0.0.0.0
> port: amqp
> authenticatePeer: no
> saslMechanisms: ANONYMOUS
> }
> connector {
> name: broker
> host: MY-HOST
> role: route-container
> port: amqp
> }
> address {
> prefix: jms.queue
> waypoint: yes
> distribution: balanced
> }
> linkRoute {
> name: myqueueIn
> dir: in
> prefix: jms.queue.myqueue
> connection: broker
> containerId: dtest
> }
> linkRoute {
> name: myqueueOut
> dir: out
> prefix: jms.queue.myqueue
> connection: broker
> containerId: dtest
> }
> log {
> module: MESSAGE
> enable: debug
> timestamp: yes
> }
> {noformat}
> Right now, router works only as described e.g. here
> [https://issues.apache.org/jira/browse/DISPATCH-640|DISPATCH-640]
> In such a case, it is important to set a *name* (aka container_id) for the
> broker, matching the value of _containerId_ attribute of the chosen
> linkRoute/autoLink entity. Then all messages are routed to this broker,
> ignoring the value of _container_id_ of the actual client itself.
> Request is that this value would be used to "specify" which clients would
> actually be allowed to make a connection to the broker.
> Usages:
> Scenario A:
> 1. Client has containerId=xxx, address="myqueue"
> 2. linkRoute has containerId=yyy, prefix="myqueue"
> resolution: connection won't be established, not matching containerId
> Scenario B:
> 1. Client has containerId=xxx, address="myqueue"
> 2. linkRoute has containerId=xxx, prefix="myqueue"
> resolution: connection will be established, client sends messages to the
> broker
> As described in
> [https://issues.apache.org/jira/browse/DISPATCH-639|DISPATCH-639] ->
> "if there is a container field, use it otherwise use the connection_field to
> specify the connection to use."
> This could be elevated to the use case, where an condition as:
> "if there is container field and also connection_field specified, demand
> matching containerId from the client"
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-641) Make containerId attribute work with clients
[
https://issues.apache.org/jira/browse/DISPATCH-641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy reassigned DISPATCH-641:
--
Assignee: Ganesh Murthy
> Make containerId attribute work with clients
>
>
> Key: DISPATCH-641
> URL: https://issues.apache.org/jira/browse/DISPATCH-641
> Project: Qpid Dispatch
> Issue Type: Improvement
> Components: Router Node
>Affects Versions: 0.7.0
>Reporter: Matej Lesko
>Assignee: Ganesh Murthy
>
> During verification of issue
> https://issues.apache.org/jira/browse/DISPATCH-628
> I found out that when I set this _containerId_ in the clients, router can see
> it but it can not route it.
> E.g. I have sender with the _containerId_ "xxx" and autoLink entity with the
> _containerId_ "xxx" ->
> this autoLink does not activate in this scenario.
> Simply said when I have sender/receiver with the _containerId_ set and
> matching the _containerId_ attribute in the configuration file, it does
> *not* accept the connection. e.g. _linkRoute_ usage ends with the "Link
> error: No route to the destination node".
> Possible configuration to use(same applies for _autoLink_ entities)
> {noformat}
> router {
> mode: standalone
> id: Router.A
> }
> listener {
> host: 0.0.0.0
> port: amqp
> authenticatePeer: no
> saslMechanisms: ANONYMOUS
> }
> connector {
> name: broker
> host: MY-HOST
> role: route-container
> port: amqp
> }
> address {
> prefix: jms.queue
> waypoint: yes
> distribution: balanced
> }
> linkRoute {
> name: myqueueIn
> dir: in
> prefix: jms.queue.myqueue
> connection: broker
> containerId: dtest
> }
> linkRoute {
> name: myqueueOut
> dir: out
> prefix: jms.queue.myqueue
> connection: broker
> containerId: dtest
> }
> log {
> module: MESSAGE
> enable: debug
> timestamp: yes
> }
> {noformat}
> Right now, router works only as described e.g. here
> [https://issues.apache.org/jira/browse/DISPATCH-640|DISPATCH-640]
> In such a case, it is important to set a *name* (aka container_id) for the
> broker, matching the value of _containerId_ attribute of the chosen
> linkRoute/autoLink entity. Then all messages are routed to this broker,
> ignoring the value of _container_id_ of the actual client itself.
> Request is that this value would be used to "specify" which clients would
> actually be allowed to make a connection to the broker.
> Usages:
> Scenario A:
> 1. Client has containerId=xxx, address="myqueue"
> 2. linkRoute has containerId=yyy, prefix="myqueue"
> resolution: connection won't be established, not matching containerId
> Scenario B:
> 1. Client has containerId=xxx, address="myqueue"
> 2. linkRoute has containerId=xxx, prefix="myqueue"
> resolution: connection will be established, client sends messages to the
> broker
> As described in
> [https://issues.apache.org/jira/browse/DISPATCH-639|DISPATCH-639] ->
> "if there is a container field, use it otherwise use the connection_field to
> specify the connection to use."
> This could be elevated to the use case, where an condition as:
> "if there is container field and also connection_field specified, demand
> matching containerId from the client"
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-620) no-strict-aliasing is only supported with GCC
[ https://issues.apache.org/jira/browse/DISPATCH-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-620. Resolution: Fixed Fix Version/s: 0.8.0 Thanks Adel for patch. Pushed up to master > no-strict-aliasing is only supported with GCC > - > > Key: DISPATCH-620 > URL: https://issues.apache.org/jira/browse/DISPATCH-620 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Adel Boutros >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: 0010-no-strict-aliasing-is-only-supported-with-GCC.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-620) no-strict-aliasing is only supported with GCC
[ https://issues.apache.org/jira/browse/DISPATCH-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy reassigned DISPATCH-620: -- Assignee: Ganesh Murthy > no-strict-aliasing is only supported with GCC > - > > Key: DISPATCH-620 > URL: https://issues.apache.org/jira/browse/DISPATCH-620 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Adel Boutros >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: 0010-no-strict-aliasing-is-only-supported-with-GCC.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-639) Document proper usage of containerId for autoLinks/linkRoutes entities
[
https://issues.apache.org/jira/browse/DISPATCH-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy updated DISPATCH-639:
---
Fix Version/s: 0.8.0
> Document proper usage of containerId for autoLinks/linkRoutes entities
> --
>
> Key: DISPATCH-639
> URL: https://issues.apache.org/jira/browse/DISPATCH-639
> Project: Qpid Dispatch
> Issue Type: Task
> Components: Documentation
>Affects Versions: 0.7.0
>Reporter: Matej Lesko
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> Usage of containerId is shadowed from the user point of the view.
> If you look at this code -
> [https://github.com/apache/qpid-dispatch/blob/master/src/router_core/agent_config_auto_link.c#L413]
> you will see -
> {code:none}
> qd_parsed_field_t *in_use_conn = is_container ? container_field :
> connection_field;
> {code}
> which means if there is a container field, use it otherwise use the
> connection_field to specify the connection to use.
> This is not specified in the documentation. It means that when user has
> created connector entity, assigned to the _autoLink/linkRoute_ entity, this
> connector won't be used if _containerId_ is specified.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-639) Document proper usage of containerId for autoLinks/linkRoutes entities
[
https://issues.apache.org/jira/browse/DISPATCH-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy reassigned DISPATCH-639:
--
Assignee: Ganesh Murthy
> Document proper usage of containerId for autoLinks/linkRoutes entities
> --
>
> Key: DISPATCH-639
> URL: https://issues.apache.org/jira/browse/DISPATCH-639
> Project: Qpid Dispatch
> Issue Type: Task
> Components: Documentation
>Affects Versions: 0.7.0
>Reporter: Matej Lesko
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> Usage of containerId is shadowed from the user point of the view.
> If you look at this code -
> [https://github.com/apache/qpid-dispatch/blob/master/src/router_core/agent_config_auto_link.c#L413]
> you will see -
> {code:none}
> qd_parsed_field_t *in_use_conn = is_container ? container_field :
> connection_field;
> {code}
> which means if there is a container field, use it otherwise use the
> connection_field to specify the connection to use.
> This is not specified in the documentation. It means that when user has
> created connector entity, assigned to the _autoLink/linkRoute_ entity, this
> connector won't be used if _containerId_ is specified.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-640) containerId field conflics with the connector name
[
https://issues.apache.org/jira/browse/DISPATCH-640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-640.
Resolution: Fixed
Fix Version/s: 0.8.0
Modified code to allow only one of connection or containerId in
linkRoute/autoLink.
> containerId field conflics with the connector name
> --
>
> Key: DISPATCH-640
> URL: https://issues.apache.org/jira/browse/DISPATCH-640
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Router Node
>Affects Versions: 0.7.0
> Environment: rhel6x,i rhel7x
>Reporter: Matej Lesko
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> Using this configuration with the JAMQ7 (with container_id "dtest") a problem
> appears when a name is specified for the connector.
> In this case linkRoutes are not established to the broker.
> Commenting out a _name_ attribute in _connector_ entity linkRouting works as
> expected.
> {noformat}
> router {
> mode: standalone
> id: Router.A
> }
> listener {
> host: 0.0.0.0
> port: amqp
> authenticatePeer: no
> saslMechanisms: ANONYMOUS
> }
> connector {
> name: broker
> host: MY-HOST
> role: route-container
> port: amqp
> }
> address {
> prefix: jms.queue
> waypoint: yes
> distribution: balanced
> }
> linkRoute {
> name: myqueueIn
> dir: in
> prefix: jms.queue.myqueue
> connection: broker
> containerId: dtest
> }
> linkRoute {
> name: myqueueOut
> dir: out
> prefix: jms.queue.myqueue
> connection: broker
> containerId: dtest
> }
> log {
> module: MESSAGE
> enable: debug
> timestamp: yes
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-639) Document proper usage of containerId for autoLinks/linkRoutes entities
[
https://issues.apache.org/jira/browse/DISPATCH-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-639.
Resolution: Fixed
Added documentation to qdrouter.json to specify that only one of containerId or
connection is allowed on autoLink/linkRoute.
> Document proper usage of containerId for autoLinks/linkRoutes entities
> --
>
> Key: DISPATCH-639
> URL: https://issues.apache.org/jira/browse/DISPATCH-639
> Project: Qpid Dispatch
> Issue Type: Task
> Components: Documentation
>Affects Versions: 0.7.0
>Reporter: Matej Lesko
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> Usage of containerId is shadowed from the user point of the view.
> If you look at this code -
> [https://github.com/apache/qpid-dispatch/blob/master/src/router_core/agent_config_auto_link.c#L413]
> you will see -
> {code:none}
> qd_parsed_field_t *in_use_conn = is_container ? container_field :
> connection_field;
> {code}
> which means if there is a container field, use it otherwise use the
> connection_field to specify the connection to use.
> This is not specified in the documentation. It means that when user has
> created connector entity, assigned to the _autoLink/linkRoute_ entity, this
> connector won't be used if _containerId_ is specified.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-611) Router core dump with old config file
[
https://issues.apache.org/jira/browse/DISPATCH-611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy reassigned DISPATCH-611:
--
Assignee: Ganesh Murthy
> Router core dump with old config file
> -
>
> Key: DISPATCH-611
> URL: https://issues.apache.org/jira/browse/DISPATCH-611
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 0.7.0
> Environment: Linux hostname 4.8.13-100.fc23.x86_64 #1 SMP Fri Dec 9
> 14:51:40 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Chuck Rolke
>Assignee: Ganesh Murthy
> Attachments: oops.conf
>
>
> Revving up an old config file causes a core dump.
> {noformat}
> > ./qdrouterd -c oops.conf -I /home/user/git/qpid-dispatch/python
> qdrouterd: /home/user/git/qpid-dispatch/src/dispatch.c:162:
> qd_dispatch_configure_router: Assertion `qd->router_id' failed.
> Aborted (core dumped)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-646) Link route tests which test the drain feature fail intermittently
Ganesh Murthy created DISPATCH-646:
--
Summary: Link route tests which test the drain feature fail
intermittently
Key: DISPATCH-646
URL: https://issues.apache.org/jira/browse/DISPATCH-646
Project: Qpid Dispatch
Issue Type: Bug
Components: Container
Affects Versions: 0.8.0
Reporter: Ganesh Murthy
Assignee: Ted Ross
There is test called test_www_drain_support_all_messages in
system_tests_link_routes that fails intermittently. Here is the output of the
test
{noformat}
[gmurthy@localhost build]$ /usr/bin/python
"/home/gmurthy/opensource/dispatch/build/tests/run.py" "-m" "unittest" "-v"
"system_tests_link_routes.LinkRouteTest.test_www_drain_support_all_messages"
test_www_drain_support_all_messages (system_tests_link_routes.LinkRouteTest)
...
FAIL
==
FAIL: test_www_drain_support_all_messages
(system_tests_link_routes.LinkRouteTest)
--
Traceback (most recent call last):
File "/home/gmurthy/opensource/dispatch/tests/system_tests_link_routes.py",
line 542, in test_www_drain_support_all_messages
self.assertEqual(None, drain_support.error)
AssertionError: None != 'Timeout Expired: sent: 10 rcvd: 7'
--
Ran 1 test in 9.421s
FAILED (failures=1)
{noformat}
The test uses 3 routers (routers A, B and C) with router A acting as the broker
and the senders and receivers connected router C and they send/receive on link
routed addresses. The messages sent to router C are link-routed to router B and
go on to router A and are eventually link routed back to router B and finally
to a receiver attached to router C.
The sender sends 10 messages and the receiver initially issues a flow of 4
followed by a drain of 20. This means that the remaining 6 messages must come
thru to the receiver. The problem in that in router B, the 6 transfers from
router A to router B are followed by a response flow frame (drain=true). In
router B, this flow frame sometimes gets ahead of the transfers and shuts down
the remaining transfers.
The following frame trace shows the flow frame coming in from router C and
being sent to router A which followed by 6 transfer frames and a response flow
frame arriving from router A. Note now that the router B forwards 3 of the 6
transfers to router C and tries sending the response flow frame before the
remaining 3 transfers. Because of this the receiver is not seeing all 10
messages.
{noformat}
Fri Mar 3 13:49:11 2017 SERVER (trace) [3]:4 <- @flow(19) [next-incoming-id=4,
incoming-window=2147483647, next-outgoing-id=0, outgoing-window=2147483647,
handle=0, delivery-count=4, link-credit=20, drain=true]
(/home/gmurthy/opensource/dispatch/src/server.c:197)
Fri Mar 3 13:49:11 2017 ROUTER_CORE (trace) Core action 'link_flow'
(/home/gmurthy/opensource/dispatch/src/router_core/router_core_thread.c:82)
Fri Mar 3 13:49:11 2017 SERVER (trace) [2]:0 -> @flow(19) [next-incoming-id=4,
incoming-window=2147483647, next-outgoing-id=0, outgoing-window=2147483647,
handle=0, delivery-count=4, link-credit=20, drain=true]
(/home/gmurthy/opensource/dispatch/src/server.c:197)
Fri Mar 3 13:49:11 2017 SERVER (trace) [2]:0 <- @transfer(20) [handle=0,
delivery-id=4, delivery-tag=b"\x04\x00\x00\x00\x00\x00\x00\x00",
message-format=0, settled=true, more=false] (96)
"\x00Sp\xd0\x00\x00\x00\x0b\x00\x00\x00\x05BP\x04@BR\x00\x00Ss\xd0\x00\x00\x00"\x00\x00\x00\x0d\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@R\x00@\x00St\xd1\x00\x00\x00\x0b\x00\x00\x00\x02\xa0\x03seqT\x04\x00Sw\xa0\x0bHello
World" (/home/gmurthy/opensource/dispatch/src/server.c:197)
Fri Mar 3 13:49:11 2017 SERVER (trace) [2]:0 <- @transfer(20) [handle=0,
delivery-id=5, delivery-tag=b"\x05\x00\x00\x00\x00\x00\x00\x00",
message-format=0, settled=true, more=false] (96)
"\x00Sp\xd0\x00\x00\x00\x0b\x00\x00\x00\x05BP\x04@BR\x00\x00Ss\xd0\x00\x00\x00"\x00\x00\x00\x0d\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@R\x00@\x00St\xd1\x00\x00\x00\x0b\x00\x00\x00\x02\xa0\x03seqT\x05\x00Sw\xa0\x0bHello
World" (/home/gmurthy/opensource/dispatch/src/server.c:197)
Fri Mar 3 13:49:11 2017 SERVER (trace) [2]:0 <- @transfer(20) [handle=0,
delivery-id=6, delivery-tag=b"\x06\x00\x00\x00\x00\x00\x00\x00",
message-format=0, settled=true, more=false] (96)
"\x00Sp\xd0\x00\x00\x00\x0b\x00\x00\x00\x05BP\x04@BR\x00\x00Ss\xd0\x00\x00\x00"\x00\x00\x00\x0d\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@R\x00@\x00St\xd1\x00\x00\x00\x0b\x00\x00\x00\x02\xa0\x03seqT\x06\x00Sw\xa0\x0bHello
World" (/home/gmurthy/opensource/dispatch/src/server.c:197)
Fri Mar 3 13:49:11 2017 SERVER (trace) [2]:0 <- @transfer(20) [handle
[jira] [Assigned] (DISPATCH-301) Some unit tests fail with workerThreads are set to 4
[
https://issues.apache.org/jira/browse/DISPATCH-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy reassigned DISPATCH-301:
--
Assignee: Ganesh Murthy
> Some unit tests fail with workerThreads are set to 4
>
>
> Key: DISPATCH-301
> URL: https://issues.apache.org/jira/browse/DISPATCH-301
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 0.6.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>
> Python tests like system_tests_user_id and system_tests_qdstat fail when the
> workerThreads are set to more than 1 (in my test case I had workerThreads set
> to 4)
> I see the following output -
> {noformat}
> [gmurthy@localhost build]$ PN_TRACE_FRM=1
> "/home/gmurthy/opensource/dispatch/build/tests/run.py" "-m" "unittest" "-v"
> "system_tests_user_id"
> test_ssl_user_id (system_tests_user_id.QdSSLUseridTest) ... [0x55a742167ee0]:
> -> SASL
> [0x55a742167ee0]: <- SASL
> [0x55a742167ee0]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:EXTERNAL]]
> [0x55a742167ee0]:0 -> @sasl-init(65) [mechanism=:EXTERNAL,
> initial-response=b""]
> [0x55a742167ee0]:0 <- @sasl-outcome(68) [code=0]
> [0x55a742167ee0]: -> AMQP
> [0x55a742167ee0]:0 -> @open(16)
> [container-id="473eaeaf-c3af-43d9-91ed-f10b53b38084", channel-max=32767]
> [0x55a742167ee0]: <- AMQP
> [0x55a742167ee0]:0 <- @open(16) [container-id="QDR", max-frame-size=16384,
> channel-max=32767, idle-time-out=6,
> offered-capabilities=:"ANONYMOUS-RELAY",
> properties={:product="qpid-dispatch-router", :version="0.6.0"}]
> [0x55a742167ee0]:0 -> @begin(17) [next-outgoing-id=0,
> incoming-window=2147483647, outgoing-window=2147483647]
> [0x55a742167ee0]:0 -> @attach(18)
> [name="473eaeaf-c3af-43d9-91ed-f10b53b38084-$management", handle=0,
> role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> [durable=0, timeout=0, dynamic=false], target=@target(41)
> [address="$management", durable=0, timeout=0, dynamic=false],
> initial-delivery-count=0]
> [0x55a742167ee0]:0 -> @close(24) [error=@error(29)
> [condition=:"amqp:connection:framing-error", description="SSL Failure:
> Unknown error."]]
> [0x55a742167ee0]: <- EOS
> [0x55a742167ee0]: -> EOS
> ERROR
> ==
> ERROR: test_ssl_user_id (system_tests_user_id.QdSSLUseridTest)
> --
> Traceback (most recent call last):
> File "/home/gmurthy/opensource/dispatch/tests/system_tests_user_id.py",
> line 220, in test_ssl_user_id
> node = Node.connect(addr, ssl_domain=domain)
> File
> "/home/gmurthy/opensource/dispatch/python/qpid_dispatch/management/client.py",
> line 98, in connect
> return Node(Node.connection(url, router, timeout, ssl_domain))
> File
> "/home/gmurthy/opensource/dispatch/python/qpid_dispatch/management/client.py",
> line 112, in __init__
> self.client = SyncRequestResponse(connection, self.url.path)
> File
> "/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/utils.py",
> line 321, in __init__
> self.sender = self.connection.create_sender(self.address)
> File
> "/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/utils.py",
> line 211, in create_sender
> return BlockingSender(self, self.container.create_sender(self.conn,
> address, name=name, handler=handler, options=options))
> File
> "/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/utils.py",
> line 68, in __init__
> super(BlockingSender, self).__init__(connection, sender)
> File
> "/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/utils.py",
> line 32, in __init__
> msg="Opening link %s" % link.name)
> File
> "/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/utils.py",
> line 264, in wait
> raise ConnectionException("Connection %s disconnected" % self.url)
> ConnectionException: Connection amqps://0.0.0.0:27216/$management disconnected
> --
> Ran 1 test in 2.144s
> FAILED (errors=1)
> [gmurthy@localhost build]$
> {noformat}
> Switch the workerThreads back to 1 and the tests will pass
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (DISPATCH-301) Some unit tests fail with workerThreads are set to 4
[
https://issues.apache.org/jira/browse/DISPATCH-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy reopened DISPATCH-301:
> Some unit tests fail with workerThreads are set to 4
>
>
> Key: DISPATCH-301
> URL: https://issues.apache.org/jira/browse/DISPATCH-301
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 0.6.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>
> Python tests like system_tests_user_id and system_tests_qdstat fail when the
> workerThreads are set to more than 1 (in my test case I had workerThreads set
> to 4)
> I see the following output -
> {noformat}
> [gmurthy@localhost build]$ PN_TRACE_FRM=1
> "/home/gmurthy/opensource/dispatch/build/tests/run.py" "-m" "unittest" "-v"
> "system_tests_user_id"
> test_ssl_user_id (system_tests_user_id.QdSSLUseridTest) ... [0x55a742167ee0]:
> -> SASL
> [0x55a742167ee0]: <- SASL
> [0x55a742167ee0]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:EXTERNAL]]
> [0x55a742167ee0]:0 -> @sasl-init(65) [mechanism=:EXTERNAL,
> initial-response=b""]
> [0x55a742167ee0]:0 <- @sasl-outcome(68) [code=0]
> [0x55a742167ee0]: -> AMQP
> [0x55a742167ee0]:0 -> @open(16)
> [container-id="473eaeaf-c3af-43d9-91ed-f10b53b38084", channel-max=32767]
> [0x55a742167ee0]: <- AMQP
> [0x55a742167ee0]:0 <- @open(16) [container-id="QDR", max-frame-size=16384,
> channel-max=32767, idle-time-out=6,
> offered-capabilities=:"ANONYMOUS-RELAY",
> properties={:product="qpid-dispatch-router", :version="0.6.0"}]
> [0x55a742167ee0]:0 -> @begin(17) [next-outgoing-id=0,
> incoming-window=2147483647, outgoing-window=2147483647]
> [0x55a742167ee0]:0 -> @attach(18)
> [name="473eaeaf-c3af-43d9-91ed-f10b53b38084-$management", handle=0,
> role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> [durable=0, timeout=0, dynamic=false], target=@target(41)
> [address="$management", durable=0, timeout=0, dynamic=false],
> initial-delivery-count=0]
> [0x55a742167ee0]:0 -> @close(24) [error=@error(29)
> [condition=:"amqp:connection:framing-error", description="SSL Failure:
> Unknown error."]]
> [0x55a742167ee0]: <- EOS
> [0x55a742167ee0]: -> EOS
> ERROR
> ==
> ERROR: test_ssl_user_id (system_tests_user_id.QdSSLUseridTest)
> --
> Traceback (most recent call last):
> File "/home/gmurthy/opensource/dispatch/tests/system_tests_user_id.py",
> line 220, in test_ssl_user_id
> node = Node.connect(addr, ssl_domain=domain)
> File
> "/home/gmurthy/opensource/dispatch/python/qpid_dispatch/management/client.py",
> line 98, in connect
> return Node(Node.connection(url, router, timeout, ssl_domain))
> File
> "/home/gmurthy/opensource/dispatch/python/qpid_dispatch/management/client.py",
> line 112, in __init__
> self.client = SyncRequestResponse(connection, self.url.path)
> File
> "/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/utils.py",
> line 321, in __init__
> self.sender = self.connection.create_sender(self.address)
> File
> "/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/utils.py",
> line 211, in create_sender
> return BlockingSender(self, self.container.create_sender(self.conn,
> address, name=name, handler=handler, options=options))
> File
> "/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/utils.py",
> line 68, in __init__
> super(BlockingSender, self).__init__(connection, sender)
> File
> "/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/utils.py",
> line 32, in __init__
> msg="Opening link %s" % link.name)
> File
> "/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/utils.py",
> line 264, in wait
> raise ConnectionException("Connection %s disconnected" % self.url)
> ConnectionException: Connection amqps://0.0.0.0:27216/$management disconnected
> --
> Ran 1 test in 2.144s
> FAILED (errors=1)
> [gmurthy@localhost build]$
> {noformat}
> Switch the workerThreads back to 1 and the tests will pass
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-301) Some unit tests fail with workerThreads are set to 4
[
https://issues.apache.org/jira/browse/DISPATCH-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-301.
Resolution: Fixed
> Some unit tests fail with workerThreads are set to 4
>
>
> Key: DISPATCH-301
> URL: https://issues.apache.org/jira/browse/DISPATCH-301
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 0.6.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>
> Python tests like system_tests_user_id and system_tests_qdstat fail when the
> workerThreads are set to more than 1 (in my test case I had workerThreads set
> to 4)
> I see the following output -
> {noformat}
> [gmurthy@localhost build]$ PN_TRACE_FRM=1
> "/home/gmurthy/opensource/dispatch/build/tests/run.py" "-m" "unittest" "-v"
> "system_tests_user_id"
> test_ssl_user_id (system_tests_user_id.QdSSLUseridTest) ... [0x55a742167ee0]:
> -> SASL
> [0x55a742167ee0]: <- SASL
> [0x55a742167ee0]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:EXTERNAL]]
> [0x55a742167ee0]:0 -> @sasl-init(65) [mechanism=:EXTERNAL,
> initial-response=b""]
> [0x55a742167ee0]:0 <- @sasl-outcome(68) [code=0]
> [0x55a742167ee0]: -> AMQP
> [0x55a742167ee0]:0 -> @open(16)
> [container-id="473eaeaf-c3af-43d9-91ed-f10b53b38084", channel-max=32767]
> [0x55a742167ee0]: <- AMQP
> [0x55a742167ee0]:0 <- @open(16) [container-id="QDR", max-frame-size=16384,
> channel-max=32767, idle-time-out=6,
> offered-capabilities=:"ANONYMOUS-RELAY",
> properties={:product="qpid-dispatch-router", :version="0.6.0"}]
> [0x55a742167ee0]:0 -> @begin(17) [next-outgoing-id=0,
> incoming-window=2147483647, outgoing-window=2147483647]
> [0x55a742167ee0]:0 -> @attach(18)
> [name="473eaeaf-c3af-43d9-91ed-f10b53b38084-$management", handle=0,
> role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> [durable=0, timeout=0, dynamic=false], target=@target(41)
> [address="$management", durable=0, timeout=0, dynamic=false],
> initial-delivery-count=0]
> [0x55a742167ee0]:0 -> @close(24) [error=@error(29)
> [condition=:"amqp:connection:framing-error", description="SSL Failure:
> Unknown error."]]
> [0x55a742167ee0]: <- EOS
> [0x55a742167ee0]: -> EOS
> ERROR
> ==
> ERROR: test_ssl_user_id (system_tests_user_id.QdSSLUseridTest)
> --
> Traceback (most recent call last):
> File "/home/gmurthy/opensource/dispatch/tests/system_tests_user_id.py",
> line 220, in test_ssl_user_id
> node = Node.connect(addr, ssl_domain=domain)
> File
> "/home/gmurthy/opensource/dispatch/python/qpid_dispatch/management/client.py",
> line 98, in connect
> return Node(Node.connection(url, router, timeout, ssl_domain))
> File
> "/home/gmurthy/opensource/dispatch/python/qpid_dispatch/management/client.py",
> line 112, in __init__
> self.client = SyncRequestResponse(connection, self.url.path)
> File
> "/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/utils.py",
> line 321, in __init__
> self.sender = self.connection.create_sender(self.address)
> File
> "/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/utils.py",
> line 211, in create_sender
> return BlockingSender(self, self.container.create_sender(self.conn,
> address, name=name, handler=handler, options=options))
> File
> "/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/utils.py",
> line 68, in __init__
> super(BlockingSender, self).__init__(connection, sender)
> File
> "/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/utils.py",
> line 32, in __init__
> msg="Opening link %s" % link.name)
> File
> "/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/utils.py",
> line 264, in wait
> raise ConnectionException("Connection %s disconnected" % self.url)
> ConnectionException: Connection amqps://0.0.0.0:27216/$management disconnected
> --
> Ran 1 test in 2.144s
> FAILED (errors=1)
> [gmurthy@localhost build]$
> {noformat}
> Switch the workerThreads back to 1 and the tests will pass
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-301) Some unit tests fail with workerThreads are set to 4
[
https://issues.apache.org/jira/browse/DISPATCH-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-301.
Resolution: Duplicate
Fix Version/s: 0.8.0
The workerThreads have been set back to 4. The only test that fails after
setting the workerThreads to 4 is the drain related link route tests. This is
already being tracked in DISPATCH-646
> Some unit tests fail with workerThreads are set to 4
>
>
> Key: DISPATCH-301
> URL: https://issues.apache.org/jira/browse/DISPATCH-301
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 0.6.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> Python tests like system_tests_user_id and system_tests_qdstat fail when the
> workerThreads are set to more than 1 (in my test case I had workerThreads set
> to 4)
> I see the following output -
> {noformat}
> [gmurthy@localhost build]$ PN_TRACE_FRM=1
> "/home/gmurthy/opensource/dispatch/build/tests/run.py" "-m" "unittest" "-v"
> "system_tests_user_id"
> test_ssl_user_id (system_tests_user_id.QdSSLUseridTest) ... [0x55a742167ee0]:
> -> SASL
> [0x55a742167ee0]: <- SASL
> [0x55a742167ee0]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:EXTERNAL]]
> [0x55a742167ee0]:0 -> @sasl-init(65) [mechanism=:EXTERNAL,
> initial-response=b""]
> [0x55a742167ee0]:0 <- @sasl-outcome(68) [code=0]
> [0x55a742167ee0]: -> AMQP
> [0x55a742167ee0]:0 -> @open(16)
> [container-id="473eaeaf-c3af-43d9-91ed-f10b53b38084", channel-max=32767]
> [0x55a742167ee0]: <- AMQP
> [0x55a742167ee0]:0 <- @open(16) [container-id="QDR", max-frame-size=16384,
> channel-max=32767, idle-time-out=6,
> offered-capabilities=:"ANONYMOUS-RELAY",
> properties={:product="qpid-dispatch-router", :version="0.6.0"}]
> [0x55a742167ee0]:0 -> @begin(17) [next-outgoing-id=0,
> incoming-window=2147483647, outgoing-window=2147483647]
> [0x55a742167ee0]:0 -> @attach(18)
> [name="473eaeaf-c3af-43d9-91ed-f10b53b38084-$management", handle=0,
> role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40)
> [durable=0, timeout=0, dynamic=false], target=@target(41)
> [address="$management", durable=0, timeout=0, dynamic=false],
> initial-delivery-count=0]
> [0x55a742167ee0]:0 -> @close(24) [error=@error(29)
> [condition=:"amqp:connection:framing-error", description="SSL Failure:
> Unknown error."]]
> [0x55a742167ee0]: <- EOS
> [0x55a742167ee0]: -> EOS
> ERROR
> ==
> ERROR: test_ssl_user_id (system_tests_user_id.QdSSLUseridTest)
> --
> Traceback (most recent call last):
> File "/home/gmurthy/opensource/dispatch/tests/system_tests_user_id.py",
> line 220, in test_ssl_user_id
> node = Node.connect(addr, ssl_domain=domain)
> File
> "/home/gmurthy/opensource/dispatch/python/qpid_dispatch/management/client.py",
> line 98, in connect
> return Node(Node.connection(url, router, timeout, ssl_domain))
> File
> "/home/gmurthy/opensource/dispatch/python/qpid_dispatch/management/client.py",
> line 112, in __init__
> self.client = SyncRequestResponse(connection, self.url.path)
> File
> "/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/utils.py",
> line 321, in __init__
> self.sender = self.connection.create_sender(self.address)
> File
> "/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/utils.py",
> line 211, in create_sender
> return BlockingSender(self, self.container.create_sender(self.conn,
> address, name=name, handler=handler, options=options))
> File
> "/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/utils.py",
> line 68, in __init__
> super(BlockingSender, self).__init__(connection, sender)
> File
> "/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/utils.py",
> line 32, in __init__
> msg="Opening link %s" % link.name)
> File
> "/opt/qpid-proton/qpid-proton/lib64/proton/bindings/python/proton/utils.py",
> line 264, in wait
> raise ConnectionException("Connection %s disconnected" % self.url)
> ConnectionException: Connection amqps://0.0.0.0:27216/$management disconnected
> --
> Ran 1 test in 2.144s
> FAILED (errors=1)
> [gmurthy@localhost build]$
> {noformat}
> Switch the workerThreads back to 1 and the tests will pass
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-615) SunStudio doesn't convert pointers to bool correctly
[ https://issues.apache.org/jira/browse/DISPATCH-615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy reassigned DISPATCH-615: -- Assignee: Ganesh Murthy > SunStudio doesn't convert pointers to bool correctly > > > Key: DISPATCH-615 > URL: https://issues.apache.org/jira/browse/DISPATCH-615 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Adel Boutros >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: > 0005-SunStudio-doesn-t-convert-pointers-to-bool-correctly.patch > > > improper pointer/integer combination: op "=" (PyObject * to bool) -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-615) SunStudio doesn't convert pointers to bool correctly
[ https://issues.apache.org/jira/browse/DISPATCH-615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy updated DISPATCH-615: --- Fix Version/s: 0.8.0 > SunStudio doesn't convert pointers to bool correctly > > > Key: DISPATCH-615 > URL: https://issues.apache.org/jira/browse/DISPATCH-615 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Adel Boutros >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: > 0005-SunStudio-doesn-t-convert-pointers-to-bool-correctly.patch > > > improper pointer/integer combination: op "=" (PyObject * to bool) -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-615) SunStudio doesn't convert pointers to bool correctly
[ https://issues.apache.org/jira/browse/DISPATCH-615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-615. Resolution: Fixed > SunStudio doesn't convert pointers to bool correctly > > > Key: DISPATCH-615 > URL: https://issues.apache.org/jira/browse/DISPATCH-615 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Adel Boutros >Assignee: Ganesh Murthy > Attachments: > 0005-SunStudio-doesn-t-convert-pointers-to-bool-correctly.patch > > > improper pointer/integer combination: op "=" (PyObject * to bool) -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-626) Add hints for getaddrinfo on Solaris
[ https://issues.apache.org/jira/browse/DISPATCH-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-626. Resolution: Fixed Fix Version/s: 0.8.0 > Add hints for getaddrinfo on Solaris > > > Key: DISPATCH-626 > URL: https://issues.apache.org/jira/browse/DISPATCH-626 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Adel Boutros >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: 0001-Add-hints-for-getaddrinfo-on-Solaris.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-626) Add hints for getaddrinfo on Solaris
[ https://issues.apache.org/jira/browse/DISPATCH-626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy reassigned DISPATCH-626: -- Assignee: Ganesh Murthy > Add hints for getaddrinfo on Solaris > > > Key: DISPATCH-626 > URL: https://issues.apache.org/jira/browse/DISPATCH-626 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Adel Boutros >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: 0001-Add-hints-for-getaddrinfo-on-Solaris.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-621) Add missing string.h include for Solaris compiler
[ https://issues.apache.org/jira/browse/DISPATCH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy reassigned DISPATCH-621: -- Assignee: Ganesh Murthy > Add missing string.h include for Solaris compiler > - > > Key: DISPATCH-621 > URL: https://issues.apache.org/jira/browse/DISPATCH-621 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Adel Boutros >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: > 0011-Add-missing-string.h-include-for-Solaris-compiler.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-621) Add missing string.h include for Solaris compiler
[ https://issues.apache.org/jira/browse/DISPATCH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-621. Resolution: Fixed Fix Version/s: 0.8.0 > Add missing string.h include for Solaris compiler > - > > Key: DISPATCH-621 > URL: https://issues.apache.org/jira/browse/DISPATCH-621 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Adel Boutros >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: > 0011-Add-missing-string.h-include-for-Solaris-compiler.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-613) Remove semi-column not needed after function definition
[ https://issues.apache.org/jira/browse/DISPATCH-613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy reassigned DISPATCH-613: -- Assignee: Ganesh Murthy > Remove semi-column not needed after function definition > --- > > Key: DISPATCH-613 > URL: https://issues.apache.org/jira/browse/DISPATCH-613 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Adel Boutros >Assignee: Ganesh Murthy > Attachments: > 0003-Remove-semi-column-not-needed-after-function-definit.patch > > > Empty statement (an extra ";") causes error on Solaris -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-597) Log enhancements
[
https://issues.apache.org/jira/browse/DISPATCH-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-597.
Resolution: Fixed
> Log enhancements
>
>
> Key: DISPATCH-597
> URL: https://issues.apache.org/jira/browse/DISPATCH-597
> Project: Qpid Dispatch
> Issue Type: Improvement
> Components: Container
>Affects Versions: 0.7.0
>Reporter: Shibi Sudhakaran
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> Print information at INFO level into log that could be used for diagnosing
> router health.
> 1. Millisecond precision timestamp
> 2. Avoid logging message body.
> 3. Capability to configure application properties to be logged (messageId,
> correlationId, creationTime , application custom properties) etc
> Sample Entries (log level : INFO)
>
> => Mon 2016-09-26 11:31:44.050750 -0700 ROUTER_HELLO (info) SENT:
> HELLO(id=Router.A.0 area=0 inst=1474860067 seen=['Router.A.1', 'Router.A.2',
> 'Router.A.3', 'Router.A.4’])
> => Mon 2016-09-26 14:15:58.088754 -0700 MESSAGE (info) Sending Message{
> message-id='' correlation-id=''
> creation-time='2016-09-26 14:15:58.084 -0700' application properties='[Key:
> request-creation-time => Value: 1474924558078]' } on link
> => Mon 2016-09-26 14:15:20.547178 -0700 MESSAGE (info) Received Message{
> message-id='' correlation-id=''
> creation-time='2016-09-26 14:15:20.542 -0700' application properties='[Key:
> request-creation-time => Value: 1474924520539]'} on link
> => Mon 2016-09-26 09:40:00.149567 -0700 ROUTER_LS (info) Computed costs:
> {'Router.A.0': 1, 'Router.A.2': 1, 'Router.A.3': 1, 'Router.A.4': 1}
> => Mon 2016-09-26 14:23:07.376756 -0700 ROUTER (info) Router started in
> Interior mode, area=0 id=Router.A.1
> => Mon 2016-09-26 14:23:07.408136 -0700 CONN_MGR (info) Configured Listener:
> 0.0.0.0:5671 proto=any role=normal
> => Mon 2016-09-26 14:14:57.520917 -0700 SERVER (info) Accepting incoming
> connection from to
> => Mon 2016-09-26 14:23:07.376471 -0700 SERVER (info) Container Name:
> Router.A.1
> => Mon 2016-09-26 14:23:07.439250 -0700 SERVER (info) Connecting to
>
> => Mon 2016-09-26 14:23:07.447536 -0700 SERVER (info) [1]:Client SSL socket
> created.
> => Mon 2016-09-26 14:15:12.310692 -0700 SERVER (info) [8783]:SSL socket freed
> => Mon 2016-09-26 14:23:03.059884 -0700 SERVER (info) Shut Down
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-611) Router core dump with old config file
[
https://issues.apache.org/jira/browse/DISPATCH-611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15897796#comment-15897796
]
Ganesh Murthy commented on DISPATCH-611:
The attached config file "oops.conf" does not have a router section (entity).
The router section is mandatory even in old config files.
The following text must be added to the description of the "router" entity in
qdrouter.json to make it clear that router is a mandatory entity without which
the router will not start -
{noformat}
"description":"Tracks peer routers and computes routes to destinations. This
entity is mandatory. The router will not start without this entity",
{noformat}
Codewise, the assert must be replaced with an exit so that router does not even
start
Replace this asset -
{noformat}
assert(qd->router_id);
{noformat}
with
{noformat}
if (!qd->router_id) {
qd_log_source_t *router_log = qd_log_source("ROUTER");
qd_log(router_log, QD_LOG_CRITICAL, "Router Id not specified - process
exiting");
exit(1);
}
{noformat}
> Router core dump with old config file
> -
>
> Key: DISPATCH-611
> URL: https://issues.apache.org/jira/browse/DISPATCH-611
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 0.7.0
> Environment: Linux hostname 4.8.13-100.fc23.x86_64 #1 SMP Fri Dec 9
> 14:51:40 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Chuck Rolke
>Assignee: Ganesh Murthy
> Attachments: oops.conf
>
>
> Revving up an old config file causes a core dump.
> {noformat}
> > ./qdrouterd -c oops.conf -I /home/user/git/qpid-dispatch/python
> qdrouterd: /home/user/git/qpid-dispatch/src/dispatch.c:162:
> qd_dispatch_configure_router: Assertion `qd->router_id' failed.
> Aborted (core dumped)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (DISPATCH-611) Router core dump with old config file
[
https://issues.apache.org/jira/browse/DISPATCH-611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15897796#comment-15897796
]
Ganesh Murthy edited comment on DISPATCH-611 at 3/6/17 6:38 PM:
The attached config file "oops.conf" does not have a router section (entity).
The router section is mandatory even in legacy config files.
The following text must be added to the description of the "router" entity in
qdrouter.json to make it clear that router is a mandatory entity without which
the router will not start -
{noformat}
"description":"Tracks peer routers and computes routes to destinations. This
entity is mandatory. The router will not start without this entity",
{noformat}
Codewise, the assert must be replaced with an exit so that router does not even
start
Replace this asset -
{noformat}
assert(qd->router_id);
{noformat}
with
{noformat}
if (!qd->router_id) {
qd_log_source_t *router_log = qd_log_source("ROUTER");
qd_log(router_log, QD_LOG_CRITICAL, "Router Id not specified - process
exiting");
exit(1);
}
{noformat}
was (Author: ganeshmurthy):
The attached config file "oops.conf" does not have a router section (entity).
The router section is mandatory even in old config files.
The following text must be added to the description of the "router" entity in
qdrouter.json to make it clear that router is a mandatory entity without which
the router will not start -
{noformat}
"description":"Tracks peer routers and computes routes to destinations. This
entity is mandatory. The router will not start without this entity",
{noformat}
Codewise, the assert must be replaced with an exit so that router does not even
start
Replace this asset -
{noformat}
assert(qd->router_id);
{noformat}
with
{noformat}
if (!qd->router_id) {
qd_log_source_t *router_log = qd_log_source("ROUTER");
qd_log(router_log, QD_LOG_CRITICAL, "Router Id not specified - process
exiting");
exit(1);
}
{noformat}
> Router core dump with old config file
> -
>
> Key: DISPATCH-611
> URL: https://issues.apache.org/jira/browse/DISPATCH-611
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 0.7.0
> Environment: Linux hostname 4.8.13-100.fc23.x86_64 #1 SMP Fri Dec 9
> 14:51:40 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Chuck Rolke
>Assignee: Ganesh Murthy
> Attachments: oops.conf
>
>
> Revving up an old config file causes a core dump.
> {noformat}
> > ./qdrouterd -c oops.conf -I /home/user/git/qpid-dispatch/python
> qdrouterd: /home/user/git/qpid-dispatch/src/dispatch.c:162:
> qd_dispatch_configure_router: Assertion `qd->router_id' failed.
> Aborted (core dumped)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-611) Router core dump with old config file
[
https://issues.apache.org/jira/browse/DISPATCH-611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy updated DISPATCH-611:
---
Fix Version/s: 0.8.0
> Router core dump with old config file
> -
>
> Key: DISPATCH-611
> URL: https://issues.apache.org/jira/browse/DISPATCH-611
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 0.7.0
> Environment: Linux hostname 4.8.13-100.fc23.x86_64 #1 SMP Fri Dec 9
> 14:51:40 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Chuck Rolke
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
> Attachments: oops.conf
>
>
> Revving up an old config file causes a core dump.
> {noformat}
> > ./qdrouterd -c oops.conf -I /home/user/git/qpid-dispatch/python
> qdrouterd: /home/user/git/qpid-dispatch/src/dispatch.c:162:
> qd_dispatch_configure_router: Assertion `qd->router_id' failed.
> Aborted (core dumped)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-647) Coverity scan reported memory leaks in Qpid Dispatch master
Ganesh Murthy created DISPATCH-647:
--
Summary: Coverity scan reported memory leaks in Qpid Dispatch
master
Key: DISPATCH-647
URL: https://issues.apache.org/jira/browse/DISPATCH-647
Project: Qpid Dispatch
Issue Type: Bug
Components: Container
Affects Versions: 0.8.0
Reporter: Ganesh Murthy
Assignee: Ganesh Murthy
** CID 142259: Memory - corruptions (USE_AFTER_FREE)
/home/kgiusti/tmp/qpid-dispatch/src/posix/driver.c: 836 in qdpn_driver_free()
*** CID 142259: Memory - corruptions (USE_AFTER_FREE)
/home/kgiusti/tmp/qpid-dispatch/src/posix/driver.c: 836 in qdpn_driver_free()
830 void qdpn_driver_free(qdpn_driver_t *d)
831 {
832 if (!d) return;
833
834 close(d->efd);
835 while (DEQ_HEAD(d->connectors))
>>> CID 142259: Memory - corruptions (USE_AFTER_FREE)
>>> Calling "qdpn_connector_free" frees pointer "d->connectors.head" which
>>> has already been freed.
836 qdpn_connector_free(DEQ_HEAD(d->connectors));
837 while (DEQ_HEAD(d->listeners))
838 qdpn_listener_free(DEQ_HEAD(d->listeners));
839 free(d->fds);
840 sys_mutex_free(d->lock);
841 free(d);
** CID 142258: Uninitialized variables (UNINIT)
/home/kgiusti/tmp/qpid-dispatch/src/message.c: 192 in print_parsed_field()
*** CID 142258: Uninitialized variables (UNINIT)
/home/kgiusti/tmp/qpid-dispatch/src/message.c: 192 in print_parsed_field()
186 if (timestamp_length > 0) {
187 // Gather the timestamp bytes into the
timestamp_bytes array, so we process them later into time.
188 timestamp_bytes[--timestamp_length] = byte;
189 }
190}
191
>>> CID 142258: Uninitialized variables (UNINIT)
>>> Using uninitialized element of array "timestamp_bytes" when calling
>>> "memcpy".
192memcpy(&creation_timestamp, timestamp_bytes, 8);
193if (creation_timestamp > 0) {
194format_time(creation_timestamp, "%Y-%m-%d
%H:%M:%S.%%03lu %z", creation_time, 100);
195aprintf(begin, end, "%s", creation_time);
196}
197break;
** CID 142257: Resource leaks (RESOURCE_LEAK)
/home/kgiusti/tmp/qpid-dispatch/tests/field_test.c: 142 in test_trim()
*** CID 142257: Resource leaks (RESOURCE_LEAK)
/home/kgiusti/tmp/qpid-dispatch/tests/field_test.c: 142 in test_trim()
136 static char *test_trim(void *context)
137 {
138 qd_iterator_t *iter = qd_iterator_string("testing.trim",
ITER_VIEW_ALL);
139
140 qd_iterator_trim_view(iter, 7);
141 if (!qd_iterator_equal(iter, (unsigned char*) "testing"))
>>> CID 142257: Resource leaks (RESOURCE_LEAK)
>>> Variable "iter" going out of scope leaks the storage it points to.
142 return "Trim on ITER_VIEW_ALL failed (1)";
143
144 qd_iterator_reset_view(iter, ITER_VIEW_ALL);
145 if (!qd_iterator_equal(iter, (unsigned char*) "testing.trim"))
146 return "Trim on ITER_VIEW_ALL failed (2)";
147
** CID 142256: Resource leaks (RESOURCE_LEAK)
/home/kgiusti/tmp/qpid-dispatch/tests/field_test.c: 193 in test_sub_iterator()
*** CID 142256: Resource leaks (RESOURCE_LEAK)
/home/kgiusti/tmp/qpid-dispatch/tests/field_test.c: 193 in test_sub_iterator()
187 qd_iterator_t *sub1 = qd_iterator_sub(iter,
qd_iterator_remaining(iter));
188 qd_iterator_advance(iter, 5);
189 qd_iterator_t *sub2 = qd_iterator_sub(iter,
qd_iterator_remaining(iter));
190 qd_iterator_t *sub3 = qd_iterator_sub(iter, 3);
191
192 if (!qd_iterator_equal(sub1, (unsigned char*) "test_sub_iterator"))
>>> CID 142256: Resource leaks (RESOURCE_LEAK)
>>> Variable "sub3" going out of scope leaks the storage it points to.
193 return "Sub Iterator failed - 1";
194 if (!qd_iterator_equal(sub2, (unsigned char*) "sub_iterator"))
195 return "Sub Iterator failed - 2";
196 if (!qd_iterator_equal(sub3, (unsigned char*) "sub"))
197 return "Sub Iterator failed - 3";
198
** CID 142255:(RESOURCE_LEAK)
/home/kgiusti/tmp/qpid-dispatch/tests/parse_test.c: 151 in test_map()
/home/kgiusti/tmp/qpid-dispatch/tests/parse_test.c: 161 in test_map()
/home/kgiusti/tmp/qpid-dispatch/tests/parse_test.c: 170 in test_map()
/home/kgiusti/tmp/qpid-dispa
[jira] [Resolved] (DISPATCH-647) Coverity scan reported memory leaks in Qpid Dispatch master
[
https://issues.apache.org/jira/browse/DISPATCH-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-647.
Resolution: Fixed
Fix Version/s: 0.8.0
> Coverity scan reported memory leaks in Qpid Dispatch master
> ---
>
> Key: DISPATCH-647
> URL: https://issues.apache.org/jira/browse/DISPATCH-647
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 0.8.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> ** CID 142259: Memory - corruptions (USE_AFTER_FREE)
> /home/kgiusti/tmp/qpid-dispatch/src/posix/driver.c: 836 in qdpn_driver_free()
>
> *** CID 142259: Memory - corruptions (USE_AFTER_FREE)
> /home/kgiusti/tmp/qpid-dispatch/src/posix/driver.c: 836 in qdpn_driver_free()
> 830 void qdpn_driver_free(qdpn_driver_t *d)
> 831 {
> 832 if (!d) return;
> 833
> 834 close(d->efd);
> 835 while (DEQ_HEAD(d->connectors))
> >>> CID 142259: Memory - corruptions (USE_AFTER_FREE)
> >>> Calling "qdpn_connector_free" frees pointer "d->connectors.head"
> >>> which has already been freed.
> 836 qdpn_connector_free(DEQ_HEAD(d->connectors));
> 837 while (DEQ_HEAD(d->listeners))
> 838 qdpn_listener_free(DEQ_HEAD(d->listeners));
> 839 free(d->fds);
> 840 sys_mutex_free(d->lock);
> 841 free(d);
> ** CID 142258: Uninitialized variables (UNINIT)
> /home/kgiusti/tmp/qpid-dispatch/src/message.c: 192 in print_parsed_field()
>
> *** CID 142258: Uninitialized variables (UNINIT)
> /home/kgiusti/tmp/qpid-dispatch/src/message.c: 192 in print_parsed_field()
> 186 if (timestamp_length > 0) {
> 187 // Gather the timestamp bytes into the
> timestamp_bytes array, so we process them later into time.
> 188 timestamp_bytes[--timestamp_length] = byte;
> 189 }
> 190}
> 191
> >>> CID 142258: Uninitialized variables (UNINIT)
> >>> Using uninitialized element of array "timestamp_bytes" when calling
> >>> "memcpy".
> 192memcpy(&creation_timestamp, timestamp_bytes, 8);
> 193if (creation_timestamp > 0) {
> 194format_time(creation_timestamp, "%Y-%m-%d
> %H:%M:%S.%%03lu %z", creation_time, 100);
> 195aprintf(begin, end, "%s", creation_time);
> 196}
> 197break;
> ** CID 142257: Resource leaks (RESOURCE_LEAK)
> /home/kgiusti/tmp/qpid-dispatch/tests/field_test.c: 142 in test_trim()
>
> *** CID 142257: Resource leaks (RESOURCE_LEAK)
> /home/kgiusti/tmp/qpid-dispatch/tests/field_test.c: 142 in test_trim()
> 136 static char *test_trim(void *context)
> 137 {
> 138 qd_iterator_t *iter = qd_iterator_string("testing.trim",
> ITER_VIEW_ALL);
> 139
> 140 qd_iterator_trim_view(iter, 7);
> 141 if (!qd_iterator_equal(iter, (unsigned char*) "testing"))
> >>> CID 142257: Resource leaks (RESOURCE_LEAK)
> >>> Variable "iter" going out of scope leaks the storage it points to.
> 142 return "Trim on ITER_VIEW_ALL failed (1)";
> 143
> 144 qd_iterator_reset_view(iter, ITER_VIEW_ALL);
> 145 if (!qd_iterator_equal(iter, (unsigned char*) "testing.trim"))
> 146 return "Trim on ITER_VIEW_ALL failed (2)";
> 147
> ** CID 142256: Resource leaks (RESOURCE_LEAK)
> /home/kgiusti/tmp/qpid-dispatch/tests/field_test.c: 193 in test_sub_iterator()
>
> *** CID 142256: Resource leaks (RESOURCE_LEAK)
> /home/kgiusti/tmp/qpid-dispatch/tests/field_test.c: 193 in test_sub_iterator()
> 187 qd_iterator_t *sub1 = qd_iterator_sub(iter,
> qd_iterator_remaining(iter));
> 188 qd_iterator_advance(iter, 5);
> 189 qd_iterator_t *sub2 = qd_iterator_sub(iter,
> qd_iterator_remaining(iter));
> 190 qd_iterator_t *sub3 = qd_iterator_sub(iter, 3);
> 191
> 192 if (!qd_iterator_equal(sub1, (unsigned char*)
> "test_sub_iterator"))
> >>> CID 142256: Resource leaks (RESOURCE_LEAK)
> >>> Variable "sub3" going out of scope leaks the storage it points to.
> 193 return "Sub Iterator failed - 1";
> 194 if (!qd_iterator_equal(sub2, (unsigned char*) "sub_iterator"))
> 195 return "Sub Iterat
[jira] [Commented] (DISPATCH-645) router crashes with memory errors
[ https://issues.apache.org/jira/browse/DISPATCH-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15905391#comment-15905391 ] Ganesh Murthy commented on DISPATCH-645: Could not reproduce the crash using the attached testme.sh script. The script has not been running locally for over an hour without crashing. > router crashes with memory errors > - > > Key: DISPATCH-645 > URL: https://issues.apache.org/jira/browse/DISPATCH-645 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 0.7.0 >Reporter: Alan Conway >Assignee: Ted Ross >Priority: Critical > Attachments: testme.sh, valgrind.out > > > The router crashes with memory errors in a straightforward test using the > quiver test tool. For me the crash happens within a couple minutes. A > reproducer script and valgrind output from the crash are attached. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (DISPATCH-645) router crashes with memory errors
[ https://issues.apache.org/jira/browse/DISPATCH-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15905391#comment-15905391 ] Ganesh Murthy edited comment on DISPATCH-645 at 3/10/17 5:21 PM: - Could not reproduce the crash using the attached testme.sh script. The script has now been running locally for over an hour without crashing. was (Author: ganeshmurthy): Could not reproduce the crash using the attached testme.sh script. The script has not been running locally for over an hour without crashing. > router crashes with memory errors > - > > Key: DISPATCH-645 > URL: https://issues.apache.org/jira/browse/DISPATCH-645 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 0.7.0 >Reporter: Alan Conway >Assignee: Ted Ross >Priority: Critical > Attachments: testme.sh, valgrind.out > > > The router crashes with memory errors in a straightforward test using the > quiver test tool. For me the crash happens within a couple minutes. A > reproducer script and valgrind output from the crash are attached. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-631) Tests should be made conditional to skip tests for SASL features that are not available
[ https://issues.apache.org/jira/browse/DISPATCH-631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-631. Resolution: Fixed Fix Version/s: 0.8.0 > Tests should be made conditional to skip tests for SASL features that are not > available > --- > > Key: DISPATCH-631 > URL: https://issues.apache.org/jira/browse/DISPATCH-631 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 0.7.0, 0.8.0 > Environment: linux, sunos >Reporter: Rabih Mourad >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: failedTests.txt > > > > Hello, > > > > I compiled qpid-proton 0.16.0 with "-DSASL_IMPL=none", but i have an > > 3 of qpid-dispatch 0.7.0 unit tests that are failing: > > > > system_tests_qdstat > > system_tests_sasl_plain > > system_tests_deprecated > > > > I attached the tests output. > > > > Do you have any idea, where should i look? Is Cyrus mandatory for the > > qpid-dispatch 0.7.0? > Not mandatory, the tests should probably be made conditional to skip tests > for SASL features that are not available. Raise a JIRA for that. > > Best regards, > > Rabih -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-631) Tests should be made conditional to skip tests for SASL features that are not available
[ https://issues.apache.org/jira/browse/DISPATCH-631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy reassigned DISPATCH-631: -- Assignee: Ganesh Murthy > Tests should be made conditional to skip tests for SASL features that are not > available > --- > > Key: DISPATCH-631 > URL: https://issues.apache.org/jira/browse/DISPATCH-631 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 0.7.0, 0.8.0 > Environment: linux, sunos >Reporter: Rabih Mourad >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: failedTests.txt > > > > Hello, > > > > I compiled qpid-proton 0.16.0 with "-DSASL_IMPL=none", but i have an > > 3 of qpid-dispatch 0.7.0 unit tests that are failing: > > > > system_tests_qdstat > > system_tests_sasl_plain > > system_tests_deprecated > > > > I attached the tests output. > > > > Do you have any idea, where should i look? Is Cyrus mandatory for the > > qpid-dispatch 0.7.0? > Not mandatory, the tests should probably be made conditional to skip tests > for SASL features that are not available. Raise a JIRA for that. > > Best regards, > > Rabih -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-611) Router core dump with old config file
[
https://issues.apache.org/jira/browse/DISPATCH-611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-611.
Resolution: Fixed
> Router core dump with old config file
> -
>
> Key: DISPATCH-611
> URL: https://issues.apache.org/jira/browse/DISPATCH-611
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 0.7.0
> Environment: Linux hostname 4.8.13-100.fc23.x86_64 #1 SMP Fri Dec 9
> 14:51:40 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Chuck Rolke
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
> Attachments: oops.conf
>
>
> Revving up an old config file causes a core dump.
> {noformat}
> > ./qdrouterd -c oops.conf -I /home/user/git/qpid-dispatch/python
> qdrouterd: /home/user/git/qpid-dispatch/src/dispatch.c:162:
> qd_dispatch_configure_router: Assertion `qd->router_id' failed.
> Aborted (core dumped)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-638) [Test] If proton is built without Swig then twenty self tests fail
[
https://issues.apache.org/jira/browse/DISPATCH-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy reassigned DISPATCH-638:
--
Assignee: Ganesh Murthy
> [Test] If proton is built without Swig then twenty self tests fail
> --
>
> Key: DISPATCH-638
> URL: https://issues.apache.org/jira/browse/DISPATCH-638
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Tests
>Affects Versions: 0.7.0
> Environment: Fedora 25, dispatch master branch at commit 6ebae
>Reporter: Chuck Rolke
>Assignee: Ganesh Murthy
>
> The tests generally fail with
> {noformat}
> 10: Run python module 'unittest': ImportError: No module named proton
> {noformat}
> A better user experience would be a message: "Test skipped because Proton
> Python is missing. (Was Proton python language binding built with Swig?)".
> And then have the test be skipped and not failed.
> Proton C tests also have issues when Swig is absent:
> https://issues.apache.org/jira/browse/PROTON-1411
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-614) strerror_r on Solaris does not return char*
[ https://issues.apache.org/jira/browse/DISPATCH-614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy reassigned DISPATCH-614: -- Assignee: Ganesh Murthy > strerror_r on Solaris does not return char* > --- > > Key: DISPATCH-614 > URL: https://issues.apache.org/jira/browse/DISPATCH-614 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Adel Boutros >Assignee: Ganesh Murthy > Attachments: 0004-strerror_r-on-Solaris-does-not-return-char.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-614) strerror_r on Solaris does not return char*
[ https://issues.apache.org/jira/browse/DISPATCH-614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-614. Resolution: Fixed Fix Version/s: 0.8.0 > strerror_r on Solaris does not return char* > --- > > Key: DISPATCH-614 > URL: https://issues.apache.org/jira/browse/DISPATCH-614 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Adel Boutros >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: 0004-strerror_r-on-Solaris-does-not-return-char.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-614) strerror_r on Solaris does not return char*
[
https://issues.apache.org/jira/browse/DISPATCH-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15907923#comment-15907923
]
Ganesh Murthy commented on DISPATCH-614:
Commit 610739ff529adc295892390294b6cfdb87f84602 got rid of the line
static inline void ignore_result(char* ignored) {}
On an unrelated note, src/posix/driver.c does have an int as a parameter to
ignore_result
static inline void ignore_result(int unused_result) {
(void) unused_result;
}
> strerror_r on Solaris does not return char*
> ---
>
> Key: DISPATCH-614
> URL: https://issues.apache.org/jira/browse/DISPATCH-614
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 0.7.0
>Reporter: Adel Boutros
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
> Attachments: 0004-strerror_r-on-Solaris-does-not-return-char.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-612) Add support for GCC equivalent compiler options
[ https://issues.apache.org/jira/browse/DISPATCH-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy reassigned DISPATCH-612: -- Assignee: Ganesh Murthy > Add support for GCC equivalent compiler options > --- > > Key: DISPATCH-612 > URL: https://issues.apache.org/jira/browse/DISPATCH-612 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Adel Boutros >Assignee: Ganesh Murthy > Attachments: > 0002-Add-support-for-GCC-equivalent-compiler-options.patch > > > Some compiler flags used are only for GCC -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-612) Add support for GCC equivalent compiler options
[ https://issues.apache.org/jira/browse/DISPATCH-612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-612. Resolution: Fixed Fix Version/s: 0.8.0 > Add support for GCC equivalent compiler options > --- > > Key: DISPATCH-612 > URL: https://issues.apache.org/jira/browse/DISPATCH-612 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Adel Boutros >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: > 0002-Add-support-for-GCC-equivalent-compiler-options.patch > > > Some compiler flags used are only for GCC -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-622) use "-lpthread" instead of "-pthread" as compiler error to avoid undefined symbol on Solaris
[ https://issues.apache.org/jira/browse/DISPATCH-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy reassigned DISPATCH-622: -- Assignee: Ganesh Murthy > use "-lpthread" instead of "-pthread" as compiler error to avoid undefined > symbol on Solaris > > > Key: DISPATCH-622 > URL: https://issues.apache.org/jira/browse/DISPATCH-622 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Adel Boutros >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: > 0012-use-lpthread-instead-of-pthread-as-compiler-error-to.patch > > > Undefined symbol _mcount : CMakeFiles/qpid-dispatch.dir/bitmask.c.o -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-622) use "-lpthread" instead of "-pthread" as compiler error to avoid undefined symbol on Solaris
[ https://issues.apache.org/jira/browse/DISPATCH-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-622. Resolution: Fixed Fix Version/s: 0.8.0 > use "-lpthread" instead of "-pthread" as compiler error to avoid undefined > symbol on Solaris > > > Key: DISPATCH-622 > URL: https://issues.apache.org/jira/browse/DISPATCH-622 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Adel Boutros >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: > 0012-use-lpthread-instead-of-pthread-as-compiler-error-to.patch > > > Undefined symbol _mcount : CMakeFiles/qpid-dispatch.dir/bitmask.c.o -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-727) qdmanage identity reporting and lookup are broken
[
https://issues.apache.org/jira/browse/DISPATCH-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15924336#comment-15924336
]
Ganesh Murthy commented on DISPATCH-727:
This problem has already been reported in
https://issues.apache.org/jira/browse/DISPATCH-437 which is an all-encompassing
issue that covers this and several other issues that need to be addressed to
reconcile the C and the Python agents.
> qdmanage identity reporting and lookup are broken
> -
>
> Key: DISPATCH-727
> URL: https://issues.apache.org/jira/browse/DISPATCH-727
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Management Agent
>Affects Versions: 0.8.0
>Reporter: Alan Conway
>Assignee: Ganesh Murthy
>Priority: Blocker
>
> This may be a duplicate, but I want to make sure it doesn't get lost.
> On master commit=81eee44, some entities (I tried router) cannot be looked up
> by their identity.
> {code}
> [aconway@wallace dispatch2 (master=)]$ qdmanage query --type=router
> [
> {
> "connectionCount": 3,
> "autoLinkCount": 0,
> "name": "Router.A",
> "area": "0",
> "linkCount": 4,
> "linkRouteCount": 0,
> "addrCount": 5,
> "routerId": "Router.A",
> "version": "0.8.0",
> "mode": "standalone",
> "nodeCount": 0,
> "type": "org.apache.qpid.dispatch.router",
> "id": "Router.A",
> "identity": "1"
> }
> ]
> [aconway@wallace dispatch2 (master=)]$ qdmanage read --identity=1
> NotFoundStatus: No entity with identity='1'
> [aconway@wallace dispatch2 (master=)]$ git log -1
> 81eee44 DISPATCH-622 - Use -lpthread compile option for Solaris
> {code}
> Some identity lookups do work e.g. `qdmanage read
> --identity=allocator/qdr_general_work_t` - I think it is the numerical
> identities generated by C that are not working.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-727) qdmanage identity reporting and lookup are broken
[
https://issues.apache.org/jira/browse/DISPATCH-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-727.
Resolution: Duplicate
Fix Version/s: 0.8.0
> qdmanage identity reporting and lookup are broken
> -
>
> Key: DISPATCH-727
> URL: https://issues.apache.org/jira/browse/DISPATCH-727
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Management Agent
>Affects Versions: 0.8.0
>Reporter: Alan Conway
>Assignee: Ganesh Murthy
>Priority: Blocker
> Fix For: 0.8.0
>
>
> This may be a duplicate, but I want to make sure it doesn't get lost.
> On master commit=81eee44, some entities (I tried router) cannot be looked up
> by their identity.
> {code}
> [aconway@wallace dispatch2 (master=)]$ qdmanage query --type=router
> [
> {
> "connectionCount": 3,
> "autoLinkCount": 0,
> "name": "Router.A",
> "area": "0",
> "linkCount": 4,
> "linkRouteCount": 0,
> "addrCount": 5,
> "routerId": "Router.A",
> "version": "0.8.0",
> "mode": "standalone",
> "nodeCount": 0,
> "type": "org.apache.qpid.dispatch.router",
> "id": "Router.A",
> "identity": "1"
> }
> ]
> [aconway@wallace dispatch2 (master=)]$ qdmanage read --identity=1
> NotFoundStatus: No entity with identity='1'
> [aconway@wallace dispatch2 (master=)]$ git log -1
> 81eee44 DISPATCH-622 - Use -lpthread compile option for Solaris
> {code}
> Some identity lookups do work e.g. `qdmanage read
> --identity=allocator/qdr_general_work_t` - I think it is the numerical
> identities generated by C that are not working.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-729) password-file option doesn't work correctly
[ https://issues.apache.org/jira/browse/DISPATCH-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy reassigned DISPATCH-729: -- Assignee: Ganesh Murthy > password-file option doesn't work correctly > --- > > Key: DISPATCH-729 > URL: https://issues.apache.org/jira/browse/DISPATCH-729 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 0.7.0 > Environment: CentOS 7 >Reporter: Rohan Mars >Assignee: Ganesh Murthy >Priority: Minor > Fix For: 0.8.0 > > > Using the "password-file" option in a a ssl-profile causes the client not to > be able to connect. The router displays a: > "Enter PEM pass phrase" log message > Using the "password" option directly works. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-729) password-file option doesn't work correctly
[ https://issues.apache.org/jira/browse/DISPATCH-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-729. Resolution: Fixed > password-file option doesn't work correctly > --- > > Key: DISPATCH-729 > URL: https://issues.apache.org/jira/browse/DISPATCH-729 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 0.7.0 > Environment: CentOS 7 >Reporter: Rohan Mars >Assignee: Ganesh Murthy >Priority: Minor > Fix For: 0.8.0 > > > Using the "password-file" option in a a ssl-profile causes the client not to > be able to connect. The router displays a: > "Enter PEM pass phrase" log message > Using the "password" option directly works. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-730) Coverity scan reported errors in Qpid Dispatch master
Ganesh Murthy created DISPATCH-730:
--
Summary: Coverity scan reported errors in Qpid Dispatch master
Key: DISPATCH-730
URL: https://issues.apache.org/jira/browse/DISPATCH-730
Project: Qpid Dispatch
Issue Type: Bug
Components: Container
Affects Versions: 0.8.0
Reporter: Ganesh Murthy
Assignee: Ganesh Murthy
Fix For: 0.8.0
5 new defect(s) introduced to Apache Qpid dispatch-router found with Coverity
Scan.
New defect(s) Reported-by: Coverity Scan
Showing 5 of 5 defect(s)
** CID 142339:(USE_AFTER_FREE)
/home/gmurthy/opensource/dispatch/src/router_core/connections.c: 284 in
qdr_connection_process()
/home/gmurthy/opensource/dispatch/src/router_core/connections.c: 284 in
qdr_connection_process()
*** CID 142339:(USE_AFTER_FREE)
/home/gmurthy/opensource/dispatch/src/router_core/connections.c: 284 in
qdr_connection_process()
278 if (link_work->work_type == QDR_LINK_WORK_DELIVERY &&
link_work->value > 0) {
279 DEQ_INSERT_HEAD(link->work_list, link_work);
280 link_work = 0; // Halt work processing
281 } else {
282 qdr_error_free(link_work->error);
283 free_qdr_link_work_t(link_work);
>>> CID 142339:(USE_AFTER_FREE)
>>> Dereferencing freed pointer "link".
284 link_work = DEQ_HEAD(link->work_list);
285 if (link_work)
286 DEQ_REMOVE_HEAD(link->work_list);
287 }
288 sys_mutex_unlock(conn->work_lock);
289 event_count++;
/home/gmurthy/opensource/dispatch/src/router_core/connections.c: 284 in
qdr_connection_process()
278 if (link_work->work_type == QDR_LINK_WORK_DELIVERY &&
link_work->value > 0) {
279 DEQ_INSERT_HEAD(link->work_list, link_work);
280 link_work = 0; // Halt work processing
281 } else {
282 qdr_error_free(link_work->error);
283 free_qdr_link_work_t(link_work);
>>> CID 142339:(USE_AFTER_FREE)
>>> Dereferencing freed pointer "link".
284 link_work = DEQ_HEAD(link->work_list);
285 if (link_work)
286 DEQ_REMOVE_HEAD(link->work_list);
287 }
288 sys_mutex_unlock(conn->work_lock);
289 event_count++;
** CID 142338: Resource leaks (RESOURCE_LEAK)
/home/gmurthy/opensource/dispatch/src/failoverlist.c: 103 in qd_failover_list()
*** CID 142338: Resource leaks (RESOURCE_LEAK)
/home/gmurthy/opensource/dispatch/src/failoverlist.c: 103 in qd_failover_list()
97 char *cursor = list->text;
98 char *next;
99 do {
100 next = qd_fol_next(cursor, ",");
101 qd_failover_item_t *item = qd_fol_item(cursor, error);
102 if (item == 0)
>>> CID 142338: Resource leaks (RESOURCE_LEAK)
>>> Variable "list" going out of scope leaks the storage it points to.
103 return 0;
104 DEQ_INSERT_TAIL(list->item_list, item);
105 cursor = next;
106 } while (cursor && *cursor);
107
108 return list;
** CID 142337: Null pointer dereferences (FORWARD_NULL)
/home/gmurthy/opensource/dispatch/src/server.c: 564 in decorate_connection()
*** CID 142337: Null pointer dereferences (FORWARD_NULL)
/home/gmurthy/opensource/dispatch/src/server.c: 564 in decorate_connection()
558 if (config && config->inter_router_cost > 1) {
559 pn_data_put_symbol(pn_connection_properties(conn),
560
pn_bytes(strlen(QD_CONNECTION_PROPERTY_COST_KEY),
QD_CONNECTION_PROPERTY_COST_KEY));
561 pn_data_put_int(pn_connection_properties(conn),
config->inter_router_cost);
562 }
563
>>> CID 142337: Null pointer dereferences (FORWARD_NULL)
>>> Dereferencing null pointer "config".
564 qd_failover_list_t *fol = config->failover_list;
565 if (fol) {
566 pn_data_put_symbol(pn_connection_properties(conn),
567
pn_bytes(strlen(QD_CONNECTION_PROPERTY_FAILOVER_LIST_KEY),
QD_CONNECTION_PROPERTY_FAILOVER_LIST_KEY));
568 pn_data_put_list(pn_connection_properties(conn));
569 pn_data_enter(pn_connection_properties(conn));
** CID 142336: API usage errors (CHAR_I
[jira] [Assigned] (DISPATCH-728) crash on shutdown with connector
[ https://issues.apache.org/jira/browse/DISPATCH-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy reassigned DISPATCH-728: -- Assignee: Ganesh Murthy > crash on shutdown with connector > > > Key: DISPATCH-728 > URL: https://issues.apache.org/jira/browse/DISPATCH-728 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 0.7.0 > Environment: CentosOS 7 >Reporter: Rohan Mars >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: qdrouterd1.conf, qdrouterd2.conf > > > Running two routers connected via a "connector" causes the router to crash on > shutdown (control-c). > qdrouterd: /home/centos/qpid-dispatch/src/posix/driver.c:451: > qdpn_driver_remove_connector: Assertion `(d->connectors).size > 0' failed. > Aborted (core dumped) -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-728) crash on shutdown with connector
[ https://issues.apache.org/jira/browse/DISPATCH-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy resolved DISPATCH-728. Resolution: Fixed > crash on shutdown with connector > > > Key: DISPATCH-728 > URL: https://issues.apache.org/jira/browse/DISPATCH-728 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 0.7.0 > Environment: CentosOS 7 >Reporter: Rohan Mars >Assignee: Ganesh Murthy > Fix For: 0.8.0 > > Attachments: qdrouterd1.conf, qdrouterd2.conf > > > Running two routers connected via a "connector" causes the router to crash on > shutdown (control-c). > qdrouterd: /home/centos/qpid-dispatch/src/posix/driver.c:451: > qdpn_driver_remove_connector: Assertion `(d->connectors).size > 0' failed. > Aborted (core dumped) -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-618) Revert eventfd on Solaris
[ https://issues.apache.org/jira/browse/DISPATCH-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy updated DISPATCH-618: --- Affects Version/s: 0.8.0 > Revert eventfd on Solaris > - > > Key: DISPATCH-618 > URL: https://issues.apache.org/jira/browse/DISPATCH-618 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.8.0 >Reporter: Adel Boutros > Attachments: 0008-Revert-eventfd-on-Solaris.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-617) Define HOST_NAME_MAX on Unix OSes where _POSIX_HOST_NAME_MAX is defined instead
[ https://issues.apache.org/jira/browse/DISPATCH-617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy updated DISPATCH-617: --- Affects Version/s: (was: 0.7.0) 0.8.0 > Define HOST_NAME_MAX on Unix OSes where _POSIX_HOST_NAME_MAX is defined > instead > --- > > Key: DISPATCH-617 > URL: https://issues.apache.org/jira/browse/DISPATCH-617 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.8.0 >Reporter: Adel Boutros > Attachments: > 0007-Define-HOST_NAME_MAX-on-Unix-OSes-where-_POSIX_HOST_.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-619) Use memalign instead of posix_memalign which is not defined on Solaris
[ https://issues.apache.org/jira/browse/DISPATCH-619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy updated DISPATCH-619: --- Affects Version/s: (was: 0.7.0) 0.8.0 > Use memalign instead of posix_memalign which is not defined on Solaris > -- > > Key: DISPATCH-619 > URL: https://issues.apache.org/jira/browse/DISPATCH-619 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.8.0 >Reporter: Adel Boutros > Attachments: > 0009-Use-memalign-instead-of-posix_memalign-which-is-not-.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-618) Revert eventfd on Solaris
[ https://issues.apache.org/jira/browse/DISPATCH-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy updated DISPATCH-618: --- Affects Version/s: (was: 0.7.0) > Revert eventfd on Solaris > - > > Key: DISPATCH-618 > URL: https://issues.apache.org/jira/browse/DISPATCH-618 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.8.0 >Reporter: Adel Boutros > Attachments: 0008-Revert-eventfd-on-Solaris.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-613) Remove semi-column not needed after function definition
[ https://issues.apache.org/jira/browse/DISPATCH-613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy updated DISPATCH-613: --- Affects Version/s: (was: 0.7.0) 0.8.0 > Remove semi-column not needed after function definition > --- > > Key: DISPATCH-613 > URL: https://issues.apache.org/jira/browse/DISPATCH-613 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.8.0 >Reporter: Adel Boutros >Assignee: Ganesh Murthy > Attachments: > 0003-Remove-semi-column-not-needed-after-function-definit.patch > > > Empty statement (an extra ";") causes error on Solaris -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-616) Arithmetic operations not allowed on void * pointer
[ https://issues.apache.org/jira/browse/DISPATCH-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy updated DISPATCH-616: --- Affects Version/s: (was: 0.7.0) 0.8.0 > Arithmetic operations not allowed on void * pointer > --- > > Key: DISPATCH-616 > URL: https://issues.apache.org/jira/browse/DISPATCH-616 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.8.0 >Reporter: Adel Boutros > Attachments: > 0006-Arithmetic-operations-not-allowed-on-void-pointer.patch > > > arithmetic on a void* is illegal in both C and C++: > > http://stackoverflow.com/questions/3523145/pointer-arithmetic-for-void-pointer-in-c > https://gcc.gnu.org/onlinedocs/gcc-4.8.0/gcc/Pointer-Arith.html -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-616) Arithmetic operations not allowed on void * pointer
[ https://issues.apache.org/jira/browse/DISPATCH-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy updated DISPATCH-616: --- Fix Version/s: 0.8.0 > Arithmetic operations not allowed on void * pointer > --- > > Key: DISPATCH-616 > URL: https://issues.apache.org/jira/browse/DISPATCH-616 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Adel Boutros > Fix For: 0.8.0 > > Attachments: > 0006-Arithmetic-operations-not-allowed-on-void-pointer.patch > > > arithmetic on a void* is illegal in both C and C++: > > http://stackoverflow.com/questions/3523145/pointer-arithmetic-for-void-pointer-in-c > https://gcc.gnu.org/onlinedocs/gcc-4.8.0/gcc/Pointer-Arith.html -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-616) Arithmetic operations not allowed on void * pointer
[ https://issues.apache.org/jira/browse/DISPATCH-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy updated DISPATCH-616: --- Affects Version/s: (was: 0.8.0) 0.7.0 > Arithmetic operations not allowed on void * pointer > --- > > Key: DISPATCH-616 > URL: https://issues.apache.org/jira/browse/DISPATCH-616 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Adel Boutros > Fix For: 0.8.0 > > Attachments: > 0006-Arithmetic-operations-not-allowed-on-void-pointer.patch > > > arithmetic on a void* is illegal in both C and C++: > > http://stackoverflow.com/questions/3523145/pointer-arithmetic-for-void-pointer-in-c > https://gcc.gnu.org/onlinedocs/gcc-4.8.0/gcc/Pointer-Arith.html -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-618) Revert eventfd on Solaris
[ https://issues.apache.org/jira/browse/DISPATCH-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy updated DISPATCH-618: --- Fix Version/s: 0.8.0 > Revert eventfd on Solaris > - > > Key: DISPATCH-618 > URL: https://issues.apache.org/jira/browse/DISPATCH-618 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Adel Boutros > Fix For: 0.8.0 > > Attachments: 0008-Revert-eventfd-on-Solaris.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-617) Define HOST_NAME_MAX on Unix OSes where _POSIX_HOST_NAME_MAX is defined instead
[ https://issues.apache.org/jira/browse/DISPATCH-617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ganesh Murthy updated DISPATCH-617: --- Fix Version/s: 0.8.0 > Define HOST_NAME_MAX on Unix OSes where _POSIX_HOST_NAME_MAX is defined > instead > --- > > Key: DISPATCH-617 > URL: https://issues.apache.org/jira/browse/DISPATCH-617 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.7.0 >Reporter: Adel Boutros > Fix For: 0.8.0 > > Attachments: > 0007-Define-HOST_NAME_MAX-on-Unix-OSes-where-_POSIX_HOST_.patch > > -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
