[jira] [Updated] (QPIDJMS-366) [Failover] JMS commit hangs forever if peer Closes gracefully and failover.maxReconnectAttempts exhausted
[
https://issues.apache.org/jira/browse/QPIDJMS-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPIDJMS-366:
---
Attachment: 4b02297_qpid-366.log
> [Failover] JMS commit hangs forever if peer Closes gracefully and
> failover.maxReconnectAttempts exhausted
> -
>
> Key: QPIDJMS-366
> URL: https://issues.apache.org/jira/browse/QPIDJMS-366
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Reporter: Keith Wall
>Priority: Major
> Attachments: 4b02297_qpid-366.log, HelloWorld.patch
>
>
> If failover occurs whilst a JMS commit is in-flight, and that failover
> exhausts its {{failover.maxReconnectAttempts}} the JMS commit call is seen to
> hang forever. This problem manifests when the connection attempts are
> failing with a graceful {{Close}} from the peer. If the connection failure
> is at a 'transport' level (e.g. Connection refused) the problem does not
> appear.
> Reproduction:
> # Start Broker-J 7.0.2
> # Go to http://localhost:8080, double click on virtualhost {{default}} in the
> virtualhost table to open the virtualhost tab.
> # Create queue {{queue}}
> # Start IDE with qpid-jms project open (master today - 7e7cebe5)
> # Apply HelloWorld patch attached to this JIRA
> # Put a breakpoint in
> {{org.apache.qpid.jms.provider.amqp.AmqpProvider#commit}} line 693 (i.e. the
> closing brace of the try/catch the statement immediately following the
> pumpToProton())
> # Run HelloWorld with attached patch applied under the debugger
> # Once the breakpoint is reached, use the console to stop the virtualhost.
> Do this by clicking the {{Stop}} button on the virtualhost tab.
> # Resume the debugger
> # Expected : once failover attempts are exhausted, the JMS {{commit()}} call
> should end with an exception - Actual: {{commit()}} continues to hang
> indefinitely.
> The blocked main thread looks like this:
> {noformat}
> "main@1" prio=5 tid=0x1 nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at
> org.apache.qpid.jms.provider.ProviderFuture.sync(ProviderFuture.java:103)
> at org.apache.qpid.jms.JmsConnection.commit(JmsConnection.java:766)
> at
> org.apache.qpid.jms.JmsLocalTransactionContext.commit(JmsLocalTransactionContext.java:171)
> at org.apache.qpid.jms.JmsSession.commit(JmsSession.java:227)
> at org.apache.qpid.jms.example.HelloWorld.main(HelloWorld.java:61)
> {noformat}
--
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-366) [Failover] JMS commit hangs forever if peer Closes gracefully and failover.maxReconnectAttempts exhausted
[
https://issues.apache.org/jira/browse/QPIDJMS-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16405496#comment-16405496
]
Keith Wall commented on QPIDJMS-366:
Please find attached log. I am reproducing the problem exactly as described
above except that I am testing with master now
(4b022971b7461ebaefe12161358e03c0af9b590a). I note that since the changes
made by QPIDJMS-365, failover for this case seems to continue indefinitely
(i.e. ignores the failover.maxReconnectAttempts=2 in my connection url).
> [Failover] JMS commit hangs forever if peer Closes gracefully and
> failover.maxReconnectAttempts exhausted
> -
>
> Key: QPIDJMS-366
> URL: https://issues.apache.org/jira/browse/QPIDJMS-366
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Reporter: Keith Wall
>Priority: Major
> Attachments: HelloWorld.patch
>
>
> If failover occurs whilst a JMS commit is in-flight, and that failover
> exhausts its {{failover.maxReconnectAttempts}} the JMS commit call is seen to
> hang forever. This problem manifests when the connection attempts are
> failing with a graceful {{Close}} from the peer. If the connection failure
> is at a 'transport' level (e.g. Connection refused) the problem does not
> appear.
> Reproduction:
> # Start Broker-J 7.0.2
> # Go to http://localhost:8080, double click on virtualhost {{default}} in the
> virtualhost table to open the virtualhost tab.
> # Create queue {{queue}}
> # Start IDE with qpid-jms project open (master today - 7e7cebe5)
> # Apply HelloWorld patch attached to this JIRA
> # Put a breakpoint in
> {{org.apache.qpid.jms.provider.amqp.AmqpProvider#commit}} line 693 (i.e. the
> closing brace of the try/catch the statement immediately following the
> pumpToProton())
> # Run HelloWorld with attached patch applied under the debugger
> # Once the breakpoint is reached, use the console to stop the virtualhost.
> Do this by clicking the {{Stop}} button on the virtualhost tab.
> # Resume the debugger
> # Expected : once failover attempts are exhausted, the JMS {{commit()}} call
> should end with an exception - Actual: {{commit()}} continues to hang
> indefinitely.
> The blocked main thread looks like this:
> {noformat}
> "main@1" prio=5 tid=0x1 nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at
> org.apache.qpid.jms.provider.ProviderFuture.sync(ProviderFuture.java:103)
> at org.apache.qpid.jms.JmsConnection.commit(JmsConnection.java:766)
> at
> org.apache.qpid.jms.JmsLocalTransactionContext.commit(JmsLocalTransactionContext.java:171)
> at org.apache.qpid.jms.JmsSession.commit(JmsSession.java:227)
> at org.apache.qpid.jms.example.HelloWorld.main(HelloWorld.java:61)
> {noformat}
--
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-366) [Failover] JMS commit hangs forever if peer Closes gracefully and failover.maxReconnectAttempts exhausted
[
https://issues.apache.org/jira/browse/QPIDJMS-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16405443#comment-16405443
]
ASF subversion and git services commented on QPIDJMS-366:
-
Commit 3e8061b448d934fbc5dab0e2d7119125e06c2265 in qpid-jms's branch
refs/heads/master from [~tabish121]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=3e8061b ]
QPIDJMS-366 Add a test of no response to TX commit and remote close
Test that failover send commit failed on remote close when commit is
pending.
> [Failover] JMS commit hangs forever if peer Closes gracefully and
> failover.maxReconnectAttempts exhausted
> -
>
> Key: QPIDJMS-366
> URL: https://issues.apache.org/jira/browse/QPIDJMS-366
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Reporter: Keith Wall
>Priority: Major
> Attachments: HelloWorld.patch
>
>
> If failover occurs whilst a JMS commit is in-flight, and that failover
> exhausts its {{failover.maxReconnectAttempts}} the JMS commit call is seen to
> hang forever. This problem manifests when the connection attempts are
> failing with a graceful {{Close}} from the peer. If the connection failure
> is at a 'transport' level (e.g. Connection refused) the problem does not
> appear.
> Reproduction:
> # Start Broker-J 7.0.2
> # Go to http://localhost:8080, double click on virtualhost {{default}} in the
> virtualhost table to open the virtualhost tab.
> # Create queue {{queue}}
> # Start IDE with qpid-jms project open (master today - 7e7cebe5)
> # Apply HelloWorld patch attached to this JIRA
> # Put a breakpoint in
> {{org.apache.qpid.jms.provider.amqp.AmqpProvider#commit}} line 693 (i.e. the
> closing brace of the try/catch the statement immediately following the
> pumpToProton())
> # Run HelloWorld with attached patch applied under the debugger
> # Once the breakpoint is reached, use the console to stop the virtualhost.
> Do this by clicking the {{Stop}} button on the virtualhost tab.
> # Resume the debugger
> # Expected : once failover attempts are exhausted, the JMS {{commit()}} call
> should end with an exception - Actual: {{commit()}} continues to hang
> indefinitely.
> The blocked main thread looks like this:
> {noformat}
> "main@1" prio=5 tid=0x1 nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at
> org.apache.qpid.jms.provider.ProviderFuture.sync(ProviderFuture.java:103)
> at org.apache.qpid.jms.JmsConnection.commit(JmsConnection.java:766)
> at
> org.apache.qpid.jms.JmsLocalTransactionContext.commit(JmsLocalTransactionContext.java:171)
> at org.apache.qpid.jms.JmsSession.commit(JmsSession.java:227)
> at org.apache.qpid.jms.example.HelloWorld.main(HelloWorld.java:61)
> {noformat}
--
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-937) schema.validate(attributes) called 4 times before the router starts
[
https://issues.apache.org/jira/browse/DISPATCH-937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16405412#comment-16405412
]
Chuck Rolke commented on DISPATCH-937:
--
The PR as it stands reduces the number of trips through validate. That said,
there are still a lot of trips through validate.
The attachment dispatch-937-1_vhost-creation-1.txt records a test run against
pull request 265. It holds a patch with a couple of python print statements, a
router config file, and a qdmanage command to create a vhost. Then it also
holds the console output generated by the extra print statements.
At first glance it seems like the validations are done on the same data but on
closer inspection I don't think that is the case. This is only visible from the
console log if your editor supports horizontal scrolling to show really long
lines.
[[~ganeshmurthy]] if the console log sequence at the end of the attachment
seems OK then this PR looks good.
> schema.validate(attributes) called 4 times before the router starts
> ---
>
> Key: DISPATCH-937
> URL: https://issues.apache.org/jira/browse/DISPATCH-937
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Management Agent
>Affects Versions: 1.0.1
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.2.0
>
> Attachments: dispatch-937-1_vhost-creation-1.txt
>
>
> Start the router with the config file etc/qdrouterd.conf. This config file
> has one router entity
> {noformat}
> router {
> mode: interior
> id: Router.A
> }{noformat}
>
> The schema.validate is called 4 times on the router entity. It should be
> called only once
>
> Here is the traceback of the 4 times it was called -
>
> {noformat}
> {'type': u'org.apache.qpid.dispatch.router', u'mode': u'standalone', u'id':
> u'Router.A'}
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
> line 142, in configure_dispatch
> config = Config(filename)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
> line 41, in __init__
> self.load(filename, raw_json)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
> line 112, in load
> self.load(f, raw_json)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
> line 120, in load
> self.schema.validate_all(entities)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 576, in validate_all
> self.validate_add(a, entities)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/qdrouter.py",
> line 53, in validate_add
> super(QdSchema, self).validate_add(attributes, entities)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 585, in validate_add
> self.validate_entity(attributes)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 568, in validate_entity
> entity_type.validate(attributes)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 396, in validate
> for line in traceback.format_stack():
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
> line 164, in configure_dispatch
> configure(config.by_type('router')[0])
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
> line 151, in configure
> agent.configure(attributes)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 855, in configure
> self._create(attributes)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 828, in _create
> self.add_entity(entity)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 859, in add_entity
> self.entities.add(entity)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 519, in add
> entity.validate() # Fill in defaults etc.
> File
>
[jira] [Updated] (DISPATCH-937) schema.validate(attributes) called 4 times before the router starts
[
https://issues.apache.org/jira/browse/DISPATCH-937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chuck Rolke updated DISPATCH-937:
-
Attachment: dispatch-937-1_vhost-creation-1.txt
> schema.validate(attributes) called 4 times before the router starts
> ---
>
> Key: DISPATCH-937
> URL: https://issues.apache.org/jira/browse/DISPATCH-937
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Management Agent
>Affects Versions: 1.0.1
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
>Priority: Major
> Fix For: 1.2.0
>
> Attachments: dispatch-937-1_vhost-creation-1.txt
>
>
> Start the router with the config file etc/qdrouterd.conf. This config file
> has one router entity
> {noformat}
> router {
> mode: interior
> id: Router.A
> }{noformat}
>
> The schema.validate is called 4 times on the router entity. It should be
> called only once
>
> Here is the traceback of the 4 times it was called -
>
> {noformat}
> {'type': u'org.apache.qpid.dispatch.router', u'mode': u'standalone', u'id':
> u'Router.A'}
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
> line 142, in configure_dispatch
> config = Config(filename)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
> line 41, in __init__
> self.load(filename, raw_json)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
> line 112, in load
> self.load(f, raw_json)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
> line 120, in load
> self.schema.validate_all(entities)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 576, in validate_all
> self.validate_add(a, entities)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/qdrouter.py",
> line 53, in validate_add
> super(QdSchema, self).validate_add(attributes, entities)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 585, in validate_add
> self.validate_entity(attributes)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 568, in validate_entity
> entity_type.validate(attributes)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 396, in validate
> for line in traceback.format_stack():
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
> line 164, in configure_dispatch
> configure(config.by_type('router')[0])
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
> line 151, in configure
> agent.configure(attributes)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 855, in configure
> self._create(attributes)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 828, in _create
> self.add_entity(entity)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 859, in add_entity
> self.entities.add(entity)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 519, in add
> entity.validate() # Fill in defaults etc.
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/agent.py",
> line 171, in validate
> super(EntityAdapter, self).validate(**kwargs)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 639, in validate
> self.entity_type.validate(self.attributes)
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/schema.py",
> line 396, in validate
> for line in traceback.format_stack():
> File
> "/home/gmurthy/opensource/qpid-dispatch/install/lib/qpid-dispatch/python/qpid_dispatch_internal/management/config.py",
> line 164, in configure_dispatch
>
[jira] [Commented] (QPIDJMS-366) [Failover] JMS commit hangs forever if peer Closes gracefully and failover.maxReconnectAttempts exhausted
[
https://issues.apache.org/jira/browse/QPIDJMS-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16405344#comment-16405344
]
Timothy Bish commented on QPIDJMS-366:
--
I've tried to reproduce it but had no luck. A test or some supporting logs
would be helpful
> [Failover] JMS commit hangs forever if peer Closes gracefully and
> failover.maxReconnectAttempts exhausted
> -
>
> Key: QPIDJMS-366
> URL: https://issues.apache.org/jira/browse/QPIDJMS-366
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Reporter: Keith Wall
>Priority: Major
> Attachments: HelloWorld.patch
>
>
> If failover occurs whilst a JMS commit is in-flight, and that failover
> exhausts its {{failover.maxReconnectAttempts}} the JMS commit call is seen to
> hang forever. This problem manifests when the connection attempts are
> failing with a graceful {{Close}} from the peer. If the connection failure
> is at a 'transport' level (e.g. Connection refused) the problem does not
> appear.
> Reproduction:
> # Start Broker-J 7.0.2
> # Go to http://localhost:8080, double click on virtualhost {{default}} in the
> virtualhost table to open the virtualhost tab.
> # Create queue {{queue}}
> # Start IDE with qpid-jms project open (master today - 7e7cebe5)
> # Apply HelloWorld patch attached to this JIRA
> # Put a breakpoint in
> {{org.apache.qpid.jms.provider.amqp.AmqpProvider#commit}} line 693 (i.e. the
> closing brace of the try/catch the statement immediately following the
> pumpToProton())
> # Run HelloWorld with attached patch applied under the debugger
> # Once the breakpoint is reached, use the console to stop the virtualhost.
> Do this by clicking the {{Stop}} button on the virtualhost tab.
> # Resume the debugger
> # Expected : once failover attempts are exhausted, the JMS {{commit()}} call
> should end with an exception - Actual: {{commit()}} continues to hang
> indefinitely.
> The blocked main thread looks like this:
> {noformat}
> "main@1" prio=5 tid=0x1 nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at
> org.apache.qpid.jms.provider.ProviderFuture.sync(ProviderFuture.java:103)
> at org.apache.qpid.jms.JmsConnection.commit(JmsConnection.java:766)
> at
> org.apache.qpid.jms.JmsLocalTransactionContext.commit(JmsLocalTransactionContext.java:171)
> at org.apache.qpid.jms.JmsSession.commit(JmsSession.java:227)
> at org.apache.qpid.jms.example.HelloWorld.main(HelloWorld.java:61)
> {noformat}
--
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-366) [Failover] JMS commit hangs forever if peer Closes gracefully and failover.maxReconnectAttempts exhausted
[
https://issues.apache.org/jira/browse/QPIDJMS-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16405339#comment-16405339
]
Keith Wall commented on QPIDJMS-366:
With the work of QPIDJMS-365, I still see this issue, but the internals look
different. It seems like failover loops forever, regardless of
\{{failover.maxReconnectAttempts}}. I can provide more details if required.
> [Failover] JMS commit hangs forever if peer Closes gracefully and
> failover.maxReconnectAttempts exhausted
> -
>
> Key: QPIDJMS-366
> URL: https://issues.apache.org/jira/browse/QPIDJMS-366
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Reporter: Keith Wall
>Priority: Major
> Attachments: HelloWorld.patch
>
>
> If failover occurs whilst a JMS commit is in-flight, and that failover
> exhausts its {{failover.maxReconnectAttempts}} the JMS commit call is seen to
> hang forever. This problem manifests when the connection attempts are
> failing with a graceful {{Close}} from the peer. If the connection failure
> is at a 'transport' level (e.g. Connection refused) the problem does not
> appear.
> Reproduction:
> # Start Broker-J 7.0.2
> # Go to http://localhost:8080, double click on virtualhost {{default}} in the
> virtualhost table to open the virtualhost tab.
> # Create queue {{queue}}
> # Start IDE with qpid-jms project open (master today - 7e7cebe5)
> # Apply HelloWorld patch attached to this JIRA
> # Put a breakpoint in
> {{org.apache.qpid.jms.provider.amqp.AmqpProvider#commit}} line 693 (i.e. the
> closing brace of the try/catch the statement immediately following the
> pumpToProton())
> # Run HelloWorld with attached patch applied under the debugger
> # Once the breakpoint is reached, use the console to stop the virtualhost.
> Do this by clicking the {{Stop}} button on the virtualhost tab.
> # Resume the debugger
> # Expected : once failover attempts are exhausted, the JMS {{commit()}} call
> should end with an exception - Actual: {{commit()}} continues to hang
> indefinitely.
> The blocked main thread looks like this:
> {noformat}
> "main@1" prio=5 tid=0x1 nid=NA waiting
> java.lang.Thread.State: WAITING
> at sun.misc.Unsafe.park(Unsafe.java:-1)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at
> org.apache.qpid.jms.provider.ProviderFuture.sync(ProviderFuture.java:103)
> at org.apache.qpid.jms.JmsConnection.commit(JmsConnection.java:766)
> at
> org.apache.qpid.jms.JmsLocalTransactionContext.commit(JmsLocalTransactionContext.java:171)
> at org.apache.qpid.jms.JmsSession.commit(JmsSession.java:227)
> at org.apache.qpid.jms.example.HelloWorld.main(HelloWorld.java:61)
> {noformat}
--
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-365) [Failover] failover.reconnectDelay not applied between connection attempts if peer Closes gracefully
[
https://issues.apache.org/jira/browse/QPIDJMS-365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16405334#comment-16405334
]
Keith Wall commented on QPIDJMS-365:
I reran the tests that caused me to discover this defect. I confirm that this
defect is resolved. Thanks for the speedy resolution.
> [Failover] failover.reconnectDelay not applied between connection attempts if
> peer Closes gracefully
>
>
> Key: QPIDJMS-365
> URL: https://issues.apache.org/jira/browse/QPIDJMS-365
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Reporter: Keith Wall
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 0.31.0
>
>
> When using Broker-J's High Availability feature, the client's failover
> abilities are used to allow the client to discover which Broker in the HA
> group has the master role. The client tries each Broker on the failover list
> until until one successfully responds to the {{Open}} indicating that it is
> current master.
>
> When a node is not in the master role, it gracefully closes the AMQP
> connection by sending a {{Close}} performative. During election periods, it
> is normal for all nodes in the HA group to respond with the {{Close}} until
> the election concludes.
> {noformat}
> Close{error=Error{condition=amqp:not-found, description='Virtual host
> 'localhost' is not active', info=null}}
> {noformat}
> The QpidJMS Client failover options includes a {{failover.reconnectDelay}}
> which "Controls the delay between successive reconnection attempts".
> However it appears that the reconnection delay is only applied between
> attempts when a connection fails owing to a 'transport' level failure
> (connection refused etc). If the connection fails at the AMQP level, the
> delay is not applied.
> This is impactful to the HA use-case for Broker-J. It means that during
> periods of reelection, the client, tightly spins in the reconnection loop,
> excessively consuming system resources. It is also necessary to ensure that
> {{failover.maxReconnectAttempts}} is set sufficiently large to allow for an
> election period to conclude successfully. Whilst the user could use
> unlimited reconnection attempts, this is unpleasant as it means the system
> won't fail in the case where the election does not conclude within a
> reasonable time period.
> Extract of TRACE level logging from
> {{org.apache.qpid.jms.provider.failover.FailoverProvider}} for the case when
> a AMQP connection is closed gracefully ({{Close}} performative):
> {noformat}
> 2018-03-13 11:04:54,951 [lization thread] - DEBUG FailoverProvider
>- Failover: the provider reports failure: Connection closed by external
> action [condition = amqp:connection:forced]
> 2018-03-13 11:04:54,951 [lization thread] - DEBUG FailoverProvider
>- handling Provider failure: Connection closed by external action
> [condition = amqp:connection:forced]
> 2018-03-13 11:04:54,951 [lization thread] - TRACE FailoverProvider
>- stack
> java.io.IOException: Connection closed by external action [condition =
> amqp:connection:forced]
> at
> org.apache.qpid.jms.util.IOExceptionSupport.create(IOExceptionSupport.java:45)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.fireProviderException(AmqpProvider.java:1086)
> at
> org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.closeResource(AmqpAbstractResource.java:182)
> at
> org.apache.qpid.jms.provider.amqp.AmqpAbstractResource.processRemoteClose(AmqpAbstractResource.java:262)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.processUpdates(AmqpProvider.java:949)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider.access$1900(AmqpProvider.java:104)
> at
> org.apache.qpid.jms.provider.amqp.AmqpProvider$17.run(AmqpProvider.java:831)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.jms.JMSException: Connection closed by external action
> [condition = amqp:connection:forced]
> at
> org.apache.qpid.jms.provider.amqp.AmqpSupport.convertToException(AmqpSupport.java:164)
> at
[jira] [Assigned] (QPID-8133) Refresh Commons-CLI dependency (1.4)
[ https://issues.apache.org/jira/browse/QPID-8133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall reassigned QPID-8133: Assignee: Keith Wall > Refresh Commons-CLI dependency (1.4) > > > Key: QPID-8133 > URL: https://issues.apache.org/jira/browse/QPID-8133 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Assignee: Keith Wall >Priority: Minor > Fix For: qpid-java-broker-7.1.0 > > > The Commons CLI dependency used by Broker-J is getting stale. The latest > release is 1.4. -- 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] (QPID-8133) Refresh Commons-CLI dependency (1.4)
[ https://issues.apache.org/jira/browse/QPID-8133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-8133: - Status: Reviewable (was: In Progress) > Refresh Commons-CLI dependency (1.4) > > > Key: QPID-8133 > URL: https://issues.apache.org/jira/browse/QPID-8133 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Assignee: Keith Wall >Priority: Minor > Fix For: qpid-java-broker-7.1.0 > > > The Commons CLI dependency used by Broker-J is getting stale. The latest > release is 1.4. -- 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-8136) [Broker-J] Upgrade Jackson dependencies
[ https://issues.apache.org/jira/browse/QPID-8136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16404802#comment-16404802 ] ASF subversion and git services commented on QPID-8136: --- Commit 906a84956baa3de272489b3265078e68add952d0 in qpid-broker-j's branch refs/heads/master from [~k-wall] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=906a849 ] QPID-8136: [Broker-J] [Jackson] Update dependency from 2.9.4 > [Broker-J] Upgrade Jackson dependencies > --- > > Key: QPID-8136 > URL: https://issues.apache.org/jira/browse/QPID-8136 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Priority: Major > > Upgrade Jackson dependencies -- 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-8136) [Broker-J] Upgrade Jackson dependencies
[ https://issues.apache.org/jira/browse/QPID-8136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16404803#comment-16404803 ] ASF subversion and git services commented on QPID-8136: --- Commit 8ef118e749a835a80f69612b4e788694b97282f0 in qpid-broker-j's branch refs/heads/7.0.x from [~k-wall] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=8ef118e ] QPID-8136: [Broker-J] [Jackson] Update dependency from 2.8.7 to 2.8.11 > [Broker-J] Upgrade Jackson dependencies > --- > > Key: QPID-8136 > URL: https://issues.apache.org/jira/browse/QPID-8136 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Priority: Major > > Upgrade Jackson dependencies -- 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-8137) [Broker-J] NPE is reported into broker logs on broker shutdown/restart when AMQP port is in ERRORED state due to port being bound by other process
[
https://issues.apache.org/jira/browse/QPID-8137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16404771#comment-16404771
]
Alex Rudyy commented on QPID-8137:
--
The fix can be potentially included onto 7.0.3
> [Broker-J] NPE is reported into broker logs on broker shutdown/restart when
> AMQP port is in ERRORED state due to port being bound by other process
> --
>
> Key: QPID-8137
> URL: https://issues.apache.org/jira/browse/QPID-8137
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.0.2, qpid-java-broker-7.0.0,
> qpid-java-broker-7.0.1, qpid-java-broker-7.1.0
>
>
> The following NPE is reported into broker logs on broker shutdown/restart
> when AMQP port is in ERRORED state due to port being bound by other process:
> {noformat}
> java.lang.NullPointerException: null
> at
> org.apache.qpid.server.transport.TCPandSSLTransport.getAcceptingPort(TCPandSSLTransport.java:86)
> at
> org.apache.qpid.server.model.port.AmqpPortImpl.closeTransport(AmqpPortImpl.java:309)
> at
> org.apache.qpid.server.model.port.AmqpPortImpl.onClose(AmqpPortImpl.java:285)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$5$2.call(AbstractConfiguredObject.java:791)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$5$2.call(AbstractConfiguredObject.java:787)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$21.onSuccess(AbstractConfiguredObject.java:2745)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2880)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2876)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$24.onSuccess(AbstractConfiguredObject.java:2875)
> at
> com.google.common.util.concurrent.Futures$CallbackListener.run(Futures.java:1237)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:400)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:183)
> at
> com.google.common.util.concurrent.AbstractFuture.executeListener(AbstractFuture.java:911)
> at
> com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:645)
> at
> com.google.common.util.concurrent.Futures.addCallback(Futures.java:1209)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.addFutureCallback(AbstractConfiguredObject.java:2870)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doAfter(AbstractConfiguredObject.java:2738)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$ChainedSettableFuture.then(AbstractConfiguredObject.java:2714)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$5.execute(AbstractConfiguredObject.java:786)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$5.execute(AbstractConfiguredObject.java:766)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:639)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:632)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:248)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submitWrappedTask(TaskExecutorImpl.java:165)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submit(TaskExecutorImpl.java:153)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doOnConfigThread(AbstractConfiguredObject.java:631)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.closeAsync(AbstractConfiguredObject.java:765)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$3.performAction(AbstractConfiguredObject.java:707)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$3.performAction(AbstractConfiguredObject.java:703)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.applyToChildren(AbstractConfiguredObject.java:1313)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.closeChildren(AbstractConfiguredObject.java:702)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$5$3.call(AbstractConfiguredObject.java:784)
> at
>
[jira] [Assigned] (QPID-8137) [Broker-J] NPE is reported into broker logs on broker shutdown/restart when AMQP port is in ERRORED state due to port being bound by other process
[
https://issues.apache.org/jira/browse/QPID-8137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy reassigned QPID-8137:
Assignee: Alex Rudyy
> [Broker-J] NPE is reported into broker logs on broker shutdown/restart when
> AMQP port is in ERRORED state due to port being bound by other process
> --
>
> Key: QPID-8137
> URL: https://issues.apache.org/jira/browse/QPID-8137
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.0.2, qpid-java-broker-7.0.0,
> qpid-java-broker-7.0.1, qpid-java-broker-7.1.0
>
>
> The following NPE is reported into broker logs on broker shutdown/restart
> when AMQP port is in ERRORED state due to port being bound by other process:
> {noformat}
> java.lang.NullPointerException: null
> at
> org.apache.qpid.server.transport.TCPandSSLTransport.getAcceptingPort(TCPandSSLTransport.java:86)
> at
> org.apache.qpid.server.model.port.AmqpPortImpl.closeTransport(AmqpPortImpl.java:309)
> at
> org.apache.qpid.server.model.port.AmqpPortImpl.onClose(AmqpPortImpl.java:285)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$5$2.call(AbstractConfiguredObject.java:791)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$5$2.call(AbstractConfiguredObject.java:787)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$21.onSuccess(AbstractConfiguredObject.java:2745)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2880)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2876)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$24.onSuccess(AbstractConfiguredObject.java:2875)
> at
> com.google.common.util.concurrent.Futures$CallbackListener.run(Futures.java:1237)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:400)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:183)
> at
> com.google.common.util.concurrent.AbstractFuture.executeListener(AbstractFuture.java:911)
> at
> com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:645)
> at
> com.google.common.util.concurrent.Futures.addCallback(Futures.java:1209)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.addFutureCallback(AbstractConfiguredObject.java:2870)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doAfter(AbstractConfiguredObject.java:2738)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$ChainedSettableFuture.then(AbstractConfiguredObject.java:2714)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$5.execute(AbstractConfiguredObject.java:786)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$5.execute(AbstractConfiguredObject.java:766)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:639)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:632)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:248)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submitWrappedTask(TaskExecutorImpl.java:165)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submit(TaskExecutorImpl.java:153)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doOnConfigThread(AbstractConfiguredObject.java:631)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.closeAsync(AbstractConfiguredObject.java:765)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$3.performAction(AbstractConfiguredObject.java:707)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$3.performAction(AbstractConfiguredObject.java:703)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.applyToChildren(AbstractConfiguredObject.java:1313)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.closeChildren(AbstractConfiguredObject.java:702)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$5$3.call(AbstractConfiguredObject.java:784)
> at
>
[jira] [Commented] (QPID-8137) [Broker-J] NPE is reported into broker logs on broker shutdown/restart when AMQP port is in ERRORED state due to port being bound by other process
[
https://issues.apache.org/jira/browse/QPID-8137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16404767#comment-16404767
]
ASF subversion and git services commented on QPID-8137:
---
Commit 43476a2a2d510943a7f0eea4e464e7f018686e49 in qpid-broker-j's branch
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=43476a2 ]
QPID-8137: [Broker-J] Return configured port as accepting port when network
transport instance is not created
> [Broker-J] NPE is reported into broker logs on broker shutdown/restart when
> AMQP port is in ERRORED state due to port being bound by other process
> --
>
> Key: QPID-8137
> URL: https://issues.apache.org/jira/browse/QPID-8137
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.0.2, qpid-java-broker-7.0.0,
> qpid-java-broker-7.0.1, qpid-java-broker-7.1.0
>
>
> The following NPE is reported into broker logs on broker shutdown/restart
> when AMQP port is in ERRORED state due to port being bound by other process:
> {noformat}
> java.lang.NullPointerException: null
> at
> org.apache.qpid.server.transport.TCPandSSLTransport.getAcceptingPort(TCPandSSLTransport.java:86)
> at
> org.apache.qpid.server.model.port.AmqpPortImpl.closeTransport(AmqpPortImpl.java:309)
> at
> org.apache.qpid.server.model.port.AmqpPortImpl.onClose(AmqpPortImpl.java:285)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$5$2.call(AbstractConfiguredObject.java:791)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$5$2.call(AbstractConfiguredObject.java:787)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$21.onSuccess(AbstractConfiguredObject.java:2745)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2880)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2876)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$24.onSuccess(AbstractConfiguredObject.java:2875)
> at
> com.google.common.util.concurrent.Futures$CallbackListener.run(Futures.java:1237)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:400)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:183)
> at
> com.google.common.util.concurrent.AbstractFuture.executeListener(AbstractFuture.java:911)
> at
> com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:645)
> at
> com.google.common.util.concurrent.Futures.addCallback(Futures.java:1209)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.addFutureCallback(AbstractConfiguredObject.java:2870)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doAfter(AbstractConfiguredObject.java:2738)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$ChainedSettableFuture.then(AbstractConfiguredObject.java:2714)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$5.execute(AbstractConfiguredObject.java:786)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$5.execute(AbstractConfiguredObject.java:766)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:639)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:632)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:248)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submitWrappedTask(TaskExecutorImpl.java:165)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submit(TaskExecutorImpl.java:153)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doOnConfigThread(AbstractConfiguredObject.java:631)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.closeAsync(AbstractConfiguredObject.java:765)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$3.performAction(AbstractConfiguredObject.java:707)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$3.performAction(AbstractConfiguredObject.java:703)
> at
>
[jira] [Updated] (QPID-8137) [Broker-J] NPE is reported into broker logs on broker shutdown/restart when AMQP port is in ERRORED state due to port being bound by other process
[
https://issues.apache.org/jira/browse/QPID-8137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8137:
-
Status: Reviewable (was: In Progress)
> [Broker-J] NPE is reported into broker logs on broker shutdown/restart when
> AMQP port is in ERRORED state due to port being bound by other process
> --
>
> Key: QPID-8137
> URL: https://issues.apache.org/jira/browse/QPID-8137
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.0.2, qpid-java-broker-7.0.0,
> qpid-java-broker-7.0.1, qpid-java-broker-7.1.0
>
>
> The following NPE is reported into broker logs on broker shutdown/restart
> when AMQP port is in ERRORED state due to port being bound by other process:
> {noformat}
> java.lang.NullPointerException: null
> at
> org.apache.qpid.server.transport.TCPandSSLTransport.getAcceptingPort(TCPandSSLTransport.java:86)
> at
> org.apache.qpid.server.model.port.AmqpPortImpl.closeTransport(AmqpPortImpl.java:309)
> at
> org.apache.qpid.server.model.port.AmqpPortImpl.onClose(AmqpPortImpl.java:285)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$5$2.call(AbstractConfiguredObject.java:791)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$5$2.call(AbstractConfiguredObject.java:787)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$21.onSuccess(AbstractConfiguredObject.java:2745)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2880)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2876)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$24.onSuccess(AbstractConfiguredObject.java:2875)
> at
> com.google.common.util.concurrent.Futures$CallbackListener.run(Futures.java:1237)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:400)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:183)
> at
> com.google.common.util.concurrent.AbstractFuture.executeListener(AbstractFuture.java:911)
> at
> com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:645)
> at
> com.google.common.util.concurrent.Futures.addCallback(Futures.java:1209)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.addFutureCallback(AbstractConfiguredObject.java:2870)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doAfter(AbstractConfiguredObject.java:2738)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$ChainedSettableFuture.then(AbstractConfiguredObject.java:2714)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$5.execute(AbstractConfiguredObject.java:786)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$5.execute(AbstractConfiguredObject.java:766)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:639)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:632)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:248)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submitWrappedTask(TaskExecutorImpl.java:165)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submit(TaskExecutorImpl.java:153)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doOnConfigThread(AbstractConfiguredObject.java:631)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.closeAsync(AbstractConfiguredObject.java:765)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$3.performAction(AbstractConfiguredObject.java:707)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$3.performAction(AbstractConfiguredObject.java:703)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.applyToChildren(AbstractConfiguredObject.java:1313)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.closeChildren(AbstractConfiguredObject.java:702)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$5$3.call(AbstractConfiguredObject.java:784)
> at
>
[jira] [Updated] (QPID-8137) [Broker-J] NPE is reported into broker logs on broker shutdown/restart when AMQP port is in ERRORED state due to port being bound by other process
[
https://issues.apache.org/jira/browse/QPID-8137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-8137:
-
Fix Version/s: qpid-java-broker-7.0.2
qpid-java-broker-7.0.0
qpid-java-broker-7.0.1
qpid-java-broker-7.1.0
> [Broker-J] NPE is reported into broker logs on broker shutdown/restart when
> AMQP port is in ERRORED state due to port being bound by other process
> --
>
> Key: QPID-8137
> URL: https://issues.apache.org/jira/browse/QPID-8137
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.0.2, qpid-java-broker-7.0.0,
> qpid-java-broker-7.0.1, qpid-java-broker-7.1.0
>
>
> The following NPE is reported into broker logs on broker shutdown/restart
> when AMQP port is in ERRORED state due to port being bound by other process:
> {noformat}
> java.lang.NullPointerException: null
> at
> org.apache.qpid.server.transport.TCPandSSLTransport.getAcceptingPort(TCPandSSLTransport.java:86)
> at
> org.apache.qpid.server.model.port.AmqpPortImpl.closeTransport(AmqpPortImpl.java:309)
> at
> org.apache.qpid.server.model.port.AmqpPortImpl.onClose(AmqpPortImpl.java:285)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$5$2.call(AbstractConfiguredObject.java:791)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$5$2.call(AbstractConfiguredObject.java:787)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$21.onSuccess(AbstractConfiguredObject.java:2745)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2880)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2876)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$24.onSuccess(AbstractConfiguredObject.java:2875)
> at
> com.google.common.util.concurrent.Futures$CallbackListener.run(Futures.java:1237)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:400)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:183)
> at
> com.google.common.util.concurrent.AbstractFuture.executeListener(AbstractFuture.java:911)
> at
> com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:645)
> at
> com.google.common.util.concurrent.Futures.addCallback(Futures.java:1209)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.addFutureCallback(AbstractConfiguredObject.java:2870)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doAfter(AbstractConfiguredObject.java:2738)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$ChainedSettableFuture.then(AbstractConfiguredObject.java:2714)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$5.execute(AbstractConfiguredObject.java:786)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$5.execute(AbstractConfiguredObject.java:766)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:639)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:632)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:248)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submitWrappedTask(TaskExecutorImpl.java:165)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submit(TaskExecutorImpl.java:153)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doOnConfigThread(AbstractConfiguredObject.java:631)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.closeAsync(AbstractConfiguredObject.java:765)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$3.performAction(AbstractConfiguredObject.java:707)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$3.performAction(AbstractConfiguredObject.java:703)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.applyToChildren(AbstractConfiguredObject.java:1313)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.closeChildren(AbstractConfiguredObject.java:702)
> at
>
[jira] [Commented] (QPID-8133) Refresh Commons-CLI dependency (1.4)
[ https://issues.apache.org/jira/browse/QPID-8133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16404755#comment-16404755 ] ASF subversion and git services commented on QPID-8133: --- Commit d189cc70172cdcf77dc2e6697d07e79bd3b33c7d in qpid-broker-j's branch refs/heads/master from [~k-wall] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=d189cc7 ] QPID-8133: [Broker-J] Correct DEPENDENCIES_REFERENCE for Commons-CLI > Refresh Commons-CLI dependency (1.4) > > > Key: QPID-8133 > URL: https://issues.apache.org/jira/browse/QPID-8133 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Priority: Minor > > The Commons CLI dependency used by Broker-J is getting stale. The latest > release is 1.4. -- 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-8137) [Broker-J] NPE is reported into broker logs on broker shutdown/restart when AMQP port is in ERRORED state due to port being bound by other process
Alex Rudyy created QPID-8137:
Summary: [Broker-J] NPE is reported into broker logs on broker
shutdown/restart when AMQP port is in ERRORED state due to port being bound by
other process
Key: QPID-8137
URL: https://issues.apache.org/jira/browse/QPID-8137
Project: Qpid
Issue Type: Bug
Components: Broker-J
Reporter: Alex Rudyy
The following NPE is reported into broker logs on broker shutdown/restart when
AMQP port is in ERRORED state due to port being bound by other process:
{noformat}
java.lang.NullPointerException: null
at
org.apache.qpid.server.transport.TCPandSSLTransport.getAcceptingPort(TCPandSSLTransport.java:86)
at
org.apache.qpid.server.model.port.AmqpPortImpl.closeTransport(AmqpPortImpl.java:309)
at
org.apache.qpid.server.model.port.AmqpPortImpl.onClose(AmqpPortImpl.java:285)
at
org.apache.qpid.server.model.AbstractConfiguredObject$5$2.call(AbstractConfiguredObject.java:791)
at
org.apache.qpid.server.model.AbstractConfiguredObject$5$2.call(AbstractConfiguredObject.java:787)
at
org.apache.qpid.server.model.AbstractConfiguredObject$21.onSuccess(AbstractConfiguredObject.java:2745)
at
org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2880)
at
org.apache.qpid.server.model.AbstractConfiguredObject$24$1.run(AbstractConfiguredObject.java:2876)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:360)
at
org.apache.qpid.server.model.AbstractConfiguredObject$24.onSuccess(AbstractConfiguredObject.java:2875)
at
com.google.common.util.concurrent.Futures$CallbackListener.run(Futures.java:1237)
at
org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:400)
at
org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:183)
at
com.google.common.util.concurrent.AbstractFuture.executeListener(AbstractFuture.java:911)
at
com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:645)
at
com.google.common.util.concurrent.Futures.addCallback(Futures.java:1209)
at
org.apache.qpid.server.model.AbstractConfiguredObject.addFutureCallback(AbstractConfiguredObject.java:2870)
at
org.apache.qpid.server.model.AbstractConfiguredObject.doAfter(AbstractConfiguredObject.java:2738)
at
org.apache.qpid.server.model.AbstractConfiguredObject$ChainedSettableFuture.then(AbstractConfiguredObject.java:2714)
at
org.apache.qpid.server.model.AbstractConfiguredObject$5.execute(AbstractConfiguredObject.java:786)
at
org.apache.qpid.server.model.AbstractConfiguredObject$5.execute(AbstractConfiguredObject.java:766)
at
org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:639)
at
org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:632)
at
org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:248)
at
org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submitWrappedTask(TaskExecutorImpl.java:165)
at
org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submit(TaskExecutorImpl.java:153)
at
org.apache.qpid.server.model.AbstractConfiguredObject.doOnConfigThread(AbstractConfiguredObject.java:631)
at
org.apache.qpid.server.model.AbstractConfiguredObject.closeAsync(AbstractConfiguredObject.java:765)
at
org.apache.qpid.server.model.AbstractConfiguredObject$3.performAction(AbstractConfiguredObject.java:707)
at
org.apache.qpid.server.model.AbstractConfiguredObject$3.performAction(AbstractConfiguredObject.java:703)
at
org.apache.qpid.server.model.AbstractConfiguredObject.applyToChildren(AbstractConfiguredObject.java:1313)
at
org.apache.qpid.server.model.AbstractConfiguredObject.closeChildren(AbstractConfiguredObject.java:702)
at
org.apache.qpid.server.model.AbstractConfiguredObject$5$3.call(AbstractConfiguredObject.java:784)
at
org.apache.qpid.server.model.AbstractConfiguredObject$5$3.call(AbstractConfiguredObject.java:780)
at
org.apache.qpid.server.model.AbstractConfiguredObject$21.onSuccess(AbstractConfiguredObject.java:2745)
{noformat}
Broker process hangs when a restart operation is invoked via management
interfaces. The issue can be work around by shutting down (or killing) the
broker and starting it again.
--
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:
[jira] [Commented] (QPID-8133) Refresh Commons-CLI dependency (1.4)
[ https://issues.apache.org/jira/browse/QPID-8133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16404748#comment-16404748 ] ASF subversion and git services commented on QPID-8133: --- Commit 89c69e7f08e9fdd606a7cbab4d18aef0f1132f1e in qpid-broker-j's branch refs/heads/master from [~k-wall] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=89c69e7 ] QPID-8133: [Broker-J] Refresh Commons-CLI dependency (1.4) > Refresh Commons-CLI dependency (1.4) > > > Key: QPID-8133 > URL: https://issues.apache.org/jira/browse/QPID-8133 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Priority: Minor > > The Commons CLI dependency used by Broker-J is getting stale. The latest > release is 1.4. -- 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-7567) [Java Broker] Select appropriate certificate for TLS based on SNIServerName
[ https://issues.apache.org/jira/browse/QPID-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16404749#comment-16404749 ] ASF subversion and git services commented on QPID-7567: --- Commit ac9069ac8cc300ca78e7ef1461de5b2eefb4fe46 in qpid-broker-j's branch refs/heads/master from [~k-wall] [ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=ac9069a ] QPID-7567 : [Broker-J] Delegate consistently to underlying KeyManager > [Java Broker] Select appropriate certificate for TLS based on SNIServerName > --- > > Key: QPID-7567 > URL: https://issues.apache.org/jira/browse/QPID-7567 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Assignee: Keith Wall >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > > Enable SNI support for the Java Broker. > We will need a X509ExtendedKeyManager implementation that gets the > SNIServerName from the SSL handshakes and then selects the most appropriate > certificate alias for the indicated hostname. > I found the following example helpful: > https://github.com/grahamedgecombe/netty-sni-example/blob/master/src/main/java/SniKeyManager.java > https://docs.oracle.com/javase/8/docs/technotes/guides/security/enhancements-8.html > This change requires Java 8, but it is probably possible to retain support > for Java 7 using reflection. > It looks to me like the clients (Qpid JMS Client and Legacy) require no > changes. They both pass the hostname through to the SSLEngine, so the > SNIServerName should already be passed through. Client side support in Java > was added at Java 7. -- 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-1797) Transport log is written on stdOut instead of stdErr
[ https://issues.apache.org/jira/browse/PROTON-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16404680#comment-16404680 ] Robbie Gemmell commented on PROTON-1797: I disagree. The logging is not actually about an error, so I don't see particular reason that it would belong on stderr more than it does stdout. I expect thats probably why it uses stdout. I didn't write it originally, but I would pick stdout today if I was doing so (or as likely, use a logging framework). I don't think 'something else users stderr' is a reason to change it after several years in any event. > Transport log is written on stdOut instead of stdErr > > > Key: PROTON-1797 > URL: https://issues.apache.org/jira/browse/PROTON-1797 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: proton-j-0.24.0 >Reporter: David Kornel >Priority: Minor > > When I export PN_TRACE_FRM=1 client writes frames on stdOut instead of stdErr > like in proton-python client. > > https://github.com/apache/qpid-proton-j/blob/e7aae9469ac2f45a6de1822d7fe3cd2d4c8a314c/proton-j/src/main/java/org/apache/qpid/proton/engine/impl/TransportImpl.java#L1694-L1709 -- 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-1797) Transport log is written on stdOut instead of stdErr
[ https://issues.apache.org/jira/browse/PROTON-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16404668#comment-16404668 ] David Kornel commented on PROTON-1797: -- [~gemmellr] Yeah it is not a bug, but anyway other amqp clients use for frame logs strerr as well as proton python. So I don't understand why proton-j uses stdout. It should be changed. > Transport log is written on stdOut instead of stdErr > > > Key: PROTON-1797 > URL: https://issues.apache.org/jira/browse/PROTON-1797 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: proton-j-0.24.0 >Reporter: David Kornel >Priority: Minor > > When I export PN_TRACE_FRM=1 client writes frames on stdOut instead of stdErr > like in proton-python client. > > https://github.com/apache/qpid-proton-j/blob/e7aae9469ac2f45a6de1822d7fe3cd2d4c8a314c/proton-j/src/main/java/org/apache/qpid/proton/engine/impl/TransportImpl.java#L1694-L1709 -- 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] (PROTON-1797) Transport log is written on stdOut instead of stdErr
[ https://issues.apache.org/jira/browse/PROTON-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed PROTON-1797. -- Resolution: Not A Problem This isn't a bug. I didn't write it, but the choice now I'd probably also think stdout is preferable to stderr personally. That the two differ is perhaps odd, but its definitely not a bug in proton-j. > Transport log is written on stdOut instead of stdErr > > > Key: PROTON-1797 > URL: https://issues.apache.org/jira/browse/PROTON-1797 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: proton-j-0.24.0 >Reporter: David Kornel >Priority: Minor > > When I export PN_TRACE_FRM=1 client writes frames on stdOut instead of stdErr > like in proton-python client. > > https://github.com/apache/qpid-proton-j/blob/e7aae9469ac2f45a6de1822d7fe3cd2d4c8a314c/proton-j/src/main/java/org/apache/qpid/proton/engine/impl/TransportImpl.java#L1694-L1709 -- 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-8136) [Broker-J] Upgrade Jackson dependencies
[ https://issues.apache.org/jira/browse/QPID-8136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16404642#comment-16404642 ] Keith Wall commented on QPID-8136: -- Broker-J currently depends on the following Jackson releases: * Jackson core/annotations/databind 2.8.7 (master/7.0.x) * Jackson core/annotations/databind 2.5.3 (6.1.x/6.0.x) > [Broker-J] Upgrade Jackson dependencies > --- > > Key: QPID-8136 > URL: https://issues.apache.org/jira/browse/QPID-8136 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Priority: Major > > Upgrade Jackson dependencies -- 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-8014) [Broker-J][WMC] Loading of WMC fails on systems with high CPU usage
[
https://issues.apache.org/jira/browse/QPID-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16404640#comment-16404640
]
ASF subversion and git services commented on QPID-8014:
---
Commit 3f0f558759b283592f50e744ca48e25a9a5932dd in qpid-broker-j's branch
refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=3f0f558 ]
QPID-8014:[Broker-J][WMC] Make sure that port UI template is parsed
> [Broker-J][WMC] Loading of WMC fails on systems with high CPU usage
> ---
>
> Key: QPID-8014
> URL: https://issues.apache.org/jira/browse/QPID-8014
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-6.0.8, qpid-java-6.1.4, qpid-java-broker-7.0.0
>Reporter: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-broker-7.1.0
>
> Attachments:
> 0001-QPID-8014-Broker-J-WMC-Make-sure-that-qpid-console-s.patch
>
>
> WMC fails to load on OS having CPU usage over 70%.
> The following error is reported in web browser web console
> {noformat}
> TypeError: controller.tabContainer is undefined
> Stack trace:
> @http://localhost:8080/js/qpid/management/controller.js:108:13
> .cache["dojo/ready"]/http://localhost:8080/dojo/dojo/dojo.js:8:98046
> .cache["dojo/ready"]/http://localhost:8080/dojo/dojo/dojo.js:8:97671
> req.signal/<@http://localhost:8080/dojo/dojo/dojo.js:8:3806
> _9@http://localhost:8080/dojo/dojo/dojo.js:8:328
> req.signal@http://localhost:8080/dojo/dojo/dojo.js:8:3771
> _38@http://localhost:8080/dojo/dojo/dojo.js:8:13709
> _81@http://localhost:8080/dojo/dojo/dojo.js:8:13758
> _33/_f6@http://localhost:8080/dojo/dojo/dojo.js:8:15537
> req.injectUrl/_10b@http://localhost:8080/dojo/dojo/dojo.js:8:18464
> xhr@http://localhost:8080/dojo/dojo/dojo.js:8:93734
> .cache["dojo/_base/xhr"]/http://localhost:8080/dojo/dojo/dojo.js:8:57975
> .cache["dojo/_base/xhr"]/http://localhost:8080/dojo/dojo/dojo.js:8:58333
> @http://localhost:8080/js/qpid/common/footer.js:26:1
> .cache["dojo/_base/array"]/http://localhost:8080/dojo/dojo/dojo.js:8:43572
> .cache["dojo/query"]/http://localhost:8080/dojo/dojo/dojo.js:8:140582
> @http://localhost:8080/js/qpid/common/footer.js:23:1
> _ce@http://localhost:8080/dojo/dojo/dojo.js:8:11945
> _37@http://localhost:8080/dojo/dojo/dojo.js:8:27097
> _37@http://localhost:8080/dojo/dojo/dojo.js:8:13438
> _81/<@http://localhost:8080/dojo/dojo/dojo.js:8:13833
> _38@http://localhost:8080/dojo/dojo/dojo.js:8:13659
> _81@http://localhost:8080/dojo/dojo/dojo.js:8:13758
> _33/_f6@http://localhost:8080/dojo/dojo/dojo.js:8:15537
> req.injectUrl/_10b@http://localhost:8080/dojo/dojo/dojo.js:8:18464
> {noformat}
> The issue was reproduced with the following:
> Firefox 45.8.0
> OS Windows 7.
> CPU usage 70%-90%
--
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-1797) Transport log is written on stdOut instead of stdErr
[ https://issues.apache.org/jira/browse/PROTON-1797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Kornel updated PROTON-1797: - Summary: Transport log is written on stdOut instead of stdErr (was: Transpot log is written on stdOut instead of stdErr) > Transport log is written on stdOut instead of stdErr > > > Key: PROTON-1797 > URL: https://issues.apache.org/jira/browse/PROTON-1797 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Affects Versions: proton-j-0.24.0 >Reporter: David Kornel >Priority: Minor > > When I export PN_TRACE_FRM=1 client writes frames on stdOut instead of stdErr > like in proton-python client. > > https://github.com/apache/qpid-proton-j/blob/e7aae9469ac2f45a6de1822d7fe3cd2d4c8a314c/proton-j/src/main/java/org/apache/qpid/proton/engine/impl/TransportImpl.java#L1694-L1709 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1797) Transpot log is written on stdOut instead of stdErr
David Kornel created PROTON-1797: Summary: Transpot log is written on stdOut instead of stdErr Key: PROTON-1797 URL: https://issues.apache.org/jira/browse/PROTON-1797 Project: Qpid Proton Issue Type: Bug Components: proton-j Affects Versions: proton-j-0.24.0 Reporter: David Kornel When I export PN_TRACE_FRM=1 client writes frames on stdOut instead of stdErr like in proton-python client. https://github.com/apache/qpid-proton-j/blob/e7aae9469ac2f45a6de1822d7fe3cd2d4c8a314c/proton-j/src/main/java/org/apache/qpid/proton/engine/impl/TransportImpl.java#L1694-L1709 -- 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-8130) [Broker-J] IAE "Comparison method violates its general contract!" can be thrown whilst comparing log file details of file logger
[
https://issues.apache.org/jira/browse/QPID-8130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall resolved QPID-8130.
--
Resolution: Fixed
> [Broker-J] IAE "Comparison method violates its general contract!" can be
> thrown whilst comparing log file details of file logger
>
>
> Key: QPID-8130
> URL: https://issues.apache.org/jira/browse/QPID-8130
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.2, qpid-java-6.0.8,
> qpid-java-broker-7.0.0, qpid-java-6.1.5, qpid-java-broker-7.0.1
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Minor
> Fix For: qpid-java-6.1.6, qpid-java-broker-7.0.3
>
>
> IllegalArgumentException "Comparison method violates its general contract!"
> can be thrown whilst comparing log file details of BrokerFileLogger or
> ViortualHostFileLogger
> {noformat}
> 2018-03-14 13:06:57,951 DEBUG [qtp127624166-218]
> (o.a.q.s.m.p.s.r.RestServlet) - IllegalArgumentException processing request
> java.lang.IllegalArgumentException: Comparison method violates its general
> contract!
> at java.util.TimSort.mergeHi(TimSort.java:899)
> at java.util.TimSort.mergeAt(TimSort.java:516)
> at java.util.TimSort.mergeForceCollapse(TimSort.java:457)
> at java.util.TimSort.sort(TimSort.java:254)
> at java.util.Arrays.sort(Arrays.java:1512)
> at java.util.ArrayList.sort(ArrayList.java:1454)
> at java.util.Collections.sort(Collections.java:175)
> at
> org.apache.qpid.server.logging.logback.RolloverWatcher.getLogFileDetails(RolloverWatcher.java:130)
> at
> org.apache.qpid.server.logging.logback.BrokerFileLoggerImpl.getLogFiles(BrokerFileLoggerImpl.java:156)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.qpid.server.model.ConfiguredObjectMethodAttributeOrStatistic.getValue(ConfiguredObjectMethodAttributeOrStatistic.java:68)
> at
> org.apache.qpid.server.model.ConfiguredObjectMethodAttribute.getValue(ConfiguredObjectMethodAttribute.java:26)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.getAttribute(AbstractConfiguredObject.java:1856)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.ConfiguredObjectToMapConverter.incorporateAttributesIntoMap(ConfiguredObjectToMapConverter.java:86)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.ConfiguredObjectToMapConverter.convertObjectToMap(ConfiguredObjectToMapConverter.java:64)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.ConfiguredObjectToMapConverter.incorporateChildrenIntoMap(ConfiguredObjectToMapConverter.java:271)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.ConfiguredObjectToMapConverter.convertObjectToMap(ConfiguredObjectToMapConverter.java:69)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.doGet(RestServlet.java:247)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet.doGet(AbstractServlet.java:128)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.service(RestServlet.java:341)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:841)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1634)
> at
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter$1.run(AuthenticationCheckFilter.java:157)
> at
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter$1.run(AuthenticationCheckFilter.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter.doFilterChainAs(AuthenticationCheckFilter.java:152)
> at
> org.apache.qpid.server.management.plugin.filter.AuthenticationCheckFilter.doFilter(AuthenticationCheckFilter.java:122)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1621)
> at
> org.apache.qpid.server.management.plugin.filter.LoggingFilter.doFilter(LoggingFilter.java:63)
> at
>
[jira] [Created] (QPID-8136) [Broker-J] Upgrade Jackson dependencies
Keith Wall created QPID-8136: Summary: [Broker-J] Upgrade Jackson dependencies Key: QPID-8136 URL: https://issues.apache.org/jira/browse/QPID-8136 Project: Qpid Issue Type: Improvement Components: Broker-J Reporter: Keith Wall Upgrade Jackson dependencies -- 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-8016) [Broker-J] FileKeyStore alias does not select the correct certificate
[
https://issues.apache.org/jira/browse/QPID-8016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16404547#comment-16404547
]
ASF subversion and git services commented on QPID-8016:
---
Commit 6995335307b60d4b365cbc0c235a98a3624bc9a6 in qpid-broker-j's branch
refs/heads/7.0.x from [~k-wall]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=6995335 ]
QPID-8016: [Broker-J] Delegate consistently to the client methods of underlying
KeyManager too
> [Broker-J] FileKeyStore alias does not select the correct certificate
> -
>
> Key: QPID-8016
> URL: https://issues.apache.org/jira/browse/QPID-8016
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-6.1, qpid-java-broker-7.0.0
>Reporter: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.0.3
>
>
> Keystore provider implementation {{FileKeyStore}} has a {{#certificateAlias}}
> attribute that is supposed to select a single certificate for use from a
> store that has many. This feature does not currently work. It seems that
> the last certificate is chosen regardless of the alias specified by the user.
> I reproduced this problem with test resource at
> {{test-profiles/test_resources/ssl/java_client_keystore.jks}}. It contains
> two non-CA certs app1 and app2. app2 was always presented over the TLS
> enabled socket, regardless of the setting of the {{certificateAlias}}
--
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
