[jira] [Closed] (PROTON-522) Apache Qpid Proton on Mac/OSX - C/Objective-C
[ https://issues.apache.org/jira/browse/PROTON-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roddie Kieley closed PROTON-522. Resolution: Implemented Assignee: Roddie Kieley Fix Version/s: proton-c-0.19.0 [~justi9] While there are many improvements that can be made, the basic functionality works as advertised. As well a MacPorts Portfile has been added for [qpid-proton|https://github.com/macports/macports-ports/blob/v2.5.0-archive/net/qpid-proton/Portfile] that has been actively [maintained|https://github.com/macports/macports-ports/pulls?utf8=%E2%9C%93=is%3Apr+is%3Aclosed+qpid-proton] since 0.19.0. Closing. > Apache Qpid Proton on Mac/OSX - C/Objective-C > - > > Key: PROTON-522 > URL: https://issues.apache.org/jira/browse/PROTON-522 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Reporter: Guy Dillen >Assignee: Roddie Kieley >Priority: Major > Labels: osx > Fix For: proton-c-0.19.0 > > > I would like using Apache Qpid Proton-C from a C or Objective-C application > on Mac/OSX to connect as a client to Windows Azure Service Bus. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-1801) Strip the version from the /usr/share/proton dir
[ https://issues.apache.org/jira/browse/PROTON-1801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross reassigned PROTON-1801: --- Assignee: Justin Ross > Strip the version from the /usr/share/proton dir > > > Key: PROTON-1801 > URL: https://issues.apache.org/jira/browse/PROTON-1801 > Project: Qpid Proton > Issue Type: Task > Components: proton-c >Reporter: Justin Ross >Assignee: Justin Ross >Priority: Major > > It's contrary to the dominant convention, and it litters /usr/share with old > dirs. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-522) Apache Qpid Proton on Mac/OSX - C/Objective-C
[ https://issues.apache.org/jira/browse/PROTON-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845241#comment-16845241 ] Justin Ross commented on PROTON-522: [~rkieley] should this remain open? > Apache Qpid Proton on Mac/OSX - C/Objective-C > - > > Key: PROTON-522 > URL: https://issues.apache.org/jira/browse/PROTON-522 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Reporter: Guy Dillen >Priority: Major > Labels: osx > > I would like using Apache Qpid Proton-C from a C or Objective-C application > on Mac/OSX to connect as a client to Windows Azure Service Bus. -- 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=16845235#comment-16845235
]
Justin Ross commented on DISPATCH-1337:
---
After we talked about this today, the terminology that really helped me
understand the feature was "fallback links". This is not about fallback
*addresses*. Rather, an address can have 0..n fallback links that consume
deliveries only if no other (primary, non-fallback) consuming link is present.
The fallback-ness is associated with the link, not the address.
The *enablement* of fallback behavior *is* associated with an address prefix.
I think this does introduce a bit of confusion. But it's not the main thing
conceptually. The stuff in the paragraph above is the important part.
> 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] [Commented] (QPIDJMS-458) Potential race condition in JmsConnection.destroyResource
[
https://issues.apache.org/jira/browse/QPIDJMS-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845050#comment-16845050
]
Christian Danner commented on QPIDJMS-458:
--
That's interesting - we do not currently set any special client side URL
parameters, the connect URL basically looks like this:
amqp://127.0.0.1:5667?jms.clientID=node1=0
We will continue testing edge cases in the next days - I will let you know if
we are able to reproduce this situation.
> Potential race condition in JmsConnection.destroyResource
> -
>
> Key: QPIDJMS-458
> URL: https://issues.apache.org/jira/browse/QPIDJMS-458
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.42.0
> Environment: OS: Windows 10 64Bit
> Broker: Apache Artemis 2.8.0
> JVM: Java HotSpot(TM) Client VM (25.40-b25, mixed mode)
> Java: version 1.8.0_40, vendor Oracle Corporation
>Reporter: Christian Danner
>Priority: Major
>
> It seems there is a race condition when attempting to close a
> JmsMessageProducer as indicated by the stack trace below. The corresponding
> Thread is stuck waiting for the JmsMessageProducer to be destroyed for a
> JmsConnection.
> This behaviour was observed while testing Apache Artemis with low disk space.
> In the provided trace we attempt to close a broker connection due to a
> JMSException (TransactionRolledBackException caused by a duplicate message
> ID), however the Thread gets stuck indefinitely waiting for the
> JmsMessageProducer to be destroyed.
> We keep track of all sessions for a JmsConnection (one session per Thread)
> and attempt to perform a graceful connection shutdown by closing all
> producers and consumers, followed by each session before finally calling
> close on the connection.
> We use external synchronization to ensure that the connection can only be
> closed by a single Thread (so in this example all other Threads attempting to
> use the broker connection are blocked waiting for the lock from the closing
> Thread to be released).
>
> Stack Trace:
> {{"Replicator_node1-->node2_[0ms]" #25 prio=5 os_prio=0 tid=0x49383c00
> nid=0x3918 in Object.wait() [0x4b1ef000]
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at java.lang.Object.wait(Object.java:502)
> at
> org.apache.qpid.jms.provider.BalancedProviderFuture.sync(BalancedProviderFuture.java:137)
> - locked <0x04e60300> (a
> org.apache.qpid.jms.provider.BalancedProviderFuture)
> at
> org.apache.qpid.jms.JmsConnection.destroyResource(JmsConnection.java:755)
> at
> org.apache.qpid.jms.JmsConnection.destroyResource(JmsConnection.java:744)
> at
> org.apache.qpid.jms.JmsMessageProducer.doClose(JmsMessageProducer.java:103)
> at
> org.apache.qpid.jms.JmsMessageProducer.close(JmsMessageProducer.java:89)
> at
> acme.broker.client.jms.impl.JMSMessageProducer.closeInternal(JMSMessageProducer.java:48)
> at
> acme.broker.client.jms.impl.JMSMessageProducer.close(JMSMessageProducer.java:43)
> at acme.broker.client.AbstractSession.tryClose(AbstractSession.java:108)
> at acme.broker.client.AbstractSession.close(AbstractSession.java:90)
> at
> acme.broker.client.AbstractThreadedSessionManager.close(AbstractThreadedSessionManager.java:108)
> - locked <0x1d321078> (a java.util.concurrent.ConcurrentHashMap)
> at
> acme.broker.client.AbstractBrokerConnection.closeInternal(AbstractBrokerConnection.java:204)
> at
> acme.broker.client.AbstractBrokerConnection.close(AbstractBrokerConnection.java:84)
> at
> acme.replication.jms.JMSMessageBridge.trySend(JMSMessageBridge.java:109)
> at
> acme.replication.jms.JMSMessageBridge.access$6(JMSMessageBridge.java:99)
> at
> acme.replication.jms.JMSMessageBridge$ReplicatorRunnable.run(JMSMessageBridge.java:62)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - <0x1cfa76b0> (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync)}}
--
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-458) Potential race condition in JmsConnection.destroyResource
[
https://issues.apache.org/jira/browse/QPIDJMS-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845043#comment-16845043
]
Timothy Bish commented on QPIDJMS-458:
--
The client does indeed offer timeouts for various operations one of which is
the "jms.closeTimeout" which covers this case and is tested in the client test
suite. The default timeout is 60 seconds unless you've altered that on the
connection URI.
[Documentation
page:|http://qpid.apache.org/releases/qpid-jms-0.42.0/docs/index.html]
> Potential race condition in JmsConnection.destroyResource
> -
>
> Key: QPIDJMS-458
> URL: https://issues.apache.org/jira/browse/QPIDJMS-458
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.42.0
> Environment: OS: Windows 10 64Bit
> Broker: Apache Artemis 2.8.0
> JVM: Java HotSpot(TM) Client VM (25.40-b25, mixed mode)
> Java: version 1.8.0_40, vendor Oracle Corporation
>Reporter: Christian Danner
>Priority: Major
>
> It seems there is a race condition when attempting to close a
> JmsMessageProducer as indicated by the stack trace below. The corresponding
> Thread is stuck waiting for the JmsMessageProducer to be destroyed for a
> JmsConnection.
> This behaviour was observed while testing Apache Artemis with low disk space.
> In the provided trace we attempt to close a broker connection due to a
> JMSException (TransactionRolledBackException caused by a duplicate message
> ID), however the Thread gets stuck indefinitely waiting for the
> JmsMessageProducer to be destroyed.
> We keep track of all sessions for a JmsConnection (one session per Thread)
> and attempt to perform a graceful connection shutdown by closing all
> producers and consumers, followed by each session before finally calling
> close on the connection.
> We use external synchronization to ensure that the connection can only be
> closed by a single Thread (so in this example all other Threads attempting to
> use the broker connection are blocked waiting for the lock from the closing
> Thread to be released).
>
> Stack Trace:
> {{"Replicator_node1-->node2_[0ms]" #25 prio=5 os_prio=0 tid=0x49383c00
> nid=0x3918 in Object.wait() [0x4b1ef000]
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at java.lang.Object.wait(Object.java:502)
> at
> org.apache.qpid.jms.provider.BalancedProviderFuture.sync(BalancedProviderFuture.java:137)
> - locked <0x04e60300> (a
> org.apache.qpid.jms.provider.BalancedProviderFuture)
> at
> org.apache.qpid.jms.JmsConnection.destroyResource(JmsConnection.java:755)
> at
> org.apache.qpid.jms.JmsConnection.destroyResource(JmsConnection.java:744)
> at
> org.apache.qpid.jms.JmsMessageProducer.doClose(JmsMessageProducer.java:103)
> at
> org.apache.qpid.jms.JmsMessageProducer.close(JmsMessageProducer.java:89)
> at
> acme.broker.client.jms.impl.JMSMessageProducer.closeInternal(JMSMessageProducer.java:48)
> at
> acme.broker.client.jms.impl.JMSMessageProducer.close(JMSMessageProducer.java:43)
> at acme.broker.client.AbstractSession.tryClose(AbstractSession.java:108)
> at acme.broker.client.AbstractSession.close(AbstractSession.java:90)
> at
> acme.broker.client.AbstractThreadedSessionManager.close(AbstractThreadedSessionManager.java:108)
> - locked <0x1d321078> (a java.util.concurrent.ConcurrentHashMap)
> at
> acme.broker.client.AbstractBrokerConnection.closeInternal(AbstractBrokerConnection.java:204)
> at
> acme.broker.client.AbstractBrokerConnection.close(AbstractBrokerConnection.java:84)
> at
> acme.replication.jms.JMSMessageBridge.trySend(JMSMessageBridge.java:109)
> at
> acme.replication.jms.JMSMessageBridge.access$6(JMSMessageBridge.java:99)
> at
> acme.replication.jms.JMSMessageBridge$ReplicatorRunnable.run(JMSMessageBridge.java:62)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - <0x1cfa76b0> (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync)}}
--
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-8315) update perftests visualisation csv dep to version available in maven central
[ https://issues.apache.org/jira/browse/QPID-8315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-8315. -- Resolution: Fixed > update perftests visualisation csv dep to version available in maven central > > > Key: QPID-8315 > URL: https://issues.apache.org/jira/browse/QPID-8315 > Project: Qpid > Issue Type: Task > Components: Java Performance Tests >Affects Versions: qpid-java-broker-7.1.3 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Trivial > Fix For: qpid-java-broker-7.1.4 > > > Currently the version of csv processing dep used for the visualisation module > requires defining an additional repository, but newer versions are released > to Maven Central so we should now update and use one of those instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8315) update perftests visualisation csv dep to version available in maven central
[ https://issues.apache.org/jira/browse/QPID-8315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845031#comment-16845031 ] ASF subversion and git services commented on QPID-8315: --- Commit c570f890c063762429055dcb96f7d97f6d2f6d9f in qpid-broker-j's branch refs/heads/7.1.x from Robert Gemmell [ https://gitbox.apache.org/repos/asf?p=qpid-broker-j.git;h=c570f89 ] QPID-8315: update csv handling dep to new version, available from maven central (cherry picked from commit b3e77760f2a4d9e5b8afd07a335a4384acabe969) > update perftests visualisation csv dep to version available in maven central > > > Key: QPID-8315 > URL: https://issues.apache.org/jira/browse/QPID-8315 > Project: Qpid > Issue Type: Task > Components: Java Performance Tests >Affects Versions: qpid-java-broker-7.1.3 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Trivial > Fix For: qpid-java-broker-7.1.4 > > > Currently the version of csv processing dep used for the visualisation module > requires defining an additional repository, but newer versions are released > to Maven Central so we should now update and use one of those instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8315) update perftests visualisation csv dep to version available in maven central
[ https://issues.apache.org/jira/browse/QPID-8315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845024#comment-16845024 ] ASF subversion and git services commented on QPID-8315: --- Commit b3e77760f2a4d9e5b8afd07a335a4384acabe969 in qpid-broker-j's branch refs/heads/master from Robert Gemmell [ https://gitbox.apache.org/repos/asf?p=qpid-broker-j.git;h=b3e7776 ] QPID-8315: update csv handling dep to new version, available from maven central > update perftests visualisation csv dep to version available in maven central > > > Key: QPID-8315 > URL: https://issues.apache.org/jira/browse/QPID-8315 > Project: Qpid > Issue Type: Task > Components: Java Performance Tests >Affects Versions: qpid-java-broker-7.1.3 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Trivial > Fix For: qpid-java-broker-7.1.4 > > > Currently the version of csv processing dep used for the visualisation module > requires defining an additional repository, but newer versions are released > to Maven Central so we should now update and use one of those instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8315) update perftests visualisation csv dep to version available in maven central
Robbie Gemmell created QPID-8315: Summary: update perftests visualisation csv dep to version available in maven central Key: QPID-8315 URL: https://issues.apache.org/jira/browse/QPID-8315 Project: Qpid Issue Type: Task Components: Java Performance Tests Affects Versions: qpid-java-broker-7.1.3 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: qpid-java-broker-7.1.4 Currently the version of csv processing dep used for the visualisation module requires defining an additional repository, but newer versions are released to Maven Central so we should now update and use one of those instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-458) Potential race condition in JmsConnection.destroyResource
[
https://issues.apache.org/jira/browse/QPIDJMS-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish updated QPIDJMS-458:
-
Priority: Major (was: Blocker)
> Potential race condition in JmsConnection.destroyResource
> -
>
> Key: QPIDJMS-458
> URL: https://issues.apache.org/jira/browse/QPIDJMS-458
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.42.0
> Environment: OS: Windows 10 64Bit
> Broker: Apache Artemis 2.8.0
> JVM: Java HotSpot(TM) Client VM (25.40-b25, mixed mode)
> Java: version 1.8.0_40, vendor Oracle Corporation
>Reporter: Christian Danner
>Priority: Major
>
> It seems there is a race condition when attempting to close a
> JmsMessageProducer as indicated by the stack trace below. The corresponding
> Thread is stuck waiting for the JmsMessageProducer to be destroyed for a
> JmsConnection.
> This behaviour was observed while testing Apache Artemis with low disk space.
> In the provided trace we attempt to close a broker connection due to a
> JMSException (TransactionRolledBackException caused by a duplicate message
> ID), however the Thread gets stuck indefinitely waiting for the
> JmsMessageProducer to be destroyed.
> We keep track of all sessions for a JmsConnection (one session per Thread)
> and attempt to perform a graceful connection shutdown by closing all
> producers and consumers, followed by each session before finally calling
> close on the connection.
> We use external synchronization to ensure that the connection can only be
> closed by a single Thread (so in this example all other Threads attempting to
> use the broker connection are blocked waiting for the lock from the closing
> Thread to be released).
>
> Stack Trace:
> {{"Replicator_node1-->node2_[0ms]" #25 prio=5 os_prio=0 tid=0x49383c00
> nid=0x3918 in Object.wait() [0x4b1ef000]
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at java.lang.Object.wait(Object.java:502)
> at
> org.apache.qpid.jms.provider.BalancedProviderFuture.sync(BalancedProviderFuture.java:137)
> - locked <0x04e60300> (a
> org.apache.qpid.jms.provider.BalancedProviderFuture)
> at
> org.apache.qpid.jms.JmsConnection.destroyResource(JmsConnection.java:755)
> at
> org.apache.qpid.jms.JmsConnection.destroyResource(JmsConnection.java:744)
> at
> org.apache.qpid.jms.JmsMessageProducer.doClose(JmsMessageProducer.java:103)
> at
> org.apache.qpid.jms.JmsMessageProducer.close(JmsMessageProducer.java:89)
> at
> acme.broker.client.jms.impl.JMSMessageProducer.closeInternal(JMSMessageProducer.java:48)
> at
> acme.broker.client.jms.impl.JMSMessageProducer.close(JMSMessageProducer.java:43)
> at acme.broker.client.AbstractSession.tryClose(AbstractSession.java:108)
> at acme.broker.client.AbstractSession.close(AbstractSession.java:90)
> at
> acme.broker.client.AbstractThreadedSessionManager.close(AbstractThreadedSessionManager.java:108)
> - locked <0x1d321078> (a java.util.concurrent.ConcurrentHashMap)
> at
> acme.broker.client.AbstractBrokerConnection.closeInternal(AbstractBrokerConnection.java:204)
> at
> acme.broker.client.AbstractBrokerConnection.close(AbstractBrokerConnection.java:84)
> at
> acme.replication.jms.JMSMessageBridge.trySend(JMSMessageBridge.java:109)
> at
> acme.replication.jms.JMSMessageBridge.access$6(JMSMessageBridge.java:99)
> at
> acme.replication.jms.JMSMessageBridge$ReplicatorRunnable.run(JMSMessageBridge.java:62)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - <0x1cfa76b0> (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync)}}
--
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-458) Potential race condition in JmsConnection.destroyResource
[
https://issues.apache.org/jira/browse/QPIDJMS-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845006#comment-16845006
]
Timothy Bish commented on QPIDJMS-458:
--
There's nothing in the trace that's indicative of a race. The trace indicates
the client is doing a wait on the remote end closing the AMQP link so that
isn't in itself surprising. We'd need more details here and ideally a
reproducer to determine if there's a client side issue. It would be good to
provide the connection URI you are using as well as any other details you can
in order to allow this to be investigated.
> Potential race condition in JmsConnection.destroyResource
> -
>
> Key: QPIDJMS-458
> URL: https://issues.apache.org/jira/browse/QPIDJMS-458
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.42.0
> Environment: OS: Windows 10 64Bit
> Broker: Apache Artemis 2.8.0
> JVM: Java HotSpot(TM) Client VM (25.40-b25, mixed mode)
> Java: version 1.8.0_40, vendor Oracle Corporation
>Reporter: Christian Danner
>Priority: Blocker
>
> It seems there is a race condition when attempting to close a
> JmsMessageProducer as indicated by the stack trace below. The corresponding
> Thread is stuck waiting for the JmsMessageProducer to be destroyed for a
> JmsConnection.
> This behaviour was observed while testing Apache Artemis with low disk space.
> In the provided trace we attempt to close a broker connection due to a
> JMSException (TransactionRolledBackException caused by a duplicate message
> ID), however the Thread gets stuck indefinitely waiting for the
> JmsMessageProducer to be destroyed.
> We keep track of all sessions for a JmsConnection (one session per Thread)
> and attempt to perform a graceful connection shutdown by closing all
> producers and consumers, followed by each session before finally calling
> close on the connection.
> We use external synchronization to ensure that the connection can only be
> closed by a single Thread (so in this example all other Threads attempting to
> use the broker connection are blocked waiting for the lock from the closing
> Thread to be released).
>
> Stack Trace:
> {{"Replicator_node1-->node2_[0ms]" #25 prio=5 os_prio=0 tid=0x49383c00
> nid=0x3918 in Object.wait() [0x4b1ef000]
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at java.lang.Object.wait(Object.java:502)
> at
> org.apache.qpid.jms.provider.BalancedProviderFuture.sync(BalancedProviderFuture.java:137)
> - locked <0x04e60300> (a
> org.apache.qpid.jms.provider.BalancedProviderFuture)
> at
> org.apache.qpid.jms.JmsConnection.destroyResource(JmsConnection.java:755)
> at
> org.apache.qpid.jms.JmsConnection.destroyResource(JmsConnection.java:744)
> at
> org.apache.qpid.jms.JmsMessageProducer.doClose(JmsMessageProducer.java:103)
> at
> org.apache.qpid.jms.JmsMessageProducer.close(JmsMessageProducer.java:89)
> at
> acme.broker.client.jms.impl.JMSMessageProducer.closeInternal(JMSMessageProducer.java:48)
> at
> acme.broker.client.jms.impl.JMSMessageProducer.close(JMSMessageProducer.java:43)
> at acme.broker.client.AbstractSession.tryClose(AbstractSession.java:108)
> at acme.broker.client.AbstractSession.close(AbstractSession.java:90)
> at
> acme.broker.client.AbstractThreadedSessionManager.close(AbstractThreadedSessionManager.java:108)
> - locked <0x1d321078> (a java.util.concurrent.ConcurrentHashMap)
> at
> acme.broker.client.AbstractBrokerConnection.closeInternal(AbstractBrokerConnection.java:204)
> at
> acme.broker.client.AbstractBrokerConnection.close(AbstractBrokerConnection.java:84)
> at
> acme.replication.jms.JMSMessageBridge.trySend(JMSMessageBridge.java:109)
> at
> acme.replication.jms.JMSMessageBridge.access$6(JMSMessageBridge.java:99)
> at
> acme.replication.jms.JMSMessageBridge$ReplicatorRunnable.run(JMSMessageBridge.java:62)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - <0x1cfa76b0> (a
> java.util.concurrent.locks.ReentrantLock$NonfairSync)}}
--
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=16844997#comment-16844997 ] ASF subversion and git services commented on QPIDJMS-457: - Commit c18f6ff3fb857917d4f19dcd39a82ae39f999cf6 in qpid-jms's branch refs/heads/master from Timothy Bish [ https://gitbox.apache.org/repos/asf?p=qpid-jms.git;h=c18f6ff ] QPIDJMS-457 Use connection listener to ensure wait until dropped Use a listener on the connection to wait until dropped before proceeding with the send / reconnect / send again phase of the test. > 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] [Updated] (QPIDJMS-458) Potential race condition in JmsConnection.destroyResource
[
https://issues.apache.org/jira/browse/QPIDJMS-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Danner updated QPIDJMS-458:
-
Description:
It seems there is a race condition when attempting to close a
JmsMessageProducer as indicated by the stack trace below. The corresponding
Thread is stuck waiting for the JmsMessageProducer to be destroyed for a
JmsConnection.
This behaviour was observed while testing Apache Artemis with low disk space.
In the provided trace we attempt to close a broker connection due to a
JMSException (TransactionRolledBackException caused by a duplicate message ID),
however the Thread gets stuck indefinitely waiting for the JmsMessageProducer
to be destroyed.
We keep track of all sessions for a JmsConnection (one session per Thread) and
attempt to perform a graceful connection shutdown by closing all producers and
consumers, followed by each session before finally calling close on the
connection.
We use external synchronization to ensure that the connection can only be
closed by a single Thread (so in this example all other Threads attempting to
use the broker connection are blocked waiting for the lock from the closing
Thread to be released).
Stack Trace:
{{"Replicator_node1-->node2_[0ms]" #25 prio=5 os_prio=0 tid=0x49383c00
nid=0x3918 in Object.wait() [0x4b1ef000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at
org.apache.qpid.jms.provider.BalancedProviderFuture.sync(BalancedProviderFuture.java:137)
- locked <0x04e60300> (a
org.apache.qpid.jms.provider.BalancedProviderFuture)
at
org.apache.qpid.jms.JmsConnection.destroyResource(JmsConnection.java:755)
at
org.apache.qpid.jms.JmsConnection.destroyResource(JmsConnection.java:744)
at
org.apache.qpid.jms.JmsMessageProducer.doClose(JmsMessageProducer.java:103)
at
org.apache.qpid.jms.JmsMessageProducer.close(JmsMessageProducer.java:89)
at
acme.broker.client.jms.impl.JMSMessageProducer.closeInternal(JMSMessageProducer.java:48)
at
acme.broker.client.jms.impl.JMSMessageProducer.close(JMSMessageProducer.java:43)
at acme.broker.client.AbstractSession.tryClose(AbstractSession.java:108)
at acme.broker.client.AbstractSession.close(AbstractSession.java:90)
at
acme.broker.client.AbstractThreadedSessionManager.close(AbstractThreadedSessionManager.java:108)
- locked <0x1d321078> (a java.util.concurrent.ConcurrentHashMap)
at
acme.broker.client.AbstractBrokerConnection.closeInternal(AbstractBrokerConnection.java:204)
at
acme.broker.client.AbstractBrokerConnection.close(AbstractBrokerConnection.java:84)
at
acme.replication.jms.JMSMessageBridge.trySend(JMSMessageBridge.java:109)
at
acme.replication.jms.JMSMessageBridge.access$6(JMSMessageBridge.java:99)
at
acme.replication.jms.JMSMessageBridge$ReplicatorRunnable.run(JMSMessageBridge.java:62)
at java.lang.Thread.run(Thread.java:745)
Locked ownable synchronizers:
- <0x1cfa76b0> (a
java.util.concurrent.locks.ReentrantLock$NonfairSync)}}
was:
It seems there is a race condition when attempting to close a
JmsMessageProducer as indicated by the stack trace below. The corresponding
Thread is stuck waiting for the JmsMessageProducer to be destroyed for a
JmsConnection.
This behaviour was observed while testing Apache Artemis with low disk space.
In the provided trace we attempt to close a broker connection due to a
JMSException (TransactionRolledBackException caused by a duplicate message ID),
however the Thread gets stuck indefinitely waiting for the JmsMessageProducer
to be destroyed.
We keep track of all sessions for a JmsConnection (one session per Thread) and
attempt to perform a graceful connection shutdown by closing all producers and
consumers, followed by each session before finally calling close on the
connection.
We use external synchronization to ensure that the connection can only be
closed by a single Thread (so in this example all other Threads attempting to
use the broker connection are blocked waiting for the lock from the closing
Thread to be released).
Stack Trace:
{{"Replicator_node1-->node2_[0ms]" #25 prio=5 os_prio=0 tid=0x49383c00
nid=0x3918 in Object.wait() [0x4b1ef000]}}
{{ java.lang.Thread.State: WAITING (on object monitor)}}
{{ at java.lang.Object.wait(Native Method)}}
{{ at java.lang.Object.wait(Object.java:502)}}
{{ at
org.apache.qpid.jms.provider.BalancedProviderFuture.sync(BalancedProviderFuture.java:137)}}
{{ - locked <0x04e60300> (a
org.apache.qpid.jms.provider.BalancedProviderFuture)}}
{{ at
org.apache.qpid.jms.JmsConnection.destroyResource(JmsConnection.java:755)}}
{{ at
org.apache.qpid.jms.JmsConnection.destroyResource(JmsConnection.java:744)}}
{{ at
[jira] [Created] (QPIDJMS-458) Potential race condition in JmsConnection.destroyResource
Christian Danner created QPIDJMS-458:
Summary: Potential race condition in JmsConnection.destroyResource
Key: QPIDJMS-458
URL: https://issues.apache.org/jira/browse/QPIDJMS-458
Project: Qpid JMS
Issue Type: Bug
Components: qpid-jms-client
Affects Versions: 0.42.0
Environment: OS: Windows 10 64Bit
Broker: Apache Artemis 2.8.0
JVM: Java HotSpot(TM) Client VM (25.40-b25, mixed mode)
Java: version 1.8.0_40, vendor Oracle Corporation
Reporter: Christian Danner
It seems there is a race condition when attempting to close a
JmsMessageProducer as indicated by the stack trace below. The corresponding
Thread is stuck waiting for the JmsMessageProducer to be destroyed for a
JmsConnection.
This behaviour was observed while testing Apache Artemis with low disk space.
In the provided trace we attempt to close a broker connection due to a
JMSException (TransactionRolledBackException caused by a duplicate message ID),
however the Thread gets stuck indefinitely waiting for the JmsMessageProducer
to be destroyed.
We keep track of all sessions for a JmsConnection (one session per Thread) and
attempt to perform a graceful connection shutdown by closing all producers and
consumers, followed by each session before finally calling close on the
connection.
We use external synchronization to ensure that the connection can only be
closed by a single Thread (so in this example all other Threads attempting to
use the broker connection are blocked waiting for the lock from the closing
Thread to be released).
Stack Trace:
{{"Replicator_node1-->node2_[0ms]" #25 prio=5 os_prio=0 tid=0x49383c00
nid=0x3918 in Object.wait() [0x4b1ef000]}}
{{ java.lang.Thread.State: WAITING (on object monitor)}}
{{ at java.lang.Object.wait(Native Method)}}
{{ at java.lang.Object.wait(Object.java:502)}}
{{ at
org.apache.qpid.jms.provider.BalancedProviderFuture.sync(BalancedProviderFuture.java:137)}}
{{ - locked <0x04e60300> (a
org.apache.qpid.jms.provider.BalancedProviderFuture)}}
{{ at
org.apache.qpid.jms.JmsConnection.destroyResource(JmsConnection.java:755)}}
{{ at
org.apache.qpid.jms.JmsConnection.destroyResource(JmsConnection.java:744)}}
{{ at
org.apache.qpid.jms.JmsMessageProducer.doClose(JmsMessageProducer.java:103)}}
{{ at org.apache.qpid.jms.JmsMessageProducer.close(JmsMessageProducer.java:89)}}
{{ at
acme.broker.client.jms.impl.JMSMessageProducer.closeInternal(JMSMessageProducer.java:48)}}
{{ at
acme.broker.client.jms.impl.JMSMessageProducer.close(JMSMessageProducer.java:43)}}
{{ at acme.broker.client.AbstractSession.tryClose(AbstractSession.java:108)}}
{{ at acme.broker.client.AbstractSession.close(AbstractSession.java:90)}}
{{ at
acme.broker.client.AbstractThreadedSessionManager.close(AbstractThreadedSessionManager.java:108)}}
{{ - locked <0x1d321078> (a java.util.concurrent.ConcurrentHashMap)}}
{{ at
acme.broker.client.AbstractBrokerConnection.closeInternal(AbstractBrokerConnection.java:204)}}
{{ at
acme.broker.client.AbstractBrokerConnection.close(AbstractBrokerConnection.java:84)}}
{{ at acme.replication.jms.JMSMessageBridge.trySend(JMSMessageBridge.java:109)}}
{{ at acme.replication.jms.JMSMessageBridge.access$6(JMSMessageBridge.java:99)}}
{{ at
acme.replication.jms.JMSMessageBridge$ReplicatorRunnable.run(JMSMessageBridge.java:62)}}
{{ at java.lang.Thread.run(Thread.java:745)}}{{Locked ownable synchronizers:}}
{{ - <0x1cfa76b0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)}}
--
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-1341) Add list of delayed links to console's overview page
Ernest Allen created DISPATCH-1341: -- Summary: Add list of delayed links to console's overview page Key: DISPATCH-1341 URL: https://issues.apache.org/jira/browse/DISPATCH-1341 Project: Qpid Dispatch Issue Type: Improvement Components: Console Affects Versions: 1.7.0 Reporter: Ernest Allen Assignee: Ernest Allen On the console's overview page, show a list of endpoint links that have delayedDeliveriesXSec > 1 For each link displayed, show a Kill button that will manually kill the link's connection. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1340) Show settlement rate and delayed deliveries in client popup
[ https://issues.apache.org/jira/browse/DISPATCH-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen resolved DISPATCH-1340. Resolution: Fixed > Show settlement rate and delayed deliveries in client popup > --- > > Key: DISPATCH-1340 > URL: https://issues.apache.org/jira/browse/DISPATCH-1340 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Console >Affects Versions: 1.7.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Major > > On the console's topology page, if you click on a client you will see a popup > that shows the connections for all clients of that type. > If you click on a connection, you will see a list of links for that > connection. > The info displayed for a link should contain the settlement rate, delayed > deliveries, a capacity percent = undelivered/capacity. -- 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-1340) Show settlement rate and delayed deliveries in client popup
[ https://issues.apache.org/jira/browse/DISPATCH-1340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844767#comment-16844767 ] ASF subversion and git services commented on DISPATCH-1340: --- Commit 9300914a8ddfa54854b87a34d1c241648dc79250 in qpid-dispatch's branch refs/heads/master from Ernest Allen [ https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;h=9300914 ] DISPATCH-1340 Show updated link statistics on client popup > Show settlement rate and delayed deliveries in client popup > --- > > Key: DISPATCH-1340 > URL: https://issues.apache.org/jira/browse/DISPATCH-1340 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Console >Affects Versions: 1.7.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Major > > On the console's topology page, if you click on a client you will see a popup > that shows the connections for all clients of that type. > If you click on a connection, you will see a list of links for that > connection. > The info displayed for a link should contain the settlement rate, delayed > deliveries, a capacity percent = undelivered/capacity. -- 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-1340) Show settlement rate and delayed deliveries in client popup
Ernest Allen created DISPATCH-1340: -- Summary: Show settlement rate and delayed deliveries in client popup Key: DISPATCH-1340 URL: https://issues.apache.org/jira/browse/DISPATCH-1340 Project: Qpid Dispatch Issue Type: Improvement Components: Console Affects Versions: 1.7.0 Reporter: Ernest Allen Assignee: Ernest Allen On the console's topology page, if you click on a client you will see a popup that shows the connections for all clients of that type. If you click on a connection, you will see a list of links for that connection. The info displayed for a link should contain the settlement rate, delayed deliveries, a capacity percent = undelivered/capacity. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1339) Multiple consoles attached to a router are showing as separate icons
[ https://issues.apache.org/jira/browse/DISPATCH-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen resolved DISPATCH-1339. Resolution: Fixed > Multiple consoles attached to a router are showing as separate icons > > > Key: DISPATCH-1339 > URL: https://issues.apache.org/jira/browse/DISPATCH-1339 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 1.7.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Major > > If multiple consoles are attached to a single router, and those consoles are > originating from multiple ip addresses, then each console is appearing as a > separate icon on the topology view. > All consoles attached to a router should be collapsed into a single icon. > When that icon is clicked, the popup should show the list of connections. -- 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-1339) Multiple consoles attached to a router are showing as separate icons
[ https://issues.apache.org/jira/browse/DISPATCH-1339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844715#comment-16844715 ] ASF subversion and git services commented on DISPATCH-1339: --- Commit 1bcf0c3c9bcf13078d9088329ec25609952562cf in qpid-dispatch's branch refs/heads/master from Ernest Allen [ https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;h=1bcf0c3 ] DISPATCH-1339 Collapse multiple clients of same time into a single icon > Multiple consoles attached to a router are showing as separate icons > > > Key: DISPATCH-1339 > URL: https://issues.apache.org/jira/browse/DISPATCH-1339 > Project: Qpid Dispatch > Issue Type: Bug > Components: Console >Affects Versions: 1.7.0 >Reporter: Ernest Allen >Assignee: Ernest Allen >Priority: Major > > If multiple consoles are attached to a single router, and those consoles are > originating from multiple ip addresses, then each console is appearing as a > separate icon on the topology view. > All consoles attached to a router should be collapsed into a single icon. > When that icon is clicked, the popup should show the list of connections. -- 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-1339) Multiple consoles attached to a router are showing as separate icons
Ernest Allen created DISPATCH-1339: -- Summary: Multiple consoles attached to a router are showing as separate icons Key: DISPATCH-1339 URL: https://issues.apache.org/jira/browse/DISPATCH-1339 Project: Qpid Dispatch Issue Type: Bug Components: Console Affects Versions: 1.7.0 Reporter: Ernest Allen Assignee: Ernest Allen If multiple consoles are attached to a single router, and those consoles are originating from multiple ip addresses, then each console is appearing as a separate icon on the topology view. All consoles attached to a router should be collapsed into a single icon. When that icon is clicked, the popup should show the list of connections. -- 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
