[jira] [Commented] (DISPATCH-1337) Alternate Destination for Unreachable Addresses
[
https://issues.apache.org/jira/browse/DISPATCH-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16844346#comment-16844346
]
Justin Ross commented on DISPATCH-1337:
---
"If not might it be better to have a config that presents them as
alternatives?" Very much agree.
What does "alternate: yes" mean on an address? What does it then mean on an
autoLink? They seem to mean different things, but they are rendered
identically in the config file.
How are alternate-capable addresses associated with autoLinks? A shared
prefix, plus having "alternate: yes" at the same time? If so, can I have many
such matches? If I can have many, how are messages distributed among them?
If you cannot have multiple matches, then some more explicit connection to the
alternate address would make sense to me: have the main address name its
alternate address. (And perhaps even consider naming a list of alternate
addresses.)
"Alternate" has the meaning "alter*nate*" (as in, alternating between two
paths), and in the specification of this you do indeed have some alternation -
when draining, between the main address and the backup one. Perhaps a
different word that avoids this collision: a "backup" or "fallback" address.
> Alternate Destination for Unreachable Addresses
> ---
>
> Key: DISPATCH-1337
> URL: https://issues.apache.org/jira/browse/DISPATCH-1337
> Project: Qpid Dispatch
> Issue Type: New Feature
> Components: Router Node
>Reporter: Ted Ross
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.8.0
>
>
> This feature allows addresses to be configured such that an alternate
> destination can be used to receive messages that are not deliverable to any
> normal consumers on the address.
> Typically, this feature will be used to allow a message broker to store
> messages that are not routable directly to consumers. When one or more
> consumers are attached in the router network, messages shall be delivered
> directly to the consumers. Where there are no reachable consumers,
> deliveries shall then be diverted to the alternate destination. Once
> consumers re-connect to the network, messages shall again be delivered
> directly.
> When a consumer comes online after messages have been stored in a broker, it
> shall receive the stored messages interleaved with new messages from
> producers. No attempt shall be made by the router network to preserve the
> original delivery order of the messages.
> This feature can be configured by adding the attribute
> {noformat}
> alternate: yes
> {noformat}
> to an address configuration. This attribute tells the router that any address
> matching the configuration that appears shall support the alternate
> destination capability.
> There are two ways to create an alternate destination for an address:
> Using auto-links:
> An auto-link (or a pair of auto-links) can be configured to create an
> alternate waypoint for an address. For example, assume that there is a
> route-container connector or listener for a broker called "alternate-broker".
> {noformat}
> address {
> prefix: position_update
> alternate: yes
> }
> autoLink {
> address: position_update.338
> direction: in
> connection: alternate-broker
> alternate: yes
> }
> autoLink {
> address: position_update.338
> direction: out
> connection: alternate-broker
> alternate: yes
> }
> {noformat}
> The above configuration will use a queue on the broker called
> "position_update.338" as the alternate destination for direct consumers.
> Furthermore, since there are both _in_ and _out_ auto-links, the router(s)
> shall send queued messages to newly attached direct consumers.
> Using terminus capabilities:
> As an alternative to using auto-links, the broker (or any other process) can
> attach sending and receiving links to the address with terminus-capability
> "qd.alternate". This will create the same behavior as the above example.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1338) Improvements to edge router documentation
Ben Hardesty created DISPATCH-1338: -- Summary: Improvements to edge router documentation Key: DISPATCH-1338 URL: https://issues.apache.org/jira/browse/DISPATCH-1338 Project: Qpid Dispatch Issue Type: Improvement Components: Documentation Reporter: Ben Hardesty Restructure the doc for edge router. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1337) Alternate Destination for Unreachable Addresses
[
https://issues.apache.org/jira/browse/DISPATCH-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated DISPATCH-1337:
---
Description:
This feature allows addresses to be configured such that an alternate
destination can be used to receive messages that are not deliverable to any
normal consumers on the address.
Typically, this feature will be used to allow a message broker to store
messages that are not routable directly to consumers. When one or more
consumers are attached in the router network, messages shall be delivered
directly to the consumers. Where there are no reachable consumers, deliveries
shall then be diverted to the alternate destination. Once consumers re-connect
to the network, messages shall again be delivered directly.
When a consumer comes online after messages have been stored in a broker, it
shall receive the stored messages interleaved with new messages from producers.
No attempt shall be made by the router network to preserve the original
delivery order of the messages.
This feature can be configured by adding the attribute
{noformat}
alternate: yes
{noformat}
to an address configuration. This attribute tells the router that any address
matching the configuration that appears shall support the alternate destination
capability.
There are two ways to create an alternate destination for an address:
Using auto-links:
An auto-link (or a pair of auto-links) can be configured to create an alternate
waypoint for an address. For example, assume that there is a route-container
connector or listener for a broker called "alternate-broker".
{noformat}
address {
prefix: position_update
alternate: yes
}
autoLink {
address: position_update.338
direction: in
connection: alternate-broker
alternate: yes
}
autoLink {
address: position_update.338
direction: out
connection: alternate-broker
alternate: yes
}
{noformat}
The above configuration will use a queue on the broker called
"position_update.338" as the alternate destination for direct consumers.
Furthermore, since there are both _in_ and _out_ auto-links, the router(s)
shall send queued messages to newly attached direct consumers.
Using terminus capabilities:
As an alternative to using auto-links, the broker (or any other process) can
attach sending and receiving links to the address with terminus-capability
"qd.alternate". This will create the same behavior as the above example.
was:
This feature allows addresses to be configured such that an alternate
destination can be used to receive messages that are not deliverable to any
normal consumers on the address.
Typically, this feature will be used to allow a message broker to store
messages that are not routable directly to consumers. When one or more
consumers are attached in the router network, messages shall be delivered
directly to the consumers. Where there are no reachable consumers, deliveries
shall then be diverted to the alternate destination. Once consumers re-connect
to the network, messages shall again be delivered directly.
When a consumer comes online after messages have been stored in a broker, it
shall receive the stored messages interleaved with new messages from producers.
No attempt shall be made by the router network to preserve the original
delivery order of the messages.
This feature can be configured by adding the attribute
{noformat}
alternate: yes
{noformat}
to an address configuration. This attribute tells the router that any address
matching the configuration that appears shall support the alternate destination
capability.
There are two ways to create an alternate destination for an address:
Using auto-links:
An auto-link (or a pair of auto-links) can be configured to create an alternate
waypoint for an address. For example, assume that there is a route-container
connector or listener for a broker called "alternate-broker".
{noformat}
address {
prefix: position_update
alternate: yes
}
autoLink {
address: position_update.338
direction: in
connection: alternate-broker
alternate: yes
}
autoLink {
address: position_update.338
direction: out
connection: alternate-broker
alternate: yes
}
{noformat}
The above configuration will use a queue on the broker called
"position_update.338" as the alternate destination for direct consumers.
Furthermore, since there are both _in_ and _out_ auto-links, the router(s)
shall send queued messages to newly attached direct consumers.
Using terminus capabilities:
As al alternative to using autl-links, the broker (or any other process) can
attach sending and receiving links to the address with terminus-capability
"qd.alternate". This will create the same behavior as the above example.
> Alternate Destination for Unreachable Addresses
> ---
>
> Key: DIS
[GitHub] [qpid-dispatch] ganeshmurthy commented on a change in pull request #506: Added Alternate-Destination feature
ganeshmurthy commented on a change in pull request #506: Added
Alternate-Destination feature
URL: https://github.com/apache/qpid-dispatch/pull/506#discussion_r285645246
##
File path: tests/system_tests_alternate_dest.py
##
@@ -0,0 +1,781 @@
+#
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+#
+
+from __future__ import unicode_literals
+from __future__ import division
+from __future__ import absolute_import
+from __future__ import print_function
+
+from time import sleep
+from threading import Event
+from threading import Timer
+
+import unittest2 as unittest
+from proton import Message, Timeout, symbol
+from system_test import TestCase, Qdrouterd, main_module, TIMEOUT, MgmtMsgProxy
+from system_test import AsyncTestReceiver
+from system_test import AsyncTestSender
+from system_test import QdManager
+from system_tests_link_routes import ConnLinkRouteService
+from proton.handlers import MessagingHandler
+from proton.reactor import Container, DynamicNodeProperties
+from proton.utils import BlockingConnection
+from qpid_dispatch.management.client import Node
+from subprocess import PIPE, STDOUT
+import re
+
+
+class AddrTimer(object):
+def __init__(self, parent):
+self.parent = parent
+
+def on_timer_task(self, event):
+self.parent.check_address()
+
+
+class RouterTest(TestCase):
+
+inter_router_port = None
+
+@classmethod
+def setUpClass(cls):
+"""Start a router"""
+super(RouterTest, cls).setUpClass()
+
+def router(name, mode, connection, extra=None):
+config = [
+('router', {'mode': mode, 'id': name}),
+('listener', {'port': cls.tester.get_port(),
'stripAnnotations': 'no'}),
+('listener', {'port': cls.tester.get_port(), 'role':
'route-container', 'name': 'WP'}),
+('address', {'prefix': 'dest', 'alternate': 'yes'}),
+('autoLink', {'connection': 'WP', 'address': 'dest.al', 'dir':
'out', 'alternate': 'yes'}),
+('autoLink', {'connection': 'WP', 'address': 'dest.al', 'dir':
'in', 'alternate': 'yes'}),
+connection
+]
+
+if extra:
+config.append(extra)
+config = Qdrouterd.Config(config)
+cls.routers.append(cls.tester.qdrouterd(name, config, wait=True))
+
+cls.routers = []
+
+inter_router_port = cls.tester.get_port()
+edge_port_A = cls.tester.get_port()
+edge_port_B = cls.tester.get_port()
+
+router('INT.A', 'interior', ('listener', {'role': 'inter-router',
'port': inter_router_port}),
+ ('listener', {'role': 'edge', 'port': edge_port_A}))
+router('INT.B', 'interior', ('connector', {'name': 'connectorToA',
'role': 'inter-router', 'port': inter_router_port}),
+ ('listener', {'role': 'edge', 'port': edge_port_B}))
+router('EA1', 'edge', ('connector', {'name': 'edge', 'role':
'edge', 'port': edge_port_A}))
+router('EA2', 'edge', ('connector', {'name': 'edge', 'role':
'edge', 'port': edge_port_A}))
+router('EB1', 'edge', ('connector', {'name': 'edge', 'role':
'edge', 'port': edge_port_B}))
+router('EB2', 'edge', ('connector', {'name': 'edge', 'role':
'edge', 'port': edge_port_B}))
+
+cls.routers[0].wait_router_connected('INT.B')
+cls.routers[1].wait_router_connected('INT.A')
+
+
+def test_01_sender_first_primary_same_interior(self):
+test = SenderFirstTest(self.routers[0].addresses[0],
+ self.routers[0].addresses[0],
+ 'dest.01', False)
+test.run()
+self.assertEqual(None, test.error)
+
+def test_02_sender_first_alternate_same_interior(self):
+test = SenderFirstTest(self.routers[0].addresses[0],
+ self.routers[0].addresses[0],
+ 'dest.02', True)
+test.run()
+self.assertEqual(None, test.error)
+
+def test_03_sender_first_primary_same_edge(self):
+test = SenderFirstTest(self.routers[2].addresses[0],
+ self.routers[2].addresses[0
[jira] [Commented] (DISPATCH-1337) Alternate Destination for Unreachable Addresses
[
https://issues.apache.org/jira/browse/DISPATCH-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16844015#comment-16844015
]
Gordon Sim commented on DISPATCH-1337:
--
Do you see some concrete use-case for waypoint+alternate? If not might it be
better to have a config that presents them as alternatives? (At a high level
they are quite similar)
> Alternate Destination for Unreachable Addresses
> ---
>
> Key: DISPATCH-1337
> URL: https://issues.apache.org/jira/browse/DISPATCH-1337
> Project: Qpid Dispatch
> Issue Type: New Feature
> Components: Router Node
>Reporter: Ted Ross
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.8.0
>
>
> This feature allows addresses to be configured such that an alternate
> destination can be used to receive messages that are not deliverable to any
> normal consumers on the address.
> Typically, this feature will be used to allow a message broker to store
> messages that are not routable directly to consumers. When one or more
> consumers are attached in the router network, messages shall be delivered
> directly to the consumers. Where there are no reachable consumers,
> deliveries shall then be diverted to the alternate destination. Once
> consumers re-connect to the network, messages shall again be delivered
> directly.
> When a consumer comes online after messages have been stored in a broker, it
> shall receive the stored messages interleaved with new messages from
> producers. No attempt shall be made by the router network to preserve the
> original delivery order of the messages.
> This feature can be configured by adding the attribute
> {noformat}
> alternate: yes
> {noformat}
> to an address configuration. This attribute tells the router that any
> address matching the configuration that appears shall support the alternate
> destination capability.
> There are two ways to create an alternate destination for an address:
> Using auto-links:
> An auto-link (or a pair of auto-links) can be configured to create an
> alternate waypoint for an address. For example, assume that there is a
> route-container connector or listener for a broker called "alternate-broker".
> {noformat}
> address {
> prefix: position_update
> alternate: yes
> }
> autoLink {
> address: position_update.338
> direction: in
> connection: alternate-broker
> alternate: yes
> }
> autoLink {
> address: position_update.338
> direction: out
> connection: alternate-broker
> alternate: yes
> }
> {noformat}
> The above configuration will use a queue on the broker called
> "position_update.338" as the alternate destination for direct consumers.
> Furthermore, since there are both _in_ and _out_ auto-links, the router(s)
> shall send queued messages to newly attached direct consumers.
> Using terminus capabilities:
> As al alternative to using autl-links, the broker (or any other process) can
> attach sending and receiving links to the address with terminus-capability
> "qd.alternate". This will create the same behavior as the above example.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1337) Alternate Destination for Unreachable Addresses
[
https://issues.apache.org/jira/browse/DISPATCH-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16843998#comment-16843998
]
Ted Ross commented on DISPATCH-1337:
To be clear: The reason waypoint+alternate is not supported in the PR is
because there isn't a test for it yet.
> Alternate Destination for Unreachable Addresses
> ---
>
> Key: DISPATCH-1337
> URL: https://issues.apache.org/jira/browse/DISPATCH-1337
> Project: Qpid Dispatch
> Issue Type: New Feature
> Components: Router Node
>Reporter: Ted Ross
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.8.0
>
>
> This feature allows addresses to be configured such that an alternate
> destination can be used to receive messages that are not deliverable to any
> normal consumers on the address.
> Typically, this feature will be used to allow a message broker to store
> messages that are not routable directly to consumers. When one or more
> consumers are attached in the router network, messages shall be delivered
> directly to the consumers. Where there are no reachable consumers,
> deliveries shall then be diverted to the alternate destination. Once
> consumers re-connect to the network, messages shall again be delivered
> directly.
> When a consumer comes online after messages have been stored in a broker, it
> shall receive the stored messages interleaved with new messages from
> producers. No attempt shall be made by the router network to preserve the
> original delivery order of the messages.
> This feature can be configured by adding the attribute
> {noformat}
> alternate: yes
> {noformat}
> to an address configuration. This attribute tells the router that any
> address matching the configuration that appears shall support the alternate
> destination capability.
> There are two ways to create an alternate destination for an address:
> Using auto-links:
> An auto-link (or a pair of auto-links) can be configured to create an
> alternate waypoint for an address. For example, assume that there is a
> route-container connector or listener for a broker called "alternate-broker".
> {noformat}
> address {
> prefix: position_update
> alternate: yes
> }
> autoLink {
> address: position_update.338
> direction: in
> connection: alternate-broker
> alternate: yes
> }
> autoLink {
> address: position_update.338
> direction: out
> connection: alternate-broker
> alternate: yes
> }
> {noformat}
> The above configuration will use a queue on the broker called
> "position_update.338" as the alternate destination for direct consumers.
> Furthermore, since there are both _in_ and _out_ auto-links, the router(s)
> shall send queued messages to newly attached direct consumers.
> Using terminus capabilities:
> As al alternative to using autl-links, the broker (or any other process) can
> attach sending and receiving links to the address with terminus-capability
> "qd.alternate". This will create the same behavior as the above example.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1337) Alternate Destination for Unreachable Addresses
[
https://issues.apache.org/jira/browse/DISPATCH-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16843994#comment-16843994
]
Ted Ross commented on DISPATCH-1337:
{quote}What is the behaviour if both the `alternate` and `waypoint` are set to
true? (Is that an allowed configuration?)
{quote}
In the current pull-request, this is not fully supported. If both are
specified, the alternate-destination behavior will be applied only to the
"ingress" phase. In other words, if the waypoint isn't reachable, the alternate
destination will be used. If the alternate destination is itself a waypoint, it
will feed messages to the primary waypoint (on in ingress phase) once the
primary waypoint is reachable.
Note that there is a related bug (Jira pending) wherein multiple terminus
capabilities are not supported. Until this is fixed, the only way _waypoint_
and _alternate_ can be specified together is via an auto-link.
{quote}Does specifying the `qd.alternate` capability on a link require special
permission?
{quote}
Yes, it should. This is not yet implemented in the pull request.
{quote}Can it only be requested on route-container connections?
{quote}
The _waypoint_ and _alternate_ terminus capabilities may be used on normal
connections as well as route-container connections.
> Alternate Destination for Unreachable Addresses
> ---
>
> Key: DISPATCH-1337
> URL: https://issues.apache.org/jira/browse/DISPATCH-1337
> Project: Qpid Dispatch
> Issue Type: New Feature
> Components: Router Node
>Reporter: Ted Ross
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.8.0
>
>
> This feature allows addresses to be configured such that an alternate
> destination can be used to receive messages that are not deliverable to any
> normal consumers on the address.
> Typically, this feature will be used to allow a message broker to store
> messages that are not routable directly to consumers. When one or more
> consumers are attached in the router network, messages shall be delivered
> directly to the consumers. Where there are no reachable consumers,
> deliveries shall then be diverted to the alternate destination. Once
> consumers re-connect to the network, messages shall again be delivered
> directly.
> When a consumer comes online after messages have been stored in a broker, it
> shall receive the stored messages interleaved with new messages from
> producers. No attempt shall be made by the router network to preserve the
> original delivery order of the messages.
> This feature can be configured by adding the attribute
> {noformat}
> alternate: yes
> {noformat}
> to an address configuration. This attribute tells the router that any
> address matching the configuration that appears shall support the alternate
> destination capability.
> There are two ways to create an alternate destination for an address:
> Using auto-links:
> An auto-link (or a pair of auto-links) can be configured to create an
> alternate waypoint for an address. For example, assume that there is a
> route-container connector or listener for a broker called "alternate-broker".
> {noformat}
> address {
> prefix: position_update
> alternate: yes
> }
> autoLink {
> address: position_update.338
> direction: in
> connection: alternate-broker
> alternate: yes
> }
> autoLink {
> address: position_update.338
> direction: out
> connection: alternate-broker
> alternate: yes
> }
> {noformat}
> The above configuration will use a queue on the broker called
> "position_update.338" as the alternate destination for direct consumers.
> Furthermore, since there are both _in_ and _out_ auto-links, the router(s)
> shall send queued messages to newly attached direct consumers.
> Using terminus capabilities:
> As al alternative to using autl-links, the broker (or any other process) can
> attach sending and receiving links to the address with terminus-capability
> "qd.alternate". This will create the same behavior as the above example.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1337) Alternate Destination for Unreachable Addresses
[
https://issues.apache.org/jira/browse/DISPATCH-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16843981#comment-16843981
]
Gordon Sim commented on DISPATCH-1337:
--
What is the behaviour if both the `alternate` and `waypoint` are set to true?
(Is that an allowed configuration?)
Does specifying the `qd.alternate` capability on a link require special
permission? Can it only be requested on route-container connections?
> Alternate Destination for Unreachable Addresses
> ---
>
> Key: DISPATCH-1337
> URL: https://issues.apache.org/jira/browse/DISPATCH-1337
> Project: Qpid Dispatch
> Issue Type: New Feature
> Components: Router Node
>Reporter: Ted Ross
>Assignee: Ted Ross
>Priority: Major
> Fix For: 1.8.0
>
>
> This feature allows addresses to be configured such that an alternate
> destination can be used to receive messages that are not deliverable to any
> normal consumers on the address.
> Typically, this feature will be used to allow a message broker to store
> messages that are not routable directly to consumers. When one or more
> consumers are attached in the router network, messages shall be delivered
> directly to the consumers. Where there are no reachable consumers,
> deliveries shall then be diverted to the alternate destination. Once
> consumers re-connect to the network, messages shall again be delivered
> directly.
> When a consumer comes online after messages have been stored in a broker, it
> shall receive the stored messages interleaved with new messages from
> producers. No attempt shall be made by the router network to preserve the
> original delivery order of the messages.
> This feature can be configured by adding the attribute
> {noformat}
> alternate: yes
> {noformat}
> to an address configuration. This attribute tells the router that any
> address matching the configuration that appears shall support the alternate
> destination capability.
> There are two ways to create an alternate destination for an address:
> Using auto-links:
> An auto-link (or a pair of auto-links) can be configured to create an
> alternate waypoint for an address. For example, assume that there is a
> route-container connector or listener for a broker called "alternate-broker".
> {noformat}
> address {
> prefix: position_update
> alternate: yes
> }
> autoLink {
> address: position_update.338
> direction: in
> connection: alternate-broker
> alternate: yes
> }
> autoLink {
> address: position_update.338
> direction: out
> connection: alternate-broker
> alternate: yes
> }
> {noformat}
> The above configuration will use a queue on the broker called
> "position_update.338" as the alternate destination for direct consumers.
> Furthermore, since there are both _in_ and _out_ auto-links, the router(s)
> shall send queued messages to newly attached direct consumers.
> Using terminus capabilities:
> As al alternative to using autl-links, the broker (or any other process) can
> attach sending and receiving links to the address with terminus-capability
> "qd.alternate". This will create the same behavior as the above example.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-457) Failed send to disconnected connection leaves message in a read only state
[ https://issues.apache.org/jira/browse/QPIDJMS-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16843837#comment-16843837 ] ASF subversion and git services commented on QPIDJMS-457: - Commit 1bd30cab4c53ad9da3c6d39a5e7081e7a127081e in qpid-jms's branch refs/heads/master from Robert Gemmell [ https://gitbox.apache.org/repos/asf?p=qpid-jms.git;h=1bd30ca ] QPIDJMS-457: protect against potential NPE > Failed send to disconnected connection leaves message in a read only state > -- > > Key: QPIDJMS-457 > URL: https://issues.apache.org/jira/browse/QPIDJMS-457 > Project: Qpid JMS > Issue Type: Task > Components: qpid-jms-client >Affects Versions: 0.42.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Minor > Fix For: 0.43.0 > > > If a message is sent using a producer that whose underlying connection has > already failed the message is left in a read-only state and cannot be resent > to another producer afterwards. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-8296) [JMS AMQP 0-x] Release 6.3.4 version of Qpid JMS client for AMQP 0-x
[ https://issues.apache.org/jira/browse/QPID-8296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy closed QPID-8296. Resolution: Done > [JMS AMQP 0-x] Release 6.3.4 version of Qpid JMS client for AMQP 0-x > > > Key: QPID-8296 > URL: https://issues.apache.org/jira/browse/QPID-8296 > Project: Qpid > Issue Type: Task > Components: JMS AMQP 0-x >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-client-0-x-6.3.4 > > > Release Qpid JMS AMQP 0-x client following instructions > [here|https://cwiki.apache.org/confluence/display/qpid/Releasing+Qpid+JMS+AMQP+0-x] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[ANNOUNCE] Apache Qpid JMS AMQP 0-x 6.3.4 released
The Apache Qpid (http://qpid.apache.org) community is pleased to announce the immediate availability of version 6.3.4 of Apache Qpid JMS for AMQP 0-x. This is the latest release of our legacy JMS client supporting AMQP 0-8, 0-9, 0-9-1 and 0-10. The release is available now from our website: http://qpid.apache.org/download.html Binaries are also available via Maven Central: http://qpid.apache.org/maven.html Release notes can be found at: http://qpid.apache.org/releases/qpid-jms-amqp-0-x-6.3.4/release-notes.html The Apache Qpid community strongly suggests to use our new JMS client (http://qpid.apache.org/components/jms/index.html) supporting AMQP 1.0 for development of new applications. Thanks to all involved, Alex - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8255) [JMS AMQP 0-x] Connection failure with connection option 'client_cert_priv_key_path' and java 11
[
https://issues.apache.org/jira/browse/QPID-8255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy resolved QPID-8255.
--
Resolution: Fixed
> [JMS AMQP 0-x] Connection failure with connection option
> 'client_cert_priv_key_path' and java 11
> -
>
> Key: QPID-8255
> URL: https://issues.apache.org/jira/browse/QPID-8255
> Project: Qpid
> Issue Type: Bug
> Components: JMS AMQP 0-x
>Affects Versions: qpid-java-client-0-x-6.3.3
> Environment: java11
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-client-0-x-6.3.4, qpid-java-client-0-x-6.4.0
>
>
> Connection establishment fails with java 11 when connection option
> 'client_cert_priv_key_path' is used:
> {noformat}
> javax.jms.JMSException: Error creating connection: Key protection algorithm
> not found: java.security.UnrecoverableKeyException: Encrypt Private Key
> failed: getSecretKey failed: Password is not ASCII
> at
> org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:169)
> at
> org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:143)
> at
> org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:57)
> at
> org.apache.qpid.systests.QpidJmsClient0xConnectionBuilder.build(QpidJmsClient0xConnectionBuilder.java:270)
> at
> org.apache.qpid.systests.jms_1_1.extensions.tls.TlsTest.testCreateSSLWithCertFileAndPrivateKey(TlsTest.java:508)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at
> org.apache.qpid.tests.utils.QpidTestRunner.runChild(QpidTestRunner.java:84)
> at
> org.apache.qpid.tests.utils.QpidTestRunner.runChild(QpidTestRunner.java:28)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.apache.qpid.tests.utils.QpidTestRunner.run(QpidTestRunner.java:59)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: org.apache.qpid.AMQConnectionFailureException: Key protection
> algorithm not found: java.security.UnrecoverableKeyException: Encrypt Private
> Key failed: getSecretKey failed: Password is not ASCII
> at
> org.apache.qpid.client.AMQConnection.makeConnection(AMQConnection.java:672)
> at org.apache.qpid.client.AMQConnection.(AMQConnection.java:522)
> at
> org.apache.qpid.client.AMQConnectionFactory.createConnection(AMQConnectionFactory.java:164)
> ... 32 more
> Caused by: org.apache.qpid.transport.TransportException: Error creating SSL
> Context
> at
> org.apache.qpid.transport.network.security.SecurityLayerFactory$SSLSecurityLayer.(SecurityLayerFactory.java:100)
> at
> org.apache.qpid.transport.network.security.SecurityLayerFactory.newInstance(SecurityLayerFactory.java:59)
> at
> org.apache.qpid.
[jira] [Resolved] (QPID-8283) [JMS AMQP 0-x] Connection option 'encryption_trust_store_password' is mistakenly used to set encryption keystore password rather than encryption trust store password as i
[
https://issues.apache.org/jira/browse/QPID-8283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy resolved QPID-8283.
--
Resolution: Fixed
> [JMS AMQP 0-x] Connection option 'encryption_trust_store_password' is
> mistakenly used to set encryption keystore password rather than encryption
> trust store password as intendant
> ---
>
> Key: QPID-8283
> URL: https://issues.apache.org/jira/browse/QPID-8283
> Project: Qpid
> Issue Type: Bug
> Components: JMS AMQP 0-x
>Affects Versions: qpid-java-6.1.6, qpid-java-6.0, qpid-java-6.0.1,
> qpid-java-6.0.2, qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5,
> qpid-java-6.1, qpid-java-6.0.6, qpid-java-6.1.1, qpid-java-6.1.2,
> qpid-java-6.0.7, qpid-java-6.1.3, qpid-java-6.0.8, qpid-java-6.1.4,
> qpid-java-client-0-x-6.3.0, qpid-java-6.1.5, qpid-java-client-0-x-6.3.1,
> qpid-java-6.1.7, qpid-java-client-0-x-6.3.2, qpid-java-client-0-x-6.3.3
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-client-0-x-6.3.4
>
>
> Connection option {{encryption_trust_store_password}} is mistakenly used to
> set encryption keystore password rather than encryption trust store password
> as intendant.
> Here is problematic code in {{BrokerDetails}}:
> {code}
> if
> (getProperty(BrokerDetails.OPTIONS_ENCRYPTION_TRUST_STORE_PASSWORD) != null)
> {
> conSettings.setEncryptionKeyStorePassword(
>
> getProperty(BrokerDetails.OPTIONS_ENCRYPTION_TRUST_STORE_PASSWORD));
> }
> {code}
> Method {{conSettings.setEncryptionTrustStorePassword}} should be invoked
> instead.
> The workaround for this issue is to set trust store password using JVM
> property {{javax.net.ssl.trustStorePassword}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8285) [JMS AMQP 0-x] Deadlock during receiveMessage when broker connecton fails
[ https://issues.apache.org/jira/browse/QPID-8285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-8285. -- Resolution: Fixed > [JMS AMQP 0-x] Deadlock during receiveMessage when broker connecton fails > - > > Key: QPID-8285 > URL: https://issues.apache.org/jira/browse/QPID-8285 > Project: Qpid > Issue Type: Bug > Components: JMS AMQP 0-x > Environment: * Java 1.8.0_20, 1.8.0_192, & 1.8.0_172 > * Linux 4.9.0-4-amd64 & 3.10.0-327.13 > * qpidd 1.39.0 >Reporter: Jonathan Beales >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-client-0-x-6.3.4 > > Attachments: qpid_jms_deaklock.patch > > > When a JMS MessageConsumer calls receiveMessage with a timeout, if no message > is received during the timeout, > BasicMessageConsumer_0_10.getMessageFromQueue() calls the syncDispatchQueue() > method. As not the dispatcher thread, the consumer waits on a method local > CountDownLatch which should be decremented when the AMQSession.Dispatcher > thread calls dispatch(). > In the AMQSession.Dispatcher thread, the core loop will stop pulling from the > queue to dispatch messages when the connection to the broker is lost > (isClosing() becomes true). > In this scenario, the receiveMessage call is waiting forever because the > Dispatcher will never call dispatch. This also leaves the Dispatcher thread > in an infinite loop (using 100% CPU) waiting to be fully closed. > This can fixed by allowing the AMQSession.Dispatcher to always dispatch > remaining queue content to ensure a consumer is not waiting forever (see > attached). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8282) [JMS AMQP 0-x] Java 11 build/runtime failure due to use of javax.xml.bind.DatatypeConverter
[ https://issues.apache.org/jira/browse/QPID-8282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-8282. -- Resolution: Fixed > [JMS AMQP 0-x] Java 11 build/runtime failure due to use of > javax.xml.bind.DatatypeConverter > --- > > Key: QPID-8282 > URL: https://issues.apache.org/jira/browse/QPID-8282 > Project: Qpid > Issue Type: Bug > Components: JMS AMQP 0-x >Affects Versions: qpid-java-client-0-x-6.3.3 >Reporter: Robbie Gemmell >Assignee: Alex Rudyy >Priority: Minor > Fix For: qpid-java-client-0-x-6.3.4, qpid-java-client-0-x-6.4.0 > > > In setting up a new system, I happened to make attempt to build the JMS AMQP > 0-x client using Java 11. It failed to compile due to use of > javax.xml.bind.DatatypeConverter for Base64 handling in the SCRAM-SHA > mechanisms. This prevents building on Java 11, and would break use of > SCRAM-SHA while running on Java 11 assuming nothing else stopped things > working. > Although the 0-x client is essentially in maintenance/legacy mode at this > point, blockers as trivial as Base 64 handling would be nice to resolved if > it made using Java 11 possible, if only to simplify migrations later. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2041) [Python] Dispatch tests fail
[
https://issues.apache.org/jira/browse/PROTON-2041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated PROTON-2041:
---
Fix Version/s: (was: proton-c-0.28.0)
> [Python] Dispatch tests fail
>
>
> Key: PROTON-2041
> URL: https://issues.apache.org/jira/browse/PROTON-2041
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: proton-c-0.28.0
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
>Priority: Major
>
> {{{color:#00}39:
> =={color}}}
> {{{color:#00}39: ERROR: tearDownClass
> (system_tests_authz_service_plugin.AuthServicePluginAuthzTest){color}}}
> {{{color:#00}39:
> --{color}}}
> {{{color:#00}39: Traceback (most recent call last):{color}}}
> {{{color:#00}39: File
> "/home/travis/build/apache/qpid-dispatch/tests/system_test.py", line 609, in
> tearDownClass{color}}}
> {{{color:#00}39: cls.tester.teardown(){color}}}
> {{{color:#00}39: File
> "/home/travis/build/apache/qpid-dispatch/tests/system_test.py", line 555, in
> teardown{color}}}
> {{{color:#00}39: raise RuntimeError("Errors during teardown: \n\n%s"
> % "\n\n".join([str(e) for e in errors])){color}}}
> {{{color:#00}39: RuntimeError: Errors during teardown: {color}}}
> {{{color:#00}39: {color}}}
> {{{color:#00}39: Process 16854 error: exit code 1, expected 0{color}}}
> {{{color:#00}39: /usr/bin/env python
> /home/travis/build/apache/qpid-dispatch/tests/authservice.py -a
> amqps://{color}[127.0.0.1:20571|http://127.0.0.1:20571/]{color:#00} -c
> /home/travis/build/apache/qpid-dispatch/build/tests/system_test.dir/system_tests_authz_service_plugin/AuthServicePluginAuthzTest/setUpClass{color}}}
> {{{color:#00}39:
> /home/travis/build/apache/qpid-dispatch/build/tests/system_test.dir/system_tests_authz_service_plugin/AuthServicePluginAuthzTest/setUpClass/env-2.cmd{color}}}
> {{{color:#00}39: {color}}}
> {{{color:#00}39: starting{color}}}
> {{{color:#00}39: set sasl config path to
> /home/travis/build/apache/qpid-dispatch/build/tests/system_test.dir/system_tests_authz_service_plugin/AuthServicePluginAuthzTest/setUpClass{color}}}
> {{{color:#00}39: Traceback (most recent call last):{color}}}
> {{{color:#00}39: File
> "/home/travis/build/apache/qpid-dispatch/tests/authservice.py", line 95, in
> {color}}}
> {{{color:#00}39: Container(handler).run(){color}}}
> {{{color:#00}39: File
> "/home/travis/build/apache/qpid-dispatch/qpid-proton/python/proton/_reactor.py",
> line 181, in run{color}}}
> {{{color:#00}39: while self.process(): pass{color}}}
> {{{color:#00}39: File
> "/home/travis/build/apache/qpid-dispatch/qpid-proton/python/proton/_reactor.py",
> line 240, in process{color}}}
> {{{color:#00}39: event.dispatch(self._global_handler){color}}}
> {{{color:#00}39: File
> "/home/travis/build/apache/qpid-dispatch/qpid-proton/python/proton/_events.py",
> line 135, in dispatch{color}}}
> {{{color:#00}39: _dispatch(handler, type.method, self){color}}}
> {{{color:#00}39: File
> "/home/travis/build/apache/qpid-dispatch/qpid-proton/python/proton/_events.py",
> line 117, in _dispatch{color}}}
> {{{color:#00}39: handler.on_unhandled(method, *args){color}}}
> {{{color:#00}39: File
> "/home/travis/build/apache/qpid-dispatch/qpid-proton/python/proton/_reactor.py",
> line 665, in on_unhandled{color}}}
> {{{color:#00}39: event.dispatch(self.base){color}}}
> {{{color:#00}39: File
> "/home/travis/build/apache/qpid-dispatch/qpid-proton/python/proton/_events.py",
> line 135, in dispatch{color}}}
> {{{color:#00}39: _dispatch(handler, type.method, self){color}}}
> {{{color:#00}39: File
> "/home/travis/build/apache/qpid-dispatch/qpid-proton/python/proton/_events.py",
> line 115, in _dispatch{color}}}
> {{{color:#00}39: m(*args){color}}}
> {{{color:#00}39: File
> "/home/travis/build/apache/qpid-dispatch/qpid-proton/python/proton/_handlers.py",
> line 771, in on_reactor_quiesced{color}}}
> {{{color:#00}39: readable, writable, expired =
> self._selector.select(r.timeout){color}}}
> {{{color:#00}39: File
> "/home/travis/build/apache/qpid-dispatch/qpid-proton/python/proton/_io.py",
> line 163, in select{color}}}
> {{{color:#00}39: w += ex{color}}}
> {{{color:#00}39: UnboundLocalError: local variable 'ex' referenced before
> assignment{color}}}
> {{{color:#00}39: {color}}}
> {{{color:#00}39: {color}}}
> {{{color:#00}39:
> --{color}}}
> {{{color:#00}39
[jira] [Closed] (PROTON-2041) [Python] Dispatch tests fail
[
https://issues.apache.org/jira/browse/PROTON-2041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell closed PROTON-2041.
--
> [Python] Dispatch tests fail
>
>
> Key: PROTON-2041
> URL: https://issues.apache.org/jira/browse/PROTON-2041
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
>Affects Versions: proton-c-0.28.0
>Reporter: Andrew Stitcher
>Assignee: Andrew Stitcher
>Priority: Major
>
> {{{color:#00}39:
> =={color}}}
> {{{color:#00}39: ERROR: tearDownClass
> (system_tests_authz_service_plugin.AuthServicePluginAuthzTest){color}}}
> {{{color:#00}39:
> --{color}}}
> {{{color:#00}39: Traceback (most recent call last):{color}}}
> {{{color:#00}39: File
> "/home/travis/build/apache/qpid-dispatch/tests/system_test.py", line 609, in
> tearDownClass{color}}}
> {{{color:#00}39: cls.tester.teardown(){color}}}
> {{{color:#00}39: File
> "/home/travis/build/apache/qpid-dispatch/tests/system_test.py", line 555, in
> teardown{color}}}
> {{{color:#00}39: raise RuntimeError("Errors during teardown: \n\n%s"
> % "\n\n".join([str(e) for e in errors])){color}}}
> {{{color:#00}39: RuntimeError: Errors during teardown: {color}}}
> {{{color:#00}39: {color}}}
> {{{color:#00}39: Process 16854 error: exit code 1, expected 0{color}}}
> {{{color:#00}39: /usr/bin/env python
> /home/travis/build/apache/qpid-dispatch/tests/authservice.py -a
> amqps://{color}[127.0.0.1:20571|http://127.0.0.1:20571/]{color:#00} -c
> /home/travis/build/apache/qpid-dispatch/build/tests/system_test.dir/system_tests_authz_service_plugin/AuthServicePluginAuthzTest/setUpClass{color}}}
> {{{color:#00}39:
> /home/travis/build/apache/qpid-dispatch/build/tests/system_test.dir/system_tests_authz_service_plugin/AuthServicePluginAuthzTest/setUpClass/env-2.cmd{color}}}
> {{{color:#00}39: {color}}}
> {{{color:#00}39: starting{color}}}
> {{{color:#00}39: set sasl config path to
> /home/travis/build/apache/qpid-dispatch/build/tests/system_test.dir/system_tests_authz_service_plugin/AuthServicePluginAuthzTest/setUpClass{color}}}
> {{{color:#00}39: Traceback (most recent call last):{color}}}
> {{{color:#00}39: File
> "/home/travis/build/apache/qpid-dispatch/tests/authservice.py", line 95, in
> {color}}}
> {{{color:#00}39: Container(handler).run(){color}}}
> {{{color:#00}39: File
> "/home/travis/build/apache/qpid-dispatch/qpid-proton/python/proton/_reactor.py",
> line 181, in run{color}}}
> {{{color:#00}39: while self.process(): pass{color}}}
> {{{color:#00}39: File
> "/home/travis/build/apache/qpid-dispatch/qpid-proton/python/proton/_reactor.py",
> line 240, in process{color}}}
> {{{color:#00}39: event.dispatch(self._global_handler){color}}}
> {{{color:#00}39: File
> "/home/travis/build/apache/qpid-dispatch/qpid-proton/python/proton/_events.py",
> line 135, in dispatch{color}}}
> {{{color:#00}39: _dispatch(handler, type.method, self){color}}}
> {{{color:#00}39: File
> "/home/travis/build/apache/qpid-dispatch/qpid-proton/python/proton/_events.py",
> line 117, in _dispatch{color}}}
> {{{color:#00}39: handler.on_unhandled(method, *args){color}}}
> {{{color:#00}39: File
> "/home/travis/build/apache/qpid-dispatch/qpid-proton/python/proton/_reactor.py",
> line 665, in on_unhandled{color}}}
> {{{color:#00}39: event.dispatch(self.base){color}}}
> {{{color:#00}39: File
> "/home/travis/build/apache/qpid-dispatch/qpid-proton/python/proton/_events.py",
> line 135, in dispatch{color}}}
> {{{color:#00}39: _dispatch(handler, type.method, self){color}}}
> {{{color:#00}39: File
> "/home/travis/build/apache/qpid-dispatch/qpid-proton/python/proton/_events.py",
> line 115, in _dispatch{color}}}
> {{{color:#00}39: m(*args){color}}}
> {{{color:#00}39: File
> "/home/travis/build/apache/qpid-dispatch/qpid-proton/python/proton/_handlers.py",
> line 771, in on_reactor_quiesced{color}}}
> {{{color:#00}39: readable, writable, expired =
> self._selector.select(r.timeout){color}}}
> {{{color:#00}39: File
> "/home/travis/build/apache/qpid-dispatch/qpid-proton/python/proton/_io.py",
> line 163, in select{color}}}
> {{{color:#00}39: w += ex{color}}}
> {{{color:#00}39: UnboundLocalError: local variable 'ex' referenced before
> assignment{color}}}
> {{{color:#00}39: {color}}}
> {{{color:#00}39: {color}}}
> {{{color:#00}39:
> --{color}}}
> {{{color:#00}39: Ran 10 tests in 1.121s{color}}}
> {{{color:#00
[jira] [Closed] (PROTON-2026) reconnect is broken
[ https://issues.apache.org/jira/browse/PROTON-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed PROTON-2026. -- > reconnect is broken > --- > > Key: PROTON-2026 > URL: https://issues.apache.org/jira/browse/PROTON-2026 > Project: Qpid Proton > Issue Type: Sub-task > Components: python-binding >Affects Versions: proton-c-0.28.0 >Reporter: Gordon Sim >Assignee: Andrew Stitcher >Priority: Blocker > > E.g. try running simple_recv.py against a server that is not there. Up to > 0.27.0 it would keep trying, on master now it exists with a socket error. > Also, likely related, up to 0.27.0 you would always get an > on_transport_closed in this case, but on master you no longer do. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
