[jira] [Updated] (QPID-7548) [Java Broker] Upgrade of configuration from model version 3 fails
[
https://issues.apache.org/jira/browse/QPID-7548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-7548:
-
Attachment: 0001-QPID-7548-Java-Broker-Fix-upgrade-from-model-version.patch
0002-QPID-7548-Remove-responsibility-to-call-next-upgrade.patch
> [Java Broker] Upgrade of configuration from model version 3 fails
> -
>
> Key: QPID-7548
> URL: https://issues.apache.org/jira/browse/QPID-7548
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.1
>Reporter: Alex Rudyy
> Fix For: qpid-java-6.1.1
>
> Attachments:
> 0001-QPID-7548-Java-Broker-Fix-upgrade-from-model-version.patch,
> 0002-QPID-7548-Remove-responsibility-to-call-next-upgrade.patch
>
>
> Broker fails to upgrade configuration v3 as it cannot delete RMI and JMX
> ports. The following exception is reported on startup
> {noformat}
> 12:08:29.756 [main] INFO o.a.q.s.store.GenericStoreUpgrader - Broker store
> has model version 3.0. Number of record(s) 31
> 12:08:29.821 [main] ERROR org.apache.qpid.server.Broker - Exception during
> startup
> java.lang.IllegalArgumentException: Cannot convert '[RMI]' into a
> java.util.Set for attribute protocols
> (No enum constant org.apache.qpid.se
> ver.model.Protocol.RMI)
> at
> org.apache.qpid.server.model.ConfiguredAutomatedAttribute.convert(ConfiguredAutomatedAttribute.java:252)
> ~[qpid-broker-core-6.1.0.jar:6.1.0]
> at
> org.apache.qpid.server.model.port.PortFactory.getProtocolType(PortFactory.java:69)
> ~[qpid-broker-core-6.1.0.jar:6.1.0]
> at
> org.apache.qpid.server.model.port.PortFactory.getPortFactory(PortFactory.java:142)
> ~[qpid-broker-core-6.1.0.jar:6.1.0]
> at
> org.apache.qpid.server.model.port.PortFactory.recover(PortFactory.java:127)
> ~[qpid-broker-core-6.1.0.jar:6.1.0]
> at
> org.apache.qpid.server.model.ConfiguredObjectFactoryImpl.recover(ConfiguredObjectFactoryImpl.java:104)
> ~[qpid-broker-core-6.1.0.jar:6.1.0]
> at
> org.apache.qpid.server.store.GenericRecoverer.resolveObjects(GenericRecoverer.java:183)
> ~[qpid-broker-core-6.1.0.jar:6.1.0]
> at
> org.apache.qpid.server.store.GenericRecoverer.performRecover(GenericRecoverer.java:91)
> ~[qpid-broker-core-6.1.0.jar:6.1.0]
> at
> org.apache.qpid.server.store.GenericRecoverer.access$000(GenericRecoverer.java:41)
> ~[qpid-broker-core-6.1.0.jar:6.1.0]
> at
> org.apache.qpid.server.store.GenericRecoverer$1.execute(GenericRecoverer.java:59)
> ~[qpid-broker-core-6.1.0.jar:6.1.0]
> at
> org.apache.qpid.server.store.GenericRecoverer$1.execute(GenericRecoverer.java:55)
> ~[qpid-broker-core-6.1.0.jar:6.1.0]
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:240)
> ~[qpid-broker-core-6.1.0.jar:6.1.0]
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submitWrappedTask(TaskExecutorImpl.java:157)
> ~[qpid-broker-core-6.1.0.jar:6.1.0]
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.run(TaskExecutorImpl.java:182)
> ~[qpid-broker-core-6.1.0.jar:6.1.0]
> at
> org.apache.qpid.server.store.GenericRecoverer.recover(GenericRecoverer.java:54)
> ~[qpid-broker-core-6.1.0.jar:6.1.0]
> at
> org.apache.qpid.server.store.BrokerStoreUpgraderAndRecoverer.upgradeAndRecover(BrokerStoreUpgraderAndRecoverer.java:919)
> ~[qpid-broker-core-6.1.0.jar:6.1.0]
> at
> org.apache.qpid.server.store.BrokerStoreUpgraderAndRecoverer.upgradeAndRecover(BrokerStoreUpgraderAndRecoverer.java:48)
> ~[qpid-broker-core-6.1.0.jar:6.1.0]
> at
> org.apache.qpid.server.model.AbstractSystemConfig.initateStoreAndRecovery(AbstractSystemConfig.java:304)
> ~[qpid-broker-core-6.1.0.jar:6.1.0]
> at
> org.apache.qpid.server.model.AbstractSystemConfig.activate(AbstractSystemConfig.java:233)
> ~[qpid-broker-core-6.1.0.jar:6.1.0]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[na:1.8.0_74]
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[na:1.8.0_74]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[na:1.8.0_74]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_74]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1482)
> ~[qpid-broker-core-6.1.0.jar:6.1.0]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1461)
> ~[qpid-broker-core-6.1.0.jar:6.1.0]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredOb
[jira] [Resolved] (QPIDJMS-240) Add configuration option to determine if the Connection maintains a non-daemon thread
[ https://issues.apache.org/jira/browse/QPIDJMS-240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-240. -- Resolution: Fixed > Add configuration option to determine if the Connection maintains a > non-daemon thread > - > > Key: QPIDJMS-240 > URL: https://issues.apache.org/jira/browse/QPIDJMS-240 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.11.1 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.20.0 > > > Add a new configuration option to control whether or no the Connection > maintains a single non-daemon thread or not. > Option to be added: "jms.useDaemonThread" -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-598) Router crash when calling sender and session close methods in onLinkFLow()
[ https://issues.apache.org/jira/browse/DISPATCH-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15752678#comment-15752678 ] Rohan Mars commented on DISPATCH-598: - the stack trace: (gdb) where #0 0x7ff26404e600 in ?? () #1 0x7ff27dd0888c in pn_class_incref (clazz=0x7ff26478, object=0x7ff26402bb30) at /home/centos/qpid-proton/proton-c/src/core/object/object.c:72 #2 0x7ff27dd1c8df in pn_collector_put (collector=0x7ff26401d4c0, clazz=0x7ff26478, context=0x7ff26402bb30, type=PN_LINK_LOCAL_CLOSE) at /home/centos/qpid-proton/proton-c/src/core/event.c:166 #3 0x7ff27dd1664e in pn_endpoint_close (endpoint=0x7ff26402bb30) at /home/centos/qpid-proton/proton-c/src/core/engine.c:88 #4 0x7ff27dd1703d in pn_link_close (link=0x7ff26402bb30) at /home/centos/qpid-proton/proton-c/src/core/engine.c:312 #5 0x7ff27df7c838 in qd_link_close (link=0x7ff26403e760) at /home/centos/qpid-dispatch/src/container.c:959 #6 0x7ff27dfa75fd in CORE_link_detach (context=0xc41350, link=0x7ff264046620, error=0x0, first=false, close=true) at /home/centos/qpid-dispatch/src/router_node.c:793 #7 0x7ff27df95d6c in qdr_connection_process (conn=0x7ff264037820) at /home/centos/qpid-dispatch/src/router_core/connections.c:147 #8 0x7ff27dfa5eaa in AMQP_writable_conn_handler (type_context=0xc41350, conn=0x7ff26400f0e0, context=0x0) at /home/centos/qpid-dispatch/src/router_node.c:85 #9 0x7ff27df7a83b in writable_handler (container=0xc47860, conn=0x7ff26401c4b0, qd_conn=0x7ff26400f0e0) ---Type to continue, or q to quit--- at /home/centos/qpid-dispatch/src/container.c:307 #10 0x7ff27df7b85c in handler (handler_context=0xc47860, conn_context=0xf3fff0, event=QD_CONN_EVENT_WRITABLE, qd_conn=0x7ff26400f0e0) at /home/centos/qpid-dispatch/src/container.c:606 #11 0x7ff27dfaba55 in process_connector (qd_server=0xf4dab0, cxtr=0x7ff264000ee0) at /home/centos/qpid-dispatch/src/server.c:862 #12 0x7ff27dfac304 in thread_run (arg=0xf4c3e0) at /home/centos/qpid-dispatch/src/server.c:1082 #13 0x7ff27dfad681 in qd_server_run (qd=0x933030) at /home/centos/qpid-dispatch/src/server.c:1482 #14 0x00401b2f in main_process ( config_path=0x4026e8 "/home/centos/dispatch/etc/qpid-dispatch/qdrouterd.conf", python_pkgdir=0x402788 "/home/centos/dispatch/lib/qpid-dispatch/python", fd=2) at /home/centos/qpid-dispatch/router/src/main.c:147 #15 0x00402418 in main (argc=1, argv=0x7ffc3309b988) at /home/centos/qpid-dispatch/router/src/main.c:353 > Router crash when calling sender and session close methods in onLinkFLow() > -- > > Key: DISPATCH-598 > URL: https://issues.apache.org/jira/browse/DISPATCH-598 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.7.0 > Environment: Centos 7. Java 1.8 >Reporter: Rohan Mars > Fix For: 0.8.0 > > Attachments: test-app-reactor-core.tar.gz > > > Closing session/connection in sender onLinkFlow() causes router to crash -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-240) Add configuration option to determine if the Connection maintains a non-daemon thread
[ https://issues.apache.org/jira/browse/QPIDJMS-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15752658#comment-15752658 ] ASF subversion and git services commented on QPIDJMS-240: - Commit f832a9ffd79f74deaf16856d41a28aa65c687901 in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=f832a9f ] QPIDJMS-240 Add option to control thread state managed by the Connection Adds option jms.useDaemonThread to allow control of the Connection thread's daemon state. > Add configuration option to determine if the Connection maintains a > non-daemon thread > - > > Key: QPIDJMS-240 > URL: https://issues.apache.org/jira/browse/QPIDJMS-240 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.11.1 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.20.0 > > > Add a new configuration option to control whether or no the Connection > maintains a single non-daemon thread or not. > Option to be added: "jms.useDaemonThread" -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPIDJMS-241) Add configuration option to determine if the Connection maintains a non-daemon thread
[ https://issues.apache.org/jira/browse/QPIDJMS-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish closed QPIDJMS-241. Resolution: Duplicate > Add configuration option to determine if the Connection maintains a > non-daemon thread > - > > Key: QPIDJMS-241 > URL: https://issues.apache.org/jira/browse/QPIDJMS-241 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.11.1 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.20.0 > > > Add a new configuration option to control whether or no the Connection > maintains a single non-daemon thread or not. > Option to be added: "jms.useDaemonThread" -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-597) Log enhancements
[
https://issues.apache.org/jira/browse/DISPATCH-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15752567#comment-15752567
]
Rohan Mars commented on DISPATCH-597:
-
Current changes which can be used for inspiration are contained at:
https://github.com/dskarbek/qpid-dispatch/commit/a11d830940ce59ebf1ab3dcdf0938ac8de42eadb
> Log enhancements
>
>
> Key: DISPATCH-597
> URL: https://issues.apache.org/jira/browse/DISPATCH-597
> Project: Qpid Dispatch
> Issue Type: Improvement
> Components: Container
>Affects Versions: 0.7.0
>Reporter: Shibi Sudhakaran
> Fix For: 0.8.0
>
>
> Print information at INFO level into log that could be used for diagnosing
> router health.
> 1. Millisecond precision timestamp
> 2. Avoid logging message body.
> 3. Capability to configure application properties to be logged (messageId,
> correlationId, creationTime , application custom properties) etc
> Sample Entries (log level : INFO)
>
> => Mon 2016-09-26 11:31:44.050750 -0700 ROUTER_HELLO (info) SENT:
> HELLO(id=Router.A.0 area=0 inst=1474860067 seen=['Router.A.1', 'Router.A.2',
> 'Router.A.3', 'Router.A.4’])
> => Mon 2016-09-26 14:15:58.088754 -0700 MESSAGE (info) Sending Message{
> message-id='' correlation-id=''
> creation-time='2016-09-26 14:15:58.084 -0700' application properties='[Key:
> request-creation-time => Value: 1474924558078]' } on link
> => Mon 2016-09-26 14:15:20.547178 -0700 MESSAGE (info) Received Message{
> message-id='' correlation-id=''
> creation-time='2016-09-26 14:15:20.542 -0700' application properties='[Key:
> request-creation-time => Value: 1474924520539]'} on link
> => Mon 2016-09-26 09:40:00.149567 -0700 ROUTER_LS (info) Computed costs:
> {'Router.A.0': 1, 'Router.A.2': 1, 'Router.A.3': 1, 'Router.A.4': 1}
> => Mon 2016-09-26 14:23:07.376756 -0700 ROUTER (info) Router started in
> Interior mode, area=0 id=Router.A.1
> => Mon 2016-09-26 14:23:07.408136 -0700 CONN_MGR (info) Configured Listener:
> 0.0.0.0:5671 proto=any role=normal
> => Mon 2016-09-26 14:14:57.520917 -0700 SERVER (info) Accepting incoming
> connection from to
> => Mon 2016-09-26 14:23:07.376471 -0700 SERVER (info) Container Name:
> Router.A.1
> => Mon 2016-09-26 14:23:07.439250 -0700 SERVER (info) Connecting to
>
> => Mon 2016-09-26 14:23:07.447536 -0700 SERVER (info) [1]:Client SSL socket
> created.
> => Mon 2016-09-26 14:15:12.310692 -0700 SERVER (info) [8783]:SSL socket freed
> => Mon 2016-09-26 14:23:03.059884 -0700 SERVER (info) Shut Down
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-598) Router crash when calling sender and session close methods in onLinkFLow()
[ https://issues.apache.org/jira/browse/DISPATCH-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross updated DISPATCH-598: -- Fix Version/s: 0.8.0 > Router crash when calling sender and session close methods in onLinkFLow() > -- > > Key: DISPATCH-598 > URL: https://issues.apache.org/jira/browse/DISPATCH-598 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.7.0 > Environment: Centos 7. Java 1.8 >Reporter: Rohan Mars > Fix For: 0.8.0 > > Attachments: test-app-reactor-core.tar.gz > > > Closing session/connection in sender onLinkFlow() causes router to crash -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-598) Router crash when calling sender and session close methods in onLinkFLow()
Rohan Mars created DISPATCH-598: --- Summary: Router crash when calling sender and session close methods in onLinkFLow() Key: DISPATCH-598 URL: https://issues.apache.org/jira/browse/DISPATCH-598 Project: Qpid Dispatch Issue Type: Bug Components: Routing Engine Affects Versions: 0.7.0 Environment: Centos 7. Java 1.8 Reporter: Rohan Mars Attachments: test-app-reactor-core.tar.gz Closing session/connection in sender onLinkFlow() causes router to crash -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-240) Add configuration option to determine if the Connection maintains a non-daemon thread
Timothy Bish created QPIDJMS-240: Summary: Add configuration option to determine if the Connection maintains a non-daemon thread Key: QPIDJMS-240 URL: https://issues.apache.org/jira/browse/QPIDJMS-240 Project: Qpid JMS Issue Type: Improvement Components: qpid-jms-client Affects Versions: 0.11.1 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.20.0 Add a new configuration option to control whether or no the Connection maintains a single non-daemon thread or not. Option to be added: "jms.useDaemonThread" -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-241) Add configuration option to determine if the Connection maintains a non-daemon thread
Timothy Bish created QPIDJMS-241: Summary: Add configuration option to determine if the Connection maintains a non-daemon thread Key: QPIDJMS-241 URL: https://issues.apache.org/jira/browse/QPIDJMS-241 Project: Qpid JMS Issue Type: Improvement Components: qpid-jms-client Affects Versions: 0.11.1 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 0.20.0 Add a new configuration option to control whether or no the Connection maintains a single non-daemon thread or not. Option to be added: "jms.useDaemonThread" -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-598) Router crash when calling sender and session close methods in onLinkFLow()
[ https://issues.apache.org/jira/browse/DISPATCH-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohan Mars updated DISPATCH-598: Attachment: test-app-reactor-core.tar.gz > Router crash when calling sender and session close methods in onLinkFLow() > -- > > Key: DISPATCH-598 > URL: https://issues.apache.org/jira/browse/DISPATCH-598 > Project: Qpid Dispatch > Issue Type: Bug > Components: Routing Engine >Affects Versions: 0.7.0 > Environment: Centos 7. Java 1.8 >Reporter: Rohan Mars > Attachments: test-app-reactor-core.tar.gz > > > Closing session/connection in sender onLinkFlow() causes router to crash -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-594) Log file over-written every time the router is restarted
[
https://issues.apache.org/jira/browse/DISPATCH-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy resolved DISPATCH-594.
Resolution: Fixed
> Log file over-written every time the router is restarted
>
>
> Key: DISPATCH-594
> URL: https://issues.apache.org/jira/browse/DISPATCH-594
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 0.7.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> Add the following in your router config file -
> {noformat}
> log {
> module: DEFAULT
> enable: trace+
> output: qdrouterd.log
> }
> {noformat}
> Start the router
> Stop the router and check the log file
> {noformat}
> Tue Dec 13 10:46:45 2016 AGENT (debug) Add entity: LogEntity(enable=trace+,
> identity=log/DEFAULT, module=DEFAULT, name=log/DEFAULT, output=qdrouterd.log,
> source=False, timestamp=True, type=org.apache.qpid.dispatch.log)
> Tue Dec 13 10:46:45 2016 AGENT (debug) Add entity:
> LogEntity(identity=log/ROUTER_LS, module=ROUTER_LS, name=log/ROUTER_LS,
> type=org.apache.qpid.dispatch.log)
> Tue Dec 13 10:46:45 2016 AGENT (debug) Add entity:
> LogEntity(identity=log/ROUTER_MA, module=ROUTER_MA, name=log/ROUTER_MA,
> type=org.apache.qpid.dispatch.log)
> Tue Dec 13 10:46:45 2016 AGENT (debug) Add entity:
> LogEntity(identity=log/ROUTER_HELLO, module=ROUTER_HELLO,
> name=log/ROUTER_HELLO, type=org.apache.qpid.dispatch.log)
> ..
> {noformat}
> Start the router again and stop it after a few seconds.
> {noformat}
> Tue Dec 13 10:49:51 2016 AGENT (debug) Add entity: LogEntity(enable=trace+,
> identity=log/DEFAULT, module=DEFAULT, name=log/DEFAULT, output=qdrouterd.log,
> source=False, timestamp=True, type=org.apache.qpid.dispatch.log)
> Tue Dec 13 10:49:51 2016 AGENT (debug) Add entity:
> LogEntity(identity=log/ROUTER_LS, module=ROUTER_LS, name=log/ROUTER_LS,
> type=org.apache.qpid.dispatch.log)
> Tue Dec 13 10:49:51 2016 AGENT (debug) Add entity:
> LogEntity(identity=log/ROUTER_MA, module=ROUTER_MA, name=log/ROUTER_MA,
> type=org.apache.qpid.dispatch.log)
> {noformat}
> The contents of the qdrouterd.log file has been erased and replaced with the
> log from the second router run.
> The router must append to the log file not erase it and start new.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-594) Log file over-written every time the router is restarted
[
https://issues.apache.org/jira/browse/DISPATCH-594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15752406#comment-15752406
]
ASF subversion and git services commented on DISPATCH-594:
--
Commit 85372a6aee200e7db59dba53301fa8cfca045008 in qpid-dispatch's branch
refs/heads/master from [~ganeshmurthy]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=85372a6 ]
DISPATCH-594 - Logs are appended to the log file if it already exists
> Log file over-written every time the router is restarted
>
>
> Key: DISPATCH-594
> URL: https://issues.apache.org/jira/browse/DISPATCH-594
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 0.7.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> Add the following in your router config file -
> {noformat}
> log {
> module: DEFAULT
> enable: trace+
> output: qdrouterd.log
> }
> {noformat}
> Start the router
> Stop the router and check the log file
> {noformat}
> Tue Dec 13 10:46:45 2016 AGENT (debug) Add entity: LogEntity(enable=trace+,
> identity=log/DEFAULT, module=DEFAULT, name=log/DEFAULT, output=qdrouterd.log,
> source=False, timestamp=True, type=org.apache.qpid.dispatch.log)
> Tue Dec 13 10:46:45 2016 AGENT (debug) Add entity:
> LogEntity(identity=log/ROUTER_LS, module=ROUTER_LS, name=log/ROUTER_LS,
> type=org.apache.qpid.dispatch.log)
> Tue Dec 13 10:46:45 2016 AGENT (debug) Add entity:
> LogEntity(identity=log/ROUTER_MA, module=ROUTER_MA, name=log/ROUTER_MA,
> type=org.apache.qpid.dispatch.log)
> Tue Dec 13 10:46:45 2016 AGENT (debug) Add entity:
> LogEntity(identity=log/ROUTER_HELLO, module=ROUTER_HELLO,
> name=log/ROUTER_HELLO, type=org.apache.qpid.dispatch.log)
> ..
> {noformat}
> Start the router again and stop it after a few seconds.
> {noformat}
> Tue Dec 13 10:49:51 2016 AGENT (debug) Add entity: LogEntity(enable=trace+,
> identity=log/DEFAULT, module=DEFAULT, name=log/DEFAULT, output=qdrouterd.log,
> source=False, timestamp=True, type=org.apache.qpid.dispatch.log)
> Tue Dec 13 10:49:51 2016 AGENT (debug) Add entity:
> LogEntity(identity=log/ROUTER_LS, module=ROUTER_LS, name=log/ROUTER_LS,
> type=org.apache.qpid.dispatch.log)
> Tue Dec 13 10:49:51 2016 AGENT (debug) Add entity:
> LogEntity(identity=log/ROUTER_MA, module=ROUTER_MA, name=log/ROUTER_MA,
> type=org.apache.qpid.dispatch.log)
> {noformat}
> The contents of the qdrouterd.log file has been erased and replaced with the
> log from the second router run.
> The router must append to the log file not erase it and start new.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-594) Log file over-written every time the router is restarted
[
https://issues.apache.org/jira/browse/DISPATCH-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ganesh Murthy reassigned DISPATCH-594:
--
Assignee: Ganesh Murthy
> Log file over-written every time the router is restarted
>
>
> Key: DISPATCH-594
> URL: https://issues.apache.org/jira/browse/DISPATCH-594
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Container
>Affects Versions: 0.7.0
>Reporter: Ganesh Murthy
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
>
> Add the following in your router config file -
> {noformat}
> log {
> module: DEFAULT
> enable: trace+
> output: qdrouterd.log
> }
> {noformat}
> Start the router
> Stop the router and check the log file
> {noformat}
> Tue Dec 13 10:46:45 2016 AGENT (debug) Add entity: LogEntity(enable=trace+,
> identity=log/DEFAULT, module=DEFAULT, name=log/DEFAULT, output=qdrouterd.log,
> source=False, timestamp=True, type=org.apache.qpid.dispatch.log)
> Tue Dec 13 10:46:45 2016 AGENT (debug) Add entity:
> LogEntity(identity=log/ROUTER_LS, module=ROUTER_LS, name=log/ROUTER_LS,
> type=org.apache.qpid.dispatch.log)
> Tue Dec 13 10:46:45 2016 AGENT (debug) Add entity:
> LogEntity(identity=log/ROUTER_MA, module=ROUTER_MA, name=log/ROUTER_MA,
> type=org.apache.qpid.dispatch.log)
> Tue Dec 13 10:46:45 2016 AGENT (debug) Add entity:
> LogEntity(identity=log/ROUTER_HELLO, module=ROUTER_HELLO,
> name=log/ROUTER_HELLO, type=org.apache.qpid.dispatch.log)
> ..
> {noformat}
> Start the router again and stop it after a few seconds.
> {noformat}
> Tue Dec 13 10:49:51 2016 AGENT (debug) Add entity: LogEntity(enable=trace+,
> identity=log/DEFAULT, module=DEFAULT, name=log/DEFAULT, output=qdrouterd.log,
> source=False, timestamp=True, type=org.apache.qpid.dispatch.log)
> Tue Dec 13 10:49:51 2016 AGENT (debug) Add entity:
> LogEntity(identity=log/ROUTER_LS, module=ROUTER_LS, name=log/ROUTER_LS,
> type=org.apache.qpid.dispatch.log)
> Tue Dec 13 10:49:51 2016 AGENT (debug) Add entity:
> LogEntity(identity=log/ROUTER_MA, module=ROUTER_MA, name=log/ROUTER_MA,
> type=org.apache.qpid.dispatch.log)
> {noformat}
> The contents of the qdrouterd.log file has been erased and replaced with the
> log from the second router run.
> The router must append to the log file not erase it and start new.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-235) add option to complete AMQP Open without waiting for a ClientID to [not] be set
[ https://issues.apache.org/jira/browse/QPIDJMS-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved QPIDJMS-235. -- Resolution: Fixed > add option to complete AMQP Open without waiting for a ClientID to [not] be > set > --- > > Key: QPIDJMS-235 > URL: https://issues.apache.org/jira/browse/QPIDJMS-235 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Reporter: Robbie Gemmell >Assignee: Timothy Bish > Fix For: 0.20.0 > > > If no ClientID was configured on the connection URI, the client delays > sending the AMQP Open frame to allow either for one to be set via > setClientID, or the Connection to be otherwise used and confirm no ClientID > can be set. It does this since we use the container-id to carry the ClientID. > If no ClientID is configured in the URI, and a Connection is created and > subsequently entirely unused (either via setClientID, or createSession etc) > for a period, this may delay the Open frame longer than a server will > tolerate. > We should add an option to provoke the AMQP connection to be Opened > immediately to allow for connections without a ClientID to succeed in this > scenario. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-235) add option to complete AMQP Open without waiting for a ClientID to [not] be set
[ https://issues.apache.org/jira/browse/QPIDJMS-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15752306#comment-15752306 ] ASF subversion and git services commented on QPIDJMS-235: - Commit 7f61e4875843b03201deaf471d7bc36967013864 in qpid-jms's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=7f61e48 ] QPIDJMS-235 Add option to control when the Connection does an Open Adds option 'jms.awaitClientID' to the connection factory which controls whether or not we wait for a client ID to be set or the connection to be used when there is not a client ID given on the connection URI before we perform the AMQP Open process. > add option to complete AMQP Open without waiting for a ClientID to [not] be > set > --- > > Key: QPIDJMS-235 > URL: https://issues.apache.org/jira/browse/QPIDJMS-235 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Reporter: Robbie Gemmell >Assignee: Timothy Bish > Fix For: 0.20.0 > > > If no ClientID was configured on the connection URI, the client delays > sending the AMQP Open frame to allow either for one to be set via > setClientID, or the Connection to be otherwise used and confirm no ClientID > can be set. It does this since we use the container-id to carry the ClientID. > If no ClientID is configured in the URI, and a Connection is created and > subsequently entirely unused (either via setClientID, or createSession etc) > for a period, this may delay the Open frame longer than a server will > tolerate. > We should add an option to provoke the AMQP connection to be Opened > immediately to allow for connections without a ClientID to succeed in this > scenario. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #128: DISPATCH-557 - Moved management of connecti...
GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/128 DISPATCH-557 - Moved management of connections from python agent to r⦠â¦outer core You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-557-3 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/128.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #128 commit 6b1bc4d3dc027730c5aa58c7c9d41697f7a478b1 Author: Ganesh Murthy Date: 2016-12-12T21:30:38Z DISPATCH-557 - Moved management of connections from python agent to router core --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-557) High connection rates cause problems in the Python management agent
[ https://issues.apache.org/jira/browse/DISPATCH-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15752211#comment-15752211 ] ASF GitHub Bot commented on DISPATCH-557: - GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/128 DISPATCH-557 - Moved management of connections from python agent to r… …outer core You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-557-3 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/128.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #128 commit 6b1bc4d3dc027730c5aa58c7c9d41697f7a478b1 Author: Ganesh Murthy Date: 2016-12-12T21:30:38Z DISPATCH-557 - Moved management of connections from python agent to router core > High connection rates cause problems in the Python management agent > --- > > Key: DISPATCH-557 > URL: https://issues.apache.org/jira/browse/DISPATCH-557 > Project: Qpid Dispatch > Issue Type: Bug > Components: Management Agent >Affects Versions: 0.7.0 >Reporter: Ted Ross >Assignee: Ganesh Murthy >Priority: Critical > Fix For: 0.8.0 > > > Since connection entities are the only non-configuration (spontaneously > occurring) entities that are still managed by the Python agent, high rates of > opening and closing connections causes large CPU overhead in the agent. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-557) High connection rates cause problems in the Python management agent
[ https://issues.apache.org/jira/browse/DISPATCH-557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15752205#comment-15752205 ] ASF GitHub Bot commented on DISPATCH-557: - Github user ganeshmurthy closed the pull request at: https://github.com/apache/qpid-dispatch/pull/125 > High connection rates cause problems in the Python management agent > --- > > Key: DISPATCH-557 > URL: https://issues.apache.org/jira/browse/DISPATCH-557 > Project: Qpid Dispatch > Issue Type: Bug > Components: Management Agent >Affects Versions: 0.7.0 >Reporter: Ted Ross >Assignee: Ganesh Murthy >Priority: Critical > Fix For: 0.8.0 > > > Since connection entities are the only non-configuration (spontaneously > occurring) entities that are still managed by the Python agent, high rates of > opening and closing connections causes large CPU overhead in the agent. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #125: DISPATCH-557 - Moved management of connecti...
Github user ganeshmurthy closed the pull request at: https://github.com/apache/qpid-dispatch/pull/125 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7575) [Java Broker] Improve AMQP 1.0 codec to retain encoded message data
[ https://issues.apache.org/jira/browse/QPID-7575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15752188#comment-15752188 ] Keith Wall commented on QPID-7575: -- Rob and I paired on the latter part of these changes. > [Java Broker] Improve AMQP 1.0 codec to retain encoded message data > --- > > Key: QPID-7575 > URL: https://issues.apache.org/jira/browse/QPID-7575 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Fix For: qpid-java-6.2 > > > Currently the AMQP 1.0 path through the broker stores all message data in > both the meta data and the message content and requires repeated parsing of > the message. We can improve performance by retaining the association between > sections and their encoded form at the point they are parsed, and only parse > sections if we require to inspect their contents -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7575) [Java Broker] Improve AMQP 1.0 codec to retain encoded message data
[ https://issues.apache.org/jira/browse/QPID-7575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall resolved QPID-7575. -- Resolution: Fixed > [Java Broker] Improve AMQP 1.0 codec to retain encoded message data > --- > > Key: QPID-7575 > URL: https://issues.apache.org/jira/browse/QPID-7575 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Fix For: qpid-java-6.2 > > > Currently the AMQP 1.0 path through the broker stores all message data in > both the meta data and the message content and requires repeated parsing of > the message. We can improve performance by retaining the association between > sections and their encoded form at the point they are parsed, and only parse > sections if we require to inspect their contents -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7580) [Java Broker] Expose the type of message (AMQP 0-9-1/0-10/1-0/Non-AMQP) through REST/Management
[ https://issues.apache.org/jira/browse/QPID-7580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall resolved QPID-7580. -- Resolution: Fixed Change looks reasonable to me. > [Java Broker] Expose the type of message (AMQP 0-9-1/0-10/1-0/Non-AMQP) > through REST/Management > --- > > Key: QPID-7580 > URL: https://issues.apache.org/jira/browse/QPID-7580 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Keith Wall > Fix For: qpid-java-6.2 > > > Currently when viewing message info it is impossible to tell what "type" of > message it is - i.e. the underlying representation that is stored in the > broker (AMQP 0-9-1, AMQP 0-10, AMQP 1.0 or "internal"). > We should add this information to MessageInfo(Impl) and the HTML management > console. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7580) [Java Broker] Expose the type of message (AMQP 0-9-1/0-10/1-0/Non-AMQP) through REST/Management
[ https://issues.apache.org/jira/browse/QPID-7580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall reassigned QPID-7580: Assignee: Keith Wall (was: Rob Godfrey) > [Java Broker] Expose the type of message (AMQP 0-9-1/0-10/1-0/Non-AMQP) > through REST/Management > --- > > Key: QPID-7580 > URL: https://issues.apache.org/jira/browse/QPID-7580 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Keith Wall > Fix For: qpid-java-6.2 > > > Currently when viewing message info it is impossible to tell what "type" of > message it is - i.e. the underlying representation that is stored in the > broker (AMQP 0-9-1, AMQP 0-10, AMQP 1.0 or "internal"). > We should add this information to MessageInfo(Impl) and the HTML management > console. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7272) [Java Broker] Direct memory QpidByteBuffer created in message conversion modules should be disposed as soon as possible after becoming unused
[ https://issues.apache.org/jira/browse/QPID-7272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall resolved QPID-7272. -- Resolution: Fixed > [Java Broker] Direct memory QpidByteBuffer created in message conversion > modules should be disposed as soon as possible after becoming unused > - > > Key: QPID-7272 > URL: https://issues.apache.org/jira/browse/QPID-7272 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.0 >Reporter: Alex Rudyy >Assignee: Keith Wall > Fix For: qpid-java-7.0.0 > > > Direct memory QpidByteBuffer in > MessageConverter_to_1_0#convertServerMessage(...) is not disposed > programmatically. We rely on GC to release it from memory when it became > unused. There is a risk that when such QpidByteBuffers are not "garbage > collected" soon enough Broker might run out of direct memory on heavy loads. > Currently a user who relies heavily of message conversion with high rates of > message flow, may see an OOM direct. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7272) [Java Broker] Direct memory QpidByteBuffer created in message conversion modules should be disposed as soon as possible after becoming unused
[ https://issues.apache.org/jira/browse/QPID-7272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15752157#comment-15752157 ] Keith Wall commented on QPID-7272: -- Change seems reasonable to me. I manually tested message conversion using a JMS publisher using both AMQP 0-9 and 0-10 and JMS consumer using AMQP 1.0. The leak reported above has been eliminated and direct memory usage (observed in jvisualvm) looks reasonable. > [Java Broker] Direct memory QpidByteBuffer created in message conversion > modules should be disposed as soon as possible after becoming unused > - > > Key: QPID-7272 > URL: https://issues.apache.org/jira/browse/QPID-7272 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.0 >Reporter: Alex Rudyy >Assignee: Keith Wall > Fix For: qpid-java-7.0.0 > > > Direct memory QpidByteBuffer in > MessageConverter_to_1_0#convertServerMessage(...) is not disposed > programmatically. We rely on GC to release it from memory when it became > unused. There is a risk that when such QpidByteBuffers are not "garbage > collected" soon enough Broker might run out of direct memory on heavy loads. > Currently a user who relies heavily of message conversion with high rates of > message flow, may see an OOM direct. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7592) [AMQP1.0] leak from Session_1_0#_outgoingUnsettled for long lived JMS auto-ack consuming session.
Keith Wall created QPID-7592: Summary: [AMQP1.0] leak from Session_1_0#_outgoingUnsettled for long lived JMS auto-ack consuming session. Key: QPID-7592 URL: https://issues.apache.org/jira/browse/QPID-7592 Project: Qpid Issue Type: Bug Components: Java Broker Reporter: Keith Wall Fix For: qpid-java-7.0.0 Running the Qpid Broker inside a profiler I see a leakage of Delivery objects for a long lived AMQP 1.0 consuming session (using JMS session auto-ack). The leak is originating from Session_1_0#_outgoingUnsettled. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPIDJMS-235) add option to complete AMQP Open without waiting for a ClientID to [not] be set
[ https://issues.apache.org/jira/browse/QPIDJMS-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish reassigned QPIDJMS-235: Assignee: Timothy Bish > add option to complete AMQP Open without waiting for a ClientID to [not] be > set > --- > > Key: QPIDJMS-235 > URL: https://issues.apache.org/jira/browse/QPIDJMS-235 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Reporter: Robbie Gemmell >Assignee: Timothy Bish > Fix For: 0.20.0 > > > If no ClientID was configured on the connection URI, the client delays > sending the AMQP Open frame to allow either for one to be set via > setClientID, or the Connection to be otherwise used and confirm no ClientID > can be set. It does this since we use the container-id to carry the ClientID. > If no ClientID is configured in the URI, and a Connection is created and > subsequently entirely unused (either via setClientID, or createSession etc) > for a period, this may delay the Open frame longer than a server will > tolerate. > We should add an option to provoke the AMQP connection to be Opened > immediately to allow for connections without a ClientID to succeed in this > scenario. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7272) [Java Broker] Direct memory QpidByteBuffer created in message conversion modules should be disposed as soon as possible after becoming unused
[ https://issues.apache.org/jira/browse/QPID-7272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall reassigned QPID-7272: Assignee: Keith Wall (was: Rob Godfrey) > [Java Broker] Direct memory QpidByteBuffer created in message conversion > modules should be disposed as soon as possible after becoming unused > - > > Key: QPID-7272 > URL: https://issues.apache.org/jira/browse/QPID-7272 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.0 >Reporter: Alex Rudyy >Assignee: Keith Wall > Fix For: qpid-java-7.0.0 > > > Direct memory QpidByteBuffer in > MessageConverter_to_1_0#convertServerMessage(...) is not disposed > programmatically. We rely on GC to release it from memory when it became > unused. There is a risk that when such QpidByteBuffers are not "garbage > collected" soon enough Broker might run out of direct memory on heavy loads. > Currently a user who relies heavily of message conversion with high rates of > message flow, may see an OOM direct. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7272) [Java Broker] Direct memory QpidByteBuffer created in message conversion modules should be disposed as soon as possible after becoming unused
[ https://issues.apache.org/jira/browse/QPID-7272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15751815#comment-15751815 ] Keith Wall commented on QPID-7272: -- Under review. > [Java Broker] Direct memory QpidByteBuffer created in message conversion > modules should be disposed as soon as possible after becoming unused > - > > Key: QPID-7272 > URL: https://issues.apache.org/jira/browse/QPID-7272 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.0 >Reporter: Alex Rudyy >Assignee: Keith Wall > Fix For: qpid-java-7.0.0 > > > Direct memory QpidByteBuffer in > MessageConverter_to_1_0#convertServerMessage(...) is not disposed > programmatically. We rely on GC to release it from memory when it became > unused. There is a risk that when such QpidByteBuffers are not "garbage > collected" soon enough Broker might run out of direct memory on heavy loads. > Currently a user who relies heavily of message conversion with high rates of > message flow, may see an OOM direct. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-239) Client ack session occasionally seen to redeliver recovered messages out of order
[ https://issues.apache.org/jira/browse/QPIDJMS-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPIDJMS-239: --- Attachment: TEST-org.apache.qpid.test.unit.ack.RecoverTest.testOrderingWithAsyncConsumer_0.20.0.txt TEST-org.apache.qpid.test.unit.ack.RecoverTest.testOrderingWithAsyncConsumer.txt > Client ack session occasionally seen to redeliver recovered messages out of > order > - > > Key: QPIDJMS-239 > URL: https://issues.apache.org/jira/browse/QPIDJMS-239 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.11.0, 0.20.0 >Reporter: Keith Wall > Attachments: > TEST-org.apache.qpid.test.unit.ack.RecoverTest.testOrderingWithAsyncConsumer.txt, > > TEST-org.apache.qpid.test.unit.ack.RecoverTest.testOrderingWithAsyncConsumer_0.20.0.txt > > > Test org.apache.qpid.test.unit.ack.RecoverTest#testOrderingWithAsyncConsumer > [1] fails occasional when run against the Java Broker. The test publishes a > number of messages then uses an async message listener to consume them. For > each message, the message listener recovers the session five times before > finally acknowledging the message, then the cycle repeats. In failure case, > I see the Qpid JMS Client delivery an unexpected message to the application > after a sequence of expected. > We have seen the failure on the Apache CI and I can reproduce the problem on > my laptop (every 15-20 runs of the test). > https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Java-MMS-1.0/40/artifact/trunk/systests/target/surefire-reports/java-mms.1-0/TEST-org.apache.qpid.test.unit.ack.RecoverTest.testOrderingWithAsyncConsumer.txt > I have reproduced locally against 0.20.0 too. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-239) Client ack session occasionally seen to redeliver recovered messages out of order
[
https://issues.apache.org/jira/browse/QPIDJMS-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15751756#comment-15751756
]
Keith Wall commented on QPIDJMS-239:
I've attached two examples. The pattern I see can be summarised with a grep.
The point the unexpected message appears seems to vary.
{format}
grep 'delivery dispatcher'
TEST-org.apache.qpid.test.unit.ack.RecoverTest.testOrderingWithAsyncConsumer_0.20.0.txt
2016-12-15 15:58:48,531 DEBUG [JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher]
o.a.q.t.u.a.RecoverTest Ignoring message 0 and calling recover
2016-12-15 15:58:48,532 DEBUG [JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher]
o.a.q.t.u.a.RecoverTest Ignoring message 0 and calling recover
2016-12-15 15:58:48,533 DEBUG [JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher]
o.a.q.t.u.a.RecoverTest Ignoring message 0 and calling recover
2016-12-15 15:58:48,533 DEBUG [JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher]
o.a.q.t.u.a.RecoverTest Ignoring message 0 and calling recover
2016-12-15 15:58:48,534 DEBUG [JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher]
o.a.q.t.u.a.RecoverTest Ignoring message 0 and calling recover
2016-12-15 15:58:48,536 DEBUG [JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher]
o.a.q.t.u.a.RecoverTest Acknowledging message 0
2016-12-15 15:58:48,537 DEBUG [JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher]
o.a.q.t.u.a.RecoverTest Ignoring message 1 and calling recover
2016-12-15 15:58:48,540 DEBUG [JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher]
o.a.q.t.u.a.RecoverTest Ignoring message 1 and calling recover
2016-12-15 15:58:48,542 DEBUG [JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher]
o.a.q.t.u.a.RecoverTest Ignoring message 1 and calling recover
# Qpid JMS Client delivers 7th message rather than redelivering the 1st
2016-12-15 15:58:48,546 ERROR [JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher]
o.a.q.t.u.InternalBrokerHolder Uncaught exception from thread JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher
junit.framework.AssertionFailedError: Received Message Out Of Order
expected:<1> but was:<7>
{format}
> Client ack session occasionally seen to redeliver recovered messages out of
> order
> -
>
> Key: QPIDJMS-239
> URL: https://issues.apache.org/jira/browse/QPIDJMS-239
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.11.0, 0.20.0
>Reporter: Keith Wall
> Attachments:
> TEST-org.apache.qpid.test.unit.ack.RecoverTest.testOrderingWithAsyncConsumer.txt,
>
> TEST-org.apache.qpid.test.unit.ack.RecoverTest.testOrderingWithAsyncConsumer_0.20.0.txt
>
>
> Test org.apache.qpid.test.unit.ack.RecoverTest#testOrderingWithAsyncConsumer
> [1] fails occasional when run against the Java Broker. The test publishes a
> number of messages then uses an async message listener to consume them. For
> each message, the message listener recovers the session five times before
> finally acknowledging the message, then the cycle repeats. In failure case,
> I see the Qpid JMS Client delivery an unexpected message to the application
> after a sequence of expected.
> We have seen the failure on the Apache CI and I can reproduce the problem on
> my laptop (every 15-20 runs of the test).
> https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Java-MMS-1.0/40/artifact/trunk/systests/target/surefire-reports/java-mms.1-0/TEST-org.apache.qpid.test.unit.ack.RecoverTest.testOrderingWithAsyncConsumer.txt
> I have reproduced locally against 0.20.0 too.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPIDJMS-239) Client ack session occasionally seen to redeliver recovered messages out of order
[
https://issues.apache.org/jira/browse/QPIDJMS-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15751756#comment-15751756
]
Keith Wall edited comment on QPIDJMS-239 at 12/15/16 4:13 PM:
--
I've attached two examples. The pattern I see can be summarised with a grep.
The point the unexpected message appears seems to vary.
{noformat}
grep 'delivery dispatcher'
TEST-org.apache.qpid.test.unit.ack.RecoverTest.testOrderingWithAsyncConsumer_0.20.0.txt
2016-12-15 15:58:48,531 DEBUG [JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher]
o.a.q.t.u.a.RecoverTest Ignoring message 0 and calling recover
2016-12-15 15:58:48,532 DEBUG [JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher]
o.a.q.t.u.a.RecoverTest Ignoring message 0 and calling recover
2016-12-15 15:58:48,533 DEBUG [JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher]
o.a.q.t.u.a.RecoverTest Ignoring message 0 and calling recover
2016-12-15 15:58:48,533 DEBUG [JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher]
o.a.q.t.u.a.RecoverTest Ignoring message 0 and calling recover
2016-12-15 15:58:48,534 DEBUG [JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher]
o.a.q.t.u.a.RecoverTest Ignoring message 0 and calling recover
2016-12-15 15:58:48,536 DEBUG [JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher]
o.a.q.t.u.a.RecoverTest Acknowledging message 0
2016-12-15 15:58:48,537 DEBUG [JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher]
o.a.q.t.u.a.RecoverTest Ignoring message 1 and calling recover
2016-12-15 15:58:48,540 DEBUG [JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher]
o.a.q.t.u.a.RecoverTest Ignoring message 1 and calling recover
2016-12-15 15:58:48,542 DEBUG [JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher]
o.a.q.t.u.a.RecoverTest Ignoring message 1 and calling recover
# Qpid JMS Client delivers 7th message rather than redelivering the 1st
2016-12-15 15:58:48,546 ERROR [JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher]
o.a.q.t.u.InternalBrokerHolder Uncaught exception from thread JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher
junit.framework.AssertionFailedError: Received Message Out Of Order
expected:<1> but was:<7>
{noformat}
was (Author: k-wall):
I've attached two examples. The pattern I see can be summarised with a grep.
The point the unexpected message appears seems to vary.
{format}
grep 'delivery dispatcher'
TEST-org.apache.qpid.test.unit.ack.RecoverTest.testOrderingWithAsyncConsumer_0.20.0.txt
2016-12-15 15:58:48,531 DEBUG [JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher]
o.a.q.t.u.a.RecoverTest Ignoring message 0 and calling recover
2016-12-15 15:58:48,532 DEBUG [JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher]
o.a.q.t.u.a.RecoverTest Ignoring message 0 and calling recover
2016-12-15 15:58:48,533 DEBUG [JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher]
o.a.q.t.u.a.RecoverTest Ignoring message 0 and calling recover
2016-12-15 15:58:48,533 DEBUG [JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher]
o.a.q.t.u.a.RecoverTest Ignoring message 0 and calling recover
2016-12-15 15:58:48,534 DEBUG [JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher]
o.a.q.t.u.a.RecoverTest Ignoring message 0 and calling recover
2016-12-15 15:58:48,536 DEBUG [JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher]
o.a.q.t.u.a.RecoverTest Acknowledging message 0
2016-12-15 15:58:48,537 DEBUG [JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher]
o.a.q.t.u.a.RecoverTest Ignoring message 1 and calling recover
2016-12-15 15:58:48,540 DEBUG [JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher]
o.a.q.t.u.a.RecoverTest Ignoring message 1 and calling recover
2016-12-15 15:58:48,542 DEBUG [JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher]
o.a.q.t.u.a.RecoverTest Ignoring message 1 and calling recover
# Qpid JMS Client delivers 7th message rather than redelivering the 1st
2016-12-15 15:58:48,546 ERROR [JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher]
o.a.q.t.u.InternalBrokerHolder Uncaught exception from thread JmsSession
[ID:f702629f-cc27-4366-87a7-55c52282b0cf:1:1] delivery dispatcher
junit.framework.AssertionFailedError: Received Message Out Of Order
expected:<1> but was:<7>
{format}
> Client ack session occasio
[jira] [Created] (QPIDJMS-239) Client ack session occasionally seen to redeliver recovered messages out of order
Keith Wall created QPIDJMS-239: -- Summary: Client ack session occasionally seen to redeliver recovered messages out of order Key: QPIDJMS-239 URL: https://issues.apache.org/jira/browse/QPIDJMS-239 Project: Qpid JMS Issue Type: Bug Components: qpid-jms-client Affects Versions: 0.11.0, 0.20.0 Reporter: Keith Wall Test org.apache.qpid.test.unit.ack.RecoverTest#testOrderingWithAsyncConsumer [1] fails occasional when run against the Java Broker. The test publishes a number of messages then uses an async message listener to consume them. For each message, the message listener recovers the session five times before finally acknowledging the message, then the cycle repeats. In failure case, I see the Qpid JMS Client delivery an unexpected message to the application after a sequence of expected. We have seen the failure on the Apache CI and I can reproduce the problem on my laptop (every 15-20 runs of the test). https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Java-Java-MMS-1.0/40/artifact/trunk/systests/target/surefire-reports/java-mms.1-0/TEST-org.apache.qpid.test.unit.ack.RecoverTest.testOrderingWithAsyncConsumer.txt I have reproduced locally against 0.20.0 too. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-492) Add a way to request logs for a specific module
[ https://issues.apache.org/jira/browse/DISPATCH-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15751701#comment-15751701 ] ASF GitHub Bot commented on DISPATCH-492: - Github user ganeshmurthy closed the pull request at: https://github.com/apache/qpid-dispatch/pull/105 > Add a way to request logs for a specific module > --- > > Key: DISPATCH-492 > URL: https://issues.apache.org/jira/browse/DISPATCH-492 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Management Agent >Reporter: Ernest Allen >Assignee: Ganesh Murthy > > The current GET-LOGS method returns log entries from all module types. > The console is then filtering the returned list to get only the entries for a > specific module (like log/ERROR, log/AGENT, etc.) > It would be more efficient to have a way to specify which module's logs are > needed and return only those. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request #105: DISPATCH-492 - Added module parameter to GE...
Github user ganeshmurthy closed the pull request at: https://github.com/apache/qpid-dispatch/pull/105 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-596) error is lost from rejected state in relayed disposition
[
https://issues.apache.org/jira/browse/DISPATCH-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15751662#comment-15751662
]
ASF GitHub Bot commented on DISPATCH-596:
-
GitHub user ganeshmurthy opened a pull request:
https://github.com/apache/qpid-dispatch/pull/127
DISPATCH-596 - Preserve the error from the rejected state in relayed …
…disposition
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-596
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/qpid-dispatch/pull/127.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #127
commit 01461e4ebb4b40fe3862a528e5b77493128ad315
Author: Ganesh Murthy
Date: 2016-12-15T15:29:44Z
DISPATCH-596 - Preserve the error from the rejected state in relayed
disposition
> error is lost from rejected state in relayed disposition
>
>
> Key: DISPATCH-596
> URL: https://issues.apache.org/jira/browse/DISPATCH-596
> Project: Qpid Dispatch
> Issue Type: Bug
>Affects Versions: 0.7.0
>Reporter: Gordon Sim
>Assignee: Ganesh Murthy
> Fix For: 0.8.0
>
> Attachments: reject.py
>
>
> {noformat}
> [0x55d7cde663a0]: -> SASL
> [0x55d7cde663a0]: <- SASL
> [0x55d7cde663a0]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
> [0x55d7cde663a0]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS,
> initial-response=b"anonymous@localhost.localdomain"]
> [0x55d7cde663a0]:0 <- @sasl-outcome(68) [code=0]
> [0x55d7cde663a0]: -> AMQP
> [0x55d7cde663a0]:0 -> @open(16)
> [container-id="4308de22-4121-49bc-bac4-8ee05bf1504e", hostname="localhost",
> channel-max=32767]
> [0x55d7cde663a0]:0 -> @begin(17) [next-outgoing-id=0,
> incoming-window=2147483647, outgoing-window=2147483647]
> [0x55d7cde663a0]:0 -> @attach(18)
> [name="4308de22-4121-49bc-bac4-8ee05bf1504e-examples", handle=0, role=true,
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="examples",
> durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0,
> timeout=0, dynamic=false], initial-delivery-count=0]
> [0x55d7cde663a0]:0 -> @attach(18)
> [name="4308de22-4121-49bc-bac4-8ee05bf1504e-examples", handle=1, role=false,
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0,
> timeout=0, dynamic=false], target=@target(41) [address="examples", durable=0,
> timeout=0, dynamic=false], initial-delivery-count=0]
> [0x55d7cde663a0]:0 -> @flow(19) [incoming-window=2147483647,
> next-outgoing-id=0, outgoing-window=2147483647, handle=0, delivery-count=0,
> link-credit=10, drain=false]
> [0x55d7cde663a0]: <- AMQP
> [0x55d7cde663a0]:0 <- @open(16) [container-id="Router.A",
> max-frame-size=16384, channel-max=32767, idle-time-out=8000,
> offered-capabilities=:"ANONYMOUS-RELAY",
> properties={:product="qpid-dispatch-router", :version="0.8.0"}]
> [0x55d7cde663a0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=0,
> incoming-window=100, outgoing-window=2147483647]
> [0x55d7cde663a0]:0 <- @attach(18)
> [name="4308de22-4121-49bc-bac4-8ee05bf1504e-examples", handle=0, role=false,
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="examples",
> durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0,
> timeout=0, dynamic=false], initial-delivery-count=0]
> [0x55d7cde663a0]:0 <- @attach(18)
> [name="4308de22-4121-49bc-bac4-8ee05bf1504e-examples", handle=1, role=true,
> snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0,
> timeout=0, dynamic=false], target=@target(41) [address="examples", durable=0,
> timeout=0, dynamic=false], initial-delivery-count=0]
> [0x55d7cde663a0]:0 <- @flow(19) [next-incoming-id=0, incoming-window=100,
> next-outgoing-id=0, outgoing-window=2147483647, handle=1, delivery-count=0,
> link-credit=250, drain=false]
> [0x55d7cde663a0]:0 -> @transfer(20) [handle=1, delivery-id=0,
> delivery-tag=b"1", message-format=0, settled=false, more=false] (78)
> "\x00Sp\xd0\x00\x00\x00\x0b\x00\x00\x00\x05BP\x04@BR\x00\x00Ss\xd0\x00\x00\x00"\x00\x00\x00\x0d\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@R\x00@\x00Sw\xa1\x0cHello
> World!"
> [0x55d7cde663a0]:0 <- @transfer(20) [handle=0, delivery-id=0,
> delivery-tag=b"\x07\x00\x00\x00\x00\x00\x00\x00", message-format=0,
> settled=false, more=false] (78)
> "\x00Sp\xd0\x00\x00\x00\x0b\x00\x00\x00\x05BP\x04@BR\x00\x00Ss\xd0\x00\x00\x00"\x00\x00\x00\x0d\x83\x00\x00\x00\x00\x00\x00\x00\x00\x83\x00\x00\x00\x00\x00\x00\x00\x00@R\x00@\x00Sw\xa1\x0cHello
> World!"
> Rejecting delivery: Hello World!
> [0x55d7cde663a0
[GitHub] qpid-dispatch pull request #127: DISPATCH-596 - Preserve the error from the ...
GitHub user ganeshmurthy opened a pull request: https://github.com/apache/qpid-dispatch/pull/127 DISPATCH-596 - Preserve the error from the rejected state in relayed ⦠â¦disposition You can merge this pull request into a Git repository by running: $ git pull https://github.com/ganeshmurthy/qpid-dispatch DISPATCH-596 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/qpid-dispatch/pull/127.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #127 commit 01461e4ebb4b40fe3862a528e5b77493128ad315 Author: Ganesh Murthy Date: 2016-12-15T15:29:44Z DISPATCH-596 - Preserve the error from the rejected state in relayed disposition --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-232) Perform Authentication when the remote connection is established instead of waiting until Connection is used
[ https://issues.apache.org/jira/browse/QPIDJMS-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15751647#comment-15751647 ] ASF subversion and git services commented on QPIDJMS-232: - Commit 3001facb74b3d3455a0d51520afe7e833fe8e5bd in qpid-jms's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=3001fac ] QPIDJMS-232: a little further reorg of the connect sequence and some more tests > Perform Authentication when the remote connection is established instead of > waiting until Connection is used > > > Key: QPIDJMS-232 > URL: https://issues.apache.org/jira/browse/QPIDJMS-232 > Project: Qpid JMS > Issue Type: Improvement > Components: qpid-jms-client >Affects Versions: 0.11.1 >Reporter: Timothy Bish >Assignee: Timothy Bish > Fix For: 0.20.0 > > > Instead of waiting until the connection is used to perform authentication we > should perform the SASL authentication if available when the connection is > established. This allows the createConnection methods in the > ConnectionFactory to fail fast instead of waiting until the Connection is > used (e.g set client ID, start, createSession etc) -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7576) Metadata loaded twice for recovered message
[
https://issues.apache.org/jira/browse/QPID-7576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15751631#comment-15751631
]
Lorenz Quack commented on QPID-7576:
stacktraces from 6.0.x of the delivery path:
{code}
java.lang.RuntimeException
at
org.apache.qpid.server.protocol.v0_8.MessageMetaData.clearEncodedForm(MessageMetaData.java:217)
at
org.apache.qpid.server.store.AbstractJDBCMessageStore$MessageDataSoftRef.clear(AbstractJDBCMessageStore.java:1377)
at
org.apache.qpid.server.store.AbstractJDBCMessageStore$StoredJDBCMessage.flowToDisk(AbstractJDBCMessageStore.java:1625)
at
org.apache.qpid.server.message.AbstractServerMessageImpl.getContent(AbstractServerMessageImpl.java:202)
at
org.apache.qpid.server.protocol.v0_8.ProtocolOutputConverterImpl.writeMessageDelivery(ProtocolOutputConverterImpl.java:114)
at
org.apache.qpid.server.protocol.v0_8.ProtocolOutputConverterImpl.writeMessageDelivery(ProtocolOutputConverterImpl.java:102)
at
org.apache.qpid.server.protocol.v0_8.ProtocolOutputConverterImpl.writeDeliver(ProtocolOutputConverterImpl.java:78)
at
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8$WriteDeliverMethod.deliverToClient(AMQPConnection_0_8.java:1356)
at
org.apache.qpid.server.protocol.v0_8.ConsumerTarget_0_8.sendToClient(ConsumerTarget_0_8.java:450)
at
org.apache.qpid.server.protocol.v0_8.ConsumerTarget_0_8$AckConsumer.doSend(ConsumerTarget_0_8.java:276)
at
org.apache.qpid.server.consumer.AbstractConsumerTarget.sendNextMessage(AbstractConsumerTarget.java:219)
at
org.apache.qpid.server.consumer.AbstractConsumerTarget.processPending(AbstractConsumerTarget.java:68)
at
org.apache.qpid.server.protocol.v0_8.AMQChannel.processPending(AMQChannel.java:3769)
at
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8$ProcessPendingIterator$1.run(AMQPConnection_0_8.java:1547)
at
org.apache.qpid.server.transport.NonBlockingConnection.processPending(NonBlockingConnection.java:372)
at
org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:277)
at
org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:124)
at
org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:508)
at
org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:341)
at
org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:89)
at
org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:466)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
java.lang.RuntimeException
at
org.apache.qpid.server.protocol.v0_8.MessageMetaData.(MessageMetaData.java:71)
at
org.apache.qpid.server.protocol.v0_8.MessageMetaData$MetaDataFactory.createMetaData(MessageMetaData.java:244)
at
org.apache.qpid.server.protocol.v0_8.MessageMetaData$MetaDataFactory.createMetaData(MessageMetaData.java:221)
at
org.apache.qpid.server.protocol.v0_8.MessageMetaDataType_0_8.createMetaData(MessageMetaDataType_0_8.java:45)
at
org.apache.qpid.server.protocol.v0_8.MessageMetaDataType_0_8.createMetaData(MessageMetaDataType_0_8.java:29)
at
org.apache.qpid.server.store.AbstractJDBCMessageStore.getMetaData(AbstractJDBCMessageStore.java:985)
at
org.apache.qpid.server.store.AbstractJDBCMessageStore.access$1200(AbstractJDBCMessageStore.java:58)
at
org.apache.qpid.server.store.AbstractJDBCMessageStore$StoredJDBCMessage.getMetaData(AbstractJDBCMessageStore.java:1443)
at
org.apache.qpid.server.message.AbstractServerMessageImpl.isPersistent(AbstractServerMessageImpl.java:162)
at
org.apache.qpid.server.queue.AbstractQueue.decrementQueueSize(AbstractQueue.java:1530)
at
org.apache.qpid.server.queue.AbstractQueue.dequeue(AbstractQueue.java:1514)
at
org.apache.qpid.server.queue.QueueEntryImpl.dequeue(QueueEntryImpl.java:530)
at
org.apache.qpid.server.queue.QueueEntryImpl.delete(QueueEntryImpl.java:578)
at
org.apache.qpid.server.protocol.v0_8.AMQChannel$MessageAcknowledgeAction.postCommit(AMQChannel.java:1600)
at
org.apache.qpid.server.protocol.v0_8.AMQChannel$AsyncCommand.complete(AMQChannel.java:1910)
at
org.apache.qpid.server.protocol.v0_8.AMQChannel.sync(AMQChannel.java:1853)
at
org.apache.qpid.server.protocol.v0_8.AMQChannel.receivedComplete(AMQChannel.java:353)
at
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8.receivedCompleteAllChannels(AMQPConnection_0_8.java:
[jira] [Commented] (QPID-7576) Metadata loaded twice for recovered message
[
https://issues.apache.org/jira/browse/QPID-7576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15751614#comment-15751614
]
Lorenz Quack commented on QPID-7576:
stacktraces from 6.1.x of the delivery path:
{code}
java.lang.RuntimeException
at
org.apache.qpid.server.protocol.v0_8.MessageMetaData.clearEncodedForm(MessageMetaData.java:150)
at
org.apache.qpid.server.store.AbstractJDBCMessageStore$MessageDataSoftRef.clear(AbstractJDBCMessageStore.java:1381)
at
org.apache.qpid.server.store.AbstractJDBCMessageStore$StoredJDBCMessage.flowToDisk(AbstractJDBCMessageStore.java:1650)
at
org.apache.qpid.server.message.AbstractServerMessageImpl.getContent(AbstractServerMessageImpl.java:183)
at
org.apache.qpid.server.protocol.v0_8.ProtocolOutputConverterImpl$MessageContentSourceBody.writePayload(ProtocolOutputConverterImpl.java:277)
at org.apache.qpid.framing.AMQFrame.writePayload(AMQFrame.java:69)
at
org.apache.qpid.server.protocol.v0_8.ProtocolOutputConverterImpl$CompositeAMQBodyBlock.writePayload(ProtocolOutputConverterImpl.java:475)
at
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.writeFrame(AMQPConnection_0_8Impl.java:382)
at
org.apache.qpid.server.protocol.v0_8.ProtocolOutputConverterImpl.writeFrame(ProtocolOutputConverterImpl.java:432)
at
org.apache.qpid.server.protocol.v0_8.ProtocolOutputConverterImpl.writeMessageDeliveryUnchanged(ProtocolOutputConverterImpl.java:231)
at
org.apache.qpid.server.protocol.v0_8.ProtocolOutputConverterImpl.writeMessageDelivery(ProtocolOutputConverterImpl.java:138)
at
org.apache.qpid.server.protocol.v0_8.ProtocolOutputConverterImpl.writeMessageDelivery(ProtocolOutputConverterImpl.java:95)
at
org.apache.qpid.server.protocol.v0_8.ProtocolOutputConverterImpl.writeDeliver(ProtocolOutputConverterImpl.java:72)
at
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$WriteDeliverMethod.deliverToClient(AMQPConnection_0_8Impl.java:1275)
at
org.apache.qpid.server.protocol.v0_8.ConsumerTarget_0_8.sendToClient(ConsumerTarget_0_8.java:452)
at
org.apache.qpid.server.protocol.v0_8.ConsumerTarget_0_8$AckConsumer.doSend(ConsumerTarget_0_8.java:274)
at
org.apache.qpid.server.consumer.AbstractConsumerTarget.sendNextMessage(AbstractConsumerTarget.java:327)
at
org.apache.qpid.server.consumer.AbstractConsumerTarget.processPending(AbstractConsumerTarget.java:99)
at
org.apache.qpid.server.protocol.v0_8.AMQChannel.processPending(AMQChannel.java:3797)
at
org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$ProcessPendingIterator$1.run(AMQPConnection_0_8Impl.java:1447)
at
org.apache.qpid.server.transport.NonBlockingConnection.processPending(NonBlockingConnection.java:375)
at
org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:279)
at
org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:126)
at
org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:563)
at
org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.run(SelectorThread.java:551)
at
org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:521)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
java.lang.RuntimeException
at
org.apache.qpid.server.protocol.v0_8.MessageMetaData.(MessageMetaData.java:66)
at
org.apache.qpid.server.protocol.v0_8.MessageMetaData$MetaDataFactory.createMetaData(MessageMetaData.java:176)
at
org.apache.qpid.server.protocol.v0_8.MessageMetaData$MetaDataFactory.createMetaData(MessageMetaData.java:154)
at
org.apache.qpid.server.protocol.v0_8.MessageMetaDataType_0_8.createMetaData(MessageMetaDataType_0_8.java:45)
at
org.apache.qpid.server.protocol.v0_8.MessageMetaDataType_0_8.createMetaData(MessageMetaDataType_0_8.java:29)
at
org.apache.qpid.server.store.AbstractJDBCMessageStore.getMetaData(AbstractJDBCMessageStore.java:985)
at
org.apache.qpid.server.store.AbstractJDBCMessageStore.access$1200(AbstractJDBCMessageStore.java:58)
at
org.apache.qpid.server.store.AbstractJDBCMessageStore$StoredJDBCMessage.getMetaData(AbstractJDBCMessageStore.java:1447)
at
org.apache.qpid.server.message.AbstractServerMessageImpl.isPersistent(AbstractServerMessageImpl.java:161)
at
org.apache.qpid.server.queue.AbstractQueue.decrementQueueSize(AbstractQueue.java:1570)
at
org.apache.qpid.server.queue.AbstractQueue.dequeue(AbstractQueue.java:1554)
at
org.apache.qpid.se
[jira] [Commented] (QPID-7104) [Java Broker] Creating multiple state transition methods on a ConfiguredObject should cause an error
[ https://issues.apache.org/jira/browse/QPID-7104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15751593#comment-15751593 ] Lorenz Quack commented on QPID-7104: This particular case was fixed in QPID-7560. The general problem remains. > [Java Broker] Creating multiple state transition methods on a > ConfiguredObject should cause an error > > > Key: QPID-7104 > URL: https://issues.apache.org/jira/browse/QPID-7104 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.32, qpid-java-6.0 >Reporter: Lorenz Quack > Fix For: qpid-java-7.0.0 > > > Currently nothing prevents one from annotating several methods with the same > @StateTransition. However, the behaviour is not well defined. > Ideally, we would catch this during compile-time. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (QPID-7560) AbstractVirtualHost defines two state transitions from ERROR to ACTIVE
[ https://issues.apache.org/jira/browse/QPID-7560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack reopened QPID-7560: > AbstractVirtualHost defines two state transitions from ERROR to ACTIVE > -- > > Key: QPID-7560 > URL: https://issues.apache.org/jira/browse/QPID-7560 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Keith Wall >Assignee: Keith Wall >Priority: Minor > Fix For: qpid-java-6.2, qpid-java-6.1.1, qpid-java-6.0.6 > > > The current implementation of AbstractVirtualHost defines two state > transitions from ERROR=>ACTIVE. The state change mechanics could choose > either which could lead to undesired results. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7560) AbstractVirtualHost defines two state transitions from ERROR to ACTIVE
[ https://issues.apache.org/jira/browse/QPID-7560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lorenz Quack resolved QPID-7560. Resolution: Fixed seems good to me. please backport > AbstractVirtualHost defines two state transitions from ERROR to ACTIVE > -- > > Key: QPID-7560 > URL: https://issues.apache.org/jira/browse/QPID-7560 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Keith Wall >Assignee: Keith Wall >Priority: Minor > Fix For: qpid-java-6.2, qpid-java-6.1.1, qpid-java-6.0.6 > > > The current implementation of AbstractVirtualHost defines two state > transitions from ERROR=>ACTIVE. The state change mechanics could choose > either which could lead to undesired results. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7576) Metadata loaded twice for recovered message
[
https://issues.apache.org/jira/browse/QPID-7576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15751504#comment-15751504
]
Lorenz Quack commented on QPID-7576:
I think the interesting parts are:
* {{AbstractServerMessageImpl#getContent}} were we decide to evict messages
that were previously flown to disk or recovered after getting their content.
This was a deliberate change in QPID-6735.
* {{AbstractQueueEntryList#updateStatsOnStateChange}} were we reload the
metadata to update the stats upon deleting the message.
> Metadata loaded twice for recovered message
> ---
>
> Key: QPID-7576
> URL: https://issues.apache.org/jira/browse/QPID-7576
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.2
>Reporter: Keith Wall
> Fix For: qpid-java-6.1.1
>
>
> For recovered messages (and possibly messages that have been flown to disk),
> the metadata is evacuated from memory unnecessarily and then immediately
> reloaded.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7546) [Java Broker] Allow the system tests to be run using the Qpid JMS client for AMQP 1.0 testing
[ https://issues.apache.org/jira/browse/QPID-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15751499#comment-15751499 ] ASF subversion and git services commented on QPID-7546: --- Commit 1774470 from [~k-wall] in branch 'java/trunk' [ https://svn.apache.org/r1774470 ] QPID-7546: Update test name in CPPExcludes - partial revert of r1774149 > [Java Broker] Allow the system tests to be run using the Qpid JMS client for > AMQP 1.0 testing > - > > Key: QPID-7546 > URL: https://issues.apache.org/jira/browse/QPID-7546 > Project: Qpid > Issue Type: Test > Components: Java Tests >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Attachments: > 0001-QPID-7546-Allow-overriding-of-jms-spec-artifact-in-o.patch > > > Currently the system tests use the JMS client for AMQP 0-8/9/10 and so the > AMQP 1.0 protocol implementation does not get as thoroughly tested. > We should aim to move all the system tests such that they can be run with > either client -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7591) Broker may send a deleted message to a queue browser
[ https://issues.apache.org/jira/browse/QPID-7591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15751497#comment-15751497 ] ASF subversion and git services commented on QPID-7591: --- Commit 1774469 from [~k-wall] in branch 'java/trunk' [ https://svn.apache.org/r1774469 ] QPID-7591: [Java Broker] Ensure that message reference is held for browsers until the consumer target sends the message > Broker may send a deleted message to a queue browser > > > Key: QPID-7591 > URL: https://issues.apache.org/jira/browse/QPID-7591 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.2 >Reporter: Keith Wall > Fix For: qpid-java-6.2 > > > The changes made by QPID-7514 inadvertently opened the possibility that a > browser may receive a deleted message. Internally, for queue browser, the > queue entries are not acquired. Instead, a message reference is taken. It > is the responsibility of the consumer target to release the message > reference. > A coding error in AbstractQueue#attemptDelivery meant that the message > reference was immediately released. > This defect never formed part of a release. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-7576) Metadata loaded twice for recovered message
[
https://issues.apache.org/jira/browse/QPID-7576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15751225#comment-15751225
]
Lorenz Quack edited comment on QPID-7576 at 12/15/16 2:13 PM:
--
Here are some stacktraces (created in
{{v0_8.MessageMetaData#MessageMetaData(MessagePublishInfo, ContentHeaderBody,
long)}}, {{v0_8.MessageMetaData#dispose}}, and
{{v0_8.MessageMetaData#clearEncodedForm}}:
On broker recovery:
{code}
java.lang.RuntimeException
at
org.apache.qpid.server.protocol.v0_8.MessageMetaData.(MessageMetaData.java:66)
at
org.apache.qpid.server.protocol.v0_8.MessageMetaData$MetaDataFactory.createMetaData(MessageMetaData.java:172)
at
org.apache.qpid.server.protocol.v0_8.MessageMetaData$MetaDataFactory.createMetaData(MessageMetaData.java:150)
at
org.apache.qpid.server.protocol.v0_8.MessageMetaDataType_0_8.createMetaData(MessageMetaDataType_0_8.java:45)
at
org.apache.qpid.server.protocol.v0_8.MessageMetaDataType_0_8.createMetaData(MessageMetaDataType_0_8.java:29)
at
org.apache.qpid.server.store.AbstractJDBCMessageStore$JDBCMessageStoreReader.visitMessages(AbstractJDBCMessageStore.java:1761)
at
org.apache.qpid.server.virtualhost.SynchronousMessageStoreRecoverer.recover(SynchronousMessageStoreRecoverer.java:78)
at
org.apache.qpid.server.virtualhost.AbstractVirtualHost.postCreateDefaultExchangeTasks(AbstractVirtualHost.java:2526)
at
org.apache.qpid.server.virtualhost.AbstractVirtualHost.onActivate(AbstractVirtualHost.java:2509)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
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:1549)
at
org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1528)
at
org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:1102)
at
org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:1096)
at
org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2676)
at
org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2672)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at
org.apache.qpid.server.model.AbstractConfiguredObject$22.onSuccess(AbstractConfiguredObject.java:2671)
at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
at
org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:392)
at
org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:175)
at
com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
at
com.google.common.util.concurrent.ExecutionList.add(ExecutionList.java:101)
at
com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:170)
at
com.google.common.util.concurrent.Futures.addCallback(Futures.java:1322)
at
org.apache.qpid.server.model.AbstractConfiguredObject.addFutureCallback(AbstractConfiguredObject.java:2666)
at
org.apache.qpid.server.model.AbstractConfiguredObject.doAttainState(AbstractConfiguredObject.java:1095)
at
org.apache.qpid.server.model.AbstractConfiguredObject.access$600(AbstractConfiguredObject.java:95)
at
org.apache.qpid.server.model.AbstractConfiguredObject$1.execute(AbstractConfiguredObject.java:619)
at
org.apache.qpid.server.model.AbstractConfiguredObject$1.execute(AbstractConfiguredObject.java:606)
at
org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:667)
at
org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:660)
at
org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:240)
at
org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper$1.run(TaskExecutorImpl.java:312)
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:305)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExec
[jira] [Created] (QPID-7591) Broker may send a deleted message to a queue browser
Keith Wall created QPID-7591: Summary: Broker may send a deleted message to a queue browser Key: QPID-7591 URL: https://issues.apache.org/jira/browse/QPID-7591 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: qpid-java-6.2 Reporter: Keith Wall Fix For: qpid-java-6.2 The changes made by QPID-7514 inadvertently opened the possibility that a browser may receive a deleted message. Internally, for queue browser, the queue entries are not acquired. Instead, a message reference is taken. It is the responsibility of the consumer target to release the message reference. A coding error in AbstractQueue#attemptDelivery meant that the message reference was immediately released. This defect never formed part of a release. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7560) AbstractVirtualHost defines two state transitions from ERROR to ACTIVE
[ https://issues.apache.org/jira/browse/QPID-7560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7560: - Priority: Minor (was: Major) > AbstractVirtualHost defines two state transitions from ERROR to ACTIVE > -- > > Key: QPID-7560 > URL: https://issues.apache.org/jira/browse/QPID-7560 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Keith Wall >Assignee: Keith Wall >Priority: Minor > Fix For: qpid-java-6.2, qpid-java-6.1.1, qpid-java-6.0.6 > > > The current implementation of AbstractVirtualHost defines two state > transitions from ERROR=>ACTIVE. The state change mechanics could choose > either which could lead to undesired results. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7560) AbstractVirtualHost defines two state transitions from ERROR to ACTIVE
[ https://issues.apache.org/jira/browse/QPID-7560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15751430#comment-15751430 ] ASF subversion and git services commented on QPID-7560: --- Commit 1774446 from [~k-wall] in branch 'java/trunk' [ https://svn.apache.org/r1774446 ] QPID-7560: [Java Broker] Remove duplicate state transition. Also interpret a negative housekeeping interval as 'disable housekeeping' rather than causing an exception. > AbstractVirtualHost defines two state transitions from ERROR to ACTIVE > -- > > Key: QPID-7560 > URL: https://issues.apache.org/jira/browse/QPID-7560 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-6.2, qpid-java-6.1.1, qpid-java-6.0.6 > > > The current implementation of AbstractVirtualHost defines two state > transitions from ERROR=>ACTIVE. The state change mechanics could choose > either which could lead to undesired results. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7560) AbstractVirtualHost defines two state transitions from ERROR to ACTIVE
[ https://issues.apache.org/jira/browse/QPID-7560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall reassigned QPID-7560: Assignee: Keith Wall > AbstractVirtualHost defines two state transitions from ERROR to ACTIVE > -- > > Key: QPID-7560 > URL: https://issues.apache.org/jira/browse/QPID-7560 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Keith Wall >Assignee: Keith Wall > Fix For: qpid-java-6.2, qpid-java-6.1.1, qpid-java-6.0.6 > > > The current implementation of AbstractVirtualHost defines two state > transitions from ERROR=>ACTIVE. The state change mechanics could choose > either which could lead to undesired results. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7560) AbstractVirtualHost defines two state transitions from ERROR to ACTIVE
[ https://issues.apache.org/jira/browse/QPID-7560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7560: - Status: Reviewable (was: In Progress) > AbstractVirtualHost defines two state transitions from ERROR to ACTIVE > -- > > Key: QPID-7560 > URL: https://issues.apache.org/jira/browse/QPID-7560 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Keith Wall >Assignee: Keith Wall > Fix For: qpid-java-6.2, qpid-java-6.1.1, qpid-java-6.0.6 > > > The current implementation of AbstractVirtualHost defines two state > transitions from ERROR=>ACTIVE. The state change mechanics could choose > either which could lead to undesired results. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-7560) AbstractVirtualHost defines two state transitions from ERROR to ACTIVE
[
https://issues.apache.org/jira/browse/QPID-7560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15751157#comment-15751157
]
Keith Wall edited comment on QPID-7560 at 12/15/16 1:49 PM:
At the moment, the only thing that causes a VH to go into {{ERROR}} is a
failure to schedule the housekeeping task. This can only happen if the
housekeeping parameters are somehow misconfigured (for instance a negative
{{period}}). As you probably would not expect such parameters to be altered
in a production environment, I think the likelihood of a VH ending up in ERROR
to be small.If a VH were to somehow end up in ERROR, and an operator
attempt a restart, currently the Broker would fail if the {{onRestart}} route
were to be followed as the VH's CO would be duplicated. A restart would be
required to clear the condition.
Note: failure to recover the messages currently causes the Broker to go down
rather than go into ERROR state.
I have also checked the other COs and don't see other instances of this type of
problem.
was (Author: k-wall):
At the moment, the only thing that causes a VH to go into {{ERROR}} is a
failure to schedule the housekeeping task. This can only happen if the
housekeeping parameters are somehow misconfigured (for instance a negative
{{period}}). As you probably would not expect such parameters to be altered
in a production environment, I think the likelihood of a VH ending up in ERROR
to be small.If a VH were to somehow end up in ERROR, and an operator
attempt a restart, currently the Broker would fail if the {{onRestart}} route
were to be followed.
Note: failure to recover the messages currently causes the Broker to go down
rather than go into ERROR state.
I have also checked the other COs and don't see other instances of this type of
problem.
> AbstractVirtualHost defines two state transitions from ERROR to ACTIVE
> --
>
> Key: QPID-7560
> URL: https://issues.apache.org/jira/browse/QPID-7560
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.2, qpid-java-6.1.1, qpid-java-6.0.6
>
>
> The current implementation of AbstractVirtualHost defines two state
> transitions from ERROR=>ACTIVE. The state change mechanics could choose
> either which could lead to undesired results.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPIDJMS-229) allow supplying an SslContext instead of the configuration used to create one
[ https://issues.apache.org/jira/browse/QPIDJMS-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPIDJMS-229. Resolution: Fixed Assignee: Robbie Gemmell Fix Version/s: 0.20.0 > allow supplying an SslContext instead of the configuration used to create one > - > > Key: QPIDJMS-229 > URL: https://issues.apache.org/jira/browse/QPIDJMS-229 > Project: Qpid JMS > Issue Type: New Feature >Affects Versions: 0.11.1 >Reporter: Jason Chan >Assignee: Robbie Gemmell > Fix For: 0.20.0 > > > In reference to QPIDJMS-183, please add back the implementation of > setSslContext(). > The originating ticket which implemented this feature is: QPID-6400. The > main reason was to support the use of HSM > (https://en.wikipedia.org/wiki/Hardware_security_module) to hold the > keystores. This was implemented for 0.32. > In subsequent releases, this implementation was removed. > Here is an example of how to use HSM to access the keystore: > http://www.pixelstech.net/article/1420699130-Different-types-of-keystore-in-JavaPKCS11. > Once you have the keystore you you can initialize the SSLcontext and pass > that to the connection factory. As mentioned in QPID-6400, other vendors > provide this API as well. > If possible, please keep the API calls similar to the one in 0.32 as > discussed in QPID-6400. > Thank you! -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-229) allow supplying an SslContext instead of the configuration used to create one
[ https://issues.apache.org/jira/browse/QPIDJMS-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15751262#comment-15751262 ] ASF subversion and git services commented on QPIDJMS-229: - Commit 1f2f4aa6565ed465545c87eda3d09540f37afa15 in qpid-jms's branch refs/heads/master from Robert Gemmell [ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=1f2f4aa ] QPIDJMS-229: add ability to set an SSLContext via the ConnectionFactory This facilitates use of hardware security modules, and other cases where supplying path configuration via the URI options isn't suitable. > allow supplying an SslContext instead of the configuration used to create one > - > > Key: QPIDJMS-229 > URL: https://issues.apache.org/jira/browse/QPIDJMS-229 > Project: Qpid JMS > Issue Type: New Feature >Affects Versions: 0.11.1 >Reporter: Jason Chan > > In reference to QPIDJMS-183, please add back the implementation of > setSslContext(). > The originating ticket which implemented this feature is: QPID-6400. The > main reason was to support the use of HSM > (https://en.wikipedia.org/wiki/Hardware_security_module) to hold the > keystores. This was implemented for 0.32. > In subsequent releases, this implementation was removed. > Here is an example of how to use HSM to access the keystore: > http://www.pixelstech.net/article/1420699130-Different-types-of-keystore-in-JavaPKCS11. > Once you have the keystore you you can initialize the SSLcontext and pass > that to the connection factory. As mentioned in QPID-6400, other vendors > provide this API as well. > If possible, please keep the API calls similar to the one in 0.32 as > discussed in QPID-6400. > Thank you! -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-7560) AbstractVirtualHost defines two state transitions from ERROR to ACTIVE
[
https://issues.apache.org/jira/browse/QPID-7560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15751157#comment-15751157
]
Keith Wall edited comment on QPID-7560 at 12/15/16 12:17 PM:
-
At the moment, the only thing that causes a VH to go into {{ERROR}} is a
failure to schedule the housekeeping task. This can only happen if the
housekeeping parameters are somehow misconfigured (for instance a negative
{{period}}). As you probably would not expect such parameters to be altered
in a production environment, I think the likelihood of a VH ending up in ERROR
to be small.If a VH were to somehow end up in ERROR, and an operator
attempt a restart, currently the Broker would fail if the {{onRestart}} route
were to be followed.
Note: failure to recover the messages currently causes the Broker to go down
rather than go into ERROR state.
I have also checked the other COs and don't see other instances of this type of
problem.
was (Author: k-wall):
At the moment, the only thing that causes a VH to go into {{ERROR}} is a
failure to schedule the housekeeping task. This can only happen if the
housekeeping parameters are somehow misconfigured (for instance a negative
{{period}}). As you probably would not expect such parameters to be altered
in a production environment, I think the likelihood of a VH ending up in ERROR
to be small.If a VH were to somehow end up in ERROR, and an operator
attempt a restart, currently the Broker would fail if the {{onRestart}} route
were to be followed.
Note: failure to recover the messages currently causes the Broker to go down
rather than go into ERROR state.
> AbstractVirtualHost defines two state transitions from ERROR to ACTIVE
> --
>
> Key: QPID-7560
> URL: https://issues.apache.org/jira/browse/QPID-7560
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.2, qpid-java-6.1.1, qpid-java-6.0.6
>
>
> The current implementation of AbstractVirtualHost defines two state
> transitions from ERROR=>ACTIVE. The state change mechanics could choose
> either which could lead to undesired results.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7576) Metadata loaded twice for recovered message
[
https://issues.apache.org/jira/browse/QPID-7576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15751225#comment-15751225
]
Lorenz Quack commented on QPID-7576:
Here are some stacktraces (created in
{{v0_8.MessageMetaData#MessageMetaData(MessagePublishInfo, ContentHeaderBody,
long)}}, {{v0_8.MessageMetaData#dispose}}, and
{{v0_8.MessageMetaData#clearEncodedForm}}:
On broker recovery:
{code}
java.lang.RuntimeException
at
org.apache.qpid.server.protocol.v0_8.MessageMetaData.(MessageMetaData.java:66)
at
org.apache.qpid.server.protocol.v0_8.MessageMetaData$MetaDataFactory.createMetaData(MessageMetaData.java:172)
at
org.apache.qpid.server.protocol.v0_8.MessageMetaData$MetaDataFactory.createMetaData(MessageMetaData.java:150)
at
org.apache.qpid.server.protocol.v0_8.MessageMetaDataType_0_8.createMetaData(MessageMetaDataType_0_8.java:45)
at
org.apache.qpid.server.protocol.v0_8.MessageMetaDataType_0_8.createMetaData(MessageMetaDataType_0_8.java:29)
at
org.apache.qpid.server.store.AbstractJDBCMessageStore$JDBCMessageStoreReader.visitMessages(AbstractJDBCMessageStore.java:1761)
at
org.apache.qpid.server.virtualhost.SynchronousMessageStoreRecoverer.recover(SynchronousMessageStoreRecoverer.java:78)
at
org.apache.qpid.server.virtualhost.AbstractVirtualHost.postCreateDefaultExchangeTasks(AbstractVirtualHost.java:2526)
at
org.apache.qpid.server.virtualhost.AbstractVirtualHost.onActivate(AbstractVirtualHost.java:2509)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
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:1549)
at
org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1528)
at
org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:1102)
at
org.apache.qpid.server.model.AbstractConfiguredObject$8.onSuccess(AbstractConfiguredObject.java:1096)
at
org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2676)
at
org.apache.qpid.server.model.AbstractConfiguredObject$22$1.run(AbstractConfiguredObject.java:2672)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:356)
at
org.apache.qpid.server.model.AbstractConfiguredObject$22.onSuccess(AbstractConfiguredObject.java:2671)
at com.google.common.util.concurrent.Futures$6.run(Futures.java:1319)
at
org.apache.qpid.server.configuration.updater.TaskExecutorImpl$ImmediateIfSameThreadExecutor.execute(TaskExecutorImpl.java:392)
at
org.apache.qpid.server.configuration.updater.TaskExecutorImpl.execute(TaskExecutorImpl.java:175)
at
com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156)
at
com.google.common.util.concurrent.ExecutionList.add(ExecutionList.java:101)
at
com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:170)
at
com.google.common.util.concurrent.Futures.addCallback(Futures.java:1322)
at
org.apache.qpid.server.model.AbstractConfiguredObject.addFutureCallback(AbstractConfiguredObject.java:2666)
at
org.apache.qpid.server.model.AbstractConfiguredObject.doAttainState(AbstractConfiguredObject.java:1095)
at
org.apache.qpid.server.model.AbstractConfiguredObject.access$600(AbstractConfiguredObject.java:95)
at
org.apache.qpid.server.model.AbstractConfiguredObject$1.execute(AbstractConfiguredObject.java:619)
at
org.apache.qpid.server.model.AbstractConfiguredObject$1.execute(AbstractConfiguredObject.java:606)
at
org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:667)
at
org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:660)
at
org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:240)
at
org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper$1.run(TaskExecutorImpl.java:312)
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:305)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[jira] [Comment Edited] (QPID-7560) AbstractVirtualHost defines two state transitions from ERROR to ACTIVE
[
https://issues.apache.org/jira/browse/QPID-7560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15751157#comment-15751157
]
Keith Wall edited comment on QPID-7560 at 12/15/16 12:16 PM:
-
At the moment, the only thing that causes a VH to go into {{ERROR}} is a
failure to schedule the housekeeping task. This can only happen if the
housekeeping parameters are somehow misconfigured (for instance a negative
{{period}}). As you probably would not expect such parameters to be altered
in a production environment, I think the likelihood of a VH ending up in ERROR
to be small.If a VH were to somehow end up in ERROR, and an operator
attempt a restart, currently the Broker would fail if the {{onRestart}} route
were to be followed.
Note: failure to recover the messages currently causes the Broker to go down
rather than go into ERROR state.
was (Author: k-wall):
At the moment, the only thing that causes a VH to go into {{ERROR}} is a
failure to schedule the housekeeping task. This can only happen if the
housekeeping parameters are somehow misconfigured (for instance a negative
{{period}}). As you probably would not expect such parameters to be altered
in a production environment, I think the likelihood of a VH ending up in ERROR
to be small.If a VH were to somehow end up in ERROR, and an operator
attempt a restart, currently the Broker would fail if the {{onRestart}} route
were to fail.
Note: failure to recover the messages currently causes the Broker to go down
rather than go into ERROR state.
> AbstractVirtualHost defines two state transitions from ERROR to ACTIVE
> --
>
> Key: QPID-7560
> URL: https://issues.apache.org/jira/browse/QPID-7560
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.2, qpid-java-6.1.1, qpid-java-6.0.6
>
>
> The current implementation of AbstractVirtualHost defines two state
> transitions from ERROR=>ACTIVE. The state change mechanics could choose
> either which could lead to undesired results.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7560) AbstractVirtualHost defines two state transitions from ERROR to ACTIVE
[
https://issues.apache.org/jira/browse/QPID-7560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15751157#comment-15751157
]
Keith Wall commented on QPID-7560:
--
At the moment, the only thing that causes a VH to go into {{ERROR}} is a
failure to schedule the housekeeping task. This can only happen if the
housekeeping parameters are somehow misconfigured (for instance a negative
{{period}}). As you probably would not expect such parameters to be altered
in a production environment, I think the likelihood of a VH ending up in ERROR
to be small.If a VH were to somehow end up in ERROR, and an operator
attempt a restart, currently the Broker would fail if the {{onRestart}} route
were to fail.
Note: failure to recover the messages currently causes the Broker to go down
rather than go into ERROR state.
> AbstractVirtualHost defines two state transitions from ERROR to ACTIVE
> --
>
> Key: QPID-7560
> URL: https://issues.apache.org/jira/browse/QPID-7560
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-6.2, qpid-java-6.1.1, qpid-java-6.0.6
>
>
> The current implementation of AbstractVirtualHost defines two state
> transitions from ERROR=>ACTIVE. The state change mechanics could choose
> either which could lead to undesired results.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7560) AbstractVirtualHost defines two state transitions from ERROR to ACTIVE
[ https://issues.apache.org/jira/browse/QPID-7560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7560: - Description: The current implementation of AbstractVirtualHost defines two state transitions from ERROR=>ACTIVE. The state change mechanics could choose either which could lead to undesired results. (was: The current implementation of AbstractVirtualHost defines two state transitions from ERROR=>ACTIVE. The state change mechanics could choose either which could lead to undesired ) > AbstractVirtualHost defines two state transitions from ERROR to ACTIVE > -- > > Key: QPID-7560 > URL: https://issues.apache.org/jira/browse/QPID-7560 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-6.2, qpid-java-6.1.1, qpid-java-6.0.6 > > > The current implementation of AbstractVirtualHost defines two state > transitions from ERROR=>ACTIVE. The state change mechanics could choose > either which could lead to undesired results. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7546) [Java Broker] Allow the system tests to be run using the Qpid JMS client for AMQP 1.0 testing
[ https://issues.apache.org/jira/browse/QPID-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-7546: - Attachment: 0001-QPID-7546-Allow-overriding-of-jms-spec-artifact-in-o.patch Attached a patch with a potential improvement to build which allows to run system tests with new qpid-jms-client implementing jms2.0 spec as in example below mvn dependency:tree -f systests/pom.xml -Pjava-mms.1-0 -Dgeronimo-jms-spec-name=geronimo-jms_2.0_spec -Dgeronimo-jms-spec-version=1.0-alpha-2 -Dqpid-jms-client-version=0.20.0-SNAPSHOT > [Java Broker] Allow the system tests to be run using the Qpid JMS client for > AMQP 1.0 testing > - > > Key: QPID-7546 > URL: https://issues.apache.org/jira/browse/QPID-7546 > Project: Qpid > Issue Type: Test > Components: Java Tests >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Attachments: > 0001-QPID-7546-Allow-overriding-of-jms-spec-artifact-in-o.patch > > > Currently the system tests use the JMS client for AMQP 0-8/9/10 and so the > AMQP 1.0 protocol implementation does not get as thoroughly tested. > We should aim to move all the system tests such that they can be run with > either client -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-7546) [Java Broker] Allow the system tests to be run using the Qpid JMS client for AMQP 1.0 testing
[ https://issues.apache.org/jira/browse/QPID-7546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15751081#comment-15751081 ] Alex Rudyy edited comment on QPID-7546 at 12/15/16 11:03 AM: - Attached a patch with a potential improvement to build which allows to run system tests with new qpid-jms-client implementing jms2.0 spec as in example below mvn verify -f systests/pom.xml -Pjava-mms.1-0 -Dgeronimo-jms-spec-name=geronimo-jms_2.0_spec -Dgeronimo-jms-spec-version=1.0-alpha-2 -Dqpid-jms-client-version=0.20.0-SNAPSHOT was (Author: alex.rufous): Attached a patch with a potential improvement to build which allows to run system tests with new qpid-jms-client implementing jms2.0 spec as in example below mvn dependency:tree -f systests/pom.xml -Pjava-mms.1-0 -Dgeronimo-jms-spec-name=geronimo-jms_2.0_spec -Dgeronimo-jms-spec-version=1.0-alpha-2 -Dqpid-jms-client-version=0.20.0-SNAPSHOT > [Java Broker] Allow the system tests to be run using the Qpid JMS client for > AMQP 1.0 testing > - > > Key: QPID-7546 > URL: https://issues.apache.org/jira/browse/QPID-7546 > Project: Qpid > Issue Type: Test > Components: Java Tests >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Attachments: > 0001-QPID-7546-Allow-overriding-of-jms-spec-artifact-in-o.patch > > > Currently the system tests use the JMS client for AMQP 0-8/9/10 and so the > AMQP 1.0 protocol implementation does not get as thoroughly tested. > We should aim to move all the system tests such that they can be run with > either client -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7562) Ensure that HTTP threads always carry a ManagementConnectionPrincipal
[ https://issues.apache.org/jira/browse/QPID-7562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall resolved QPID-7562. -- Resolution: Fixed > Ensure that HTTP threads always carry a ManagementConnectionPrincipal > - > > Key: QPID-7562 > URL: https://issues.apache.org/jira/browse/QPID-7562 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-6.2 > > > QPID-7549 exposed a defect that HTTP threads are not always carrying a > Subject. > * We should ensure that HTTP threads always carry a Subject. If the user is > not yet authenticated, this will simple be a Subject containing a > ManagementConnectionPrincipal. If think this is best done once in a filter, > towards the front of the filter chain. The management thread, working on > behalf of the user must also ensure that the task executor subject is not > inherited,. > * Is there a reason why AuthenticationResultCacher should not consider all > SocketConnectionPrincipal rather than just ConnectionPrincipal. I realise > that if Qpid were to be behind a web proxy, then there would be not > uniqueness added (as the end point would be same), but the same argument > could be made about AMQP if it were using a AMQP proxy. > * I think the responsibilities for preemptive authentication and possibly > sasl authentication should be refactored into filters. I think the current > code is hard to follow (separate JIRA). > The simply fix for qpid-java-6.1.x will be carried out under QPID-7549. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7562) Ensure that HTTP threads always carry a ManagementConnectionPrincipal
[ https://issues.apache.org/jira/browse/QPID-7562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15750956#comment-15750956 ] Keith Wall commented on QPID-7562: -- Work was done under QPID-7549. > Ensure that HTTP threads always carry a ManagementConnectionPrincipal > - > > Key: QPID-7562 > URL: https://issues.apache.org/jira/browse/QPID-7562 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-6.2 > > > QPID-7549 exposed a defect that HTTP threads are not always carrying a > Subject. > * We should ensure that HTTP threads always carry a Subject. If the user is > not yet authenticated, this will simple be a Subject containing a > ManagementConnectionPrincipal. If think this is best done once in a filter, > towards the front of the filter chain. The management thread, working on > behalf of the user must also ensure that the task executor subject is not > inherited,. > * Is there a reason why AuthenticationResultCacher should not consider all > SocketConnectionPrincipal rather than just ConnectionPrincipal. I realise > that if Qpid were to be behind a web proxy, then there would be not > uniqueness added (as the end point would be same), but the same argument > could be made about AMQP if it were using a AMQP proxy. > * I think the responsibilities for preemptive authentication and possibly > sasl authentication should be refactored into filters. I think the current > code is hard to follow (separate JIRA). > The simply fix for qpid-java-6.1.x will be carried out under QPID-7549. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7576) Metadata loaded twice for recovered message
[ https://issues.apache.org/jira/browse/QPID-7576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15750947#comment-15750947 ] Keith Wall commented on QPID-7576: -- For consideration for qpid-java-6.1.1 > Metadata loaded twice for recovered message > --- > > Key: QPID-7576 > URL: https://issues.apache.org/jira/browse/QPID-7576 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.2 >Reporter: Keith Wall > Fix For: qpid-java-6.1.1 > > > For recovered messages (and possibly messages that have been flown to disk), > the metadata is evacuated from memory unnecessarily and then immediately > reloaded. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7576) Metadata loaded twice for recovered message
[ https://issues.apache.org/jira/browse/QPID-7576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-7576: - Fix Version/s: qpid-java-6.1.1 > Metadata loaded twice for recovered message > --- > > Key: QPID-7576 > URL: https://issues.apache.org/jira/browse/QPID-7576 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.2 >Reporter: Keith Wall > Fix For: qpid-java-6.1.1 > > > For recovered messages (and possibly messages that have been flown to disk), > the metadata is evacuated from memory unnecessarily and then immediately > reloaded. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
C++ windows broker heartbeat not work
hello! I use the c++ broker and C++ client 0.34, both running on windows. I set the heartbeat interval 30 seconds and not set reconnect options,after 60 seconds I found the fetch function throw TransportFailure exception. It seems to disconnected from broker. if the broker run on linux ,the heartbeat worked well. Is it any bugs running on windows ? Look forward to your reply ,thanks a lot! -- View this message in context: http://qpid.2158936.n2.nabble.com/C-windows-broker-heartbeat-not-work-tp7656442.html Sent from the Apache Qpid developers mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1375) Compile without warnings under clang 4.0
[ https://issues.apache.org/jira/browse/PROTON-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15750892#comment-15750892 ] Jiri Danek commented on PROTON-1375: I reported this to Clang Bugzilla and I was told that the warning is correct. I do not understand the intricacies of C++ well enough to judge. Here is the Bugzilla link, https://llvm.org/bugs/show_bug.cgi?id=31379. > Compile without warnings under clang 4.0 > > > Key: PROTON-1375 > URL: https://issues.apache.org/jira/browse/PROTON-1375 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.16.0 > Environment: Debian Jessie. Install latest clang 4.0 snapshot from > http://apt.llvm.org/. >Reporter: Jiri Danek >Assignee: Andrew Stitcher >Priority: Minor > Labels: patch > Fix For: 0.17.0 > > > A new warning in clang is causing proton-c compilation to fail. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (PROTON-1375) Compile without warnings under clang 4.0
[ https://issues.apache.org/jira/browse/PROTON-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiri Danek reopened PROTON-1375: > Compile without warnings under clang 4.0 > > > Key: PROTON-1375 > URL: https://issues.apache.org/jira/browse/PROTON-1375 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.16.0 > Environment: Debian Jessie. Install latest clang 4.0 snapshot from > http://apt.llvm.org/. >Reporter: Jiri Danek >Assignee: Andrew Stitcher >Priority: Minor > Labels: patch > Fix For: 0.17.0 > > > A new warning in clang is causing proton-c compilation to fail. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1375) Compile without warnings under clang 4.0
[ https://issues.apache.org/jira/browse/PROTON-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15750889#comment-15750889 ] Jiri Danek commented on PROTON-1375: I consider this sub-issue closed. Thanks for fixing. > Compile without warnings under clang 4.0 > > > Key: PROTON-1375 > URL: https://issues.apache.org/jira/browse/PROTON-1375 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.16.0 > Environment: Debian Jessie. Install latest clang 4.0 snapshot from > http://apt.llvm.org/. >Reporter: Jiri Danek >Assignee: Andrew Stitcher >Priority: Minor > Labels: patch > Fix For: 0.17.0 > > > A new warning in clang is causing proton-c compilation to fail. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-7590) Add documentation on how to provide a custom PasswordEncrypter
Adel Boutros created QPID-7590: -- Summary: Add documentation on how to provide a custom PasswordEncrypter Key: QPID-7590 URL: https://issues.apache.org/jira/browse/QPID-7590 Project: Qpid Issue Type: Improvement Components: Java Broker Affects Versions: qpid-java-6.0.4 Reporter: Adel Boutros Priority: Minor More information available on [the mailing list| http://qpid.2158936.n2.nabble.com/Qpid-Java-Broker-Providing-external-encryptor-for-configuration-tp7656183.html] -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
