[jira] [Commented] (QPID-5868) Java client ignores exceptions when waiting on sync
[ https://issues.apache.org/jira/browse/QPID-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14052722#comment-14052722 ] Rajith Attapattu commented on QPID-5868: I verified that both the transport session and the AMQSession_0_10 (jms session) are both marked closed by the time the exception is thrown to the application, which I think is the most important thing. Both the sync method and the exception method (called via the listener interface) delegates to setCurrentException method. Therefore which gets called first doesn't matter. Without the patch, important exceptions are not reported and customers have complained about it. Therefore I believe it's important to get this patch in. > Java client ignores exceptions when waiting on sync > --- > > Key: QPID-5868 > URL: https://issues.apache.org/jira/browse/QPID-5868 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.27 >Reporter: Rajith Attapattu > Fix For: 0.29 > > Attachments: QPID-5868.patch > > > The java client will wait on the sync command even if an execution exception > is received from the broker. > It will then proceed to throw a timeout exception and the execution exception > is not reported properly to the application. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5610) implement a Maven 3 build for the Java QMF tools and GUI
[ https://issues.apache.org/jira/browse/QPID-5610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14052635#comment-14052635 ] ASF subversion and git services commented on QPID-5610: --- Commit 1607921 from [~gemmellr] in branch 'qpid/trunk' [ https://svn.apache.org/r1607921 ] QPID-5610: update readme to detail usage of the copy-broker profile > implement a Maven 3 build for the Java QMF tools and GUI > > > Key: QPID-5610 > URL: https://issues.apache.org/jira/browse/QPID-5610 > Project: Qpid > Issue Type: Improvement > Components: Tools >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.29 > > > The work being done in QPID-5048 will add an initial Maven 3 build for the > components in the current main java tree, subsequent to which we will look to > split the tree apart to become more component oriented. > As part of the overall process we will also look to implement a Maven 3 build > for the Java QMF tools, since these depend on e.g the Java client or the Java > broker and currently utilise the output of their existing Ant build. In > addition to adopting the new builds for the other components, this will > additionally allow deploying them to Maven Central and make it easier to keep > the QMF tools functioning. > This will be a more involved process for the QMF tools than those in > QPID-5048, requiring layout changes to adopt a suitable structure in the > repository around which to create the new build. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5610) implement a Maven 3 build for the Java QMF tools and GUI
[ https://issues.apache.org/jira/browse/QPID-5610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14052629#comment-14052629 ] ASF subversion and git services commented on QPID-5610: --- Commit 1607915 from [~gemmellr] in branch 'qpid/trunk' [ https://svn.apache.org/r1607915 ] QPID-5610: add a profile to optionally extract the broker release artifact and copy the QMF2 broker plugin into the lib dir > implement a Maven 3 build for the Java QMF tools and GUI > > > Key: QPID-5610 > URL: https://issues.apache.org/jira/browse/QPID-5610 > Project: Qpid > Issue Type: Improvement > Components: Tools >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.29 > > > The work being done in QPID-5048 will add an initial Maven 3 build for the > components in the current main java tree, subsequent to which we will look to > split the tree apart to become more component oriented. > As part of the overall process we will also look to implement a Maven 3 build > for the Java QMF tools, since these depend on e.g the Java client or the Java > broker and currently utilise the output of their existing Ant build. In > addition to adopting the new builds for the other components, this will > additionally allow deploying them to Maven Central and make it easier to keep > the QMF tools functioning. > This will be a more involved process for the QMF tools than those in > QPID-5048, requiring layout changes to adopt a suitable structure in the > repository around which to create the new build. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5873) Allow ACL rules to be applied to VirtualHostNode objects
[ https://issues.apache.org/jira/browse/QPID-5873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14052544#comment-14052544 ] ASF subversion and git services commented on QPID-5873: --- Commit 1607889 from [~k-wall] in branch 'qpid/trunk' [ https://svn.apache.org/r1607889 ] QPID-5873: Exclude new ACL system tests from Json profile; fix BDBHARemoteReplicationNodeTest unit test wrt monitor attribute > Allow ACL rules to be applied to VirtualHostNode objects > > > Key: QPID-5873 > URL: https://issues.apache.org/jira/browse/QPID-5873 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Assignee: Andrew MacBean > Fix For: 0.29 > > > Using the existing ACL mechanism to allow the creation/update/delete of > virtualhostnode objects within the Broker to be controlled. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5876) Java client causes unecessary rejects after failover when using 0-8..0-9-1 protocols
[ https://issues.apache.org/jira/browse/QPID-5876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14052536#comment-14052536 ] Robbie Gemmell commented on QPID-5876: -- QPID-3521 + QPID-3546 sprung to mind. > Java client causes unecessary rejects after failover when using 0-8..0-9-1 > protocols > > > Key: QPID-5876 > URL: https://issues.apache.org/jira/browse/QPID-5876 > Project: Qpid > Issue Type: Bug > Components: Java Client >Reporter: Andrew MacBean >Assignee: Keith Wall > > Highest delivery tag variable not reset after failover and causes rejections > to be sent unecessarily. > The AMQSession.resubscribe() implementation does not reset the > _highestDeliveryTag member variable. This means that rejects are send > needlessly/incorrectly after failover occurs as the value is higher than it > should be. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-5875) [Java Tests] Test VirtualHostRestTest testPutCreateVirtualHostUsingProfileNodeType is failing because ProvidedStore virtual host cannot be used with JSON VHN
[
https://issues.apache.org/jira/browse/QPID-5875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall closed QPID-5875.
Changes seem reasonable to me
> [Java Tests] Test VirtualHostRestTest
> testPutCreateVirtualHostUsingProfileNodeType is failing because ProvidedStore
> virtual host cannot be used with JSON VHN
> -
>
> Key: QPID-5875
> URL: https://issues.apache.org/jira/browse/QPID-5875
> Project: Qpid
> Issue Type: Bug
> Components: Java Tests
>Reporter: Alex Rudyy
>Assignee: Keith Wall
> Fix For: 0.29
>
>
> {noformat}
> qtp1061565585-20493 2014-07-04 04:50:38,574 WARN
> [plugin.servlet.rest.RestServlet] Caught exception
> org.apache.qpid.server.configuration.IllegalConfigurationException:
> ProvidedStore virtual host can only be used where the node's store
> (org.apache.qpid.server.store.JsonFileConfigStore) is a message store
> provider.
> at
> org.apache.qpid.server.virtualhost.ProvidedStoreVirtualHostImpl.onValidate(ProvidedStoreVirtualHostImpl.java:62)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doValidation(AbstractConfiguredObject.java:531)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.create(AbstractConfiguredObject.java:472)
> at
> org.apache.qpid.server.model.AbstractConfiguredObjectTypeFactory.create(AbstractConfiguredObjectTypeFactory.java:58)
> at
> org.apache.qpid.server.model.AbstractConfiguredObjectTypeFactory.create(AbstractConfiguredObjectTypeFactory.java:31)
> at
> org.apache.qpid.server.model.ConfiguredObjectFactoryImpl.create(ConfiguredObjectFactoryImpl.java:112)
> at
> org.apache.qpid.server.virtualhostnode.AbstractStandardVirtualHostNode.addChild(AbstractStandardVirtualHostNode.java:63)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$10.execute(AbstractConfiguredObject.java:1078)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$10.execute(AbstractConfiguredObject.java:1072)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.executeTask(TaskExecutorImpl.java:299)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.access$400(TaskExecutorImpl.java:43)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper$1.run(TaskExecutorImpl.java:327)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:356)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper.call(TaskExecutorImpl.java:322)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-5875) [Java Tests] Test VirtualHostRestTest testPutCreateVirtualHostUsingProfileNodeType is failing because ProvidedStore virtual host cannot be used with JSON VHN
[
https://issues.apache.org/jira/browse/QPID-5875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall resolved QPID-5875.
--
Resolution: Fixed
> [Java Tests] Test VirtualHostRestTest
> testPutCreateVirtualHostUsingProfileNodeType is failing because ProvidedStore
> virtual host cannot be used with JSON VHN
> -
>
> Key: QPID-5875
> URL: https://issues.apache.org/jira/browse/QPID-5875
> Project: Qpid
> Issue Type: Bug
> Components: Java Tests
>Reporter: Alex Rudyy
>Assignee: Keith Wall
> Fix For: 0.29
>
>
> {noformat}
> qtp1061565585-20493 2014-07-04 04:50:38,574 WARN
> [plugin.servlet.rest.RestServlet] Caught exception
> org.apache.qpid.server.configuration.IllegalConfigurationException:
> ProvidedStore virtual host can only be used where the node's store
> (org.apache.qpid.server.store.JsonFileConfigStore) is a message store
> provider.
> at
> org.apache.qpid.server.virtualhost.ProvidedStoreVirtualHostImpl.onValidate(ProvidedStoreVirtualHostImpl.java:62)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doValidation(AbstractConfiguredObject.java:531)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.create(AbstractConfiguredObject.java:472)
> at
> org.apache.qpid.server.model.AbstractConfiguredObjectTypeFactory.create(AbstractConfiguredObjectTypeFactory.java:58)
> at
> org.apache.qpid.server.model.AbstractConfiguredObjectTypeFactory.create(AbstractConfiguredObjectTypeFactory.java:31)
> at
> org.apache.qpid.server.model.ConfiguredObjectFactoryImpl.create(ConfiguredObjectFactoryImpl.java:112)
> at
> org.apache.qpid.server.virtualhostnode.AbstractStandardVirtualHostNode.addChild(AbstractStandardVirtualHostNode.java:63)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$10.execute(AbstractConfiguredObject.java:1078)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$10.execute(AbstractConfiguredObject.java:1072)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.executeTask(TaskExecutorImpl.java:299)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.access$400(TaskExecutorImpl.java:43)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper$1.run(TaskExecutorImpl.java:327)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:356)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper.call(TaskExecutorImpl.java:322)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5876) Java client causes unecessary rejects after failover when using 0-8..0-9-1 protocols
[ https://issues.apache.org/jira/browse/QPID-5876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14052527#comment-14052527 ] ASF subversion and git services commented on QPID-5876: --- Commit 1607882 from [~macbean] in branch 'qpid/trunk' [ https://svn.apache.org/r1607882 ] QPID-5876: [Java Client] Highest delivery tag variable not reset after failover and causes rejections to be sent Work by Keith Wall and me. > Java client causes unecessary rejects after failover when using 0-8..0-9-1 > protocols > > > Key: QPID-5876 > URL: https://issues.apache.org/jira/browse/QPID-5876 > Project: Qpid > Issue Type: Bug > Components: Java Client >Reporter: Andrew MacBean >Assignee: Andrew MacBean > > Highest delivery tag variable not reset after failover and causes rejections > to be sent unecessarily. > The AMQSession.resubscribe() implementation does not reset the > _highestDeliveryTag member variable. This means that rejects are send > needlessly/incorrectly after failover occurs as the value is higher than it > should be. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-5876) Java client causes unecessary rejects after failover when using 0-8..0-9-1 protocols
[ https://issues.apache.org/jira/browse/QPID-5876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew MacBean reassigned QPID-5876: Assignee: Keith Wall (was: Andrew MacBean) Could you please accept this change we paired on? > Java client causes unecessary rejects after failover when using 0-8..0-9-1 > protocols > > > Key: QPID-5876 > URL: https://issues.apache.org/jira/browse/QPID-5876 > Project: Qpid > Issue Type: Bug > Components: Java Client >Reporter: Andrew MacBean >Assignee: Keith Wall > > Highest delivery tag variable not reset after failover and causes rejections > to be sent unecessarily. > The AMQSession.resubscribe() implementation does not reset the > _highestDeliveryTag member variable. This means that rejects are send > needlessly/incorrectly after failover occurs as the value is higher than it > should be. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-5876) Java client causes unecessary rejects after failover when using 0-8..0-9-1 protocols
[ https://issues.apache.org/jira/browse/QPID-5876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew MacBean updated QPID-5876: - Status: Reviewable (was: In Progress) > Java client causes unecessary rejects after failover when using 0-8..0-9-1 > protocols > > > Key: QPID-5876 > URL: https://issues.apache.org/jira/browse/QPID-5876 > Project: Qpid > Issue Type: Bug > Components: Java Client >Reporter: Andrew MacBean >Assignee: Andrew MacBean > > Highest delivery tag variable not reset after failover and causes rejections > to be sent unecessarily. > The AMQSession.resubscribe() implementation does not reset the > _highestDeliveryTag member variable. This means that rejects are send > needlessly/incorrectly after failover occurs as the value is higher than it > should be. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5870) Closing a topic consumer should delete its exclusive auto-delete queue
[ https://issues.apache.org/jira/browse/QPID-5870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14052523#comment-14052523 ] Rajith Attapattu commented on QPID-5870: Again I apologize for not providing enough context. Yes the key change here is "deleteSubscriptionQueue" is always being called. This is to bring the JMS client inline with the address spec. This is something requested by customers and IMO it is the correct behavior as well. The delete directive should only apply for node properties (like the exchange or queue being created). The subscription queue should not exist beyond the subscription except in the case of durable subscriptions. I will make sure the durable subscriptions aren't affected. > Closing a topic consumer should delete its exclusive auto-delete queue > -- > > Key: QPID-5870 > URL: https://issues.apache.org/jira/browse/QPID-5870 > Project: Qpid > Issue Type: Bug >Reporter: Rajith Attapattu > Attachments: QPID-5870.patch > > > When a topic consumer is closed, the subscription queue needs to be closed as > well. > Currently this queue is only deleted when the session is closed (due to being > marked auto-deleted). -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-5785) QueueBindTest.testQueueCanBeReboundOnTopicExchange shows NPE in logs when trying to unbind exchange
[
https://issues.apache.org/jira/browse/QPID-5785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy resolved QPID-5785.
--
Resolution: Fixed
The changes look good to me
> QueueBindTest.testQueueCanBeReboundOnTopicExchange shows NPE in logs when
> trying to unbind exchange
> ---
>
> Key: QPID-5785
> URL: https://issues.apache.org/jira/browse/QPID-5785
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: 0.29
>Reporter: Keith Wall
>Assignee: Alex Rudyy
> Fix For: 0.29
>
>
> QBT.testQueueCanBeReboundOnTopicExchange is showing a NPE the log when run on
> a slow CI box. Note this issue does not cause a test failure, the the
> ConnectionCloseMethodHandler reports an error broker side.
> {noformat}
> IoReceiver - /127.0.0.1:41943 2014-05-23 11:19:55,984 ERROR
> [protocol.v0_8.handler.ConnectionCloseMethodHandler] Error closing protocol
> session: java.lang.NullPointerException
> java.lang.NullPointerException
> at
> org.apache.qpid.server.exchange.topic.TopicExchangeResult.removeUnfilteredQueue(TopicExchangeResult.java:63)
> at
> org.apache.qpid.server.exchange.TopicExchange.deregisterQueue(TopicExchange.java:274)
> at
> org.apache.qpid.server.exchange.TopicExchange.onUnbind(TopicExchange.java:330)
> at
> org.apache.qpid.server.exchange.AbstractExchange.doRemoveBinding(AbstractExchange.java:431)
> at
> org.apache.qpid.server.exchange.AbstractExchange.removeBinding(AbstractExchange.java:640)
> at
> org.apache.qpid.server.exchange.AbstractExchange.access$000(AbstractExchange.java:71)
> at
> org.apache.qpid.server.exchange.AbstractExchange$1.stateChanged(AbstractExchange.java:134)
> at
> org.apache.qpid.server.exchange.AbstractExchange$1.stateChanged(AbstractExchange.java:128)
> at
> org.apache.qpid.server.binding.BindingImpl.doDelete(BindingImpl.java:208)
> at sun.reflect.GeneratedMethodAccessor47.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:632)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainStateIfResolved(AbstractConfiguredObject.java:612)
> at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.automatedSetValue(AbstractConfiguredObject.java:374)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.changeAttribute(AbstractConfiguredObject.java:940)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.changeAttributes(AbstractConfiguredObject.java:1223)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$11.execute(AbstractConfiguredObject.java:1202)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$2.execute(TaskExecutorImpl.java:148)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$2.execute(TaskExecutorImpl.java:144)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.executeTask(TaskExecutorImpl.java:298)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submit(TaskExecutorImpl.java:130)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.run(TaskExecutorImpl.java:250)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.run(TaskExecutorImpl.java:143)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.runTask(AbstractConfiguredObject.java:1179)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.setAttributes(AbstractConfiguredObject.java:1196)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$7.execute(AbstractConfiguredObject.java:734)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$7.execute(AbstractConfiguredObject.java:719)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.executeTask(TaskExecutorImpl.java:298)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.access$400(TaskExecutorImpl.java:43)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper$1.run(TaskExecutorImpl.java:326)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:356)
[jira] [Assigned] (QPID-5875) [Java Tests] Test VirtualHostRestTest testPutCreateVirtualHostUsingProfileNodeType is failing because ProvidedStore virtual host cannot be used with JSON VHN
[
https://issues.apache.org/jira/browse/QPID-5875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy reassigned QPID-5875:
Assignee: Keith Wall (was: Alex Rudyy)
Keith,
I mistakenly committed the changes [r1607860|https://svn.apache.org/r1607860]
for QPID-5867 against this JIRA. Could you please review this JIRA as well?
> [Java Tests] Test VirtualHostRestTest
> testPutCreateVirtualHostUsingProfileNodeType is failing because ProvidedStore
> virtual host cannot be used with JSON VHN
> -
>
> Key: QPID-5875
> URL: https://issues.apache.org/jira/browse/QPID-5875
> Project: Qpid
> Issue Type: Bug
> Components: Java Tests
>Reporter: Alex Rudyy
>Assignee: Keith Wall
> Fix For: 0.29
>
>
> {noformat}
> qtp1061565585-20493 2014-07-04 04:50:38,574 WARN
> [plugin.servlet.rest.RestServlet] Caught exception
> org.apache.qpid.server.configuration.IllegalConfigurationException:
> ProvidedStore virtual host can only be used where the node's store
> (org.apache.qpid.server.store.JsonFileConfigStore) is a message store
> provider.
> at
> org.apache.qpid.server.virtualhost.ProvidedStoreVirtualHostImpl.onValidate(ProvidedStoreVirtualHostImpl.java:62)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doValidation(AbstractConfiguredObject.java:531)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.create(AbstractConfiguredObject.java:472)
> at
> org.apache.qpid.server.model.AbstractConfiguredObjectTypeFactory.create(AbstractConfiguredObjectTypeFactory.java:58)
> at
> org.apache.qpid.server.model.AbstractConfiguredObjectTypeFactory.create(AbstractConfiguredObjectTypeFactory.java:31)
> at
> org.apache.qpid.server.model.ConfiguredObjectFactoryImpl.create(ConfiguredObjectFactoryImpl.java:112)
> at
> org.apache.qpid.server.virtualhostnode.AbstractStandardVirtualHostNode.addChild(AbstractStandardVirtualHostNode.java:63)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$10.execute(AbstractConfiguredObject.java:1078)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$10.execute(AbstractConfiguredObject.java:1072)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.executeTask(TaskExecutorImpl.java:299)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.access$400(TaskExecutorImpl.java:43)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper$1.run(TaskExecutorImpl.java:327)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:356)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper.call(TaskExecutorImpl.java:322)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-5875) [Java Tests] Test VirtualHostRestTest testPutCreateVirtualHostUsingProfileNodeType is failing because ProvidedStore virtual host cannot be used with JSON VHN
[
https://issues.apache.org/jira/browse/QPID-5875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-5875:
-
Status: Reviewable (was: In Progress)
> [Java Tests] Test VirtualHostRestTest
> testPutCreateVirtualHostUsingProfileNodeType is failing because ProvidedStore
> virtual host cannot be used with JSON VHN
> -
>
> Key: QPID-5875
> URL: https://issues.apache.org/jira/browse/QPID-5875
> Project: Qpid
> Issue Type: Bug
> Components: Java Tests
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
> Fix For: 0.29
>
>
> {noformat}
> qtp1061565585-20493 2014-07-04 04:50:38,574 WARN
> [plugin.servlet.rest.RestServlet] Caught exception
> org.apache.qpid.server.configuration.IllegalConfigurationException:
> ProvidedStore virtual host can only be used where the node's store
> (org.apache.qpid.server.store.JsonFileConfigStore) is a message store
> provider.
> at
> org.apache.qpid.server.virtualhost.ProvidedStoreVirtualHostImpl.onValidate(ProvidedStoreVirtualHostImpl.java:62)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doValidation(AbstractConfiguredObject.java:531)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.create(AbstractConfiguredObject.java:472)
> at
> org.apache.qpid.server.model.AbstractConfiguredObjectTypeFactory.create(AbstractConfiguredObjectTypeFactory.java:58)
> at
> org.apache.qpid.server.model.AbstractConfiguredObjectTypeFactory.create(AbstractConfiguredObjectTypeFactory.java:31)
> at
> org.apache.qpid.server.model.ConfiguredObjectFactoryImpl.create(ConfiguredObjectFactoryImpl.java:112)
> at
> org.apache.qpid.server.virtualhostnode.AbstractStandardVirtualHostNode.addChild(AbstractStandardVirtualHostNode.java:63)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$10.execute(AbstractConfiguredObject.java:1078)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$10.execute(AbstractConfiguredObject.java:1072)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.executeTask(TaskExecutorImpl.java:299)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.access$400(TaskExecutorImpl.java:43)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper$1.run(TaskExecutorImpl.java:327)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:356)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper.call(TaskExecutorImpl.java:322)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-5819) Starting a Broker with a virtualhostnode in stopped state causes exception
[
https://issues.apache.org/jira/browse/QPID-5819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy resolved QPID-5819.
--
Resolution: Fixed
The change looks Ok to me
> Starting a Broker with a virtualhostnode in stopped state causes exception
> --
>
> Key: QPID-5819
> URL: https://issues.apache.org/jira/browse/QPID-5819
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: 0.29
>Reporter: Keith Wall
>Assignee: Alex Rudyy
>Priority: Critical
> Fix For: 0.29
>
>
> If I start a Broker that has a virtualhostnode in the STOPPED state, the
> following exception is observed and the Broker fails to start.
> {noformat}
> FATAL [main] (server.Broker) - Exception during startup
> java.lang.NullPointerException
> at
> org.apache.qpid.server.store.JsonFileConfigStore.releaseFileLock(JsonFileConfigStore.java:593)
> at
> org.apache.qpid.server.store.JsonFileConfigStore.closeConfigurationStore(JsonFileConfigStore.java:565)
> at
> org.apache.qpid.server.virtualhostnode.AbstractVirtualHostNode.closeConfigurationStore(AbstractVirtualHostNode.java:245)
> at
> org.apache.qpid.server.virtualhostnode.AbstractVirtualHostNode.doStop(AbstractVirtualHostNode.java:209)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5868) Java client ignores exceptions when waiting on sync
[ https://issues.apache.org/jira/browse/QPID-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14052508#comment-14052508 ] Rajith Attapattu commented on QPID-5868: Apologies for not putting enough info in the JIRA. Robbie you description is correct. If an execution exception is thrown at the time close is initiated you can easily reproduce this issue. When notified of the exception the AMQSession_0_10 tries to close the session. However the thread is blocked waiting to grab the message delivery lock. But that lock is already taken by the thread that initiated the close and is blocked (timed wait) on the commandsLock waiting for the sync to complete. Once it times out, and since the session is still not closed, the exception being thrown is the time out exception and not the exception that caused the session close. > Java client ignores exceptions when waiting on sync > --- > > Key: QPID-5868 > URL: https://issues.apache.org/jira/browse/QPID-5868 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.27 >Reporter: Rajith Attapattu > Fix For: 0.29 > > Attachments: QPID-5868.patch > > > The java client will wait on the sync command even if an execution exception > is received from the broker. > It will then proceed to throw a timeout exception and the execution exception > is not reported properly to the application. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5868) Java client ignores exceptions when waiting on sync
[ https://issues.apache.org/jira/browse/QPID-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14052509#comment-14052509 ] Rajith Attapattu commented on QPID-5868: As for the session being closed, once the message delivery lock gets released, the thread IO Receiver thread will continue and will call closed method on the Session which will mark it close. > Java client ignores exceptions when waiting on sync > --- > > Key: QPID-5868 > URL: https://issues.apache.org/jira/browse/QPID-5868 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.27 >Reporter: Rajith Attapattu > Fix For: 0.29 > > Attachments: QPID-5868.patch > > > The java client will wait on the sync command even if an execution exception > is received from the broker. > It will then proceed to throw a timeout exception and the execution exception > is not reported properly to the application. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-5782) VirtualHostHouseKeeper tries to check queues that are not yet open leading to NPE in logs
[
https://issues.apache.org/jira/browse/QPID-5782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy resolved QPID-5782.
--
Resolution: Fixed
The changes look good to me
> VirtualHostHouseKeeper tries to check queues that are not yet open leading to
> NPE in logs
> -
>
> Key: QPID-5782
> URL: https://issues.apache.org/jira/browse/QPID-5782
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: 0.29
>Reporter: Keith Wall
>Assignee: Alex Rudyy
> Fix For: 0.29
>
>
> Since QPID-5710, there has been a possibility that the housekeeper can
> attempt to check that message status on queues that are not yet open, and
> this leads to an NPE as such queues have a null entry list.
> TransactionTimeoutTest occasionally shows this problem (see log excerpt
> below). It does not cause a test failure as the housekeeper merely logs all
> exceptions and continues.
> It seems QPID-5710 introduced this possibility as it moved the creation of
> the queue entry list from construction time to onOpen().
> {noformat}
> IoReceiver - localhost/127.0.0.1:15672 2014-05-23 08:00:17,586 DEBUG
> [qpid.client.protocol.AMQProtocolHandler] (1873784078)Method frame received:
> [ExchangeDeclareOkBodyImpl: ]
> main 2014-05-23 08:00:17,586 DEBUG [qpid.protocol] SEND:
> [org.apache.qpid.client.protocol.AMQProtocolHandler@6fafad0e] Frame
> channelId: 3, bodyFrame: [QueueDeclareBodyImpl: ticket=0,
> queue=TransactionTimeoutTest-testConsumerIdleCommit, passive=false,
> durable=true, exclusive=false, autoDelete=false, nowait=false, arguments=null]
> IoReceiver - /127.0.0.1:50620 2014-05-23 08:00:17,586 DEBUG
> [server.protocol.v0_8.AMQProtocolEngine] Frame handled in 0 ms. Frame: Frame
> channelId: 3, bodyFrame: [ExchangeDeclareBodyImpl: ticket=0,
> exchange=amq.direct, type=direct, passive=true, durable=false,
> autoDelete=false, internal=false, nowait=false, arguments=null]
> IoReceiver - /127.0.0.1:50620 2014-05-23 08:00:17,586 DEBUG
> [server.protocol.v0_8.AMQChannel] sync() called on channel 3(1965183178)
> IoReceiver - /127.0.0.1:50620 2014-05-23 08:00:17,586 DEBUG
> [server.protocol.v0_8.AMQProtocolEngine] RECV: Frame channelId: 3, bodyFrame:
> [QueueDeclareBodyImpl: ticket=0,
> queue=TransactionTimeoutTest-testConsumerIdleCommit, passive=false,
> durable=true, exclusive=false, autoDelete=false, nowait=false, arguments=null]
> IoReceiver - /127.0.0.1:50620 2014-05-23 08:00:17,587 DEBUG
> [server.store.berkeleydb.BDBMessageStore] Create
> [name=TransactionTimeoutTest-testConsumerIdleCommit, categoryClass=interface
> org.apache.qpid.server.model.Queue, type=Queue,
> id=848209cf-5c99-4b95-8488-c07973eb199f]
> IoReceiver - /127.0.0.1:50620 2014-05-23 08:00:17,587 DEBUG
> [server.store.berkeleydb.BDBMessageStore] Storing configured object record:
> [name=TransactionTimeoutTest-testConsumerIdleCommit, categoryClass=interface
> org.apache.qpid.server.model.Queue, type=Queue,
> id=848209cf-5c99-4b95-8488-c07973eb199f]
> test:VirtualHostHouseKeepingTask 2014-05-23 08:00:17,589 DEBUG
> [qpid.server.virtualhost.AbstractVirtualHost] Checking message status for
> queue: TransactionTimeoutTest-testConsumerIdleCommit
> test:VirtualHostHouseKeepingTask 2014-05-23 08:00:17,589 ERROR
> [qpid.server.virtualhost.AbstractVirtualHost] Exception in housekeeping for
> queue: TransactionTimeoutTest-testConsumerIdleCommit
> java.lang.NullPointerException
> at
> org.apache.qpid.server.queue.AbstractQueue.checkMessageStatus(AbstractQueue.java:1999)
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost$VirtualHostHouseKeepingTask.execute(AbstractVirtualHost.java:935)
> at
> org.apache.qpid.server.virtualhost.HouseKeepingTask$1.run(HouseKeepingTask.java:61)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:356)
> at
> org.apache.qpid.server.virtualhost.HouseKeepingTask.run(HouseKeepingTask.java:54)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> IoReceiver - /127.0.0.1:50620 2014-05-23 08:00:17,598 INFO
> [qpid.message.queue
Re: Potential qpid cpp 0.28 bug
On 07/04/2014 04:00 PM, Duong Quynh (FSU1.Z8.IP) wrote: Like I said in a different thread, I was using JBOSS A-MQ. Which is based on ActiveMQ. However the point is that its some compatibility issue, and a protocol trace will help establish what that is. __ From: Gordon Sim [g...@redhat.com] Sent: Friday, July 04, 2014 6:41 PM To: dev@qpid.apache.org Subject: Re: Potential qpid cpp 0.28 bug On 07/04/2014 10:31 AM, Duong Quynh (FSU1.Z8.IP) wrote: I will get down to the log later when I have time, however, I don't see this problem happening with the JAVA client, the Producer just exits with identical logic. The c++ sender example you posted works fine for me against ActiveMQ 5.9 when using the 0.28 release. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-5867) [Java Broker] Add functionality to prevent unintended HA node creation and mechanisms to react on intruder HA nodes
[ https://issues.apache.org/jira/browse/QPID-5867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-5867: - Fix Version/s: 0.29 > [Java Broker] Add functionality to prevent unintended HA node creation and > mechanisms to react on intruder HA nodes > --- > > Key: QPID-5867 > URL: https://issues.apache.org/jira/browse/QPID-5867 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Alex Rudyy >Assignee: Keith Wall > Fix For: 0.29 > > > Add functionality to prevent unintended node creation and mechanisms to react > on intruder nodes > New HA VH attribute permittedNodeList > Nodes register the contents of this attribute as app-state > On adding a new node to the griup, the node must check to see its node > address is included in the app-state, if not, refuse to join > All nodes periodically (BDBHAVHN has a thread dedicated to the purpose or > reuse node discovery thread?) check to see if nodes exist that do not appear > in the app-state. If so VHN will close env and go into ERROR state. > If in management mode don't periodically check the PNL, thus allowing an > intruder to be removed. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-5867) [Java Broker] Add functionality to prevent unintended HA node creation and mechanisms to react on intruder HA nodes
[ https://issues.apache.org/jira/browse/QPID-5867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall closed QPID-5867. > [Java Broker] Add functionality to prevent unintended HA node creation and > mechanisms to react on intruder HA nodes > --- > > Key: QPID-5867 > URL: https://issues.apache.org/jira/browse/QPID-5867 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Alex Rudyy >Assignee: Keith Wall > > Add functionality to prevent unintended node creation and mechanisms to react > on intruder nodes > New HA VH attribute permittedNodeList > Nodes register the contents of this attribute as app-state > On adding a new node to the griup, the node must check to see its node > address is included in the app-state, if not, refuse to join > All nodes periodically (BDBHAVHN has a thread dedicated to the purpose or > reuse node discovery thread?) check to see if nodes exist that do not appear > in the app-state. If so VHN will close env and go into ERROR state. > If in management mode don't periodically check the PNL, thus allowing an > intruder to be removed. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-5867) [Java Broker] Add functionality to prevent unintended HA node creation and mechanisms to react on intruder HA nodes
[ https://issues.apache.org/jira/browse/QPID-5867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall resolved QPID-5867. -- Resolution: Fixed Changes seem reasonable to me. > [Java Broker] Add functionality to prevent unintended HA node creation and > mechanisms to react on intruder HA nodes > --- > > Key: QPID-5867 > URL: https://issues.apache.org/jira/browse/QPID-5867 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Alex Rudyy >Assignee: Keith Wall > > Add functionality to prevent unintended node creation and mechanisms to react > on intruder nodes > New HA VH attribute permittedNodeList > Nodes register the contents of this attribute as app-state > On adding a new node to the griup, the node must check to see its node > address is included in the app-state, if not, refuse to join > All nodes periodically (BDBHAVHN has a thread dedicated to the purpose or > reuse node discovery thread?) check to see if nodes exist that do not appear > in the app-state. If so VHN will close env and go into ERROR state. > If in management mode don't periodically check the PNL, thus allowing an > intruder to be removed. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
RE: Potential qpid cpp 0.28 bug
Like I said in a different thread, I was using JBOSS A-MQ. Cheers. From: Gordon Sim [g...@redhat.com] Sent: Friday, July 04, 2014 6:41 PM To: dev@qpid.apache.org Subject: Re: Potential qpid cpp 0.28 bug On 07/04/2014 10:31 AM, Duong Quynh (FSU1.Z8.IP) wrote: > I will get down to the log later when I have time, however, I don't see this > problem happening with the JAVA client, the Producer just exits with > identical logic. The c++ sender example you posted works fine for me against ActiveMQ 5.9 when using the 0.28 release. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (QPID-5877) Potential for rejected messages to be resent out of order
[ https://issues.apache.org/jira/browse/QPID-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew MacBean reopened QPID-5877: -- > Potential for rejected messages to be resent out of order > - > > Key: QPID-5877 > URL: https://issues.apache.org/jira/browse/QPID-5877 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Andrew MacBean >Assignee: Andrew MacBean > Fix For: 0.29 > > > Based on investigation of a test failures in the > FailoverBehaviourTest#testTransactionRolledBackExceptionThrownOnCommitAfterFailoverOnMessageReceiving() > it was observed that the messages consumed by the client after failover were > out of order. > This manifested itself because of a client bug (QPID-5878) that means that > after failover the highestDeliveryTag was not rest and so rejects were send > spuriosly for messages previously delivered. > This meant that if the AbstractQueue.getNextAvailableEntry was executing > while the IO Thread caused a rejected message to be requeued (and updated > lastSeen node) the logic that finally decides the next entry node would > incorrectly continue if the lastSeen and releasedNodes where the very same > queue entry. This would mean that the next selected by the broker would > break the ordering sequence expected. > Basically, the AbstractQueue.getNextAvailableEntry implementation has the > potential to choose the wrong node when lastSeen and releasedNode are the > same as the compareTo impl to determine which node to select but uses the > > operator rather than >= and so wont select releasedNode in the case were that > and lastSeen are the same. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-5877) Potential for rejected messages to be resent out of order
[ https://issues.apache.org/jira/browse/QPID-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew MacBean updated QPID-5877: - Status: Reviewable (was: In Progress) > Potential for rejected messages to be resent out of order > - > > Key: QPID-5877 > URL: https://issues.apache.org/jira/browse/QPID-5877 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Andrew MacBean >Assignee: Andrew MacBean > Fix For: 0.29 > > > Based on investigation of a test failures in the > FailoverBehaviourTest#testTransactionRolledBackExceptionThrownOnCommitAfterFailoverOnMessageReceiving() > it was observed that the messages consumed by the client after failover were > out of order. > This manifested itself because of a client bug (QPID-5878) that means that > after failover the highestDeliveryTag was not rest and so rejects were send > spuriosly for messages previously delivered. > This meant that if the AbstractQueue.getNextAvailableEntry was executing > while the IO Thread caused a rejected message to be requeued (and updated > lastSeen node) the logic that finally decides the next entry node would > incorrectly continue if the lastSeen and releasedNodes where the very same > queue entry. This would mean that the next selected by the broker would > break the ordering sequence expected. > Basically, the AbstractQueue.getNextAvailableEntry implementation has the > potential to choose the wrong node when lastSeen and releasedNode are the > same as the compareTo impl to determine which node to select but uses the > > operator rather than >= and so wont select releasedNode in the case were that > and lastSeen are the same. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-5877) Potential for rejected messages to be resent out of order
[ https://issues.apache.org/jira/browse/QPID-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew MacBean updated QPID-5877: - Description: Based on investigation of a test failures in the FailoverBehaviourTest#testTransactionRolledBackExceptionThrownOnCommitAfterFailoverOnMessageReceiving() it was observed that the messages consumed by the client after failover were out of order. This manifested itself because of a client bug (QPID-5878) that means that after failover the highestDeliveryTag was not rest and so rejects were send spuriosly for messages previously delivered. This meant that if the AbstractQueue.getNextAvailableEntry was executing while the IO Thread caused a rejected message to be requeued (and updated lastSeen node) the logic that finally decides the next entry node would incorrectly continue if the lastSeen and releasedNodes where the very same queue entry. This would mean that the next selected by the broker would break the ordering sequence expected. Basically, the AbstractQueue.getNextAvailableEntry implementation has the potential to choose the wrong node when lastSeen and releasedNode are the same as the compareTo impl to determine which node to select but uses the > operator rather than >= and so wont select releasedNode in the case were that and lastSeen are the same. was: Based on investigation of a test failures in the FailoverBehaviourTest#testTransactionRolledBackExceptionThrownOnCommitAfterFailoverOnMessageReceiving() it was observed that the messages consumed by the client after failover were out of order. This manifested itself because of a client bug (QPID-5878) that means that after failover the highestDeliveryTag was not rest and so rejects were send spuriosly for messages. This meant that if the AbstractQueue.getNextAvailableEntry was executing while the IO Thread caused a rejected message to be requeued the logic that finally decides the next entry node would incorrectly continue if the lastSeen and releasedNodes where the very same queue entry. This would mean that the next selected by the broker would break the ordering. Basically, the AbstractQueue.getNextAvailableEntry implementation has the potential to choose the wrong node when lastSeen and releasedNode are the same as the compareTo impl to determine which node to select but uses the > operator rather than >= and so wont select releasedNode in the case were that and lastSeen are the same. > Potential for rejected messages to be resent out of order > - > > Key: QPID-5877 > URL: https://issues.apache.org/jira/browse/QPID-5877 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Andrew MacBean >Assignee: Andrew MacBean > Fix For: 0.29 > > > Based on investigation of a test failures in the > FailoverBehaviourTest#testTransactionRolledBackExceptionThrownOnCommitAfterFailoverOnMessageReceiving() > it was observed that the messages consumed by the client after failover were > out of order. > This manifested itself because of a client bug (QPID-5878) that means that > after failover the highestDeliveryTag was not rest and so rejects were send > spuriosly for messages previously delivered. > This meant that if the AbstractQueue.getNextAvailableEntry was executing > while the IO Thread caused a rejected message to be requeued (and updated > lastSeen node) the logic that finally decides the next entry node would > incorrectly continue if the lastSeen and releasedNodes where the very same > queue entry. This would mean that the next selected by the broker would > break the ordering sequence expected. > Basically, the AbstractQueue.getNextAvailableEntry implementation has the > potential to choose the wrong node when lastSeen and releasedNode are the > same as the compareTo impl to determine which node to select but uses the > > operator rather than >= and so wont select releasedNode in the case were that > and lastSeen are the same. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-5877) Potential for rejected messages to be resent out of order
[ https://issues.apache.org/jira/browse/QPID-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew MacBean resolved QPID-5877. -- Resolution: Fixed > Potential for rejected messages to be resent out of order > - > > Key: QPID-5877 > URL: https://issues.apache.org/jira/browse/QPID-5877 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Andrew MacBean >Assignee: Andrew MacBean > Fix For: 0.29 > > > Based on investigation of a test failures in the > FailoverBehaviourTest#testTransactionRolledBackExceptionThrownOnCommitAfterFailoverOnMessageReceiving() > it was observed that the messages consumed by the client after failover were > out of order. > This manifested itself because of a client bug (QPID-5878) that means that > after failover the highestDeliveryTag was not rest and so rejects were send > spuriosly for messages previously delivered. > This meant that if the AbstractQueue.getNextAvailableEntry was executing > while the IO Thread caused a rejected message to be requeued (and updated > lastSeen node) the logic that finally decides the next entry node would > incorrectly continue if the lastSeen and releasedNodes where the very same > queue entry. This would mean that the next selected by the broker would > break the ordering sequence expected. > Basically, the AbstractQueue.getNextAvailableEntry implementation has the > potential to choose the wrong node when lastSeen and releasedNode are the > same as the compareTo impl to determine which node to select but uses the > > operator rather than >= and so wont select releasedNode in the case were that > and lastSeen are the same. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-5877) Potential for rejected messages to be resent out of order
[ https://issues.apache.org/jira/browse/QPID-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew MacBean updated QPID-5877: - Description: Based on investigation of a test failures in the FailoverBehaviourTest#testTransactionRolledBackExceptionThrownOnCommitAfterFailoverOnMessageReceiving() it was observed that the messages consumed by the client after failover were out of order. This manifested itself because of a client bug (QPID-5878) that means that after failover the highestDeliveryTag was not rest and so rejects were send spuriosly for messages. This meant that if the AbstractQueue.getNextAvailableEntry was executing while the IO Thread caused a rejected message to be requeued the logic that finally decides the next entry node would incorrectly continue if the lastSeen and releasedNodes where the very same queue entry. This would mean that the next selected by the broker would break the ordering. Basically, the AbstractQueue.getNextAvailableEntry implementation has the potential to choose the wrong node when lastSeen and releasedNode are the same as the compareTo impl to determine which node to select but uses the > operator rather than >= and so wont select releasedNode in the case were that and lastSeen are the same. was: The AbstractQueue.getNextAvailableEntry implementation has the potential to choose the wrong node when lastSeen and releasedNode are the same. The logic currently uses the compareTo impl to determine which node to select but uses the > operator and so wont select releasedNode in the case were that and lastSeen are the same. > Potential for rejected messages to be resent out of order > - > > Key: QPID-5877 > URL: https://issues.apache.org/jira/browse/QPID-5877 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Andrew MacBean >Assignee: Andrew MacBean > Fix For: 0.29 > > > Based on investigation of a test failures in the > FailoverBehaviourTest#testTransactionRolledBackExceptionThrownOnCommitAfterFailoverOnMessageReceiving() > it was observed that the messages consumed by the client after failover were > out of order. This manifested itself because of a client bug (QPID-5878) > that means that after failover the highestDeliveryTag was not rest and so > rejects were send spuriosly for messages. This meant that if the > AbstractQueue.getNextAvailableEntry was executing while the IO Thread caused > a rejected message to be requeued the logic that finally decides the next > entry node would incorrectly continue if the lastSeen and releasedNodes where > the very same queue entry. This would mean that the next selected by the > broker would break the ordering. > Basically, the AbstractQueue.getNextAvailableEntry implementation has the > potential to choose the wrong node when lastSeen and releasedNode are the > same as the compareTo impl to determine which node to select but uses the > > operator rather than >= and so wont select releasedNode in the case were that > and lastSeen are the same. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Review Request 22630: [QPID-5823]: Python client should create a node with name starting '#'
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/22630/#review47342
---
Ship it!
Ship It!
- Alan Conway
On July 4, 2014, 10:48 a.m., Pavel Moravec wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22630/
> ---
>
> (Updated July 4, 2014, 10:48 a.m.)
>
>
> Review request for qpid, Alan Conway, Gordon Sim, Kenneth Giusti, and Rafael
> Schloming.
>
>
> Bugs: QPID-5823
> https://issues.apache.org/jira/browse/QPID-5823
>
>
> Repository: qpid
>
>
> Description
> ---
>
> The easiest "solution" would be to do the "mangling" in parse_address method
> in driver.py (see original https://svn.apache.org/r1602820 I reverted). That
> prevents any application to get proper node address ('#' expanded).
>
> So the '#' expansion needs to be done in endpoints.py and the information
> "address is expanded" needs to be passed to parse_address method. Either
> using [Sender|Receiver].mangled boolean (like in attached patch) or
> Sender.target / Receiver.source could be a double (address_string, mangled),
> like _mangle method returns in the patch. I don't know what approach (or some
> combination) is better.
>
>
> FYI C++ client has similar code:
>
> if (qpid::messaging::AddressImpl::isTemporary(a) &&
> createPolicy.isVoid()) {
> createPolicy = "always";
> Opt specified = Opt(a)/NODE/X_DECLARE;
> if (!specified.hasKey(AUTO_DELETE)) autoDelete = true;
> if (!specified.hasKey(EXCLUSIVE)) exclusive = true;
> }
>
> where isTemporary(a)==true iff node name starts with '#'.
>
>
> Diffs
> -
>
> /trunk/qpid/python/qpid/messaging/driver.py 1607804
> /trunk/qpid/python/qpid/messaging/endpoints.py 1607804
>
> Diff: https://reviews.apache.org/r/22630/diff/
>
>
> Testing
> ---
>
> Automated tests passed.
>
> Manual test passed as well:
>
> $ drain "#q; {node: {durable:true}}" -t 2 & qpid-stat -q
> [1] 25174
> c17af530-6cd8-462d-b8e8-5e4b6c9d50f8#q; {node: {durable:true}}
> Queues
> queue dur autoDel excl msg msgIn
> msgOut bytes bytesIn bytesOut cons bind
>
> =
> af192c4d-b2a0-47c3-8dd4-e99f400da51d:0.0 YY0 0
> 0 0 00 1 2
> c17af530-6cd8-462d-b8e8-5e4b6c9d50f8#qYYY0 0
> 0 0 00 1 1
> $
>
> (the same for spout)
>
> receiver / producer is able to print expanded address (see the
> "c17af530-6cd8-462d-b8e8-5e4b6c9d50f8#q; {node: {durable:true}}" line).
>
>
> Thanks,
>
> Pavel Moravec
>
>
[jira] [Resolved] (QPID-5873) Allow ACL rules to be applied to VirtualHostNode objects
[ https://issues.apache.org/jira/browse/QPID-5873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew MacBean resolved QPID-5873. -- Resolution: Fixed > Allow ACL rules to be applied to VirtualHostNode objects > > > Key: QPID-5873 > URL: https://issues.apache.org/jira/browse/QPID-5873 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Assignee: Andrew MacBean > Fix For: 0.29 > > > Using the existing ACL mechanism to allow the creation/update/delete of > virtualhostnode objects within the Broker to be controlled. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-5873) Allow ACL rules to be applied to VirtualHostNode objects
[ https://issues.apache.org/jira/browse/QPID-5873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-5873: - Fix Version/s: 0.29 > Allow ACL rules to be applied to VirtualHostNode objects > > > Key: QPID-5873 > URL: https://issues.apache.org/jira/browse/QPID-5873 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Assignee: Keith Wall > Fix For: 0.29 > > > Using the existing ACL mechanism to allow the creation/update/delete of > virtualhostnode objects within the Broker to be controlled. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-5873) Allow ACL rules to be applied to VirtualHostNode objects
[ https://issues.apache.org/jira/browse/QPID-5873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-5873: - Assignee: Andrew MacBean (was: Keith Wall) > Allow ACL rules to be applied to VirtualHostNode objects > > > Key: QPID-5873 > URL: https://issues.apache.org/jira/browse/QPID-5873 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Assignee: Andrew MacBean > Fix For: 0.29 > > > Using the existing ACL mechanism to allow the creation/update/delete of > virtualhostnode objects within the Broker to be controlled. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5873) Allow ACL rules to be applied to VirtualHostNode objects
[ https://issues.apache.org/jira/browse/QPID-5873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14052480#comment-14052480 ] ASF subversion and git services commented on QPID-5873: --- Commit 1607868 from [~k-wall] in branch 'qpid/trunk' [ https://svn.apache.org/r1607868 ] QPID-5873: [Java Broker] Allow ACL rules to be applied to VirtualHostNode objects * ACL rules using the new operation VIRTUALHOSTNODE apply to VHN model objects. * ACL rules using the operation VIRTUALHOST apply to VH model objects for CREATE, UPDATE and DELETE. This is a change from previous version where BROKER operation permission was required. * For HA, VIRTUALHOSTNODE permission is required to perform updates on RemoteReplicationNodes. > Allow ACL rules to be applied to VirtualHostNode objects > > > Key: QPID-5873 > URL: https://issues.apache.org/jira/browse/QPID-5873 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Assignee: Keith Wall > Fix For: 0.29 > > > Using the existing ACL mechanism to allow the creation/update/delete of > virtualhostnode objects within the Broker to be controlled. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-5873) Allow ACL rules to be applied to VirtualHostNode objects
[ https://issues.apache.org/jira/browse/QPID-5873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-5873: - Status: Reviewable (was: In Progress) > Allow ACL rules to be applied to VirtualHostNode objects > > > Key: QPID-5873 > URL: https://issues.apache.org/jira/browse/QPID-5873 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Assignee: Keith Wall > Fix For: 0.29 > > > Using the existing ACL mechanism to allow the creation/update/delete of > virtualhostnode objects within the Broker to be controlled. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-5877) Potential for rejected messages to be resent out of order
[ https://issues.apache.org/jira/browse/QPID-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-5877: - Fix Version/s: 0.29 > Potential for rejected messages to be resent out of order > - > > Key: QPID-5877 > URL: https://issues.apache.org/jira/browse/QPID-5877 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Andrew MacBean >Assignee: Andrew MacBean > Fix For: 0.29 > > > The AbstractQueue.getNextAvailableEntry implementation has the potential to > choose the wrong node when lastSeen and releasedNode are the same. > The logic currently uses the compareTo impl to determine which node to select > but uses the > operator and so wont select releasedNode in the case were that > and lastSeen are the same. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5877) Potential for rejected messages to be resent out of order
[ https://issues.apache.org/jira/browse/QPID-5877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14052473#comment-14052473 ] ASF subversion and git services commented on QPID-5877: --- Commit 1607863 from [~macbean] in branch 'qpid/trunk' [ https://svn.apache.org/r1607863 ] QPID-5877: [Java Broker] Potential for rejected messages to be resent out of order Work completed by Keith Wall and me. > Potential for rejected messages to be resent out of order > - > > Key: QPID-5877 > URL: https://issues.apache.org/jira/browse/QPID-5877 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Andrew MacBean >Assignee: Andrew MacBean > > The AbstractQueue.getNextAvailableEntry implementation has the potential to > choose the wrong node when lastSeen and releasedNode are the same. > The logic currently uses the compareTo impl to determine which node to select > but uses the > operator and so wont select releasedNode in the case were that > and lastSeen are the same. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5875) [Java Tests] Test VirtualHostRestTest testPutCreateVirtualHostUsingProfileNodeType is failing because ProvidedStore virtual host cannot be used with JSON VHN
[
https://issues.apache.org/jira/browse/QPID-5875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14052456#comment-14052456
]
ASF subversion and git services commented on QPID-5875:
---
Commit 1607860 from oru...@apache.org in branch 'qpid/trunk'
[ https://svn.apache.org/r1607860 ]
QPID-5875: Fix intruder protection system test
> [Java Tests] Test VirtualHostRestTest
> testPutCreateVirtualHostUsingProfileNodeType is failing because ProvidedStore
> virtual host cannot be used with JSON VHN
> -
>
> Key: QPID-5875
> URL: https://issues.apache.org/jira/browse/QPID-5875
> Project: Qpid
> Issue Type: Bug
> Components: Java Tests
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
> Fix For: 0.29
>
>
> {noformat}
> qtp1061565585-20493 2014-07-04 04:50:38,574 WARN
> [plugin.servlet.rest.RestServlet] Caught exception
> org.apache.qpid.server.configuration.IllegalConfigurationException:
> ProvidedStore virtual host can only be used where the node's store
> (org.apache.qpid.server.store.JsonFileConfigStore) is a message store
> provider.
> at
> org.apache.qpid.server.virtualhost.ProvidedStoreVirtualHostImpl.onValidate(ProvidedStoreVirtualHostImpl.java:62)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doValidation(AbstractConfiguredObject.java:531)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.create(AbstractConfiguredObject.java:472)
> at
> org.apache.qpid.server.model.AbstractConfiguredObjectTypeFactory.create(AbstractConfiguredObjectTypeFactory.java:58)
> at
> org.apache.qpid.server.model.AbstractConfiguredObjectTypeFactory.create(AbstractConfiguredObjectTypeFactory.java:31)
> at
> org.apache.qpid.server.model.ConfiguredObjectFactoryImpl.create(ConfiguredObjectFactoryImpl.java:112)
> at
> org.apache.qpid.server.virtualhostnode.AbstractStandardVirtualHostNode.addChild(AbstractStandardVirtualHostNode.java:63)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$10.execute(AbstractConfiguredObject.java:1078)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$10.execute(AbstractConfiguredObject.java:1072)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.executeTask(TaskExecutorImpl.java:299)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.access$400(TaskExecutorImpl.java:43)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper$1.run(TaskExecutorImpl.java:327)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:356)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper.call(TaskExecutorImpl.java:322)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-4300) [Java Broker Web Console]NullPointerException was reported into broker log on request from the web management console when broker was starting up
[
https://issues.apache.org/jira/browse/QPID-4300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew MacBean resolved QPID-4300.
--
Resolution: Fixed
This is issue was resolved by refactoring done since 0.18 and is no longer an
issue in 0.29.
> [Java Broker Web Console]NullPointerException was reported into broker log on
> request from the web management console when broker was starting up
> -
>
> Key: QPID-4300
> URL: https://issues.apache.org/jira/browse/QPID-4300
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: 0.18, 0.19
>Reporter: Alex Rudyy
>
> NullPointerException was reported into broker log on request from the web
> management console when the broker was in a process of start up.
> The web management console was left running and on broker restart the
> exception stack trace was added into the broker log:
> {noformat}
> 2012-09-11 16:00:08,155 WARN [qtp404150953-21] (ServletHandler.java:546) -
> /rest/authenticationprovider/PrincipalDatabaseAuthenticationManager
> java.lang.NullPointerException
> at
> org.apache.qpid.server.registry.ApplicationRegistry.getSubjectCreator(ApplicationRegistry.java:624)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet.getAndCacheAuthorizedSubject(AbstractServlet.java:266)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet.doWithSubjectAndActor(AbstractServlet.java:199)
> at
> org.apache.qpid.server.management.plugin.servlet.rest.AbstractServlet.doGet(AbstractServlet.java:80)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
> at
> org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:565)
> at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:479)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:225)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1031)
> at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:406)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:965)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111)
> at org.eclipse.jetty.server.Server.handle(Server.java:348)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:452)
> at
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:884)
> at
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:938)
> at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:630)
> at
> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230)
> at
> org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:77)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:606)
> at
> org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:46)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:603)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:538)
> at java.lang.Thread.run(Thread.java:662)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5870) Closing a topic consumer should delete its exclusive auto-delete queue
[ https://issues.apache.org/jira/browse/QPID-5870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14052427#comment-14052427 ] Robbie Gemmell commented on QPID-5870: -- Seconding Keiths request for more detail. Most of the patch seems to be extracting parameters and adding another method, the key bit seems to be always calling 'deleteSubscriptionQueue' rather than only do so if the Address string said to delete always/receiver. I see that checks to ensure that it is a 'topic address', but I wonder what happens around e.g. DurableSubscriptions, are they handled appropriately? Needs some tests. > Closing a topic consumer should delete its exclusive auto-delete queue > -- > > Key: QPID-5870 > URL: https://issues.apache.org/jira/browse/QPID-5870 > Project: Qpid > Issue Type: Bug >Reporter: Rajith Attapattu > Attachments: QPID-5870.patch > > > When a topic consumer is closed, the subscription queue needs to be closed as > well. > Currently this queue is only deleted when the session is closed (due to being > marked auto-deleted). -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5868) Java client ignores exceptions when waiting on sync
[ https://issues.apache.org/jira/browse/QPID-5868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14052412#comment-14052412 ] Robbie Gemmell commented on QPID-5868: -- Like Keith, I wondered what exactly the original issue was, as its not clear the title/description fully conveys the required detail for the suggested change, though I think my comments below typed while looking at it mean I figured it out... Looking at what happens when an ExecutionException is received, it sets the exception on the Session, closes the session (but only after notifying the AMQSession_0_10 and ExceptionListener), takes the command lock and does a notify on it. That seems to point to any previously waiting thread in sync eventually being woken up, determining the session was closed, and throwing the exception. However, it is a bit iffy around what happens when notifying the AMQSession_0_10 and ExceptionListener before it actually marks the transport Session closed and wakes the waiting thread, which might make it possible for it to report a timeout rather the ExecutionException that caused it all. The change suggested would stop around that by tripping the boolean while setting the exception and causing the waiting thread to be woken before going near the AMQSession_0_10 or ExceptionListener, though it also means the Session will still marked open when the exception gets thrown by the waiter, rather than closed as it would have been before. > Java client ignores exceptions when waiting on sync > --- > > Key: QPID-5868 > URL: https://issues.apache.org/jira/browse/QPID-5868 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.27 >Reporter: Rajith Attapattu > Fix For: 0.29 > > Attachments: QPID-5868.patch > > > The java client will wait on the sync command even if an execution exception > is received from the broker. > It will then proceed to throw a timeout exception and the execution exception > is not reported properly to the application. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Potential qpid cpp 0.28 bug
On 07/04/2014 10:31 AM, Duong Quynh (FSU1.Z8.IP) wrote: I will get down to the log later when I have time, however, I don't see this problem happening with the JAVA client, the Producer just exits with identical logic. The c++ sender example you posted works fine for me against ActiveMQ 5.9 when using the 0.28 release. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-5877) Potential for rejected messages to be resent out of order
Andrew MacBean created QPID-5877: Summary: Potential for rejected messages to be resent out of order Key: QPID-5877 URL: https://issues.apache.org/jira/browse/QPID-5877 Project: Qpid Issue Type: Bug Components: Java Broker Reporter: Andrew MacBean Assignee: Andrew MacBean The AbstractQueue.getNextAvailableEntry implementation has the potential to choose the wrong node when lastSeen and releasedNode are the same. The logic currently uses the compareTo impl to determine which node to select but uses the > operator and so wont select releasedNode in the case were that and lastSeen are the same. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-5876) Java client causes unecessary rejects after failover when using 0-8..0-9-1 protocols
Andrew MacBean created QPID-5876: Summary: Java client causes unecessary rejects after failover when using 0-8..0-9-1 protocols Key: QPID-5876 URL: https://issues.apache.org/jira/browse/QPID-5876 Project: Qpid Issue Type: Bug Components: Java Client Reporter: Andrew MacBean Assignee: Andrew MacBean Highest delivery tag variable not reset after failover and causes rejections to be sent unecessarily. The AMQSession.resubscribe() implementation does not reset the _highestDeliveryTag member variable. This means that rejects are send needlessly/incorrectly after failover occurs as the value is higher than it should be. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Review Request 22630: [QPID-5823]: Python client should create a node with name starting '#'
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/22630/
---
(Updated July 4, 2014, 10:48 a.m.)
Review request for qpid, Alan Conway, Gordon Sim, Kenneth Giusti, and Rafael
Schloming.
Changes
---
New patch proposal, with Alan's idea of MangledString class implemented (it
gets really easier, thanks!).
Bugs: QPID-5823
https://issues.apache.org/jira/browse/QPID-5823
Repository: qpid
Description
---
The easiest "solution" would be to do the "mangling" in parse_address method in
driver.py (see original https://svn.apache.org/r1602820 I reverted). That
prevents any application to get proper node address ('#' expanded).
So the '#' expansion needs to be done in endpoints.py and the information
"address is expanded" needs to be passed to parse_address method. Either using
[Sender|Receiver].mangled boolean (like in attached patch) or Sender.target /
Receiver.source could be a double (address_string, mangled), like _mangle
method returns in the patch. I don't know what approach (or some combination)
is better.
FYI C++ client has similar code:
if (qpid::messaging::AddressImpl::isTemporary(a) && createPolicy.isVoid()) {
createPolicy = "always";
Opt specified = Opt(a)/NODE/X_DECLARE;
if (!specified.hasKey(AUTO_DELETE)) autoDelete = true;
if (!specified.hasKey(EXCLUSIVE)) exclusive = true;
}
where isTemporary(a)==true iff node name starts with '#'.
Diffs (updated)
-
/trunk/qpid/python/qpid/messaging/driver.py 1607804
/trunk/qpid/python/qpid/messaging/endpoints.py 1607804
Diff: https://reviews.apache.org/r/22630/diff/
Testing
---
Automated tests passed.
Manual test passed as well:
$ drain "#q; {node: {durable:true}}" -t 2 & qpid-stat -q
[1] 25174
c17af530-6cd8-462d-b8e8-5e4b6c9d50f8#q; {node: {durable:true}}
Queues
queue dur autoDel excl msg msgIn
msgOut bytes bytesIn bytesOut cons bind
=
af192c4d-b2a0-47c3-8dd4-e99f400da51d:0.0 YY0 0
0 0 00 1 2
c17af530-6cd8-462d-b8e8-5e4b6c9d50f8#qYYY0 0
0 0 00 1 1
$
(the same for spout)
receiver / producer is able to print expanded address (see the
"c17af530-6cd8-462d-b8e8-5e4b6c9d50f8#q; {node: {durable:true}}" line).
Thanks,
Pavel Moravec
[jira] [Commented] (QPID-5875) [Java Tests] Test VirtualHostRestTest testPutCreateVirtualHostUsingProfileNodeType is failing because ProvidedStore virtual host cannot be used with JSON VHN
[
https://issues.apache.org/jira/browse/QPID-5875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14052342#comment-14052342
]
ASF subversion and git services commented on QPID-5875:
---
Commit 1607825 from oru...@apache.org in branch 'qpid/trunk'
[ https://svn.apache.org/r1607825 ]
QPID-5875: Exclude test
VirtualHostRestTest.testPutCreateVirtualHostUsingProfileNodeType from json
profiles
> [Java Tests] Test VirtualHostRestTest
> testPutCreateVirtualHostUsingProfileNodeType is failing because ProvidedStore
> virtual host cannot be used with JSON VHN
> -
>
> Key: QPID-5875
> URL: https://issues.apache.org/jira/browse/QPID-5875
> Project: Qpid
> Issue Type: Bug
> Components: Java Tests
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
> Fix For: 0.29
>
>
> {noformat}
> qtp1061565585-20493 2014-07-04 04:50:38,574 WARN
> [plugin.servlet.rest.RestServlet] Caught exception
> org.apache.qpid.server.configuration.IllegalConfigurationException:
> ProvidedStore virtual host can only be used where the node's store
> (org.apache.qpid.server.store.JsonFileConfigStore) is a message store
> provider.
> at
> org.apache.qpid.server.virtualhost.ProvidedStoreVirtualHostImpl.onValidate(ProvidedStoreVirtualHostImpl.java:62)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doValidation(AbstractConfiguredObject.java:531)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.create(AbstractConfiguredObject.java:472)
> at
> org.apache.qpid.server.model.AbstractConfiguredObjectTypeFactory.create(AbstractConfiguredObjectTypeFactory.java:58)
> at
> org.apache.qpid.server.model.AbstractConfiguredObjectTypeFactory.create(AbstractConfiguredObjectTypeFactory.java:31)
> at
> org.apache.qpid.server.model.ConfiguredObjectFactoryImpl.create(ConfiguredObjectFactoryImpl.java:112)
> at
> org.apache.qpid.server.virtualhostnode.AbstractStandardVirtualHostNode.addChild(AbstractStandardVirtualHostNode.java:63)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$10.execute(AbstractConfiguredObject.java:1078)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$10.execute(AbstractConfiguredObject.java:1072)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.executeTask(TaskExecutorImpl.java:299)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.access$400(TaskExecutorImpl.java:43)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper$1.run(TaskExecutorImpl.java:327)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:356)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper.call(TaskExecutorImpl.java:322)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-5875) [Java Tests] Test VirtualHostRestTest testPutCreateVirtualHostUsingProfileNodeType is failing because ProvidedStore virtual host cannot be used with JSON VHN
Alex Rudyy created QPID-5875:
Summary: [Java Tests] Test VirtualHostRestTest
testPutCreateVirtualHostUsingProfileNodeType is failing because ProvidedStore
virtual host cannot be used with JSON VHN
Key: QPID-5875
URL: https://issues.apache.org/jira/browse/QPID-5875
Project: Qpid
Issue Type: Bug
Components: Java Tests
Reporter: Alex Rudyy
Assignee: Alex Rudyy
Fix For: 0.29
{noformat}
qtp1061565585-20493 2014-07-04 04:50:38,574 WARN
[plugin.servlet.rest.RestServlet] Caught exception
org.apache.qpid.server.configuration.IllegalConfigurationException:
ProvidedStore virtual host can only be used where the node's store
(org.apache.qpid.server.store.JsonFileConfigStore) is a message store provider.
at
org.apache.qpid.server.virtualhost.ProvidedStoreVirtualHostImpl.onValidate(ProvidedStoreVirtualHostImpl.java:62)
at
org.apache.qpid.server.model.AbstractConfiguredObject.doValidation(AbstractConfiguredObject.java:531)
at
org.apache.qpid.server.model.AbstractConfiguredObject.create(AbstractConfiguredObject.java:472)
at
org.apache.qpid.server.model.AbstractConfiguredObjectTypeFactory.create(AbstractConfiguredObjectTypeFactory.java:58)
at
org.apache.qpid.server.model.AbstractConfiguredObjectTypeFactory.create(AbstractConfiguredObjectTypeFactory.java:31)
at
org.apache.qpid.server.model.ConfiguredObjectFactoryImpl.create(ConfiguredObjectFactoryImpl.java:112)
at
org.apache.qpid.server.virtualhostnode.AbstractStandardVirtualHostNode.addChild(AbstractStandardVirtualHostNode.java:63)
at
org.apache.qpid.server.model.AbstractConfiguredObject$10.execute(AbstractConfiguredObject.java:1078)
at
org.apache.qpid.server.model.AbstractConfiguredObject$10.execute(AbstractConfiguredObject.java:1072)
at
org.apache.qpid.server.configuration.updater.TaskExecutorImpl.executeTask(TaskExecutorImpl.java:299)
at
org.apache.qpid.server.configuration.updater.TaskExecutorImpl.access$400(TaskExecutorImpl.java:43)
at
org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper$1.run(TaskExecutorImpl.java:327)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at
org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper.call(TaskExecutorImpl.java:322)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
RE: Potential qpid cpp 0.28 bug
I will get down to the log later when I have time, however, I don't see this problem happening with the JAVA client, the Producer just exits with identical logic. > Not sure what you mean by that... do you mean that the subsequent call, i.e. > session.close() does not return? > The most likely reason for that is around the settlement of messages. If you > can enable some more detailed logging it should be able to spot the issue. > > E.g. QPID_LOG_ENABLE=trace+:Protocol >The session.close() will wait for all sent messages to be settled before >closing. I suspect that is where it is blocked. The protocol trace should help. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: Potential qpid cpp 0.28 bug
On 07/04/2014 08:05 AM, Duong Quynh (FSU1.Z8.IP) wrote: Hi everyone, Today while coding a simple sender on qpid cpp 0.28 I encountered a problem where the program will not quit after completing its task. I am building using g++ 4.8.3, boost 1.49.0, proton 0.70 to name a few. I put the program through gdb and it seems to jump around infitely after the std::cout << "2" << endl; line. Not sure what you mean by that... do you mean that the subsequent call, i.e. session.close() does not return? The most likely reason for that is around the settlement of messages. If you can enable some more detailed logging it should be able to spot the issue. E.g. QPID_LOG_ENABLE=trace+:Protocol My current guess is Sender class has issues since the receiver I wrote would quit gracefully. The session.close() will wait for all sent messages to be settled before closing. I suspect that is where it is blocked. The protocol trace should help. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-5867) [Java Broker] Add functionality to prevent unintended HA node creation and mechanisms to react on intruder HA nodes
[ https://issues.apache.org/jira/browse/QPID-5867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy reassigned QPID-5867: Assignee: Keith Wall (was: Alex Rudyy) Keith please the review the changes made in revision [r1607772|https://svn.apache.org/r1607772]? > [Java Broker] Add functionality to prevent unintended HA node creation and > mechanisms to react on intruder HA nodes > --- > > Key: QPID-5867 > URL: https://issues.apache.org/jira/browse/QPID-5867 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Alex Rudyy >Assignee: Keith Wall > > Add functionality to prevent unintended node creation and mechanisms to react > on intruder nodes > New HA VH attribute permittedNodeList > Nodes register the contents of this attribute as app-state > On adding a new node to the griup, the node must check to see its node > address is included in the app-state, if not, refuse to join > All nodes periodically (BDBHAVHN has a thread dedicated to the purpose or > reuse node discovery thread?) check to see if nodes exist that do not appear > in the app-state. If so VHN will close env and go into ERROR state. > If in management mode don't periodically check the PNL, thus allowing an > intruder to be removed. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-5867) [Java Broker] Add functionality to prevent unintended HA node creation and mechanisms to react on intruder HA nodes
[ https://issues.apache.org/jira/browse/QPID-5867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-5867: - Status: Reviewable (was: In Progress) > [Java Broker] Add functionality to prevent unintended HA node creation and > mechanisms to react on intruder HA nodes > --- > > Key: QPID-5867 > URL: https://issues.apache.org/jira/browse/QPID-5867 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Alex Rudyy >Assignee: Alex Rudyy > > Add functionality to prevent unintended node creation and mechanisms to react > on intruder nodes > New HA VH attribute permittedNodeList > Nodes register the contents of this attribute as app-state > On adding a new node to the griup, the node must check to see its node > address is included in the app-state, if not, refuse to join > All nodes periodically (BDBHAVHN has a thread dedicated to the purpose or > reuse node discovery thread?) check to see if nodes exist that do not appear > in the app-state. If so VHN will close env and go into ERROR state. > If in management mode don't periodically check the PNL, thus allowing an > intruder to be removed. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Potential qpid cpp 0.28 bug
Hi everyone,
Today while coding a simple sender on qpid cpp 0.28 I encountered a problem
where the program will not quit after completing its task. I am building using
g++ 4.8.3, boost 1.49.0, proton 0.70 to name a few. I put the program through
gdb and it seems to jump around infitely after the std::cout << "2" << endl;
line. My current guess is Sender class has issues since the receiver I wrote
would quit gracefully.
Please see the code below:
//C++ producer code starts
#include
#include
#include
#include
#include
#include
using namespace qpid::messaging;
int main(int argc, char** argv) {
Connection connection;
try
{
std::string url = argc > 1 ? argv[1] : "localhost:5672";
std::string address = argc > 2 ? argv[2] : "'topic://usa.news'";
std::string connectionOptions = argc > 3 ? argv[3] :
"{username:guest,password:guest,sasl_mechanisms:PLAIN,protocol:amqp1.0}";
connection = Connection(url, connectionOptions);
connection.open();
std::cout << "1" << std::endl;
Session session = connection.createSession();
Sender sender = session.createSender(address);
int count = 10;
for (int i = 0; i < count; i++)
{
sender.send(Message("Hello news!"));
std::cout << "Sent - Hello news! " << i << std::endl;
}
std::cout << "2" << std::endl; // program seems to have problem after
this point
session.close();
connection.close();
return 0;
} catch (const std::exception& error) {
std::cout << "Error: " << error.what() << std::endl;
connection.close();
}
return 1;
} //C++ code ends
Q
