[jira] [Created] (DISPATCH-477) Drop pre-settled under congestion
Ted Ross created DISPATCH-477: - Summary: Drop pre-settled under congestion Key: DISPATCH-477 URL: https://issues.apache.org/jira/browse/DISPATCH-477 Project: Qpid Dispatch Issue Type: New Feature Components: Router Node Reporter: Ted Ross Assignee: Ted Ross Fix For: 0.7.0 When a pre-settled (fire-and-forget) delivery is routed to a destination, and that destination's undelivered FIFO is at or above its capacity (default 250), pre-settled deliveries must be dropped to reduce congestion and prevent unbounded memory consumption. Once congestion is detected on a pre-settled delivery, all earlier pre-settled deliveries on the same outgoing link shall be dropped and only the most recent pre-settled delivery shall remain. Note that an outgoing link may contain a mixture of pre-settled and unsettled deliveries. -- 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-336) Very high latency for fire-and-forget sender
[ https://issues.apache.org/jira/browse/DISPATCH-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reassigned DISPATCH-336: - Assignee: Ted Ross > Very high latency for fire-and-forget sender > > > Key: DISPATCH-336 > URL: https://issues.apache.org/jira/browse/DISPATCH-336 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 > Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and > dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines >Reporter: Vishal Sharda >Assignee: Ted Ross >Priority: Critical > Fix For: 0.7.0 > > Attachments: config1.conf, config2.conf, output_1S_1R.txt > > > We are running two interconnected routers with 1 fire-and-forget sender > connected to 1 router and 1 receiver connected to another router. We are > observing increasing latency for the messages irrespective of number messages > sent. -- 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-103) Websocket Listeners
[ https://issues.apache.org/jira/browse/DISPATCH-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-103: -- Fix Version/s: 0.7.0 > Websocket Listeners > --- > > Key: DISPATCH-103 > URL: https://issues.apache.org/jira/browse/DISPATCH-103 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Container >Reporter: Ted Ross >Priority: Minor > Fix For: 0.7.0 > > > Add an option in configured listeners to use websockets encapsulation. This > will allow AMQP clients inside web browsers to directly connect to the > message bus. -- 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-8) Message:user-id must be authenticated on ingress
[ https://issues.apache.org/jira/browse/DISPATCH-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-8: Priority: Critical (was: Major) > Message:user-id must be authenticated on ingress > > > Key: DISPATCH-8 > URL: https://issues.apache.org/jira/browse/DISPATCH-8 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.1 >Reporter: Ted Ross >Priority: Critical > Fix For: 0.7.0 > > > When a message is received on an ingress link (i.e. from an originating > endpoint) and the message has a user-id field in its properties, that user-id > must be authenticated. > At first, this means that the user-id must be the same as that which was used > to authenticate the connection. > There may be other means of authenticating user-ids in the future, but > Dispatch must not simply pass them on unchecked. -- 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-55) Qdrouterd does not exit when service port is unavailable
[
https://issues.apache.org/jira/browse/DISPATCH-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated DISPATCH-55:
-
Fix Version/s: (was: 0.7.0)
0.8.0
> Qdrouterd does not exit when service port is unavailable
>
>
> Key: DISPATCH-55
> URL: https://issues.apache.org/jira/browse/DISPATCH-55
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 0.2
> Environment: Fedora 19, trunk build, x86_64
>Reporter: Chuck Rolke
> Fix For: 0.8.0
>
>
> When qdrouterd's port 5672 is in use then the router prints an error at
> startup but otherwise keeps running with no apparent open port. Log from
> failed startup:
> {noformat}
> Fri May 16 09:19:17 2014 CONN_MGR (INFO) Configured Listener: 0.0.0.0:amqp
> role=normal
> Fri May 16 09:19:17 2014 SERVER (ERROR) Driver Error 0 ((null))
> Fri May 16 09:19:17 2014 SERVER (INFO) Operational, 4 Threads Running
> {noformat}
> Startup from when the port is available have the same log without the (ERROR)
> line.
> Expected behavior is either
> * a qpidd-like exit-with-failure-message or
> * qdrouterd keeps trying to open the port and succeeds eventually.
--
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-467) Terminus renaming for autoLinks
[ https://issues.apache.org/jira/browse/DISPATCH-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-467: -- Priority: Minor (was: Major) > Terminus renaming for autoLinks > --- > > Key: DISPATCH-467 > URL: https://issues.apache.org/jira/browse/DISPATCH-467 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Router Node >Reporter: Ted Ross >Priority: Minor > Fix For: 0.7.0 > > > This feature is an enhancement to autolinks which allows the terminus (source > or target) address in the autolink to be different from the address used in > the router. -- 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-468) Display-name for identity in x.509 certificates
[ https://issues.apache.org/jira/browse/DISPATCH-468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-468: -- Priority: Blocker (was: Major) > Display-name for identity in x.509 certificates > --- > > Key: DISPATCH-468 > URL: https://issues.apache.org/jira/browse/DISPATCH-468 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Container >Reporter: Ted Ross >Priority: Blocker > Fix For: 0.7.0 > > > The displayname feature is partially implemented in 0.6.0. It needs to be > wired into the connection-open sequence. > This feature allows user-friendly identities to be used in lieu of > complicated identities from x.509 certificates (particularly if the > certificate signature is used for identification). > The user-friendly identities appear in the connection attributes and are used > to index access policy. -- 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-89) Model the legacy topic exchange behavior of qpidd
[ https://issues.apache.org/jira/browse/DISPATCH-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-89: - Fix Version/s: (was: 0.7.0) 0.8.0 > Model the legacy topic exchange behavior of qpidd > - > > Key: DISPATCH-89 > URL: https://issues.apache.org/jira/browse/DISPATCH-89 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Routing Engine >Affects Versions: 0.2 >Reporter: Ken Giusti >Assignee: Ken Giusti > Fix For: 0.8.0 > > > With Qpidd, a user can define a binding from an Exchange to a target queue. > The binding uses a key that is compared to a message's subject field. If the > key matches, the message is routed to the target queue for that binding. > It should be possible to emulate this behavior using the dispatch router. > Example: > User defines a mappings from a target address (the 'exchange') to a different > target address(es) (the 'queue'). These mappings (the 'bindings') are driven > by a pattern match against the inbound message's subject field. > Messages arriving at the router from any link whose target address has > bindings defined are not immediately routed. Prior to routing, the message's > subject field is extracted and compared against each binding defined for the > target. A list of new target addresses is created containing the target > address from each binding that satisfied the pattern match. The message is > then routed to each new target address. > The pattern syntax should be the same 'dotted string' notation from qpidd, > including '*' and "#' wildcarding. -- This message was sent by Atlassian JIRA (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-414) Deleting a ProxyListener from dispatch-console segfaults the router
[ https://issues.apache.org/jira/browse/DISPATCH-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-414: -- Fix Version/s: 0.7.0 > Deleting a ProxyListener from dispatch-console segfaults the router > --- > > Key: DISPATCH-414 > URL: https://issues.apache.org/jira/browse/DISPATCH-414 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 0.6.1 >Reporter: Jiri Danek >Assignee: Ganesh Murthy > Fix For: 0.7.0 > > Attachments: backtrace.log, console.conf, core.bz2, qdrouterd.log > > > Start qdrouterd with the attached config (default, except for the log and > console sections). > Start dispatch-console, connect to the router, go to Entities tab > Open listener/ProxyListener, click Delete, confirm > Wait for qdrouterd 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] [Updated] (DISPATCH-373) qdmanage : no clear error message when "read" type linkRoute, address and autoLink
[
https://issues.apache.org/jira/browse/DISPATCH-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated DISPATCH-373:
--
Fix Version/s: 0.7.0
> qdmanage : no clear error message when "read" type linkRoute, address and
> autoLink
> --
>
> Key: DISPATCH-373
> URL: https://issues.apache.org/jira/browse/DISPATCH-373
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 0.6.0
>Reporter: Paolo Patierno
>Assignee: Ganesh Murthy
> Fix For: 0.7.0
>
>
> Executing a bad request with "read" operation (only ---type option) produces
> following results for linkRoute, address and autoLink :
> [root@localhost /]# qdmanage -b localhost:5673 read --type linkRoute
> BadRequestStatus: Bad Request
> [root@localhost /]# qdmanage -b localhost:5673 read --type address
> BadRequestStatus: Bad Request
> [root@localhost /]# qdmanage -b localhost:5673 read --type autoLink
> BadRequestStatus: Bad Request
> and the router doesn't produce any error or output on the console.
> Instead, using another type, for example connector produces following result :
> [root@localhost /]# qdmanage -b localhost:5673 read --type connector
> BadRequestStatus: No name or identity provided
> with a clearer error on what user misses on the command line.
> At same time the router output shows following error to the console :
> Thu Jun 9 07:26:13 2016 AGENT (error) Error dispatching
> Message(address=None, properties={'operation': 'READ', 'type':
> 'org.apache.qpid.dispatch.connector'}, body={},
> reply_to='amqp:/_topo/0/Router.A/temp.JJRdbcd9RbPxemN', correlation_id=1L):
> No name or identity provided
> Traceback (most recent call last):
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 790, in receive
> status, body = self.handle(request)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 815, in handle
> target = self.find_entity(request)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 892, in find_entity
> raise BadRequestStatus("No name or identity provided")
> BadRequestStatus: No name or identity provided
> I guess that for all types provided, missing name or identity, the behavior
> should be the same.
--
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-449) Link-leak for attach-routed links
[ https://issues.apache.org/jira/browse/DISPATCH-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-449. --- Resolution: Fixed > Link-leak for attach-routed links > - > > Key: DISPATCH-449 > URL: https://issues.apache.org/jira/browse/DISPATCH-449 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 0.6.0 >Reporter: Ted Ross >Assignee: Ted Ross > Fix For: 0.7.0 > > > In a link-routing scenario, if the client endpoint detaches its link, the > outbound (routed) link is detached but not properly cleaned up in memory. In > fact, the leaked links appear in the list provided by "qdstat -l". -- 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-469) Address namespaces for multi-tennancy
Ted Ross created DISPATCH-469: - Summary: Address namespaces for multi-tennancy Key: DISPATCH-469 URL: https://issues.apache.org/jira/browse/DISPATCH-469 Project: Qpid Dispatch Issue Type: New Feature Components: Container Reporter: Ted Ross This feature is selectable per-listener. If enabled, namespace mapping is enabled on connections established through the listener. Address mapping is done for terminus addresses (source and target) on attached links and on the "to" field for messages delivered on anonymous senders. The namespace used is derived from the virtual host (open.hostname field). -- 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-468) Display-name for identity in x.509 certificates
Ted Ross created DISPATCH-468: - Summary: Display-name for identity in x.509 certificates Key: DISPATCH-468 URL: https://issues.apache.org/jira/browse/DISPATCH-468 Project: Qpid Dispatch Issue Type: New Feature Components: Container Reporter: Ted Ross Fix For: 0.7.0 The displayname feature is partially implemented in 0.6.0. It needs to be wired into the connection-open sequence. This feature allows user-friendly identities to be used in lieu of complicated identities from x.509 certificates (particularly if the certificate signature is used for identification). The user-friendly identities appear in the connection attributes and are used to index access policy. -- 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-467) Terminus renaming for autoLinks
Ted Ross created DISPATCH-467: - Summary: Terminus renaming for autoLinks Key: DISPATCH-467 URL: https://issues.apache.org/jira/browse/DISPATCH-467 Project: Qpid Dispatch Issue Type: New Feature Components: Router Node Reporter: Ted Ross Fix For: 0.7.0 This feature is an enhancement to autolinks which allows the terminus (source or target) address in the autolink to be different from the address used in the router. -- 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-466) Orderly Quiescence of Links
Ted Ross created DISPATCH-466: - Summary: Orderly Quiescence of Links Key: DISPATCH-466 URL: https://issues.apache.org/jira/browse/DISPATCH-466 Project: Qpid Dispatch Issue Type: New Feature Components: Router Node Reporter: Ted Ross Assignee: Ted Ross Fix For: 0.7.0 This features provides an "adminStatus" field for links which is "enabled" or "disabled". When a link is set to disabled, its operStatus transitions from UP to IDLE in an orderly fashion, such that message deliveries are not dropped if an idle link is closed. For incoming links, this means draining remaining credit and waiting for unsettled deliveries to be settled. For outgoing links, stop routing new deliveries to the link and wait for unsettled deliveries to be settled. Note that this feature is neither meaningful nor supported for routed links. -- 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-9) Refactor the routing fast-path to allow the insertion of an asynchronous address lookup
[ https://issues.apache.org/jira/browse/DISPATCH-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-9. - Resolution: Fixed Fix Version/s: 0.6.0 > Refactor the routing fast-path to allow the insertion of an asynchronous > address lookup > --- > > Key: DISPATCH-9 > URL: https://issues.apache.org/jira/browse/DISPATCH-9 > Project: Qpid Dispatch > Issue Type: Improvement >Affects Versions: 0.1 >Reporter: Ted Ross >Assignee: Ted Ross > Fix For: 0.6.0 > > > As we introduce more sophisticated ways to look up addresses, the router > fast-path needs to be able to accommodate the insertion of an asynchronous > look up. -- 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-8) Message:user-id must be authenticated on ingress
[ https://issues.apache.org/jira/browse/DISPATCH-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-8: Fix Version/s: 0.7.0 > Message:user-id must be authenticated on ingress > > > Key: DISPATCH-8 > URL: https://issues.apache.org/jira/browse/DISPATCH-8 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.1 >Reporter: Ted Ross > Fix For: 0.7.0 > > > When a message is received on an ingress link (i.e. from an originating > endpoint) and the message has a user-id field in its properties, that user-id > must be authenticated. > At first, this means that the user-id must be the same as that which was used > to authenticate the connection. > There may be other means of authenticating user-ids in the future, but > Dispatch must not simply pass them on unchecked. -- 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-210) try an epoll-based driver ...
[ https://issues.apache.org/jira/browse/DISPATCH-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross closed DISPATCH-210. - Resolution: Duplicate > try an epoll-based driver ... > - > > Key: DISPATCH-210 > URL: https://issues.apache.org/jira/browse/DISPATCH-210 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: michael goulish > > ...to improve scalability to large numbers of attached messaging apps. -- 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-443) Reverse name lookup on listener connections can hang the entire router
[ https://issues.apache.org/jira/browse/DISPATCH-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-443: -- Fix Version/s: (was: 0.7.0) > Reverse name lookup on listener connections can hang the entire router > -- > > Key: DISPATCH-443 > URL: https://issues.apache.org/jira/browse/DISPATCH-443 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 0.6.0 >Reporter: Ted Ross >Assignee: Ted Ross > Fix For: 0.6.1 > > > Depending on the configuration of the system on which the router is running, > the getnameinfo call invoked (under lock) on new incoming connections can > hang for a significant amount of time. When this happens, the router > suspends its operation. -- 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-410) console build fixups
[ https://issues.apache.org/jira/browse/DISPATCH-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-410: -- Fix Version/s: (was: 0.7.0) > console build fixups > > > Key: DISPATCH-410 > URL: https://issues.apache.org/jira/browse/DISPATCH-410 > Project: Qpid Dispatch > Issue Type: Task > Components: Console >Affects Versions: 0.6.0 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.6.1 > > > The hawtio console plugin build produces a 'source release' when using the > apache-release profile, even though the actual release is part of the overall > dispatch release archive. > The produced war file lacks LICENCE+NOTICE in META-INF taking specific > consideration of the bundled dependencies. -- 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-366) When delivery fails the router sends the RELEASED disposition, not MODIFIED
[ https://issues.apache.org/jira/browse/DISPATCH-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-366: -- Fix Version/s: (was: 0.7.0) > When delivery fails the router sends the RELEASED disposition, not MODIFIED > --- > > Key: DISPATCH-366 > URL: https://issues.apache.org/jira/browse/DISPATCH-366 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 0.6.0 >Reporter: Ken Giusti >Assignee: Ted Ross >Priority: Blocker > Fix For: 0.6.1 > > > The router does not properly distinguish between a delivery failure and > undeliverable. > In the case of a delivery failure - where the router cannot ensure that the > message wasn't consumed - the router must send back the MODIFIED terminal > disposition with the delivery-failed flag set. This is necessary as the > sender must increment the message's delivery-count if it retransmits. > In the case of an undeliverable message - where the router cannot forward a > message to the destination - the router must send back the RELEASED terminal > disposition. RELEASED informs the sender that the message was not acted > upon. The sender must not increment the message's delivery-count if it > retransmits. > Currently the router uses RELEASED in both these cases. -- 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-367) balanced distribution needs to be more... balanced.
[ https://issues.apache.org/jira/browse/DISPATCH-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-367: -- Fix Version/s: (was: 0.7.0) > balanced distribution needs to be more... balanced. > --- > > Key: DISPATCH-367 > URL: https://issues.apache.org/jira/browse/DISPATCH-367 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node >Affects Versions: 0.6.0 >Reporter: Ken Giusti >Assignee: Ganesh Murthy >Priority: Trivial > Fix For: 0.6.1 > > > When blocking sends are done to a balanced address with multiple consumers on > the same router all the messages go to one of the consumers. > I would expect that the messages would be evenly distributed across all > _locally_attached_ consumers. -- 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-460) Regression: Link-routed dynamic sources don't work
[ https://issues.apache.org/jira/browse/DISPATCH-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-460: -- Fix Version/s: (was: 0.7.0) 0.6.1 > Regression: Link-routed dynamic sources don't work > -- > > Key: DISPATCH-460 > URL: https://issues.apache.org/jira/browse/DISPATCH-460 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 0.6.0 >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Critical > Fix For: 0.6.1 > > > Two problems: > - There is no test for link-routing dynamic sources. > - Link routing dynamic sources doesn't work in 0.6.0. -- 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-460) Regression: Link-routed dynamic sources don't work
[ https://issues.apache.org/jira/browse/DISPATCH-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-460. --- Resolution: Fixed > Regression: Link-routed dynamic sources don't work > -- > > Key: DISPATCH-460 > URL: https://issues.apache.org/jira/browse/DISPATCH-460 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 0.6.0 >Reporter: Ted Ross >Assignee: Ted Ross >Priority: Critical > Fix For: 0.7.0 > > > Two problems: > - There is no test for link-routing dynamic sources. > - Link routing dynamic sources doesn't work in 0.6.0. -- 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-460) Regression: Link-routed dynamic sources don't work
Ted Ross created DISPATCH-460: - Summary: Regression: Link-routed dynamic sources don't work Key: DISPATCH-460 URL: https://issues.apache.org/jira/browse/DISPATCH-460 Project: Qpid Dispatch Issue Type: Bug Components: Router Node Affects Versions: 0.6.0 Reporter: Ted Ross Assignee: Ted Ross Priority: Critical Fix For: 0.7.0 Two problems: - There is no test for link-routing dynamic sources. - Link routing dynamic sources doesn't work in 0.6.0. -- 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-458) Batching of settlement can cause credit to be not issued to senders
Ted Ross created DISPATCH-458: - Summary: Batching of settlement can cause credit to be not issued to senders Key: DISPATCH-458 URL: https://issues.apache.org/jira/browse/DISPATCH-458 Project: Qpid Dispatch Issue Type: Bug Components: Router Node Affects Versions: 0.6.0 Reporter: Ted Ross Assignee: Ted Ross Fix For: 0.7.0 In a message routing scenario, if the receiver sends settlement in batches larger than about 150 (deliveries), credit to the sender can become stuck in the router causing the transfer to hang. -- 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-449) Link-leak for attach-routed links
Ted Ross created DISPATCH-449: - Summary: Link-leak for attach-routed links Key: DISPATCH-449 URL: https://issues.apache.org/jira/browse/DISPATCH-449 Project: Qpid Dispatch Issue Type: Bug Components: Router Node Affects Versions: 0.6.0 Reporter: Ted Ross Assignee: Ted Ross Fix For: 0.7.0 In a link-routing scenario, if the client endpoint detaches its link, the outbound (routed) link is detached but not properly cleaned up in memory. In fact, the leaked links appear in the list provided by "qdstat -l". -- 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-357) Address field is empty for link routed links in the qdstat "links" output
[ https://issues.apache.org/jira/browse/DISPATCH-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reopened DISPATCH-357: --- There's an architectural problem with this update. Will fix... > Address field is empty for link routed links in the qdstat "links" output > - > > Key: DISPATCH-357 > URL: https://issues.apache.org/jira/browse/DISPATCH-357 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.6.0 >Reporter: Paolo Patierno >Assignee: Ganesh Murthy > Fix For: 0.7.0 > > Attachments: qdstat_links.txt > > > I have a router with a link routed link for address "my_queue" configured (in > both directions in and out). > Executing "qdstat -l", it doesn't show me the address name; the "addr" field > is empty. > Attached you can find the file with output. -- 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-367) balanced distribution needs to be more... balanced.
[ https://issues.apache.org/jira/browse/DISPATCH-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-367: -- Fix Version/s: 0.6.1 > balanced distribution needs to be more... balanced. > --- > > Key: DISPATCH-367 > URL: https://issues.apache.org/jira/browse/DISPATCH-367 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node >Affects Versions: 0.6.0 >Reporter: Ken Giusti >Assignee: Ganesh Murthy >Priority: Trivial > Fix For: 0.6.1, 0.7.0 > > > When blocking sends are done to a balanced address with multiple consumers on > the same router all the messages go to one of the consumers. > I would expect that the messages would be evenly distributed across all > _locally_attached_ consumers. -- 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-367) balanced distribution needs to be more... balanced.
[ https://issues.apache.org/jira/browse/DISPATCH-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-367. --- Resolution: Fixed Fix Version/s: 0.7.0 > balanced distribution needs to be more... balanced. > --- > > Key: DISPATCH-367 > URL: https://issues.apache.org/jira/browse/DISPATCH-367 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node >Affects Versions: 0.6.0 >Reporter: Ken Giusti >Assignee: Ganesh Murthy >Priority: Trivial > Fix For: 0.7.0 > > > When blocking sends are done to a balanced address with multiple consumers on > the same router all the messages go to one of the consumers. > I would expect that the messages would be evenly distributed across all > _locally_attached_ consumers. -- 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-367) balanced distribution needs to be more... balanced.
[ https://issues.apache.org/jira/browse/DISPATCH-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-367: -- Issue Type: Improvement (was: Bug) > balanced distribution needs to be more... balanced. > --- > > Key: DISPATCH-367 > URL: https://issues.apache.org/jira/browse/DISPATCH-367 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node >Affects Versions: 0.6.0 >Reporter: Ken Giusti >Assignee: Ganesh Murthy > > When blocking sends are done to a balanced address with multiple consumers on > the same router all the messages go to one of the consumers. > I would expect that the messages would be evenly distributed across all > _locally_attached_ consumers. -- 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-233) Allow client side saslMechanisms to be specified for qdstat and qdmanage
[ https://issues.apache.org/jira/browse/DISPATCH-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-233. --- Resolution: Fixed Fix Version/s: 0.7.0 > Allow client side saslMechanisms to be specified for qdstat and qdmanage > > > Key: DISPATCH-233 > URL: https://issues.apache.org/jira/browse/DISPATCH-233 > Project: Qpid Dispatch > Issue Type: Improvement >Affects Versions: 0.5 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy > Fix For: 0.7.0 > > > There seems to be no way currently for the qdstat and the qdmanage programs > to specify the saslMechanisms they want to use when making a connection to > the Dispatch router -- 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-367) balanced distribution needs to be more... balanced.
[ https://issues.apache.org/jira/browse/DISPATCH-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-367: -- Priority: Trivial (was: Major) > balanced distribution needs to be more... balanced. > --- > > Key: DISPATCH-367 > URL: https://issues.apache.org/jira/browse/DISPATCH-367 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node >Affects Versions: 0.6.0 >Reporter: Ken Giusti >Assignee: Ganesh Murthy >Priority: Trivial > > When blocking sends are done to a balanced address with multiple consumers on > the same router all the messages go to one of the consumers. > I would expect that the messages would be evenly distributed across all > _locally_attached_ consumers. -- 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-443) Reverse name lookup on listener connections can hang the entire router
[ https://issues.apache.org/jira/browse/DISPATCH-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-443. --- Resolution: Fixed Fix Version/s: 0.6.1 > Reverse name lookup on listener connections can hang the entire router > -- > > Key: DISPATCH-443 > URL: https://issues.apache.org/jira/browse/DISPATCH-443 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 0.6.0 >Reporter: Ted Ross >Assignee: Ted Ross > Fix For: 0.6.1, 0.7.0 > > > Depending on the configuration of the system on which the router is running, > the getnameinfo call invoked (under lock) on new incoming connections can > hang for a significant amount of time. When this happens, the router > suspends its operation. -- 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-443) Reverse name lookup on listener connections can hang the entire router
Ted Ross created DISPATCH-443: - Summary: Reverse name lookup on listener connections can hang the entire router Key: DISPATCH-443 URL: https://issues.apache.org/jira/browse/DISPATCH-443 Project: Qpid Dispatch Issue Type: Bug Components: Container Affects Versions: 0.6.0 Reporter: Ted Ross Assignee: Ted Ross Fix For: 0.7.0 Depending on the configuration of the system on which the router is running, the getnameinfo call invoked (under lock) on new incoming connections can hang for a significant amount of time. When this happens, the router suspends its operation. -- 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-432) Qpid Dispatch Router does not close connection to Broker on exit
[
https://issues.apache.org/jira/browse/DISPATCH-432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15364911#comment-15364911
]
Ted Ross commented on DISPATCH-432:
---
Is this not a broker bug? If Artemis can't recover from a client that doesn't
close cleanly, it needs to be fixed.
When the router is shut down, it closes all of its connections, but not
cleanly. There is no AMQP handshake on the close when the router is shut down
by signal.
> Qpid Dispatch Router does not close connection to Broker on exit
>
>
> Key: DISPATCH-432
> URL: https://issues.apache.org/jira/browse/DISPATCH-432
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 0.6.0
>Reporter: Jiri Danek
>
> I have the following configuration for connecting to broker in my
> {{qdrouterd.conf}}
> {noformat}
> connector {
> name: ba
> role: route-container
> host: 172.28.128.221
> port: amqp
> sasl-mechanisms: ANONYMOUS
> }
> address {
> prefix: jms.queue
> waypoint: yes
> }
> autoLink {
> addr: jms.queue.first
> dir: in
> connection: ba
> }
> autoLink {
> addr: jms.queue.first
> dir: out
> connection: ba
> }
> autoLink {
> addr: jms.queue.second
> dir: in
> connection: ba
> }
> autoLink {
> addr: jms.queue.second
> dir: out
> connection: ba
> }
> {noformat}
> If I stop dispatch demon with {{sudo service qdrouterd stop}} and then kill
> Artemis broker with ^C, broker prints the following
> {noformat}
> 12:18:04,721 INFO [org.apache.activemq.artemis] AMQ241001: HTTP Server
> started at http://localhost:8161
> 12:18:04,722 INFO [org.apache.activemq.artemis] AMQ241002: Artemis Jolokia
> REST API available at http://localhost:8161/jolokia
> ^C12:18:16,881 ERROR [org.apache.activemq.artemis.core.server] AMQ224065:
> Failed to remove auto-created queue jms.queue.second:
> java.lang.IllegalStateException: Cannot access JMS Server, core server is not
> active
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.checkInitialised(JMSServerManagerImpl.java:1416)
> [artemis-jms-server-1.2.0.amq-77-redhat-1.jar:1.2.0.amq-77-redhat-1]
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.destroyQueue(JMSServerManagerImpl.java:766)
> [artemis-jms-server-1.2.0.amq-77-redhat-1.jar:1.2.0.amq-77-redhat-1]
> at
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl$JMSQueueDeleter.delete(JMSServerManagerImpl.java:1639)
> [artemis-jms-server-1.2.0.amq-77-redhat-1.jar:1.2.0.amq-77-redhat-1]
> at
> org.apache.activemq.artemis.core.server.impl.AutoCreatedQueueManagerImpl$1.run(AutoCreatedQueueManagerImpl.java:50)
> [artemis-server-1.2.0.amq-77-redhat-1.jar:1.2.0.amq-77-redhat-1]
> at
> org.apache.activemq.artemis.utils.ReferenceCounterUtil.decrement(ReferenceCounterUtil.java:55)
> [artemis-commons-1.2.0.amq-77-redhat-1.jar:1.2.0.amq-77-redhat-1]
> at
> org.apache.activemq.artemis.core.server.impl.AutoCreatedQueueManagerImpl.decrement(AutoCreatedQueueManagerImpl.java:78)
> [artemis-server-1.2.0.amq-77-redhat-1.jar:1.2.0.amq-77-redhat-1]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.removeConsumer(QueueImpl.java:768)
> [artemis-server-1.2.0.amq-77-redhat-1.jar:1.2.0.amq-77-redhat-1]
> at
> org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.removeItself(ServerConsumerImpl.java:500)
> [artemis-server-1.2.0.amq-77-redhat-1.jar:1.2.0.amq-77-redhat-1]
> at
> org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.close(ServerConsumerImpl.java:446)
> [artemis-server-1.2.0.amq-77-redhat-1.jar:1.2.0.amq-77-redhat-1]
> at
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.doClose(ServerSessionImpl.java:345)
> [artemis-server-1.2.0.amq-77-redhat-1.jar:1.2.0.amq-77-redhat-1]
> at
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$1.done(ServerSessionImpl.java:1160)
> [artemis-server-1.2.0.amq-77-redhat-1.jar:1.2.0.amq-77-redhat-1]
> at
> org.apache.activemq.artemis.core.persistence.impl.journal.OperationContextImpl.executeOnCompletion(OperationContextImpl.java:168)
> [artemis-server-1.2.0.amq-77-redhat-1.jar:1.2.0.amq-77-redhat-1]
> at
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.close(ServerSessionImpl.java:1152)
> [artemis-server-1.2.0.amq-77-redhat-1.jar:1.2.0.amq-77-redhat-1]
> at
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.freezeConnections(ActiveMQServerImpl.java:926)
> [artemis-server-1.2.0.amq-77-redhat-1.jar:1.2.0.amq-77-redhat-1]
> at
>
[jira] [Updated] (DISPATCH-402) Remove deprecated hyphen-separated config and entity names
[ https://issues.apache.org/jira/browse/DISPATCH-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-402: -- Fix Version/s: (was: 0.6.1) 0.7.0 > Remove deprecated hyphen-separated config and entity names > -- > > Key: DISPATCH-402 > URL: https://issues.apache.org/jira/browse/DISPATCH-402 > Project: Qpid Dispatch > Issue Type: Bug > Components: Documentation, Tests >Affects Versions: 0.6.0 >Reporter: Alan Conway >Assignee: Alan Conway > Fix For: 0.7.0 > > > Remove all uses of hyphenated config names from documentation and tests. -- 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-386) Router crashes in qd_link_pn
[ https://issues.apache.org/jira/browse/DISPATCH-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15336497#comment-15336497 ] Ted Ross commented on DISPATCH-386: --- Thanks for the confirmation. > Router crashes in qd_link_pn > > > Key: DISPATCH-386 > URL: https://issues.apache.org/jira/browse/DISPATCH-386 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 > Environment: Debian 8.3, Apache Qpid Proton 0.13.0-RC for drivers and > dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD each on 3 separate > machines >Reporter: Eric Leu > Attachments: core.gz-1, core.gz-2, core.gz-3, trace > > > Network: A network of 3 interior routers built using the latest trunk and > connected to each other using 2-way SSL, same as in DISPATCH-383. > Run 3 pairs of senders and receivers on three different destination > addresses. Each sender has 60 threads. Each receiver has 60 threads. > Seg fault happened with either of of the two traces: > (1) > Program received signal SIGSEGV, Segmentation fault. > 0x77ab4ee0 in qd_link_pn () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > (gdb) bt > #0 0x77ab4ee0 in qd_link_pn () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #1 0x77ad70cc in ?? () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #2 0x77acc906 in qdr_connection_process () from > /usr/local/lib/qpid-dispatch/libqpid- > dispatch.so > #3 0x77ab3b28 in ?? () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #4 0x77adad55 in ?? () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #5 0x77adb272 in qd_server_run () from > /usr/local/lib/qpid-dispatch/libqpid- > dispatch.so > #6 0x00401a47 in _start () > (2) > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x70d1f700 (LWP 27862)] > 0x77ab4ee0 in qd_link_pn () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > (gdb) bt > #0 0x77ab4ee0 in qd_link_pn () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #1 0x77ad71b3 in ?? () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #2 0x77acc988 in qdr_connection_process () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #3 0x77ab3b28 in ?? () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #4 0x77adad55 in ?? () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #5 0x775d10a4 in start_thread (arg=0x70d1f700) at > pthread_create.c:309 > #6 0x7697587d in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 -- 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-397) Error creating a new connector on a router with same name but on another router
[
https://issues.apache.org/jira/browse/DISPATCH-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15335926#comment-15335926
]
Ted Ross commented on DISPATCH-397:
---
In case it's not obvious from the description, the create request was evidently
directed to router A instead of router B.
> Error creating a new connector on a router with same name but on another
> router
> ---
>
> Key: DISPATCH-397
> URL: https://issues.apache.org/jira/browse/DISPATCH-397
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Console
>Affects Versions: 0.6.0
>Reporter: Paolo Patierno
> Attachments: Selection_015.png
>
>
> I have a network with three routers A, B and C.
> A is connected to B and a broker with a connector named "BROKER".
> B is connected to C.
> Using the Entities page and selecting router B, I can see the only connector
> from B to C named "INTER_ROUTER.
> If I try to create a new connector for the router B in order to connect it to
> the broker as well using the name "BROKER" for the connector, I receive the
> following error : Duplicate value 'BROKER' for unique attribute 'name'.
> It's true if I create a connector for router A which already has a connector
> with this name, but not true for router B.
> Attached the screenshot of the error.
> At same time the error on the console on the router A is the following :
> Fri Jun 17 09:54:13 2016 AGENT (error) Error dispatching
> Message(address='_topo/0/Router.A/$management', properties={'operation':
> 'CREATE', 'type': 'org.apache.qpid.dispatch.connector', 'name': 'BROKER'},
> body={'role': 'normal', 'type': 'org.apache.qpid.dispatch.connector', 'name':
> 'BROKER', 'port': '5672'},
> reply_to='amqp:/_topo/0/Router.A/temp.3lKIzN7YrrNNvms',
> correlation_id='6363'): org.apache.qpid.dispatch.connector: Duplicate value
> 'BROKER' for unique attribute 'name'
> Traceback (most recent call last):
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 790, in receive
> status, body = self.handle(request)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 813, in handle
> return self.create(request)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 854, in create
> return (CREATED, self._create(attributes).attributes)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 829, in _create
> self.entities.add_implementation(cimplementation, entity)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 538, in add_implementation
> self._add_implementation(implementation, adapter=adapter)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 535, in _add_implementation
> self.add(adapter)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 524, in add
> self.schema.validate_full(chain(iter([entity]), iter(self.entities)))
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/qdrouter.py",
> line 59, in validate_full
> super(QdSchema, self).validate_all(entities, **kwargs)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 597, in validate_all
> check_singleton=check_singleton)
> File
> "/usr/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 574, in validate_entity
> check_singleton=check_singleton)
> File "/
--
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-386) Router crashes in qd_link_pn
[ https://issues.apache.org/jira/browse/DISPATCH-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross closed DISPATCH-386. - Resolution: Duplicate > Router crashes in qd_link_pn > > > Key: DISPATCH-386 > URL: https://issues.apache.org/jira/browse/DISPATCH-386 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 > Environment: Debian 8.3, Apache Qpid Proton 0.13.0-RC for drivers and > dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD each on 3 separate > machines >Reporter: Eric Leu > Attachments: core.gz-1, core.gz-2, core.gz-3, trace > > > Network: A network of 3 interior routers built using the latest trunk and > connected to each other using 2-way SSL, same as in DISPATCH-383. > Run 3 pairs of senders and receivers on three different destination > addresses. Each sender has 60 threads. Each receiver has 60 threads. > Seg fault happened with either of of the two traces: > (1) > Program received signal SIGSEGV, Segmentation fault. > 0x77ab4ee0 in qd_link_pn () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > (gdb) bt > #0 0x77ab4ee0 in qd_link_pn () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #1 0x77ad70cc in ?? () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #2 0x77acc906 in qdr_connection_process () from > /usr/local/lib/qpid-dispatch/libqpid- > dispatch.so > #3 0x77ab3b28 in ?? () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #4 0x77adad55 in ?? () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #5 0x77adb272 in qd_server_run () from > /usr/local/lib/qpid-dispatch/libqpid- > dispatch.so > #6 0x00401a47 in _start () > (2) > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x70d1f700 (LWP 27862)] > 0x77ab4ee0 in qd_link_pn () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > (gdb) bt > #0 0x77ab4ee0 in qd_link_pn () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #1 0x77ad71b3 in ?? () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #2 0x77acc988 in qdr_connection_process () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #3 0x77ab3b28 in ?? () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #4 0x77adad55 in ?? () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #5 0x775d10a4 in start_thread (arg=0x70d1f700) at > pthread_create.c:309 > #6 0x7697587d in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 -- 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-363) Autogenerated part of man page qdrouterd.conf and output of `qdmanage print-json-schema` leave out the `name:` attribute in annotation sections
[ https://issues.apache.org/jira/browse/DISPATCH-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15331819#comment-15331819 ] Ted Ross commented on DISPATCH-363: --- I think the following should be done with the autogenerated man page for the configuration: - Remove all mention of annotation sections - Treat sslProfile as a first-class entity - Include "name" in the sslProfile description (it is mandatory) - Remove the attributes from sslProfile that appear in listener and connector - Add sslProfile as an attribute of listener and connector > Autogenerated part of man page qdrouterd.conf and output of `qdmanage > print-json-schema` leave out the `name:` attribute in annotation sections > --- > > Key: DISPATCH-363 > URL: https://issues.apache.org/jira/browse/DISPATCH-363 > Project: Qpid Dispatch > Issue Type: Bug > Components: Documentation >Affects Versions: 0.6.0 >Reporter: Jiri Danek > > (Hat tip to [~enkeys]) > The man page at > https://qpid.apache.org/releases/qpid-dispatch-master/man/qdrouterd.conf.html > describes a `name:` attribute in the handwritten opening paragraphs. It is > not mentioned later in the auto-generated list of attributes of any of the > annotation sections. Neither is the `name` attribute present in the JSON > schema from qdmanage. This attribute should be documented. > In case of `sslProfile` annotation section, attribute `sslProfileName` is > mentioned in the qdmanage output (but not in in the man page). This attribute > is for internal use only and should be documented as such in the JSON. -- 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-361) Annotation section `addrPort` should be deprecated and replaced with `hostPort` section
[ https://issues.apache.org/jira/browse/DISPATCH-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15331806#comment-15331806 ] Ted Ross commented on DISPATCH-361: --- I've lowered the priority of this issue. What really needs to be done is to remove this annotation from the configuration man page. > Annotation section `addrPort` should be deprecated and replaced with > `hostPort` section > --- > > Key: DISPATCH-361 > URL: https://issues.apache.org/jira/browse/DISPATCH-361 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.6.0 >Reporter: Jiri Danek >Assignee: Ganesh Murthy >Priority: Trivial > > https://qpid.apache.org/releases/qpid-dispatch-master/man/qdrouterd.conf.html' > Current: > Manual page qdrouterd.conf describes an `addrPort` section that contains > `addr` (deprecated) and `host` attributes. > Expected: > `addrPort` section should be deprecated and new section should be called > `hostPort`, to be in keeping with changes introduced in DISPATCH-306. > Deprecated section `addrPort` should contain only an `addr` deprecated > attribute and new section `hostPort` should contain only a `host` attribute. -- 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-361) Annotation section `addrPort` should be deprecated and replaced with `hostPort` section
[ https://issues.apache.org/jira/browse/DISPATCH-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-361: -- Priority: Trivial (was: Major) > Annotation section `addrPort` should be deprecated and replaced with > `hostPort` section > --- > > Key: DISPATCH-361 > URL: https://issues.apache.org/jira/browse/DISPATCH-361 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.6.0 >Reporter: Jiri Danek >Assignee: Ganesh Murthy >Priority: Trivial > > https://qpid.apache.org/releases/qpid-dispatch-master/man/qdrouterd.conf.html' > Current: > Manual page qdrouterd.conf describes an `addrPort` section that contains > `addr` (deprecated) and `host` attributes. > Expected: > `addrPort` section should be deprecated and new section should be called > `hostPort`, to be in keeping with changes introduced in DISPATCH-306. > Deprecated section `addrPort` should contain only an `addr` deprecated > attribute and new section `hostPort` should contain only a `host` attribute. -- 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-184) dispatch do not stop when 'amqp' is not defined
[ https://issues.apache.org/jira/browse/DISPATCH-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross closed DISPATCH-184. - Resolution: Not A Bug I'm closing this issue as not-a-bug. If there's no amqp entry in the /etc/services file, then the router is doing the right thing by raising a log message and not opening the listener. This is the same behavior that would occur if the port were specified as any other unknown protocol name. > dispatch do not stop when 'amqp' is not defined > --- > > Key: DISPATCH-184 > URL: https://issues.apache.org/jira/browse/DISPATCH-184 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container > Environment: Gentoo linux, Linux falka 4.2.3-gentoo #1 SMP Thu Oct 8 > 10:08:43 CEST 2015 x86_64 Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz > GenuineIntel GNU/Linux > proton-c (latest from apache github a16c58a59c2a5504ecd556dd397b7d28cc68dbd4) > dispatch (latest from apache github 8353ac674a7150a1bbfa63c912ad9689a492e84a) > sys-devel/gcc-4.9.3 > dev-lang/python-2.7.10 >Reporter: Zdenek Kraus >Priority: Minor > Attachments: python_qdstat-g_fc23.stacktrace > > > If there is no existent record of 'amqp' protocol being 5672/tcp in > /etc/services, dispatch logs error messages and continue on. > steps: > 1. make sure that record 'amqp 5672/tcp' is not present at /etc/services > 2. run qpid dispatch > current results: > Wed Oct 21 16:11:35 2015 DRIVER (error) getaddrinfo(0.0.0.0, amqp): Servname > not supported for ai_socktype > and continue. > expected: > error message and should stop with error. > note: this could be added into documentation -- 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-386) Router crashes in qd_link_pn
[ https://issues.apache.org/jira/browse/DISPATCH-386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15331630#comment-15331630 ] Ted Ross commented on DISPATCH-386: --- I believe that this is a duplicate of DISPATCH-387. Can you please re-test against the 0.6.x branch which has the fix for DISPATCH-387? > Router crashes in qd_link_pn > > > Key: DISPATCH-386 > URL: https://issues.apache.org/jira/browse/DISPATCH-386 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 > Environment: Debian 8.3, Apache Qpid Proton 0.13.0-RC for drivers and > dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD each on 3 separate > machines >Reporter: Eric Leu > Attachments: core.gz-1, core.gz-2, core.gz-3, trace > > > Network: A network of 3 interior routers built using the latest trunk and > connected to each other using 2-way SSL, same as in DISPATCH-383. > Run 3 pairs of senders and receivers on three different destination > addresses. Each sender has 60 threads. Each receiver has 60 threads. > Seg fault happened with either of of the two traces: > (1) > Program received signal SIGSEGV, Segmentation fault. > 0x77ab4ee0 in qd_link_pn () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > (gdb) bt > #0 0x77ab4ee0 in qd_link_pn () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #1 0x77ad70cc in ?? () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #2 0x77acc906 in qdr_connection_process () from > /usr/local/lib/qpid-dispatch/libqpid- > dispatch.so > #3 0x77ab3b28 in ?? () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #4 0x77adad55 in ?? () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #5 0x77adb272 in qd_server_run () from > /usr/local/lib/qpid-dispatch/libqpid- > dispatch.so > #6 0x00401a47 in _start () > (2) > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x70d1f700 (LWP 27862)] > 0x77ab4ee0 in qd_link_pn () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > (gdb) bt > #0 0x77ab4ee0 in qd_link_pn () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #1 0x77ad71b3 in ?? () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #2 0x77acc988 in qdr_connection_process () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #3 0x77ab3b28 in ?? () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #4 0x77adad55 in ?? () from > /usr/local/lib/qpid-dispatch/libqpid-dispatch.so > #5 0x775d10a4 in start_thread (arg=0x70d1f700) at > pthread_create.c:309 > #6 0x7697587d in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 -- 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-378) Seg Fault in CORE_link_push
[
https://issues.apache.org/jira/browse/DISPATCH-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross closed DISPATCH-378.
-
Resolution: Fixed
> Seg Fault in CORE_link_push
> ---
>
> Key: DISPATCH-378
> URL: https://issues.apache.org/jira/browse/DISPATCH-378
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 0.6.1
> Environment: Latest master branch of dispatch, fedora 23
>Reporter: Gordon Sim
>Assignee: Ted Ross
>
> Doing some perf testing with a very simple two router setup, one router
> connecting to the other. Hit this once only so far (i.e. not readily
> reproducible) wasn't doing anything noticeably different at the time.
> {noformat}
> Core was generated by `./sbin/qdrouterd --conf
> ./etc/qpid-dispatch/router2.conf'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 qd_link_pn (link=0x0) at
> /home/gordon/projects/dispatch/src/container.c:862
> 862 return link->pn_link;
> [Current thread is 1 (Thread 0x7f07c4f53700 (LWP 27600))]
> Missing separate debuginfos, use: dnf debuginfo-install
> cyrus-sasl-gssapi-2.1.26-25.2.fc23.x86_64
> cyrus-sasl-lib-2.1.26-25.2.fc23.x86_64 cyrus-sasl-md5-2.1.26-25.2.fc23.x86_64
> cyrus-sasl-plain-2.1.26-25.2.fc23.x86_64
> cyrus-sasl-scram-2.1.26-25.2.fc23.x86_64 glibc-2.22-11.fc23.x86_64
> keyutils-libs-1.5.9-7.fc23.x86_64 krb5-libs-1.14.1-3.fc23.x86_64
> libcom_err-1.42.13-3.fc23.x86_64 libdb-5.3.28-13.fc23.x86_64
> libffi-3.1-8.fc23.x86_64 libselinux-2.4-4.fc23.x86_64
> nss-softokn-freebl-3.23.0-1.0.fc23.x86_64 openssl-libs-1.0.2g-2.fc23.x86_64
> pcre-8.38-7.fc23.x86_64 python-libs-2.7.10-8.fc23.x86_64
> sssd-client-1.13.3-5.fc23.x86_64 zlib-1.2.8-9.fc23.x86_64
> (gdb) bt
> #0 qd_link_pn (link=0x0) at
> /home/gordon/projects/dispatch/src/container.c:862
> #1 0x7f07d429b0fc in CORE_link_push (context=0xf11550,
> link=0x7f07bc035a70) at /home/gordon/projects/dispatch/src/router_node.c:808
> #2 0x7f07d429159e in qdr_connection_process (conn=0x7f07b80c3070) at
> /home/gordon/projects/dispatch/src/router_core/connections.c:175
> #3 0x7f07d427f728 in writable_handler (container=0xe3db70,
> container=0xe3db70, conn=, qd_conn=0x7f07bc02ea10) at
> /home/gordon/projects/dispatch/src/container.c:353
> #4 handler (handler_context=0xe3db70, conn_context=,
> event=, qd_conn=0x7f07bc02ea10) at
> /home/gordon/projects/dispatch/src/container.c:590
> #5 0x7f07d429ed85 in process_connector (cxtr=0x7f07bc021b40,
> qd_server=0xdd33f0) at /home/gordon/projects/dispatch/src/server.c:804
> #6 thread_run (arg=) at
> /home/gordon/projects/dispatch/src/server.c:1024
> #7 0x7f07d3dff60a in start_thread () from /lib64/libpthread.so.0
> #8 0x7f07d3364a4d in clone () from /lib64/libc.so.6
> (gdb) info threads
> Id Target Id Frame
> 5Thread 0x7f07d46b0180 (LWP 27596) 0x7f07d3e04b10 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> 4Thread 0x7f07c5f55700 (LWP 27598) 0x7f07d3e04b10 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> 3Thread 0x7f07c5754700 (LWP 27599) 0x7f07d3358fdd in poll () from
> /lib64/libc.so.6
> 2Thread 0x7f07c6968700 (LWP 27597) 0x7f07d3e04b10 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> * 1Thread 0x7f07c4f53700 (LWP 27600) qd_link_pn (link=0x0) at
> /home/gordon/projects/dispatch/src/container.c:862
> (gdb) thread 2
> [Switching to thread 2 (Thread 0x7f07c6968700 (LWP 27597))]
> #0 0x7f07d3e04b10 in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
> (gdb) bt
> #0 0x7f07d3e04b10 in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
> #1 0x7f07d428afaf in sys_cond_wait (cond=,
> held_mutex=0xf169a0) at
> /home/gordon/projects/dispatch/src/posix/threading.c:107
> #2 0x7f07d42962fd in router_core_thread (arg=0xf16670) at
> /home/gordon/projects/dispatch/src/router_core/router_core_thread.c:54
> #3 0x7f07d3dff60a in start_thread () from /lib64/libpthread.so.0
> #4 0x7f07d3364a4d in clone () from /lib64/libc.so.6
> (gdb) thread 3
> [Switching to thread 3 (Thread 0x7f07c5754700 (LWP 27599))]
> #0 0x7f07d3358fdd in poll () from /lib64/libc.so.6
> (gdb) bt
> #0 0x7f07d3358fdd in poll () from /lib64/libc.so.6
> #1 0x7f07d428aa00 in qdpn_driver_wait_2 (d=0xe468c0, timeout= out>, timeout@entry=64) at
> /home/gordon/projects/dispatch/src/posix/driver.c:964
> #2 0x7f07d429e609 in thread_run (arg=) at
> /home/gordon/projects/dispatch/src/server.c:932
> #3 0x7f07d3dff60a in start_thread () from /lib64/libpthread.so.0
> #4 0x7f07d3364a4d in clone () from /lib64/libc.so.6
> (gdb) thread 4
> [Switching to thread 4 (Thread 0x7f07c5f55700 (LWP 27598))]
> #0 0x7f07d3e04b10 in pthread_cond_wait@@GLIBC_2.3.2 ()
[jira] [Resolved] (DISPATCH-387) Router core dumps with misbehaving client
[ https://issues.apache.org/jira/browse/DISPATCH-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-387. --- Resolution: Fixed The code in router_node.c made an incorrect assumption that core links are always paired with qd-links during calls from the core. This is usually true but there's a case with lost links (when a session with active links is closed) where this is not true. > Router core dumps with misbehaving client > - > > Key: DISPATCH-387 > URL: https://issues.apache.org/jira/browse/DISPATCH-387 > Project: Qpid Dispatch > Issue Type: Bug >Reporter: Ulf Lilleengen >Assignee: Ted Ross > Fix For: 0.6.1 > > Attachments: simple_direct.conf > > > I have a simple setup with a router, a sender and a receiver. > The receiver is qpid-receiver from qpid-cpp-client-devel. The sender is a > modified version of https://github.com/orpiske/msg-perf-tool, and I've pushed > my modifications that made the router crash here: > https://github.com/lulf/msg-perf-tool/tree/lulf/dispatch-crash-sender > Using router built from master. > Invoking the receiver: qpid-receive --broker 127.0.0.1:5674 --address > amqp-test --ack-frequency 1 --messages 1 --report-total -f > --print-content false > Invoking the sender: ./bin/mpt-sender -b amqp://127.0.0.1:5674/amqp-test -p 1 > -d 1 -s 128 > The client might not behaving appropriately, so its entirely possible that I > don't know what I'm doing! But I was thinking that the router should probably > not crash due to misbehaving clients anyway. The core dump can be found here: > http://lulf.no/stuff/qdrouterd_dispatch_387.core > (gdb) where > #0 qd_link_pn (link=0x0) at /home/lulf/git/qpid-dispatch/src/container.c:862 > #1 0x7fbf4fc34e0c in CORE_link_push (context=0x1c5e3c0, link=0x1c84b80) > at /home/lulf/git/qpid-dispatch/src/router_node.c:808 > #2 0x7fbf4fc2b27e in qdr_connection_process (conn=0x7fbf380194a0) > at /home/lulf/git/qpid-dispatch/src/router_core/connections.c:175 > #3 0x7fbf4fc19528 in writable_handler (container=0x1b7b510, > container=0x1b7b510, conn=, > qd_conn=0x7fbf3800e4f0) at > /home/lulf/git/qpid-dispatch/src/container.c:353 > #4 handler (handler_context=0x1b7b510, conn_context=, > event=, qd_conn=0x7fbf3800e4f0) > at /home/lulf/git/qpid-dispatch/src/container.c:590 > #5 0x7fbf4fc389c5 in process_connector (cxtr=0x7fbf38000950, > qd_server=0x1c17ef0) > at /home/lulf/git/qpid-dispatch/src/server.c:744 > #6 thread_run (arg=) at > /home/lulf/git/qpid-dispatch/src/server.c:964 > #7 0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0 > #8 0x7fbf4ecf859d in clone () from /lib64/libc.so.6 > (gdb) thread apply all bt > Thread 5 (Thread 0x7fbf41fc1700 (LWP 13316)): > #0 0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x7fbf4fc24c8f in sys_cond_wait (cond=, > held_mutex=0x1b939c0) > at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107 > #2 0x7fbf4fc38764 in thread_run (arg=) at > /home/lulf/git/qpid-dispatch/src/server.c:846 > #3 0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0 > #4 0x7fbf4ecf859d in clone () from /lib64/libc.so.6 > Thread 4 (Thread 0x7fbf50041180 (LWP 13314)): > #0 0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x7fbf4fc24c8f in sys_cond_wait (cond=, > held_mutex=0x1b939c0) > at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107 > #2 0x7fbf4fc38764 in thread_run (arg=) at > /home/lulf/git/qpid-dispatch/src/server.c:846 > #3 0x7fbf4fc38eb0 in qd_server_run (qd=0x1944030) at > /home/lulf/git/qpid-dispatch/src/server.c:1371 > #4 0x00401aa7 in main_process ( > config_path=config_path@entry=0x7fffe5d8fdf0 > "../../qpid-examples/simple_direct.conf", > python_pkgdir=python_pkgdir@entry=0x402420 > "../../qpid-install/lib/qpid-dispatch/python", fd=fd@entry=2) > at /home/lulf/git/qpid-dispatch/router/src/main.c:145 > #5 0x00401797 in main (argc=3, argv=0x7fffe5d8f348) at > /home/lulf/git/qpid-dispatch/router/src/main.c:345 > Thread 3 (Thread 0x7fbf429d4700 (LWP 13315)): > #0 0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x7fbf4fc24c8f in sys_cond_wait (cond=, > held_mutex=0x1c637c0) > at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107 > #2 0x7fbf4fc2ffdd in router_core_thread (arg=0x1c63490) > at /home/lulf/git/qpid-dispatch/src/router_core/router_core_thread.c:54 > #3 0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0 > #4 0x7fbf4ecf859d in clone () from /lib64/libc.so.6 > Thread 2 (Thread 0x7fbf417c0700 (LWP 13317)): > #0 0x7fbf4ececb1d in poll () from
[jira] [Updated] (DISPATCH-387) Router core dumps with misbehaving client
[ https://issues.apache.org/jira/browse/DISPATCH-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-387: -- Fix Version/s: 0.6.1 > Router core dumps with misbehaving client > - > > Key: DISPATCH-387 > URL: https://issues.apache.org/jira/browse/DISPATCH-387 > Project: Qpid Dispatch > Issue Type: Bug >Reporter: Ulf Lilleengen >Assignee: Ted Ross > Fix For: 0.6.1 > > Attachments: simple_direct.conf > > > I have a simple setup with a router, a sender and a receiver. > The receiver is qpid-receiver from qpid-cpp-client-devel. The sender is a > modified version of https://github.com/orpiske/msg-perf-tool, and I've pushed > my modifications that made the router crash here: > https://github.com/lulf/msg-perf-tool/tree/lulf/dispatch-crash-sender > Using router built from master. > Invoking the receiver: qpid-receive --broker 127.0.0.1:5674 --address > amqp-test --ack-frequency 1 --messages 1 --report-total -f > --print-content false > Invoking the sender: ./bin/mpt-sender -b amqp://127.0.0.1:5674/amqp-test -p 1 > -d 1 -s 128 > The client might not behaving appropriately, so its entirely possible that I > don't know what I'm doing! But I was thinking that the router should probably > not crash due to misbehaving clients anyway. The core dump can be found here: > http://lulf.no/stuff/qdrouterd_dispatch_387.core > (gdb) where > #0 qd_link_pn (link=0x0) at /home/lulf/git/qpid-dispatch/src/container.c:862 > #1 0x7fbf4fc34e0c in CORE_link_push (context=0x1c5e3c0, link=0x1c84b80) > at /home/lulf/git/qpid-dispatch/src/router_node.c:808 > #2 0x7fbf4fc2b27e in qdr_connection_process (conn=0x7fbf380194a0) > at /home/lulf/git/qpid-dispatch/src/router_core/connections.c:175 > #3 0x7fbf4fc19528 in writable_handler (container=0x1b7b510, > container=0x1b7b510, conn=, > qd_conn=0x7fbf3800e4f0) at > /home/lulf/git/qpid-dispatch/src/container.c:353 > #4 handler (handler_context=0x1b7b510, conn_context=, > event=, qd_conn=0x7fbf3800e4f0) > at /home/lulf/git/qpid-dispatch/src/container.c:590 > #5 0x7fbf4fc389c5 in process_connector (cxtr=0x7fbf38000950, > qd_server=0x1c17ef0) > at /home/lulf/git/qpid-dispatch/src/server.c:744 > #6 thread_run (arg=) at > /home/lulf/git/qpid-dispatch/src/server.c:964 > #7 0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0 > #8 0x7fbf4ecf859d in clone () from /lib64/libc.so.6 > (gdb) thread apply all bt > Thread 5 (Thread 0x7fbf41fc1700 (LWP 13316)): > #0 0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x7fbf4fc24c8f in sys_cond_wait (cond=, > held_mutex=0x1b939c0) > at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107 > #2 0x7fbf4fc38764 in thread_run (arg=) at > /home/lulf/git/qpid-dispatch/src/server.c:846 > #3 0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0 > #4 0x7fbf4ecf859d in clone () from /lib64/libc.so.6 > Thread 4 (Thread 0x7fbf50041180 (LWP 13314)): > #0 0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x7fbf4fc24c8f in sys_cond_wait (cond=, > held_mutex=0x1b939c0) > at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107 > #2 0x7fbf4fc38764 in thread_run (arg=) at > /home/lulf/git/qpid-dispatch/src/server.c:846 > #3 0x7fbf4fc38eb0 in qd_server_run (qd=0x1944030) at > /home/lulf/git/qpid-dispatch/src/server.c:1371 > #4 0x00401aa7 in main_process ( > config_path=config_path@entry=0x7fffe5d8fdf0 > "../../qpid-examples/simple_direct.conf", > python_pkgdir=python_pkgdir@entry=0x402420 > "../../qpid-install/lib/qpid-dispatch/python", fd=fd@entry=2) > at /home/lulf/git/qpid-dispatch/router/src/main.c:145 > #5 0x00401797 in main (argc=3, argv=0x7fffe5d8f348) at > /home/lulf/git/qpid-dispatch/router/src/main.c:345 > Thread 3 (Thread 0x7fbf429d4700 (LWP 13315)): > #0 0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x7fbf4fc24c8f in sys_cond_wait (cond=, > held_mutex=0x1c637c0) > at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107 > #2 0x7fbf4fc2ffdd in router_core_thread (arg=0x1c63490) > at /home/lulf/git/qpid-dispatch/src/router_core/router_core_thread.c:54 > #3 0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0 > #4 0x7fbf4ecf859d in clone () from /lib64/libc.so.6 > Thread 2 (Thread 0x7fbf417c0700 (LWP 13317)): > #0 0x7fbf4ececb1d in poll () from /lib64/libc.so.6 > #1 0x7fbf4fc246e0 in qdpn_driver_wait_2 (d=0x1b2e270, timeout= out>, timeout@entry=397) > at /home/lulf/git/qpid-dispatch/src/posix/driver.c:964 > #2 0x7fbf4fc38249 in thread_run (arg=) at >
[jira] [Assigned] (DISPATCH-387) Router core dumps with misbehaving client
[ https://issues.apache.org/jira/browse/DISPATCH-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reassigned DISPATCH-387: - Assignee: Ted Ross > Router core dumps with misbehaving client > - > > Key: DISPATCH-387 > URL: https://issues.apache.org/jira/browse/DISPATCH-387 > Project: Qpid Dispatch > Issue Type: Bug >Reporter: Ulf Lilleengen >Assignee: Ted Ross > Attachments: simple_direct.conf > > > I have a simple setup with a router, a sender and a receiver. > The receiver is qpid-receiver from qpid-cpp-client-devel. The sender is a > modified version of https://github.com/orpiske/msg-perf-tool, and I've pushed > my modifications that made the router crash here: > https://github.com/lulf/msg-perf-tool/tree/lulf/dispatch-crash-sender > Using router built from master. > Invoking the receiver: qpid-receive --broker 127.0.0.1:5674 --address > amqp-test --ack-frequency 1 --messages 1 --report-total -f > --print-content false > Invoking the sender: ./bin/mpt-sender -b amqp://127.0.0.1:5674/amqp-test -p 1 > -d 1 -s 128 > The client might not behaving appropriately, so its entirely possible that I > don't know what I'm doing! But I was thinking that the router should probably > not crash due to misbehaving clients anyway. The core dump can be found here: > http://lulf.no/stuff/qdrouterd_dispatch_387.core > (gdb) where > #0 qd_link_pn (link=0x0) at /home/lulf/git/qpid-dispatch/src/container.c:862 > #1 0x7fbf4fc34e0c in CORE_link_push (context=0x1c5e3c0, link=0x1c84b80) > at /home/lulf/git/qpid-dispatch/src/router_node.c:808 > #2 0x7fbf4fc2b27e in qdr_connection_process (conn=0x7fbf380194a0) > at /home/lulf/git/qpid-dispatch/src/router_core/connections.c:175 > #3 0x7fbf4fc19528 in writable_handler (container=0x1b7b510, > container=0x1b7b510, conn=, > qd_conn=0x7fbf3800e4f0) at > /home/lulf/git/qpid-dispatch/src/container.c:353 > #4 handler (handler_context=0x1b7b510, conn_context=, > event=, qd_conn=0x7fbf3800e4f0) > at /home/lulf/git/qpid-dispatch/src/container.c:590 > #5 0x7fbf4fc389c5 in process_connector (cxtr=0x7fbf38000950, > qd_server=0x1c17ef0) > at /home/lulf/git/qpid-dispatch/src/server.c:744 > #6 thread_run (arg=) at > /home/lulf/git/qpid-dispatch/src/server.c:964 > #7 0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0 > #8 0x7fbf4ecf859d in clone () from /lib64/libc.so.6 > (gdb) thread apply all bt > Thread 5 (Thread 0x7fbf41fc1700 (LWP 13316)): > #0 0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x7fbf4fc24c8f in sys_cond_wait (cond=, > held_mutex=0x1b939c0) > at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107 > #2 0x7fbf4fc38764 in thread_run (arg=) at > /home/lulf/git/qpid-dispatch/src/server.c:846 > #3 0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0 > #4 0x7fbf4ecf859d in clone () from /lib64/libc.so.6 > Thread 4 (Thread 0x7fbf50041180 (LWP 13314)): > #0 0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x7fbf4fc24c8f in sys_cond_wait (cond=, > held_mutex=0x1b939c0) > at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107 > #2 0x7fbf4fc38764 in thread_run (arg=) at > /home/lulf/git/qpid-dispatch/src/server.c:846 > #3 0x7fbf4fc38eb0 in qd_server_run (qd=0x1944030) at > /home/lulf/git/qpid-dispatch/src/server.c:1371 > #4 0x00401aa7 in main_process ( > config_path=config_path@entry=0x7fffe5d8fdf0 > "../../qpid-examples/simple_direct.conf", > python_pkgdir=python_pkgdir@entry=0x402420 > "../../qpid-install/lib/qpid-dispatch/python", fd=fd@entry=2) > at /home/lulf/git/qpid-dispatch/router/src/main.c:145 > #5 0x00401797 in main (argc=3, argv=0x7fffe5d8f348) at > /home/lulf/git/qpid-dispatch/router/src/main.c:345 > Thread 3 (Thread 0x7fbf429d4700 (LWP 13315)): > #0 0x7fbf4f79eb20 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x7fbf4fc24c8f in sys_cond_wait (cond=, > held_mutex=0x1c637c0) > at /home/lulf/git/qpid-dispatch/src/posix/threading.c:107 > #2 0x7fbf4fc2ffdd in router_core_thread (arg=0x1c63490) > at /home/lulf/git/qpid-dispatch/src/router_core/router_core_thread.c:54 > #3 0x7fbf4f79961a in start_thread () from /lib64/libpthread.so.0 > #4 0x7fbf4ecf859d in clone () from /lib64/libc.so.6 > Thread 2 (Thread 0x7fbf417c0700 (LWP 13317)): > #0 0x7fbf4ececb1d in poll () from /lib64/libc.so.6 > #1 0x7fbf4fc246e0 in qdpn_driver_wait_2 (d=0x1b2e270, timeout= out>, timeout@entry=397) > at /home/lulf/git/qpid-dispatch/src/posix/driver.c:964 > #2 0x7fbf4fc38249 in thread_run (arg=) at > /home/lulf/git/qpid-dispatch/src/server.c:872 > #3 0x7fbf4f79961a
[jira] [Updated] (DISPATCH-341) router did not respond to request to drain a message-routed consumers link credit
[
https://issues.apache.org/jira/browse/DISPATCH-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated DISPATCH-341:
--
Fix Version/s: (was: 0.7.0)
0.6.1
> router did not respond to request to drain a message-routed consumers link
> credit
> -
>
> Key: DISPATCH-341
> URL: https://issues.apache.org/jira/browse/DISPATCH-341
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 0.6.0
> Environment: Qpid Dispatch 0.6.0 RC3
> Qpid JMS 0.10.0-SNAPSHOT
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
> Fix For: 0.6.1
>
>
> With a router using the provided default config (updated only to set
> saslMechanisms to ANONYMOUS), and attaching a sender and receiver (using the
> JMS client Sender and Receiver examples) to the address "queue" (so
> presumably using messge routing), it could be seen that Dispatch didn't
> respond to requests to drain the receivers link.
> In one case, after receiving some messages, a 'drain requst' flow is issued,
> but neither enough messages to use the credit (expected since no more were
> sent) or a 'drain reponse' flow are received, just heartbeating back and
> forth.
> {noformat}
> [1925974223:1] -> Disposition{role=RECEIVER, first=8, last=8, settled=true,
> state=Accepted{}, batchable=false}
> [1925974223:1] -> Flow{nextIncomingId=9, incomingWindow=2047,
> nextOutgoingId=1, outgoingWindow=2147483647, handle=0, deliveryCount=9,
> linkCredit=991, available=null, drain=true, echo=false, properties=null}
> [1925974223:0] -> Empty Frame
> [1925974223:0] -> Empty Frame
> [1925974223:0] <- Empty Frame
> {noformat}
> In another case, after flowing some credit but not receiving any messages, a
> 'drain request' is issued, but neither enough messages to use the credit
> (expected since none were sent) or a 'drain reponse' flow are received, just
> heartbeating back and forth.
> {noformat}
> [2111953084:1] -> Flow{nextIncomingId=0, incomingWindow=2047,
> nextOutgoingId=1, outgoingWindow=2147483647, handle=0, deliveryCount=0,
> linkCredit=1000, available=null, drain=false, echo=false, properties=null}
> [2111953084:1] -> Flow{nextIncomingId=0, incomingWindow=2047,
> nextOutgoingId=1, outgoingWindow=2147483647, handle=0, deliveryCount=0,
> linkCredit=1000, available=null, drain=true, echo=false, properties=null}
> [2111953084:0] -> Empty Frame
> [2111953084:0] -> Empty Frame
> [2111953084:0] <- Empty Frame
> {noformat}
--
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-365) Standalone router crashes if an interior router attempts to connect to it
[ https://issues.apache.org/jira/browse/DISPATCH-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-365: -- Fix Version/s: (was: 0.6.0) 0.6.1 > Standalone router crashes if an interior router attempts to connect to it > - > > Key: DISPATCH-365 > URL: https://issues.apache.org/jira/browse/DISPATCH-365 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 0.6.0 > Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and > dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines >Reporter: Vishal Sharda >Assignee: Ted Ross >Priority: Critical > Fix For: 0.6.1 > > Attachments: config1_standalone.conf, config2_nossl.conf > > > I accidentally pointed my interior router to a standalone router. The > standalone router did not ignore the connection request and crashed. The > attached config files reproduce the 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] [Updated] (DISPATCH-364) Inter-router listeners should not permit normal endpoint traffic
[ https://issues.apache.org/jira/browse/DISPATCH-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-364: -- Fix Version/s: 0.6.1 > Inter-router listeners should not permit normal endpoint traffic > > > Key: DISPATCH-364 > URL: https://issues.apache.org/jira/browse/DISPATCH-364 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 0.6.0 >Reporter: Ted Ross >Assignee: Ted Ross > Fix For: 0.6.1 > > > A router network can be configured such that normal clients connect to the > network using listeners designated with the inter-router role. Since there > can be only a limited number of routers in a network (128 in 0.6.0), it > doesn't take many connected clients to clog up the inter-router connection > space. > The router node should be modified such that normal links attaching over > inter-router connections are forbidden. -- 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-380) Router stops receiving messages from multiple senders publishing to multiple queues in parallel
[ https://issues.apache.org/jira/browse/DISPATCH-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-380: -- Fix Version/s: (was: 0.6.0) > Router stops receiving messages from multiple senders publishing to multiple > queues in parallel > --- > > Key: DISPATCH-380 > URL: https://issues.apache.org/jira/browse/DISPATCH-380 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine > Environment: Debian 8.3, Apache Qpid Proton 0.13.0-RC for drivers and > dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD each on 3 separate > machines >Reporter: Vishal Sharda >Priority: Critical > Attachments: AWS_hung_at_round_figures.png, > AWS_hung_for_4_seconds.png, AWS_uneven_start.png, Senders_1.png, > Senders_2.png, Senders_3_10_Queues.png, Senders_4_10_queues.png, > Single_router_testing_results.pdf, qdstat_wrong_output.png > > > I am running a Java Client against a cluster of 3 interior routers connected > to each other. 2-way SSL is enabled for all the connections. > There were 20 simultaneous queues with 20 senders on each queue and each > sender publishing 1000 messages. All the senders were connected to Router 1. > 20 receivers were connected to Router 2 with 1 receiver receiving from each > queue. > In the first run, router stopped receiving incoming messages after delivering > 386,339 out of 400K "Hello World!" messages. > In the second run, 388,781 messages out of 400K were delivered. > I reduced the number of queues to 10 (halving total number of messages to > 200K) and the issue occurred again. > I ran the Java client on an 8 CPU machine again with 10 queues and the issue > occurred again after delivering just 54K out of 200K messages. > All the senders were hung (still connected) with no messages flowing at all. > Connection information from qdstat: > When the messages are flowing properly and I run "qdstat -c", I see all the > senders as secure and authenticated. > After they hang and I run "qdstat -c", it erroneously shows all the clients > as insecure and unauthenticated. > Shortly after the clients hang, all the queues are deleted from the router > network but connections are still shown until I terminate the clients. > I saw this erroneous situation before also when "qdstat -c" showed some > senders as secure and authentic but some as insecure/unauthentic. -- 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-256) Documentation Updates for 0.6
[ https://issues.apache.org/jira/browse/DISPATCH-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-256. --- Resolution: Fixed > Documentation Updates for 0.6 > - > > Key: DISPATCH-256 > URL: https://issues.apache.org/jira/browse/DISPATCH-256 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Documentation >Reporter: Ted Ross > Fix For: 0.6.0 > > -- 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-367) balanced distribution needs to be more... balanced.
[ https://issues.apache.org/jira/browse/DISPATCH-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-367: -- Fix Version/s: (was: 0.6.0) > balanced distribution needs to be more... balanced. > --- > > Key: DISPATCH-367 > URL: https://issues.apache.org/jira/browse/DISPATCH-367 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 0.6.0 >Reporter: Ken Giusti >Assignee: Ganesh Murthy > > When blocking sends are done to a balanced address with multiple consumers on > the same router all the messages go to one of the consumers. > I would expect that the messages would be evenly distributed across all > _locally_attached_ consumers. -- 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-378) Seg Fault in CORE_link_push
[
https://issues.apache.org/jira/browse/DISPATCH-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross reassigned DISPATCH-378:
-
Assignee: Ted Ross
> Seg Fault in CORE_link_push
> ---
>
> Key: DISPATCH-378
> URL: https://issues.apache.org/jira/browse/DISPATCH-378
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 0.6.1
> Environment: Latest master branch of dispatch, fedora 23
>Reporter: Gordon Sim
>Assignee: Ted Ross
>
> Doing some perf testing with a very simple two router setup, one router
> connecting to the other. Hit this once only so far (i.e. not readily
> reproducible) wasn't doing anything noticeably different at the time.
> {noformat}
> Core was generated by `./sbin/qdrouterd --conf
> ./etc/qpid-dispatch/router2.conf'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 qd_link_pn (link=0x0) at
> /home/gordon/projects/dispatch/src/container.c:862
> 862 return link->pn_link;
> [Current thread is 1 (Thread 0x7f07c4f53700 (LWP 27600))]
> Missing separate debuginfos, use: dnf debuginfo-install
> cyrus-sasl-gssapi-2.1.26-25.2.fc23.x86_64
> cyrus-sasl-lib-2.1.26-25.2.fc23.x86_64 cyrus-sasl-md5-2.1.26-25.2.fc23.x86_64
> cyrus-sasl-plain-2.1.26-25.2.fc23.x86_64
> cyrus-sasl-scram-2.1.26-25.2.fc23.x86_64 glibc-2.22-11.fc23.x86_64
> keyutils-libs-1.5.9-7.fc23.x86_64 krb5-libs-1.14.1-3.fc23.x86_64
> libcom_err-1.42.13-3.fc23.x86_64 libdb-5.3.28-13.fc23.x86_64
> libffi-3.1-8.fc23.x86_64 libselinux-2.4-4.fc23.x86_64
> nss-softokn-freebl-3.23.0-1.0.fc23.x86_64 openssl-libs-1.0.2g-2.fc23.x86_64
> pcre-8.38-7.fc23.x86_64 python-libs-2.7.10-8.fc23.x86_64
> sssd-client-1.13.3-5.fc23.x86_64 zlib-1.2.8-9.fc23.x86_64
> (gdb) bt
> #0 qd_link_pn (link=0x0) at
> /home/gordon/projects/dispatch/src/container.c:862
> #1 0x7f07d429b0fc in CORE_link_push (context=0xf11550,
> link=0x7f07bc035a70) at /home/gordon/projects/dispatch/src/router_node.c:808
> #2 0x7f07d429159e in qdr_connection_process (conn=0x7f07b80c3070) at
> /home/gordon/projects/dispatch/src/router_core/connections.c:175
> #3 0x7f07d427f728 in writable_handler (container=0xe3db70,
> container=0xe3db70, conn=, qd_conn=0x7f07bc02ea10) at
> /home/gordon/projects/dispatch/src/container.c:353
> #4 handler (handler_context=0xe3db70, conn_context=,
> event=, qd_conn=0x7f07bc02ea10) at
> /home/gordon/projects/dispatch/src/container.c:590
> #5 0x7f07d429ed85 in process_connector (cxtr=0x7f07bc021b40,
> qd_server=0xdd33f0) at /home/gordon/projects/dispatch/src/server.c:804
> #6 thread_run (arg=) at
> /home/gordon/projects/dispatch/src/server.c:1024
> #7 0x7f07d3dff60a in start_thread () from /lib64/libpthread.so.0
> #8 0x7f07d3364a4d in clone () from /lib64/libc.so.6
> (gdb) info threads
> Id Target Id Frame
> 5Thread 0x7f07d46b0180 (LWP 27596) 0x7f07d3e04b10 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> 4Thread 0x7f07c5f55700 (LWP 27598) 0x7f07d3e04b10 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> 3Thread 0x7f07c5754700 (LWP 27599) 0x7f07d3358fdd in poll () from
> /lib64/libc.so.6
> 2Thread 0x7f07c6968700 (LWP 27597) 0x7f07d3e04b10 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> * 1Thread 0x7f07c4f53700 (LWP 27600) qd_link_pn (link=0x0) at
> /home/gordon/projects/dispatch/src/container.c:862
> (gdb) thread 2
> [Switching to thread 2 (Thread 0x7f07c6968700 (LWP 27597))]
> #0 0x7f07d3e04b10 in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
> (gdb) bt
> #0 0x7f07d3e04b10 in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
> #1 0x7f07d428afaf in sys_cond_wait (cond=,
> held_mutex=0xf169a0) at
> /home/gordon/projects/dispatch/src/posix/threading.c:107
> #2 0x7f07d42962fd in router_core_thread (arg=0xf16670) at
> /home/gordon/projects/dispatch/src/router_core/router_core_thread.c:54
> #3 0x7f07d3dff60a in start_thread () from /lib64/libpthread.so.0
> #4 0x7f07d3364a4d in clone () from /lib64/libc.so.6
> (gdb) thread 3
> [Switching to thread 3 (Thread 0x7f07c5754700 (LWP 27599))]
> #0 0x7f07d3358fdd in poll () from /lib64/libc.so.6
> (gdb) bt
> #0 0x7f07d3358fdd in poll () from /lib64/libc.so.6
> #1 0x7f07d428aa00 in qdpn_driver_wait_2 (d=0xe468c0, timeout= out>, timeout@entry=64) at
> /home/gordon/projects/dispatch/src/posix/driver.c:964
> #2 0x7f07d429e609 in thread_run (arg=) at
> /home/gordon/projects/dispatch/src/server.c:932
> #3 0x7f07d3dff60a in start_thread () from /lib64/libpthread.so.0
> #4 0x7f07d3364a4d in clone () from /lib64/libc.so.6
> (gdb) thread 4
> [Switching to thread 4 (Thread 0x7f07c5f55700 (LWP 27598))]
> #0 0x7f07d3e04b10 in
[jira] [Resolved] (DISPATCH-366) When delivery fails the router sends the RELEASED disposition, not MODIFIED
[ https://issues.apache.org/jira/browse/DISPATCH-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-366. --- Resolution: Fixed > When delivery fails the router sends the RELEASED disposition, not MODIFIED > --- > > Key: DISPATCH-366 > URL: https://issues.apache.org/jira/browse/DISPATCH-366 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 0.6.0 >Reporter: Ken Giusti >Assignee: Ted Ross >Priority: Blocker > Fix For: 0.7.0, 0.6.1 > > > The router does not properly distinguish between a delivery failure and > undeliverable. > In the case of a delivery failure - where the router cannot ensure that the > message wasn't consumed - the router must send back the MODIFIED terminal > disposition with the delivery-failed flag set. This is necessary as the > sender must increment the message's delivery-count if it retransmits. > In the case of an undeliverable message - where the router cannot forward a > message to the destination - the router must send back the RELEASED terminal > disposition. RELEASED informs the sender that the message was not acted > upon. The sender must not increment the message's delivery-count if it > retransmits. > Currently the router uses RELEASED in both these cases. -- 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-358) Intermittent crashes in qdrouterd under load from parallel senders
[ https://issues.apache.org/jira/browse/DISPATCH-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15322464#comment-15322464 ] Ted Ross commented on DISPATCH-358: --- I believe this may be an instance of PROTON-992, which is fixed in proton 0.13. The issue has to do with thread safety in the way Proton uses Cyrus SASL. Crashes have been observed in cases where multiple connections are established concurrently. > Intermittent crashes in qdrouterd under load from parallel senders > -- > > Key: DISPATCH-358 > URL: https://issues.apache.org/jira/browse/DISPATCH-358 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 > Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and > dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines >Reporter: Vishal Sharda >Assignee: Ted Ross >Priority: Critical > Attachments: Crash_EXTERNAL.png, Crash_Java_Router_3.png, > Crash_Java_Send.png, Crash_Java_free_qd_connection.png, > Crash_Java_same_router.png, Crash_Java_same_router_another.png, > Crash_Java_same_router_another_bt.png, Crash_SASL.png, Crash_SASL_2.png, > Crash_SR_1.png, Crash_SR_2.png, Crash_bt_double_free_Java_RES_266MB.png, > Crash_double_free_Java_RES_266MB.png, Crash_free.png, > Crash_sasl_server_done.png, Crash_watch_qdstat.png, Overflow_Error.png > > > In my setup of two inter-connected routers, several senders connecting to one > router while few receivers connecting to the other router, I see several > crashes in the router to which senders connect. These crashes are > intermittent and happen once in every 10 runs or so. I have collected the > backtraces of all the crashes but do not yet have a test case that can > reliably reproduce any of them. -- 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-367) balanced distribution needs to be more... balanced.
[ https://issues.apache.org/jira/browse/DISPATCH-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15322432#comment-15322432 ] Ted Ross commented on DISPATCH-367: --- For the record... This Jira is requesting an enhancement that is arguably meaningless but will improve the way balanced distribution looks to casual testers. The fix for this is also simple and inexpensive, so it's probably worthwhile. The problem is that if a tester tests balanced distribution with a single synchronous sender, the distribution doesn't look very balanced, even though it is behaving reasonably. With a single synchronous sender, there are never any previous deliveries in-flight, so the delivery always goes to the "first" local consumer. Balanced delivery tries to deliver messages to the consumer with the fewest outstanding (unsettled) deliveries. The value of balanced distribution doesn't really kick in until there are multiple in-flight deliveries to the same address with multiple consumers. > balanced distribution needs to be more... balanced. > --- > > Key: DISPATCH-367 > URL: https://issues.apache.org/jira/browse/DISPATCH-367 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 0.6.0 >Reporter: Ken Giusti >Assignee: Ganesh Murthy > Fix For: 0.6.0 > > > When blocking sends are done to a balanced address with multiple consumers on > the same router all the messages go to one of the consumers. > I would expect that the messages would be evenly distributed across all > _locally_attached_ consumers. -- 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-366) When delivery fails the router sends the RELEASED disposition, not MODIFIED
[ https://issues.apache.org/jira/browse/DISPATCH-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reassigned DISPATCH-366: - Assignee: Ted Ross > When delivery fails the router sends the RELEASED disposition, not MODIFIED > --- > > Key: DISPATCH-366 > URL: https://issues.apache.org/jira/browse/DISPATCH-366 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 0.6.0 >Reporter: Ken Giusti >Assignee: Ted Ross >Priority: Blocker > Fix For: 0.7.0, 0.6.1 > > > The router does not properly distinguish between a delivery failure and > undeliverable. > In the case of a delivery failure - where the router cannot ensure that the > message wasn't consumed - the router must send back the MODIFIED terminal > disposition with the delivery-failed flag set. This is necessary as the > sender must increment the message's delivery-count if it retransmits. > In the case of an undeliverable message - where the router cannot forward a > message to the destination - the router must send back the RELEASED terminal > disposition. RELEASED informs the sender that the message was not acted > upon. The sender must not increment the message's delivery-count if it > retransmits. > Currently the router uses RELEASED in both these cases. -- 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-368) Router in bad state in two inter-connected routers
[
https://issues.apache.org/jira/browse/DISPATCH-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15320464#comment-15320464
]
Ted Ross commented on DISPATCH-368:
---
DISPATCH-364 fixes two issues: First, it prevents normal clients from using
inter-router listeners and consuming inter-router resources. Secondly, it
fixes a bug where inter-router connections did not relinquish all their
resources when closed. This is why the test fails after some time with the
"overflow" error.
> Router in bad state in two inter-connected routers
> --
>
> Key: DISPATCH-368
> URL: https://issues.apache.org/jira/browse/DISPATCH-368
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Affects Versions: 0.6.0
> Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and
> dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines
>Reporter: Eric Leu
>Assignee: Ted Ross
> Fix For: 0.6.0
>
>
> The setup of two inter-connected routers is the same as in DISPATCH-358. Let
> the routers be A and B. Senders connect to A and receivers connect to B.
> While senders are sending messages to A, restart router B every 10 sec.
> Senders check tracker status to make sure messages are accepted by the
> receivers. After running for some time, router A is in bad state. No
> messages sent are accepted. After that point, I keep router B up without
> restarting. The problem does not go away. Restart senders and receivers and
> does not help. I also notice the error in the log:
>
> 2016-06-07 14:13:39.287550 -0700 AGENT (debug) Add entity: RouterNodeEntity
> (address=amqp:/_topo/0/Router.A.1, cost=None, id=Router.A.1,
> instance=1465333922, linkState=[],
> nextHop=None, routerLink=None, type=org.apache.qpid.dispatch.router.node,
> validOrigins=None)
> 2016-06-07 14:13:39.294891 -0700 ROUTER (error) Control message error:
> opcode=HELLO body=
> {'seen': ['Router.A.0'], 'area': '0', 'id': 'Router.A.1', 'instance':
> 1465333922L}
> Traceback (most recent call last):
> File
> "/usr/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/engine.py",
> line 137,
> in handleControlMessage
> self.hello_protocol.handle_hello(msg, now, link_id, cost)
> File
> "/usr/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/hello.py",
> line 55,
> in handle_hello
> self.node_tracker.neighbor_refresh(msg.id, msg.instance, link_id, cost,
> now)
> File
> "/usr/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/node.py",
> line 207,
> in neighbor_refresh
> if node.set_link_id(link_id):
> File
> "/usr/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/node.py",
> line 410,
> in set_link_id
> self.adapter.set_link(self.maskbit, link_id)
> OverflowError: signed integer is greater than maximum
--
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-368) Router in bad state in two inter-connected routers
[
https://issues.apache.org/jira/browse/DISPATCH-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross resolved DISPATCH-368.
---
Resolution: Fixed
Fix Version/s: 0.6.0
> Router in bad state in two inter-connected routers
> --
>
> Key: DISPATCH-368
> URL: https://issues.apache.org/jira/browse/DISPATCH-368
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Affects Versions: 0.6.0
> Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and
> dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines
>Reporter: Eric Leu
>Assignee: Ted Ross
> Fix For: 0.6.0
>
>
> The setup of two inter-connected routers is the same as in DISPATCH-358. Let
> the routers be A and B. Senders connect to A and receivers connect to B.
> While senders are sending messages to A, restart router B every 10 sec.
> Senders check tracker status to make sure messages are accepted by the
> receivers. After running for some time, router A is in bad state. No
> messages sent are accepted. After that point, I keep router B up without
> restarting. The problem does not go away. Restart senders and receivers and
> does not help. I also notice the error in the log:
>
> 2016-06-07 14:13:39.287550 -0700 AGENT (debug) Add entity: RouterNodeEntity
> (address=amqp:/_topo/0/Router.A.1, cost=None, id=Router.A.1,
> instance=1465333922, linkState=[],
> nextHop=None, routerLink=None, type=org.apache.qpid.dispatch.router.node,
> validOrigins=None)
> 2016-06-07 14:13:39.294891 -0700 ROUTER (error) Control message error:
> opcode=HELLO body=
> {'seen': ['Router.A.0'], 'area': '0', 'id': 'Router.A.1', 'instance':
> 1465333922L}
> Traceback (most recent call last):
> File
> "/usr/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/engine.py",
> line 137,
> in handleControlMessage
> self.hello_protocol.handle_hello(msg, now, link_id, cost)
> File
> "/usr/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/hello.py",
> line 55,
> in handle_hello
> self.node_tracker.neighbor_refresh(msg.id, msg.instance, link_id, cost,
> now)
> File
> "/usr/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/node.py",
> line 207,
> in neighbor_refresh
> if node.set_link_id(link_id):
> File
> "/usr/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/node.py",
> line 410,
> in set_link_id
> self.adapter.set_link(self.maskbit, link_id)
> OverflowError: signed integer is greater than maximum
--
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-368) Router in bad state in two inter-connected routers
[
https://issues.apache.org/jira/browse/DISPATCH-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15320460#comment-15320460
]
Ted Ross commented on DISPATCH-368:
---
The fix for DISPATCH-364 should also fix this issue.
> Router in bad state in two inter-connected routers
> --
>
> Key: DISPATCH-368
> URL: https://issues.apache.org/jira/browse/DISPATCH-368
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Affects Versions: 0.6.0
> Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and
> dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines
>Reporter: Eric Leu
>
> The setup of two inter-connected routers is the same as in DISPATCH-358. Let
> the routers be A and B. Senders connect to A and receivers connect to B.
> While senders are sending messages to A, restart router B every 10 sec.
> Senders check tracker status to make sure messages are accepted by the
> receivers. After running for some time, router A is in bad state. No
> messages sent are accepted. After that point, I keep router B up without
> restarting. The problem does not go away. Restart senders and receivers and
> does not help. I also notice the error in the log:
>
> 2016-06-07 14:13:39.287550 -0700 AGENT (debug) Add entity: RouterNodeEntity
> (address=amqp:/_topo/0/Router.A.1, cost=None, id=Router.A.1,
> instance=1465333922, linkState=[],
> nextHop=None, routerLink=None, type=org.apache.qpid.dispatch.router.node,
> validOrigins=None)
> 2016-06-07 14:13:39.294891 -0700 ROUTER (error) Control message error:
> opcode=HELLO body=
> {'seen': ['Router.A.0'], 'area': '0', 'id': 'Router.A.1', 'instance':
> 1465333922L}
> Traceback (most recent call last):
> File
> "/usr/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/engine.py",
> line 137,
> in handleControlMessage
> self.hello_protocol.handle_hello(msg, now, link_id, cost)
> File
> "/usr/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/hello.py",
> line 55,
> in handle_hello
> self.node_tracker.neighbor_refresh(msg.id, msg.instance, link_id, cost,
> now)
> File
> "/usr/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/node.py",
> line 207,
> in neighbor_refresh
> if node.set_link_id(link_id):
> File
> "/usr/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/node.py",
> line 410,
> in set_link_id
> self.adapter.set_link(self.maskbit, link_id)
> OverflowError: signed integer is greater than maximum
--
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-368) Router in bad state in two inter-connected routers
[
https://issues.apache.org/jira/browse/DISPATCH-368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross reassigned DISPATCH-368:
-
Assignee: Ted Ross
> Router in bad state in two inter-connected routers
> --
>
> Key: DISPATCH-368
> URL: https://issues.apache.org/jira/browse/DISPATCH-368
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Affects Versions: 0.6.0
> Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and
> dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines
>Reporter: Eric Leu
>Assignee: Ted Ross
>
> The setup of two inter-connected routers is the same as in DISPATCH-358. Let
> the routers be A and B. Senders connect to A and receivers connect to B.
> While senders are sending messages to A, restart router B every 10 sec.
> Senders check tracker status to make sure messages are accepted by the
> receivers. After running for some time, router A is in bad state. No
> messages sent are accepted. After that point, I keep router B up without
> restarting. The problem does not go away. Restart senders and receivers and
> does not help. I also notice the error in the log:
>
> 2016-06-07 14:13:39.287550 -0700 AGENT (debug) Add entity: RouterNodeEntity
> (address=amqp:/_topo/0/Router.A.1, cost=None, id=Router.A.1,
> instance=1465333922, linkState=[],
> nextHop=None, routerLink=None, type=org.apache.qpid.dispatch.router.node,
> validOrigins=None)
> 2016-06-07 14:13:39.294891 -0700 ROUTER (error) Control message error:
> opcode=HELLO body=
> {'seen': ['Router.A.0'], 'area': '0', 'id': 'Router.A.1', 'instance':
> 1465333922L}
> Traceback (most recent call last):
> File
> "/usr/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/engine.py",
> line 137,
> in handleControlMessage
> self.hello_protocol.handle_hello(msg, now, link_id, cost)
> File
> "/usr/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/hello.py",
> line 55,
> in handle_hello
> self.node_tracker.neighbor_refresh(msg.id, msg.instance, link_id, cost,
> now)
> File
> "/usr/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/node.py",
> line 207,
> in neighbor_refresh
> if node.set_link_id(link_id):
> File
> "/usr/local/lib/qpid-dispatch/python/qpid_dispatch_internal/router/node.py",
> line 410,
> in set_link_id
> self.adapter.set_link(self.maskbit, link_id)
> OverflowError: signed integer is greater than maximum
--
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-364) Inter-router listeners should not permit normal endpoint traffic
[ https://issues.apache.org/jira/browse/DISPATCH-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-364. --- Resolution: Fixed > Inter-router listeners should not permit normal endpoint traffic > > > Key: DISPATCH-364 > URL: https://issues.apache.org/jira/browse/DISPATCH-364 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 0.6.0 >Reporter: Ted Ross >Assignee: Ted Ross > > A router network can be configured such that normal clients connect to the > network using listeners designated with the inter-router role. Since there > can be only a limited number of routers in a network (128 in 0.6.0), it > doesn't take many connected clients to clog up the inter-router connection > space. > The router node should be modified such that normal links attaching over > inter-router connections are forbidden. -- 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-365) Standalone router crashes if an interior router attempts to connect to it
[ https://issues.apache.org/jira/browse/DISPATCH-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-365. --- Resolution: Fixed Fix Version/s: 0.6.0 > Standalone router crashes if an interior router attempts to connect to it > - > > Key: DISPATCH-365 > URL: https://issues.apache.org/jira/browse/DISPATCH-365 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 0.6.0 > Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and > dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines >Reporter: Vishal Sharda >Assignee: Ted Ross >Priority: Critical > Fix For: 0.6.0 > > Attachments: config1_standalone.conf, config2_nossl.conf > > > I accidentally pointed my interior router to a standalone router. The > standalone router did not ignore the connection request and crashed. The > attached config files reproduce the 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] [Assigned] (DISPATCH-365) Standalone router crashes if an interior router attempts to connect to it
[ https://issues.apache.org/jira/browse/DISPATCH-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reassigned DISPATCH-365: - Assignee: Ted Ross > Standalone router crashes if an interior router attempts to connect to it > - > > Key: DISPATCH-365 > URL: https://issues.apache.org/jira/browse/DISPATCH-365 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 0.6.0 > Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and > dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines >Reporter: Vishal Sharda >Assignee: Ted Ross >Priority: Critical > Attachments: config1_standalone.conf, config2_nossl.conf > > > I accidentally pointed my interior router to a standalone router. The > standalone router did not ignore the connection request and crashed. The > attached config files reproduce the 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] [Created] (DISPATCH-364) Inter-router listeners should not permit normal endpoint traffic
Ted Ross created DISPATCH-364: - Summary: Inter-router listeners should not permit normal endpoint traffic Key: DISPATCH-364 URL: https://issues.apache.org/jira/browse/DISPATCH-364 Project: Qpid Dispatch Issue Type: Bug Components: Router Node Affects Versions: 0.6.0 Reporter: Ted Ross Assignee: Ted Ross A router network can be configured such that normal clients connect to the network using listeners designated with the inter-router role. Since there can be only a limited number of routers in a network (128 in 0.6.0), it doesn't take many connected clients to clog up the inter-router connection space. The router node should be modified such that normal links attaching over inter-router connections are forbidden. -- 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-358) Intermittent crashes in qdrouterd under load from parallel senders
[ https://issues.apache.org/jira/browse/DISPATCH-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reassigned DISPATCH-358: - Assignee: Ted Ross > Intermittent crashes in qdrouterd under load from parallel senders > -- > > Key: DISPATCH-358 > URL: https://issues.apache.org/jira/browse/DISPATCH-358 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 > Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and > dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines >Reporter: Vishal Sharda >Assignee: Ted Ross >Priority: Critical > Attachments: Crash_Java_Router_3.png, Crash_Java_Send.png, > Crash_Java_free_qd_connection.png, Crash_Java_same_router.png, > Crash_Java_same_router_another.png, Crash_Java_same_router_another_bt.png, > Crash_SASL.png, Crash_SASL_2.png, Crash_SR_1.png, Crash_SR_2.png, > Crash_bt_double_free_Java_RES_266MB.png, > Crash_double_free_Java_RES_266MB.png, Crash_free.png, > Crash_sasl_server_done.png, Crash_watch_qdstat.png, Overflow_Error.png > > > In my setup of two inter-connected routers, several senders connecting to one > router while few receivers connecting to the other router, I see several > crashes in the router to which senders connect. These crashes are > intermittent and happen once in every 10 runs or so. I have collected the > backtraces of all the crashes but do not yet have a test case that can > reliably reproduce any of them. -- 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] [Comment Edited] (DISPATCH-360) Sender and receiver cannot communicate using a network of 3 inter-connected routers having insecure connections
[
https://issues.apache.org/jira/browse/DISPATCH-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15318372#comment-15318372
]
Ted Ross edited comment on DISPATCH-360 at 6/7/16 12:18 PM:
Two of your configurations, config2_nossl.conf and config3_nossl.conf have the
same routerId (Router.A.2). You should be seeing a log message that looks like
the following:
{code}
Tue Jun 7 08:11:40 2016 ROUTER_HELLO (critical) Detected Neighbor Router with
a Duplicate ID - Router.A.2
{code}
Duplicate router IDs will cause problems with forwarding messages across the
network.
was (Author: tedross):
Two of you configurations, config2_nossl.conf and config3_nossl.conf have the
same routerId (Router.A.2). You should be seeing a log message that looks like
the following:
{code}
Tue Jun 7 08:11:40 2016 ROUTER_HELLO (critical) Detected Neighbor Router with
a Duplicate ID - Router.A.2
{code}
> Sender and receiver cannot communicate using a network of 3 inter-connected
> routers having insecure connections
> ---
>
> Key: DISPATCH-360
> URL: https://issues.apache.org/jira/browse/DISPATCH-360
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Affects Versions: 0.6.0
> Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and
> dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 3 separate machines
>Reporter: Vishal Sharda
>Priority: Blocker
> Attachments: Crash_bt_no_SSL.png, Crash_bt_no_SSL_2.png,
> config1_nossl.conf, config2_nossl.conf, config3_nossl.conf
>
>
> In order to isolate the issues that I am getting with 2-way SSL connections
> among routers, I created a cluster of 3 inter-connected routers (R1, R2 and
> R3 with R2 connecting to R1 and R3 connecting to both R1 and R2) without any
> type of SSL (I had been using just 2 routers so far but our actual cluster
> consists of 3 nodes). All connections were insecure as shown in my config
> files.
> When I tried sending 4 messages using simple_send.py to R1 after starting
> simple_recv.py to receive from R2, I saw no messages were sent.
> If I stop R3 and reduce the cluster to just two nodes, it works fine.
> If I have 2-way SSL connections between all the 3 routers, it again works
> fine.
> In my more than 20 runs to test this scenario of sending just 4 messages, it
> even worked a few times after waiting for very long. In the other two cases
> above, I always got the messages instantaneously (there were no other
> senders/receivers active).
> The drivers.tar.gz that I attached in DISPATCH-343 either timed out or
> returned with unclear status when trying to send just 4 messages from 1
> sender (connected to R1) to 1 receiver (connected to R2). It showed
> successful just once. The behavior is completely non-deterministic.
> This basic test working non-deterministically some times and failing most of
> the times seemed very weird and I turned to running routers outside gdb but
> the results were similar. In the process of stopping/restarting the 3
> routers for testing this scenario, I also got a crash (backtrace attached).
--
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] [Comment Edited] (DISPATCH-360) Sender and receiver cannot communicate using a network of 3 inter-connected routers having insecure connections
[
https://issues.apache.org/jira/browse/DISPATCH-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15318372#comment-15318372
]
Ted Ross edited comment on DISPATCH-360 at 6/7/16 12:16 PM:
Two of you configurations, config2_nossl.conf and config3_nossl.conf have the
same routerId (Router.A.2). You should be seeing a log message that looks like
the following:
{code}
Tue Jun 7 08:11:40 2016 ROUTER_HELLO (critical) Detected Neighbor Router with
a Duplicate ID - Router.A.2
{code}
was (Author: tedross):
Two of you configurations, config2_nossl.conf and config3_nossl.conf have the
same routerId (Router.A.2). You should be seeing a log message that looks like
the following:
{noformat}
Tue Jun 7 08:11:40 2016 ROUTER_HELLO (critical) Detected Neighbor Router with
a Duplicate ID - Router.A.2
{noformat}
> Sender and receiver cannot communicate using a network of 3 inter-connected
> routers having insecure connections
> ---
>
> Key: DISPATCH-360
> URL: https://issues.apache.org/jira/browse/DISPATCH-360
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Affects Versions: 0.6.0
> Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and
> dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 3 separate machines
>Reporter: Vishal Sharda
>Priority: Blocker
> Attachments: Crash_bt_no_SSL.png, Crash_bt_no_SSL_2.png,
> config1_nossl.conf, config2_nossl.conf, config3_nossl.conf
>
>
> In order to isolate the issues that I am getting with 2-way SSL connections
> among routers, I created a cluster of 3 inter-connected routers (R1, R2 and
> R3 with R2 connecting to R1 and R3 connecting to both R1 and R2) without any
> type of SSL (I had been using just 2 routers so far but our actual cluster
> consists of 3 nodes). All connections were insecure as shown in my config
> files.
> When I tried sending 4 messages using simple_send.py to R1 after starting
> simple_recv.py to receive from R2, I saw no messages were sent.
> If I stop R3 and reduce the cluster to just two nodes, it works fine.
> If I have 2-way SSL connections between all the 3 routers, it again works
> fine.
> In my more than 20 runs to test this scenario of sending just 4 messages, it
> even worked a few times after waiting for very long. In the other two cases
> above, I always got the messages instantaneously (there were no other
> senders/receivers active).
> The drivers.tar.gz that I attached in DISPATCH-343 either timed out or
> returned with unclear status when trying to send just 4 messages from 1
> sender (connected to R1) to 1 receiver (connected to R2). It showed
> successful just once. The behavior is completely non-deterministic.
> This basic test working non-deterministically some times and failing most of
> the times seemed very weird and I turned to running routers outside gdb but
> the results were similar. In the process of stopping/restarting the 3
> routers for testing this scenario, I also got a crash (backtrace attached).
--
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-360) Sender and receiver cannot communicate using a network of 3 inter-connected routers having insecure connections
[
https://issues.apache.org/jira/browse/DISPATCH-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15318372#comment-15318372
]
Ted Ross commented on DISPATCH-360:
---
Two of you configurations, config2_nossl.conf and config3_nossl.conf have the
same routerId (Router.A.2). You should be seeing a log message that looks like
the following:
{noformat}
Tue Jun 7 08:11:40 2016 ROUTER_HELLO (critical) Detected Neighbor Router with
a Duplicate ID - Router.A.2
{noformat}
> Sender and receiver cannot communicate using a network of 3 inter-connected
> routers having insecure connections
> ---
>
> Key: DISPATCH-360
> URL: https://issues.apache.org/jira/browse/DISPATCH-360
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Routing Engine
>Affects Versions: 0.6.0
> Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and
> dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 3 separate machines
>Reporter: Vishal Sharda
>Priority: Blocker
> Attachments: Crash_bt_no_SSL.png, Crash_bt_no_SSL_2.png,
> config1_nossl.conf, config2_nossl.conf, config3_nossl.conf
>
>
> In order to isolate the issues that I am getting with 2-way SSL connections
> among routers, I created a cluster of 3 inter-connected routers (R1, R2 and
> R3 with R2 connecting to R1 and R3 connecting to both R1 and R2) without any
> type of SSL (I had been using just 2 routers so far but our actual cluster
> consists of 3 nodes). All connections were insecure as shown in my config
> files.
> When I tried sending 4 messages using simple_send.py to R1 after starting
> simple_recv.py to receive from R2, I saw no messages were sent.
> If I stop R3 and reduce the cluster to just two nodes, it works fine.
> If I have 2-way SSL connections between all the 3 routers, it again works
> fine.
> In my more than 20 runs to test this scenario of sending just 4 messages, it
> even worked a few times after waiting for very long. In the other two cases
> above, I always got the messages instantaneously (there were no other
> senders/receivers active).
> The drivers.tar.gz that I attached in DISPATCH-343 either timed out or
> returned with unclear status when trying to send just 4 messages from 1
> sender (connected to R1) to 1 receiver (connected to R2). It showed
> successful just once. The behavior is completely non-deterministic.
> This basic test working non-deterministically some times and failing most of
> the times seemed very weird and I turned to running routers outside gdb but
> the results were similar. In the process of stopping/restarting the 3
> routers for testing this scenario, I also got a crash (backtrace attached).
--
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-341) router did not respond to request to drain a message-routed consumers link credit
[
https://issues.apache.org/jira/browse/DISPATCH-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross resolved DISPATCH-341.
---
Resolution: Fixed
> router did not respond to request to drain a message-routed consumers link
> credit
> -
>
> Key: DISPATCH-341
> URL: https://issues.apache.org/jira/browse/DISPATCH-341
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 0.6.0
> Environment: Qpid Dispatch 0.6.0 RC3
> Qpid JMS 0.10.0-SNAPSHOT
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
> Fix For: 0.7.0
>
>
> With a router using the provided default config (updated only to set
> saslMechanisms to ANONYMOUS), and attaching a sender and receiver (using the
> JMS client Sender and Receiver examples) to the address "queue" (so
> presumably using messge routing), it could be seen that Dispatch didn't
> respond to requests to drain the receivers link.
> In one case, after receiving some messages, a 'drain requst' flow is issued,
> but neither enough messages to use the credit (expected since no more were
> sent) or a 'drain reponse' flow are received, just heartbeating back and
> forth.
> {noformat}
> [1925974223:1] -> Disposition{role=RECEIVER, first=8, last=8, settled=true,
> state=Accepted{}, batchable=false}
> [1925974223:1] -> Flow{nextIncomingId=9, incomingWindow=2047,
> nextOutgoingId=1, outgoingWindow=2147483647, handle=0, deliveryCount=9,
> linkCredit=991, available=null, drain=true, echo=false, properties=null}
> [1925974223:0] -> Empty Frame
> [1925974223:0] -> Empty Frame
> [1925974223:0] <- Empty Frame
> {noformat}
> In another case, after flowing some credit but not receiving any messages, a
> 'drain request' is issued, but neither enough messages to use the credit
> (expected since none were sent) or a 'drain reponse' flow are received, just
> heartbeating back and forth.
> {noformat}
> [2111953084:1] -> Flow{nextIncomingId=0, incomingWindow=2047,
> nextOutgoingId=1, outgoingWindow=2147483647, handle=0, deliveryCount=0,
> linkCredit=1000, available=null, drain=false, echo=false, properties=null}
> [2111953084:1] -> Flow{nextIncomingId=0, incomingWindow=2047,
> nextOutgoingId=1, outgoingWindow=2147483647, handle=0, deliveryCount=0,
> linkCredit=1000, available=null, drain=true, echo=false, properties=null}
> [2111953084:0] -> Empty Frame
> [2111953084:0] -> Empty Frame
> [2111953084:0] <- Empty Frame
> {noformat}
--
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-341) router did not respond to request to drain a message-routed consumers link credit
[
https://issues.apache.org/jira/browse/DISPATCH-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated DISPATCH-341:
--
Fix Version/s: 0.7.0
> router did not respond to request to drain a message-routed consumers link
> credit
> -
>
> Key: DISPATCH-341
> URL: https://issues.apache.org/jira/browse/DISPATCH-341
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 0.6.0
> Environment: Qpid Dispatch 0.6.0 RC3
> Qpid JMS 0.10.0-SNAPSHOT
>Reporter: Robbie Gemmell
>Assignee: Ganesh Murthy
> Fix For: 0.7.0
>
>
> With a router using the provided default config (updated only to set
> saslMechanisms to ANONYMOUS), and attaching a sender and receiver (using the
> JMS client Sender and Receiver examples) to the address "queue" (so
> presumably using messge routing), it could be seen that Dispatch didn't
> respond to requests to drain the receivers link.
> In one case, after receiving some messages, a 'drain requst' flow is issued,
> but neither enough messages to use the credit (expected since no more were
> sent) or a 'drain reponse' flow are received, just heartbeating back and
> forth.
> {noformat}
> [1925974223:1] -> Disposition{role=RECEIVER, first=8, last=8, settled=true,
> state=Accepted{}, batchable=false}
> [1925974223:1] -> Flow{nextIncomingId=9, incomingWindow=2047,
> nextOutgoingId=1, outgoingWindow=2147483647, handle=0, deliveryCount=9,
> linkCredit=991, available=null, drain=true, echo=false, properties=null}
> [1925974223:0] -> Empty Frame
> [1925974223:0] -> Empty Frame
> [1925974223:0] <- Empty Frame
> {noformat}
> In another case, after flowing some credit but not receiving any messages, a
> 'drain request' is issued, but neither enough messages to use the credit
> (expected since none were sent) or a 'drain reponse' flow are received, just
> heartbeating back and forth.
> {noformat}
> [2111953084:1] -> Flow{nextIncomingId=0, incomingWindow=2047,
> nextOutgoingId=1, outgoingWindow=2147483647, handle=0, deliveryCount=0,
> linkCredit=1000, available=null, drain=false, echo=false, properties=null}
> [2111953084:1] -> Flow{nextIncomingId=0, incomingWindow=2047,
> nextOutgoingId=1, outgoingWindow=2147483647, handle=0, deliveryCount=0,
> linkCredit=1000, available=null, drain=true, echo=false, properties=null}
> [2111953084:0] -> Empty Frame
> [2111953084:0] -> Empty Frame
> [2111953084:0] <- Empty Frame
> {noformat}
--
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-343) Router stops accepting connections after load from parallel senders
[ https://issues.apache.org/jira/browse/DISPATCH-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-343. --- Resolution: Fixed > Router stops accepting connections after load from parallel senders > --- > > Key: DISPATCH-343 > URL: https://issues.apache.org/jira/browse/DISPATCH-343 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 >Reporter: Vishal Sharda >Assignee: Ted Ross >Priority: Blocker > Fix For: 0.6.0 > > Attachments: Connection_aborted.png, Connection_aborted_1.png, > Crash.png, Crash_10S_2R.png, R1.conf, R2.conf, R3.conf, > Sender_router_crash.png, bt_qd_dealloc.png, bt_qdr_link_cleanup_CT.png, > bt_sasl.png, bt_sys_mutex_lock.png, config1_nossl.conf, config2_nossl.conf, > drivers.tar.gz, resource-limit-exceeded.png > > > We ran 2 parallel senders and 2 receivers with each sender sending 5 > messages. After a while we saw that router stopped accepting connections > even from qdstat. We saw various errors in the logs (screenshots attached). -- 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-343) Router stops accepting connections after load from parallel senders
[ https://issues.apache.org/jira/browse/DISPATCH-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15307623#comment-15307623 ] Ted Ross commented on DISPATCH-343: --- Quick status on this issue: The thing about this test that causes the problem is that it uses 2-ack transfers. The messages are sent by the sender, acknowledged (but not settled) by the receiver, then settled by the sender. However, since it is built on Messenger with a limited windows size, sometimes the receiver will settle the deliveries (presumably because the window is full). All of this should work fine of course, but it exposes a bug in the lifecycle management of deliveries in Dispatch Router. A fix for this is imminent. If this is a blocker for your project, you can probably work around it by switching away from 2-ack deliveries. They are probably not providing any added value since Messenger doesn't support exactly-once delivery. > Router stops accepting connections after load from parallel senders > --- > > Key: DISPATCH-343 > URL: https://issues.apache.org/jira/browse/DISPATCH-343 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 >Reporter: Vishal Sharda >Assignee: Ted Ross >Priority: Blocker > Fix For: 0.6.0 > > Attachments: Connection_aborted.png, Connection_aborted_1.png, > Crash.png, Crash_10S_2R.png, R1.conf, R2.conf, R3.conf, > Sender_router_crash.png, bt_qd_dealloc.png, bt_qdr_link_cleanup_CT.png, > bt_sasl.png, bt_sys_mutex_lock.png, config1_nossl.conf, config2_nossl.conf, > drivers.tar.gz, resource-limit-exceeded.png > > > We ran 2 parallel senders and 2 receivers with each sender sending 5 > messages. After a while we saw that router stopped accepting connections > even from qdstat. We saw various errors in the logs (screenshots attached). -- 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-343) Router stops accepting connections after load from parallel senders
[ https://issues.apache.org/jira/browse/DISPATCH-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15302388#comment-15302388 ] Ted Ross commented on DISPATCH-343: --- Your reproducer reproduces and we understand why the crash is occurring. We hope to have a fix today. > Router stops accepting connections after load from parallel senders > --- > > Key: DISPATCH-343 > URL: https://issues.apache.org/jira/browse/DISPATCH-343 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 >Reporter: Vishal Sharda >Assignee: Ted Ross >Priority: Blocker > Fix For: 0.6.0 > > Attachments: Connection_aborted.png, Connection_aborted_1.png, > Crash.png, Crash_10S_2R.png, R1.conf, R2.conf, R3.conf, > Sender_router_crash.png, bt_qd_dealloc.png, bt_qdr_link_cleanup_CT.png, > bt_sasl.png, bt_sys_mutex_lock.png, config1_nossl.conf, config2_nossl.conf, > drivers.tar.gz, resource-limit-exceeded.png > > > We ran 2 parallel senders and 2 receivers with each sender sending 5 > messages. After a while we saw that router stopped accepting connections > even from qdstat. We saw various errors in the logs (screenshots attached). -- 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-343) Router stops accepting connections after load from parallel senders
[ https://issues.apache.org/jira/browse/DISPATCH-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-343: -- Fix Version/s: 0.6.0 > Router stops accepting connections after load from parallel senders > --- > > Key: DISPATCH-343 > URL: https://issues.apache.org/jira/browse/DISPATCH-343 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 >Reporter: Vishal Sharda >Priority: Blocker > Fix For: 0.6.0 > > Attachments: Connection_aborted.png, Connection_aborted_1.png, > Crash.png, Crash_10S_2R.png, R1.conf, R2.conf, R3.conf, > Sender_router_crash.png, bt_qd_dealloc.png, bt_qdr_link_cleanup_CT.png, > bt_sasl.png, bt_sys_mutex_lock.png, config1_nossl.conf, config2_nossl.conf, > drivers.tar.gz, resource-limit-exceeded.png > > > We ran 2 parallel senders and 2 receivers with each sender sending 5 > messages. After a while we saw that router stopped accepting connections > even from qdstat. We saw various errors in the logs (screenshots attached). -- 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-343) Router stops accepting connections after load from parallel senders
[ https://issues.apache.org/jira/browse/DISPATCH-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reassigned DISPATCH-343: - Assignee: Ted Ross > Router stops accepting connections after load from parallel senders > --- > > Key: DISPATCH-343 > URL: https://issues.apache.org/jira/browse/DISPATCH-343 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 >Reporter: Vishal Sharda >Assignee: Ted Ross >Priority: Blocker > Fix For: 0.6.0 > > Attachments: Connection_aborted.png, Connection_aborted_1.png, > Crash.png, Crash_10S_2R.png, R1.conf, R2.conf, R3.conf, > Sender_router_crash.png, bt_qd_dealloc.png, bt_qdr_link_cleanup_CT.png, > bt_sasl.png, bt_sys_mutex_lock.png, config1_nossl.conf, config2_nossl.conf, > drivers.tar.gz, resource-limit-exceeded.png > > > We ran 2 parallel senders and 2 receivers with each sender sending 5 > messages. After a while we saw that router stopped accepting connections > even from qdstat. We saw various errors in the logs (screenshots attached). -- 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-339) The change from 'routerId' to 'id' and 'addr' to 'host' configuration option is not backwards compatible
[
https://issues.apache.org/jira/browse/DISPATCH-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross resolved DISPATCH-339.
---
Resolution: Fixed
> The change from 'routerId' to 'id' and 'addr' to 'host' configuration option
> is not backwards compatible
>
>
> Key: DISPATCH-339
> URL: https://issues.apache.org/jira/browse/DISPATCH-339
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Router Node
>Affects Versions: 0.6.0
>Reporter: Jiri Danek
>Assignee: Ganesh Murthy
> Fix For: 0.6.0
>
> Attachments: ra.conf, ra_.conf, ra_local.conf, rb.conf, rb_.conf,
> rb_local.conf
>
>
> I started qdrouterd with the following configuration
> {noformat}
> router {
> mode: interior
> routerId: r.a
> }
> listener {
> addr: 0.0.0.0
> port: amqp
> authenticatePeer: no
> }
> {noformat}
> Running qdstat then prints that Router id is None.
> {code:title=qdstat -g|borderStyle=solid}
> Router Statistics
> attr value
> =
> Mode interior
> Area 0
> Router Id None
> Address Count 0
> Link Count 0
> Node Count 0
> {code}
> Other commands, for example
> {code:title=qdstat -n|borderStyle=solid}
> Routers in the Network
> router-id next-hop link
> ===
> r.a(self)
> {code}
> work correctly in this respect.
> If I update my config and use {{id}} instead of {{routerId}}, then qdstat
> prints correct information.
> I'd expect that the config that worked before the routerId/id change would
> continue working.
> If I use {{addr}} in my connectors, then my router does not connect to other
> routers. I had to update the config to using {{host}} and only then it worked
> for me.
> {noformat}
> router {
> mode: interior
> id: r.a
> }
> listener {
> addr: 0.0.0.0
> port: amqp
> authenticatePeer: no
> }
> connector {
> name: to.r.b
> addr: {{ rb_ip }}
> port: 50001
> role: inter-router
> }
> {noformat}
> {noformat}
> router {
> mode: interior
> id: r.b
> }
> listener {
> addr: 0.0.0.0
> port: amqp
> authenticatePeer: no
> }
> listener {
> role: inter-router
> addr: 0.0.0.0
> port: 50001
> authenticatePeer: no
> }
> {noformat}
> {code:title=qdstat -n|borderStyle=solid}
> Routers in the Network
> router-id next-hop link
> ===
> r.a(self)
> {code}
> After I change addr to host and restart both routers,
> {code:title=qdstat -n|borderStyle=solid}
> Routers in the Network
> router-id next-hop link
> ===
> r.a(self)-
> r.b- 1
> {code}
> NOTE: I noticed that if I use routerId or addr, no deprecation warning is
> shown in qdrouterd output with the default log level. As far as I can
> remember, there are deprecation warnings for some features like fixedAddress,
> I think.
--
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-342) qdrouterd.conf doc calls out router.config.{address,linkRoute,autoLink}
[
https://issues.apache.org/jira/browse/DISPATCH-342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross resolved DISPATCH-342.
---
Resolution: Fixed
> qdrouterd.conf doc calls out router.config.{address,linkRoute,autoLink}
> ---
>
> Key: DISPATCH-342
> URL: https://issues.apache.org/jira/browse/DISPATCH-342
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Documentation
>Affects Versions: 0.6.0
>Reporter: Ted Ross
>Assignee: Ganesh Murthy
> Fix For: 0.6.0
>
>
> Three configuration entities: address, linkRoute, and autoLink are called
> out in the configuration doc with a prefix of router.config.
> This is incorrect syntax. The "router.config" should not be displayed.
--
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-343) Router stops accepting connections after load from parallel senders
[ https://issues.apache.org/jira/browse/DISPATCH-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15299332#comment-15299332 ] Ted Ross commented on DISPATCH-343: --- Vishal, Can you check the integrity of your build? Make sure that the dispatch and proton libraries that you're running with are the same as you built with. You can run ldd against the qdrouterd executable to get the list of libraries. The type of problems you are reporting look like internal data corruption. Nobody else has reported seeing this and our testing has not shown any similar behavior. I'm wondering if there's something wrong with your installation or if there's something specific to Debian going on. We are putting together a Debian 8 system to test your scenario on. -Ted > Router stops accepting connections after load from parallel senders > --- > > Key: DISPATCH-343 > URL: https://issues.apache.org/jira/browse/DISPATCH-343 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 >Reporter: Vishal Sharda >Priority: Blocker > Attachments: Connection_aborted.png, Connection_aborted_1.png, > Crash.png, Crash_10S_2R.png, R1.conf, R2.conf, R3.conf, > Sender_router_crash.png, bt_qd_dealloc.png, bt_qdr_link_cleanup_CT.png, > bt_sasl.png, bt_sys_mutex_lock.png, config1_nossl.conf, config2_nossl.conf, > resource-limit-exceeded.png > > > We ran 2 parallel senders and 2 receivers with each sender sending 5 > messages. After a while we saw that router stopped accepting connections > even from qdstat. We saw various errors in the logs (screenshots attached). -- 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-337) Huge memory leaks in Qpid Dispatch router
[ https://issues.apache.org/jira/browse/DISPATCH-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15298647#comment-15298647 ] Ted Ross commented on DISPATCH-337: --- The following are singleton allocations at startup. We should clean these up at shutdown, but this is not a blocker issue. There is no memory leak. 2 bytes in 1 blocks are definitely lost in loss record 2 of 1,521 24 bytes in 1 blocks are definitely lost in loss record 550 of 1,521 24 bytes in 1 blocks are definitely lost in loss record 551 of 1,521 40 bytes in 1 blocks are definitely lost in loss record 677 of 1,521 48 bytes in 1 blocks are definitely lost in loss record 769 of 1,521 60 bytes in 1 blocks are definitely lost in loss record 774 of 1,521 1,024 bytes in 1 blocks are definitely lost in loss record 1,264 of 1,521 1,024 bytes in 1 blocks are definitely lost in loss record 1,265 of 1,521 1,024 bytes in 1 blocks are definitely lost in loss record 1,266 of 1,521 1,200 (1,024 direct, 176 indirect) bytes in 1 blocks are definitely lost in loss record 1,282 of 1,521 2,088 (40 direct, 2,048 indirect) bytes in 1 blocks are definitely lost in loss record 1,319 of 1,521 The following are associated with normal router operation (router nodes, sessions, connections, deliveries). I would like to know more about how the router was shut down before I consider these actual memory leaks. 52 bytes in 1 blocks are definitely lost in loss record 771 of 1,521 300 bytes in 1 blocks are definitely lost in loss record 1,049 of 1,521 300 bytes in 1 blocks are definitely lost in loss record 1,050 of 1,521 392 (196 direct, 196 indirect) bytes in 1 blocks are definitely lost in loss record 1,064 of 1,521 405,104 (288 direct, 404,816 indirect) bytes in 1 blocks are definitely lost in loss record 1,518 of 1,521 408,264 (288 direct, 407,976 indirect) bytes in 1 blocks are definitely lost in loss record 1,519 of 1,521 > Huge memory leaks in Qpid Dispatch router > - > > Key: DISPATCH-337 > URL: https://issues.apache.org/jira/browse/DISPATCH-337 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.6.0 > Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and > dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines >Reporter: Vishal Sharda >Priority: Critical > Attachments: config1.conf, config2.conf, val2_receiver.txt, > val2_sender.txt > > > Valgrind shows huge memory leaks while running 2 interconnected routers with > 2 parallel senders connected to the one router and 2 parallel receivers > connected to the other router. > The CRYPTO leak that is coming from Qpid Proton 0.12.2 is already fixed here: > https://issues.apache.org/jira/browse/PROTON-1115 > However, the rest of the leaks are from qdrouterd. -- 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-337) Huge memory leaks in Qpid Dispatch router
[ https://issues.apache.org/jira/browse/DISPATCH-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15298658#comment-15298658 ] Ted Ross commented on DISPATCH-337: --- Also, the leak reports involving embedded Python are not valid. The embedded Python engine does not free allocated objects on shutdown. This results in massive numbers of false positives from tools like valgrind. > Huge memory leaks in Qpid Dispatch router > - > > Key: DISPATCH-337 > URL: https://issues.apache.org/jira/browse/DISPATCH-337 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.6.0 > Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and > dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines >Reporter: Vishal Sharda >Priority: Critical > Attachments: config1.conf, config2.conf, val2_receiver.txt, > val2_sender.txt > > > Valgrind shows huge memory leaks while running 2 interconnected routers with > 2 parallel senders connected to the one router and 2 parallel receivers > connected to the other router. > The CRYPTO leak that is coming from Qpid Proton 0.12.2 is already fixed here: > https://issues.apache.org/jira/browse/PROTON-1115 > However, the rest of the leaks are from qdrouterd. -- 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-343) Router stops accepting connections after load from parallel senders
[ https://issues.apache.org/jira/browse/DISPATCH-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15298536#comment-15298536 ] Ted Ross commented on DISPATCH-343: --- Vishal, Can you provide information about what platform you are building on and which openssl version you are building against? Thanks, -Ted > Router stops accepting connections after load from parallel senders > --- > > Key: DISPATCH-343 > URL: https://issues.apache.org/jira/browse/DISPATCH-343 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 >Reporter: Vishal Sharda >Priority: Blocker > Attachments: Connection_aborted.png, Connection_aborted_1.png, > Crash.png, Crash_10S_2R.png, R1.conf, R2.conf, R3.conf, > Sender_router_crash.png, resource-limit-exceeded.png > > > We ran 2 parallel senders and 2 receivers with each sender sending 5 > messages. After a while we saw that router stopped accepting connections > even from qdstat. We saw various errors in the logs (screenshots attached). -- 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-343) Router stops accepting connections after load from parallel senders
[ https://issues.apache.org/jira/browse/DISPATCH-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15298211#comment-15298211 ] Ted Ross commented on DISPATCH-343: --- We are trying to reproduce this locally. In the mean time, if you can get a backtrace for the router crash, that would be very helpful. > Router stops accepting connections after load from parallel senders > --- > > Key: DISPATCH-343 > URL: https://issues.apache.org/jira/browse/DISPATCH-343 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 >Reporter: Vishal Sharda >Priority: Blocker > Attachments: Connection_aborted.png, Connection_aborted_1.png, > Crash.png, R1.conf, R2.conf, R3.conf, Sender_router_crash.png, > resource-limit-exceeded.png > > > We ran 2 parallel senders and 2 receivers with each sender sending 5 > messages. After a while we saw that router stopped accepting connections > even from qdstat. We saw various errors in the logs (screenshots attached). -- 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-343) Router stops accepting connections after load from parallel senders
[ https://issues.apache.org/jira/browse/DISPATCH-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15296325#comment-15296325 ] Ted Ross commented on DISPATCH-343: --- Vishal, Can you provide some further detail as to how this test was run? What was the distribution mode for the address(es) in use? Were the deliveries unsettled or pre-settled? How many routers were in your configuration? Thanks, -Ted > Router stops accepting connections after load from parallel senders > --- > > Key: DISPATCH-343 > URL: https://issues.apache.org/jira/browse/DISPATCH-343 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 >Reporter: Vishal Sharda >Priority: Blocker > Attachments: Connection_aborted.png, Connection_aborted_1.png, > resource-limit-exceeded.png > > > We ran 2 parallel senders and 2 receivers with each sender sending 5 > messages. After a while we saw that router stopped accepting connections > even from qdstat. We saw various errors in the logs (screenshots attached). -- 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-342) qdrouterd.conf doc calls out router.config.{address,linkRoute,autoLink}
Ted Ross created DISPATCH-342:
-
Summary: qdrouterd.conf doc calls out
router.config.{address,linkRoute,autoLink}
Key: DISPATCH-342
URL: https://issues.apache.org/jira/browse/DISPATCH-342
Project: Qpid Dispatch
Issue Type: Bug
Components: Documentation
Affects Versions: 0.6.0
Reporter: Ted Ross
Fix For: 0.6.0
Three configuration entities: address, linkRoute, and autoLink are called out
in the configuration doc with a prefix of router.config.
This is incorrect syntax. The "router.config" should not be displayed.
--
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-339) The change from 'routerId' to 'id' and 'addr' to 'host' configuration option is not backwards compatible
[
https://issues.apache.org/jira/browse/DISPATCH-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated DISPATCH-339:
--
Assignee: Ganesh Murthy
> The change from 'routerId' to 'id' and 'addr' to 'host' configuration option
> is not backwards compatible
>
>
> Key: DISPATCH-339
> URL: https://issues.apache.org/jira/browse/DISPATCH-339
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Router Node
>Affects Versions: 0.6.0
>Reporter: Jiri Danek
>Assignee: Ganesh Murthy
>
> I started qdrouterd with the following configuration
> {noformat}
> router {
> mode: interior
> routerId: r.a
> }
> listener {
> addr: 0.0.0.0
> port: amqp
> authenticatePeer: no
> }
> {noformat}
> Running qdstat then prints that Router id is None.
> {code:title=qdstat -g|borderStyle=solid}
> Router Statistics
> attr value
> =
> Mode interior
> Area 0
> Router Id None
> Address Count 0
> Link Count 0
> Node Count 0
> {code}
> Other commands, for example
> {code:title=qdstat -n|borderStyle=solid}
> Routers in the Network
> router-id next-hop link
> ===
> r.a(self)
> {code}
> work correctly in this respect.
> If I update my config and use {{id}} instead of {{routerId}}, then qdstat
> prints correct information.
> I'd expect that the config that worked before the routerId/id change would
> continue working.
> If I use {{addr}} in my connectors, then my router does not connect to other
> routers. I had to update the config to using {{host}} and only then it worked
> for me.
> {noformat}
> router {
> mode: interior
> id: r.a
> }
> listener {
> addr: 0.0.0.0
> port: amqp
> authenticatePeer: no
> }
> connector {
> name: to.r.b
> addr: {{ rb_ip }}
> port: 50001
> role: inter-router
> }
> {noformat}
> {noformat}
> router {
> mode: interior
> id: r.b
> }
> listener {
> addr: 0.0.0.0
> port: amqp
> authenticatePeer: no
> }
> listener {
> role: inter-router
> addr: 0.0.0.0
> port: 50001
> authenticatePeer: no
> }
> {noformat}
> {code:title=qdstat -n|borderStyle=solid}
> Routers in the Network
> router-id next-hop link
> ===
> r.a(self)
> {code}
> After I change addr to host and restart both routers,
> {code:title=qdstat -n|borderStyle=solid}
> Routers in the Network
> router-id next-hop link
> ===
> r.a(self)-
> r.b- 1
> {code}
> NOTE: I noticed that if I use routerId or addr, no deprecation warning is
> shown in qdrouterd output with the default log level. As far as I can
> remember, there are deprecation warnings for some features like fixedAddress,
> I think.
--
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-338) Incorrect default distribution for addresses
[
https://issues.apache.org/jira/browse/DISPATCH-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross resolved DISPATCH-338.
---
Resolution: Fixed
> Incorrect default distribution for addresses
>
>
> Key: DISPATCH-338
> URL: https://issues.apache.org/jira/browse/DISPATCH-338
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Router Node
>Affects Versions: 0.6.0
>Reporter: Ted Ross
>Assignee: Ted Ross
> Fix For: 0.6.0
>
>
> Hat tip to Jiri Danek:
> I observed the following behavior. If I do not specify an address {} section
> in qdrouterd.conf at all, then the router behaves as if I set a closest
> distribution for that address.
> If I do specify address {} section and do not specify distribution for it,
> then
> the router behaves as if I set the balanced distribution for that address.
> Manual page for qdrouterd.conf says that the default distribution is
> balanced. Shouldn't the balanced distribution be applied in the first case
> as well as in the second case?
--
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-155) Allow multiple connectors to the same broker
[ https://issues.apache.org/jira/browse/DISPATCH-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-155. --- Resolution: Fixed > Allow multiple connectors to the same broker > > > Key: DISPATCH-155 > URL: https://issues.apache.org/jira/browse/DISPATCH-155 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.4 >Reporter: Jakub Scholz >Assignee: Ganesh Murthy > Fix For: 0.6.0 > > Attachments: DISPATCH-155.patch > > > In some use cases it might make sense to have multiple connectors configured, > which connect to the same broker. This makes sense for example when each > connection is using different credentials, where each set of credentials has > different access rights on the broker. > Unfortunately, after DISPATCH-95, the identity of connectors is always > generated only using the address and port. As a result, you cannot have two > connectors to the same broker. > It would be great if the identity of connectors could be based not only on > address and port but also include something more unique. Either a counter as > it was before or for example the connector name, which has to be unique > anyway. -- 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-155) Allow multiple connectors to the same broker
[ https://issues.apache.org/jira/browse/DISPATCH-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-155: -- Assignee: Ganesh Murthy (was: Ted Ross) > Allow multiple connectors to the same broker > > > Key: DISPATCH-155 > URL: https://issues.apache.org/jira/browse/DISPATCH-155 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.4 >Reporter: Jakub Scholz >Assignee: Ganesh Murthy > Fix For: 0.6.0 > > Attachments: DISPATCH-155.patch > > > In some use cases it might make sense to have multiple connectors configured, > which connect to the same broker. This makes sense for example when each > connection is using different credentials, where each set of credentials has > different access rights on the broker. > Unfortunately, after DISPATCH-95, the identity of connectors is always > generated only using the address and port. As a result, you cannot have two > connectors to the same broker. > It would be great if the identity of connectors could be based not only on > address and port but also include something more unique. Either a counter as > it was before or for example the connector name, which has to be unique > anyway. -- 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-338) Incorrect default distribution for addresses
Ted Ross created DISPATCH-338:
-
Summary: Incorrect default distribution for addresses
Key: DISPATCH-338
URL: https://issues.apache.org/jira/browse/DISPATCH-338
Project: Qpid Dispatch
Issue Type: Bug
Components: Router Node
Affects Versions: 0.6.0
Reporter: Ted Ross
Assignee: Ted Ross
Fix For: 0.6.0
Hat tip to Jiri Danek:
I observed the following behavior. If I do not specify an address {} section in
qdrouterd.conf at all, then the router behaves as if I set a closest
distribution for that address.
If I do specify address {} section and do not specify distribution for it, then
the router behaves as if I set the balanced distribution for that address.
Manual page for qdrouterd.conf says that the default distribution is balanced.
Shouldn't the balanced distribution be applied in the first case as well as in
the second case?
--
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-338) Incorrect default distribution for addresses
[
https://issues.apache.org/jira/browse/DISPATCH-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15287095#comment-15287095
]
Ted Ross commented on DISPATCH-338:
---
The default should be "balanced" in both cases.
> Incorrect default distribution for addresses
>
>
> Key: DISPATCH-338
> URL: https://issues.apache.org/jira/browse/DISPATCH-338
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Router Node
>Affects Versions: 0.6.0
>Reporter: Ted Ross
>Assignee: Ted Ross
> Fix For: 0.6.0
>
>
> Hat tip to Jiri Danek:
> I observed the following behavior. If I do not specify an address {} section
> in qdrouterd.conf at all, then the router behaves as if I set a closest
> distribution for that address.
> If I do specify address {} section and do not specify distribution for it,
> then
> the router behaves as if I set the balanced distribution for that address.
> Manual page for qdrouterd.conf says that the default distribution is
> balanced. Shouldn't the balanced distribution be applied in the first case
> as well as in the second case?
--
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-155) Allow multiple connectors to the same broker
[ https://issues.apache.org/jira/browse/DISPATCH-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-155: -- Fix Version/s: 0.6.0 > Allow multiple connectors to the same broker > > > Key: DISPATCH-155 > URL: https://issues.apache.org/jira/browse/DISPATCH-155 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.4 >Reporter: Jakub Scholz > Fix For: 0.6.0 > > Attachments: DISPATCH-155.patch > > > In some use cases it might make sense to have multiple connectors configured, > which connect to the same broker. This makes sense for example when each > connection is using different credentials, where each set of credentials has > different access rights on the broker. > Unfortunately, after DISPATCH-95, the identity of connectors is always > generated only using the address and port. As a result, you cannot have two > connectors to the same broker. > It would be great if the identity of connectors could be based not only on > address and port but also include something more unique. Either a counter as > it was before or for example the connector name, which has to be unique > anyway. -- 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-155) Allow multiple connectors to the same broker
[ https://issues.apache.org/jira/browse/DISPATCH-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross reassigned DISPATCH-155: - Assignee: Ted Ross > Allow multiple connectors to the same broker > > > Key: DISPATCH-155 > URL: https://issues.apache.org/jira/browse/DISPATCH-155 > Project: Qpid Dispatch > Issue Type: Bug >Affects Versions: 0.4 >Reporter: Jakub Scholz >Assignee: Ted Ross > Fix For: 0.6.0 > > Attachments: DISPATCH-155.patch > > > In some use cases it might make sense to have multiple connectors configured, > which connect to the same broker. This makes sense for example when each > connection is using different credentials, where each set of credentials has > different access rights on the broker. > Unfortunately, after DISPATCH-95, the identity of connectors is always > generated only using the address and port. As a result, you cannot have two > connectors to the same broker. > It would be great if the identity of connectors could be based not only on > address and port but also include something more unique. Either a counter as > it was before or for example the connector name, which has to be unique > anyway. -- 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-336) Very high latency for fire-and-forget sender
[ https://issues.apache.org/jira/browse/DISPATCH-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-336: -- Fix Version/s: 0.7.0 > Very high latency for fire-and-forget sender > > > Key: DISPATCH-336 > URL: https://issues.apache.org/jira/browse/DISPATCH-336 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 > Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and > dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines >Reporter: Vishal Sharda >Priority: Critical > Fix For: 0.7.0 > > Attachments: config1.conf, config2.conf, output_1S_1R.txt > > > We are running two interconnected routers with 1 fire-and-forget sender > connected to 1 router and 1 receiver connected to another router. We are > observing increasing latency for the messages irrespective of number messages > sent. -- 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-334) Proton sequence error during backpressure with balanced distribution
[
https://issues.apache.org/jira/browse/DISPATCH-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross resolved DISPATCH-334.
---
Resolution: Fixed
The bug was caused by the router core attempting to send deliveries on a
receiving link. The "undelivered" messages on the incoming link were mistaken
as outgoing messages when other, settled deliveries on the link were updating
their dispositions.
> Proton sequence error during backpressure with balanced distribution
>
>
> Key: DISPATCH-334
> URL: https://issues.apache.org/jira/browse/DISPATCH-334
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Router Node
>Affects Versions: 0.6.0
>Reporter: Ted Ross
>Assignee: Ted Ross
>Priority: Blocker
> Fix For: 0.6.0
>
>
> Scenario:
> {noformat}
> +-++-+
> Sender1>| || |>Receiver1
> | || |
> | Router1 || Router2 |
> | || |
> Sender2>| || |>Receiver2
> +-++-+
> {noformat}
> All senders and receivers are using the same address, which is configured to
> be "balanced". When both Senders are operating, eventually one or both of
> the sending links will fail due to a sequence error:
> {noformat}
> ERROR:root:sequencing error, expected delivery-id 181, got 182
> {noformat}
> This occurs when one delivery results in a fanout of zero and is placed on
> the incoming link's undelivered list.
--
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-336) Very high latency for fire-and-forget sender
[ https://issues.apache.org/jira/browse/DISPATCH-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15283024#comment-15283024 ] Ted Ross commented on DISPATCH-336: --- The increases in latency that you see are the result of buffering of the pre-settled (fire and forget) messages in the router. This will also cause large memory usage in the router(s). As of the current snapshot, end-to-end flow control is not in effect for pre-settled deliveries. Since your producers are outrunning your consumers, the resultant buffering increases memory usage and latency. You will get much better results if you use unsettled messages because the routers will apply flow control across the network and there will be no excessive buffering. This should result in much more uniform latency that is consistent with the lowest latencies you see in your pre-settled test. Our internal testing shows no throughput cost for using unsettled deliveries. To solve the pre-settled problem, we can do one of two things: We can drop excessive deliveries to avoid buffer expansion; Alternatively we've considered using an unsettled delivery mode across the network even for pre-settled deliveries to get the benefits of flow-control. In this case, the producers and consumers would not see any different behavior. The messages would be delivered pre-settled. If you have an opinion as to which works better, we'd be interested in hearing it. As a comparison, doing a large-volume throughput/latency test using pre-settled deliveries is like doing the same over an IP network using UDP datagrams. Such a test is very taxing on the underlying network. Real applications should not use pre-settled for high-volume traffic. > Very high latency for fire-and-forget sender > > > Key: DISPATCH-336 > URL: https://issues.apache.org/jira/browse/DISPATCH-336 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.6.0 > Environment: Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and > dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 2 separate machines >Reporter: Vishal Sharda >Priority: Critical > Attachments: config1.conf, config2.conf, output_1S_1R.txt > > > We are running two interconnected routers with 1 fire-and-forget sender > connected to 1 router and 1 receiver connected to another router. We are > observing increasing latency for the messages irrespective of number messages > sent. -- 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-335) link routes aren't balanced over remote routers
[ https://issues.apache.org/jira/browse/DISPATCH-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-335: -- Assignee: Ganesh Murthy > link routes aren't balanced over remote routers > --- > > Key: DISPATCH-335 > URL: https://issues.apache.org/jira/browse/DISPATCH-335 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 0.6.0 >Reporter: Gordon Sim >Assignee: Ganesh Murthy > > Setup has three routers A, B and C with B and C both connected to A. I have a > linkRoute with the same prefix and dir on each of these. On B and C that > linkRoute has a connection referencing a connector to a broker (different > broker in each case). > When I establish a link to A, it is always routed to the same broker. Only if > I kill that broker, will links be routed to the other broker. -- 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
