[jira] [Created] (QPID-6950) [Java Broker]
Alex Rudyy created QPID-6950:
Summary: [Java Broker]
Key: QPID-6950
URL: https://issues.apache.org/jira/browse/QPID-6950
Project: Qpid
Issue Type: Bug
Components: Java Broker
Affects Versions: qpid-java-6.0
Reporter: Alex Rudyy
Starting embedded broker programmatically using
{code}
...
import org.apache.qpid.server.Broker;
import org.apache.qpid.server.BrokerOptions;
...
BrokerOptions options = new BrokerOptions();
...
Broker broker = new Broker();
broker.startup(options);
{code}
with http-managment plugin requires setting of Thread.UncaughtExceptionHandler.
Otherwise http management plugin throws an Exception on start-up about not set
UncaughtExceptionHandler
{noformat}
[WARNING]
java.lang.reflect.InvocationTargetException
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.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.qpid.server.util.ServerScopedRuntimeException: Failed to
start HTTP management on ports : [HttpPortImpl
[id=eebcd33d-a536-40ed-b696-24a50d04e419, name=HTTP, p
ort=8080]]
at
org.apache.qpid.server.management.plugin.HttpManagement.doStart(HttpManagement.java:155)
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:951)
at
org.apache.qpid.server.model.AbstractConfiguredObject.doAttainState(AbstractConfiguredObject.java:650)
at
org.apache.qpid.server.model.AbstractConfiguredObject.access$400(AbstractConfiguredObject.java:83)
at
org.apache.qpid.server.model.AbstractConfiguredObject$2.performAction(AbstractConfiguredObject.java:640)
at
org.apache.qpid.server.model.AbstractConfiguredObject$2.performAction(AbstractConfiguredObject.java:629)
at
org.apache.qpid.server.model.AbstractConfiguredObject.applyToChildren(AbstractConfiguredObject.java:777)
at
org.apache.qpid.server.model.AbstractConfiguredObject.doAttainState(AbstractConfiguredObject.java:628)
at
org.apache.qpid.server.model.AbstractConfiguredObject.open(AbstractConfiguredObject.java:464)
at
org.apache.qpid.server.model.AbstractSystemConfig.activate(AbstractSystemConfig.java:238)
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:951)
at
org.apache.qpid.server.model.AbstractConfiguredObject.doAttainState(AbstractConfiguredObject.java:650)
at
org.apache.qpid.server.model.AbstractConfiguredObject.open(AbstractConfiguredObject.java:464)
at org.apache.qpid.server.Broker.startupImpl(Broker.java:199)
at org.apache.qpid.server.Broker.access$000(Broker.java:57)
at org.apache.qpid.server.Broker$1.run(Broker.java:143)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:415)
at org.apache.qpid.server.Broker.startup(Broker.java:138)
at
com.jpmorgan.qpid.mavenexample.BrokerAndClientRunner.main(BrokerAndClientRunner.java:95)
... 6 more
Caused by: java.lang.IllegalStateException: no uncaught exception handler set
at
org.apache.qpid.server.management.plugin.filter.ExceptionHandlingFilter.init(ExceptionHandlingFilter.java:49)
at org.eclipse.jetty.servlet.FilterHolder.doStart(FilterHolder.java:118)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at
org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:768)
at
org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:265)
at
org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:717)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at
org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:95)
at org.eclipse.jetty.serve
[jira] [Updated] (QPID-6950) [Java Broker]
[
https://issues.apache.org/jira/browse/QPID-6950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-6950:
-
Summary: [Java Broker] (was: [Java Broker])
> [Java Broker]
> --
>
> Key: QPID-6950
> URL: https://issues.apache.org/jira/browse/QPID-6950
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.0
>Reporter: Alex Rudyy
>
> Starting embedded broker programmatically using
> {code}
> ...
> import org.apache.qpid.server.Broker;
> import org.apache.qpid.server.BrokerOptions;
>
> ...
> BrokerOptions options = new BrokerOptions();
> ...
> Broker broker = new Broker();
> broker.startup(options);
> {code}
> with http-managment plugin requires setting of
> Thread.UncaughtExceptionHandler.
> Otherwise http management plugin throws an Exception on start-up about not
> set UncaughtExceptionHandler
> {noformat}
> [WARNING]
> java.lang.reflect.InvocationTargetException
> 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.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.qpid.server.util.ServerScopedRuntimeException: Failed
> to start HTTP management on ports : [HttpPortImpl
> [id=eebcd33d-a536-40ed-b696-24a50d04e419, name=HTTP, p
> ort=8080]]
> at
> org.apache.qpid.server.management.plugin.HttpManagement.doStart(HttpManagement.java:155)
> 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:951)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doAttainState(AbstractConfiguredObject.java:650)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.access$400(AbstractConfiguredObject.java:83)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.performAction(AbstractConfiguredObject.java:640)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.performAction(AbstractConfiguredObject.java:629)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.applyToChildren(AbstractConfiguredObject.java:777)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doAttainState(AbstractConfiguredObject.java:628)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.open(AbstractConfiguredObject.java:464)
> at
> org.apache.qpid.server.model.AbstractSystemConfig.activate(AbstractSystemConfig.java:238)
> 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:951)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doAttainState(AbstractConfiguredObject.java:650)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.open(AbstractConfiguredObject.java:464)
> at org.apache.qpid.server.Broker.startupImpl(Broker.java:199)
> at org.apache.qpid.server.Broker.access$000(Broker.java:57)
> at org.apache.qpid.server.Broker$1.run(Broker.java:143)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at org.apache.qpid.server.Broker.startup(Broker.java:138)
> at
> com.jpmorgan.qpid.mavenexample.BrokerAndClientRunner.main(BrokerAndClientRunner.java:95)
> ... 6 more
> Caused by: java.lang.IllegalStateException: no uncaught exception handler set
> at
> org.apache.qpid.server.management.plugin.filter.ExceptionHandlingFilter.init(ExceptionHandlingFilter.java:49)
> at
> org.eclipse.jetty.servlet.FilterHolder.doStart(FilterHolder.java:118)
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
> at
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:768)
> at
> org.eclipse.jetty.servlet.ServletContextHandler
[jira] [Updated] (QPID-6950) [Java Broker] Starting embedded broker programmatically with Broker#startup(BrokerOptions) with Http-Management plugin requires Thread.UncaughtExceptionHandler to be set
[
https://issues.apache.org/jira/browse/QPID-6950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-6950:
-
Summary: [Java Broker] Starting embedded broker programmatically with
Broker#startup(BrokerOptions) with Http-Management plugin requires
Thread.UncaughtExceptionHandler to be set (was: [Java Broker] )
> [Java Broker] Starting embedded broker programmatically with
> Broker#startup(BrokerOptions) with Http-Management plugin requires
> Thread.UncaughtExceptionHandler to be set
> -
>
> Key: QPID-6950
> URL: https://issues.apache.org/jira/browse/QPID-6950
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.0
>Reporter: Alex Rudyy
>
> Starting embedded broker programmatically using
> {code}
> ...
> import org.apache.qpid.server.Broker;
> import org.apache.qpid.server.BrokerOptions;
>
> ...
> BrokerOptions options = new BrokerOptions();
> ...
> Broker broker = new Broker();
> broker.startup(options);
> {code}
> with http-managment plugin requires setting of
> Thread.UncaughtExceptionHandler.
> Otherwise http management plugin throws an Exception on start-up about not
> set UncaughtExceptionHandler
> {noformat}
> [WARNING]
> java.lang.reflect.InvocationTargetException
> 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.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.qpid.server.util.ServerScopedRuntimeException: Failed
> to start HTTP management on ports : [HttpPortImpl
> [id=eebcd33d-a536-40ed-b696-24a50d04e419, name=HTTP, p
> ort=8080]]
> at
> org.apache.qpid.server.management.plugin.HttpManagement.doStart(HttpManagement.java:155)
> 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:951)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doAttainState(AbstractConfiguredObject.java:650)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.access$400(AbstractConfiguredObject.java:83)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.performAction(AbstractConfiguredObject.java:640)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.performAction(AbstractConfiguredObject.java:629)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.applyToChildren(AbstractConfiguredObject.java:777)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doAttainState(AbstractConfiguredObject.java:628)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.open(AbstractConfiguredObject.java:464)
> at
> org.apache.qpid.server.model.AbstractSystemConfig.activate(AbstractSystemConfig.java:238)
> 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:951)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doAttainState(AbstractConfiguredObject.java:650)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.open(AbstractConfiguredObject.java:464)
> at org.apache.qpid.server.Broker.startupImpl(Broker.java:199)
> at org.apache.qpid.server.Broker.access$000(Broker.java:57)
> at org.apache.qpid.server.Broker$1.run(Broker.java:143)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at org.apache.qpid.server.Broker.startup(Broker.java:138)
> at
> com.jpmorgan.qpid.mavenexample.BrokerAndClientRunner.main(BrokerAndClientRunner.java:95)
> ... 6 more
> Caused by: java.lang.IllegalStateException: no uncaught exception handle
[jira] [Created] (QPID-6951) [Java Client] AMQSession.deregisterConsumer() leaks Memory
Lorenz Quack created QPID-6951:
--
Summary: [Java Client] AMQSession.deregisterConsumer() leaks Memory
Key: QPID-6951
URL: https://issues.apache.org/jira/browse/QPID-6951
Project: Qpid
Issue Type: Bug
Components: Java Client
Affects Versions: qpid-java-6.0, 0.32
Reporter: Lorenz Quack
{{AMQSession.deregisterConsumer()}} contains the following code:
{code}
if (_transacted)
{
_removedConsumers.add(consumer);
}
{code}
However, the {{_removedConsumers}} list is only cleaned up on rollback and
nowhere else.
--
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-6950) [Java Broker] Starting embedded broker with http-management plugin using Broker#startup(BrokerOptions) requires Thread.UncaughtExceptionHandler to be set
[
https://issues.apache.org/jira/browse/QPID-6950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-6950:
-
Summary: [Java Broker] Starting embedded broker with http-management plugin
using Broker#startup(BrokerOptions) requires Thread.UncaughtExceptionHandler
to be set (was: [Java Broker] Starting embedded broker programmatically with
Broker#startup(BrokerOptions) with Http-Management plugin requires
Thread.UncaughtExceptionHandler to be set)
> [Java Broker] Starting embedded broker with http-management plugin using
> Broker#startup(BrokerOptions) requires Thread.UncaughtExceptionHandler to be
> set
> --
>
> Key: QPID-6950
> URL: https://issues.apache.org/jira/browse/QPID-6950
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.0
>Reporter: Alex Rudyy
>
> Starting embedded broker programmatically using
> {code}
> ...
> import org.apache.qpid.server.Broker;
> import org.apache.qpid.server.BrokerOptions;
>
> ...
> BrokerOptions options = new BrokerOptions();
> ...
> Broker broker = new Broker();
> broker.startup(options);
> {code}
> with http-managment plugin requires setting of
> Thread.UncaughtExceptionHandler.
> Otherwise http management plugin throws an Exception on start-up about not
> set UncaughtExceptionHandler
> {noformat}
> [WARNING]
> java.lang.reflect.InvocationTargetException
> 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.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.qpid.server.util.ServerScopedRuntimeException: Failed
> to start HTTP management on ports : [HttpPortImpl
> [id=eebcd33d-a536-40ed-b696-24a50d04e419, name=HTTP, p
> ort=8080]]
> at
> org.apache.qpid.server.management.plugin.HttpManagement.doStart(HttpManagement.java:155)
> 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:951)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doAttainState(AbstractConfiguredObject.java:650)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.access$400(AbstractConfiguredObject.java:83)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.performAction(AbstractConfiguredObject.java:640)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.performAction(AbstractConfiguredObject.java:629)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.applyToChildren(AbstractConfiguredObject.java:777)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doAttainState(AbstractConfiguredObject.java:628)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.open(AbstractConfiguredObject.java:464)
> at
> org.apache.qpid.server.model.AbstractSystemConfig.activate(AbstractSystemConfig.java:238)
> 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:951)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.doAttainState(AbstractConfiguredObject.java:650)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.open(AbstractConfiguredObject.java:464)
> at org.apache.qpid.server.Broker.startupImpl(Broker.java:199)
> at org.apache.qpid.server.Broker.access$000(Broker.java:57)
> at org.apache.qpid.server.Broker$1.run(Broker.java:143)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at org.apache.qpid.server.Broker.startup(Broker.java:138)
> at
> com.jpmorgan.qpid.mavenexample.BrokerAndClientRunner.main(BrokerAndClien
[jira] [Updated] (QPID-6950) [Java Broker] Starting embedded broker with http-management plugin using Broker#startup(BrokerOptions) requires Thread.UncaughtExceptionHandler to be set
[
https://issues.apache.org/jira/browse/QPID-6950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Rudyy updated QPID-6950:
-
Description:
Starting embedded broker programmatically using
{code}
...
import org.apache.qpid.server.Broker;
import org.apache.qpid.server.BrokerOptions;
...
BrokerOptions options = new BrokerOptions();
...
Broker broker = new Broker();
broker.startup(options);
{code}
with http-managment plugin requires setting of Thread.UncaughtExceptionHandler.
Otherwise http management plugin throws an Exception on start-up about not set
UncaughtExceptionHandler
{noformat}
Caused by: org.apache.qpid.server.util.ServerScopedRuntimeException: Failed to
start HTTP management on ports : [HttpPortImpl
[id=eebcd33d-a536-40ed-b696-24a50d04e419, name=HTTP, p
ort=8080]]
at
org.apache.qpid.server.management.plugin.HttpManagement.doStart(HttpManagement.java:155)
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:951)
at
org.apache.qpid.server.model.AbstractConfiguredObject.doAttainState(AbstractConfiguredObject.java:650)
at
org.apache.qpid.server.model.AbstractConfiguredObject.access$400(AbstractConfiguredObject.java:83)
at
org.apache.qpid.server.model.AbstractConfiguredObject$2.performAction(AbstractConfiguredObject.java:640)
at
org.apache.qpid.server.model.AbstractConfiguredObject$2.performAction(AbstractConfiguredObject.java:629)
at
org.apache.qpid.server.model.AbstractConfiguredObject.applyToChildren(AbstractConfiguredObject.java:777)
at
org.apache.qpid.server.model.AbstractConfiguredObject.doAttainState(AbstractConfiguredObject.java:628)
at
org.apache.qpid.server.model.AbstractConfiguredObject.open(AbstractConfiguredObject.java:464)
at
org.apache.qpid.server.model.AbstractSystemConfig.activate(AbstractSystemConfig.java:238)
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:951)
at
org.apache.qpid.server.model.AbstractConfiguredObject.doAttainState(AbstractConfiguredObject.java:650)
at
org.apache.qpid.server.model.AbstractConfiguredObject.open(AbstractConfiguredObject.java:464)
at org.apache.qpid.server.Broker.startupImpl(Broker.java:199)
at org.apache.qpid.server.Broker.access$000(Broker.java:57)
at org.apache.qpid.server.Broker$1.run(Broker.java:143)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:415)
at org.apache.qpid.server.Broker.startup(Broker.java:138)
at
com.jpmorgan.qpid.mavenexample.BrokerAndClientRunner.main(BrokerAndClientRunner.java:95)
... 6 more
Caused by: java.lang.IllegalStateException: no uncaught exception handler set
at
org.apache.qpid.server.management.plugin.filter.ExceptionHandlingFilter.init(ExceptionHandlingFilter.java:49)
at org.eclipse.jetty.servlet.FilterHolder.doStart(FilterHolder.java:118)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at
org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:768)
at
org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:265)
at
org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:717)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at
org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:95)
at org.eclipse.jetty.server.Server.doStart(Server.java:282)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at
org.apache.qpid.server.management.plugin.HttpManagement.doStart(HttpManagement.java:150)
... 33 more
{noformat}
was:
Starting embedded broker programmatically using
{code}
...
import org.apache.qpid.server.Broker;
import org.apache.qpid.server.BrokerOptions;
...
BrokerOptions options = new BrokerOptions();
...
Broker broker = new Broker();
broker.startup(options);
{code}
with http-managment plugin requires setting of Thread.UncaughtExceptionHandler.
Otherwise http management plugin throws an E
[jira] [Created] (QPID-6952) [AMQP 1.0 C++ and Python Client] Temporary queues broken if using queue name instead of Address.
Håkan Johansson created QPID-6952:
-
Summary: [AMQP 1.0 C++ and Python Client] Temporary queues broken
if using queue name instead of Address.
Key: QPID-6952
URL: https://issues.apache.org/jira/browse/QPID-6952
Project: Qpid
Issue Type: Bug
Environment: Red Hat Enterprise Linux Server release 6.7 (Santiago)
The _qpid-cpp_ code has been built with _qpid-proton_ version 0.10.
The broker is ActiveMQ 5.12.1.
The protocol used in AMQP 1.0.
Reporter: Håkan Johansson
I create a temporary queue by creating a receiver with {{"#"}} as queue name.
So far so good. The problem comes when I try to send a reply on that queue. If
I use the {{Address}}, then it works, but not if I use the resulting queue name.
In C++ this is easy to work around, just use the result from
{{receiver.getAddress()}} when setting the reply-to queue and use the sender
constructor that takes an {{Address}} object.
In Python this becomes a bit of a problem since the SWIG:ed methods gets rid of
the {{Address}} object and returns a string instead. I have to call the private
method {{message._getReplyTo()}} to get it to work. If I use
{{message.reply_to}} or {{message.getReplyTo()}} I get a string instead, which
does not work.
--
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-6952) [AMQP 1.0 C++ and Python Client] Temporary queues broken if using queue name instead of Address.
[
https://issues.apache.org/jira/browse/QPID-6952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Håkan Johansson updated QPID-6952:
--
Attachment: experiment.py
cpp_experiment.cc
> [AMQP 1.0 C++ and Python Client] Temporary queues broken if using queue name
> instead of Address.
>
>
> Key: QPID-6952
> URL: https://issues.apache.org/jira/browse/QPID-6952
> Project: Qpid
> Issue Type: Bug
> Environment: Red Hat Enterprise Linux Server release 6.7 (Santiago)
> The _qpid-cpp_ code has been built with _qpid-proton_ version 0.10.
> The broker is ActiveMQ 5.12.1.
> The protocol used in AMQP 1.0.
>Reporter: Håkan Johansson
> Attachments: cpp_experiment.cc, experiment.py
>
>
> I create a temporary queue by creating a receiver with {{"#"}} as queue name.
> So far so good. The problem comes when I try to send a reply on that queue.
> If I use the {{Address}}, then it works, but not if I use the resulting queue
> name.
> In C++ this is easy to work around, just use the result from
> {{receiver.getAddress()}} when setting the reply-to queue and use the sender
> constructor that takes an {{Address}} object.
> In Python this becomes a bit of a problem since the SWIG:ed methods gets rid
> of the {{Address}} object and returns a string instead. I have to call the
> private method {{message._getReplyTo()}} to get it to work. If I use
> {{message.reply_to}} or {{message.getReplyTo()}} I get a string instead,
> which does not work.
--
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-6952) [AMQP 1.0 C++ and Python Client] Temporary queues broken if using queue name instead of Address.
[
https://issues.apache.org/jira/browse/QPID-6952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Håkan Johansson updated QPID-6952:
--
Description:
I create a temporary queue by creating a receiver with {{"#"}} as queue name.
So far so good. The problem comes when I try to send a reply on that queue. If
I use the {{Address}}, then it works, but not if I use the resulting queue name.
In C++ this is easy to work around, just use the result from
{{receiver.getAddress()}} when setting the reply-to queue and use the sender
constructor that takes an {{Address}} object.
In Python this becomes a bit of a problem since the SWIG:ed methods gets rid of
the {{Address}} object and returns a string instead. I have to call the private
method {{message._getReplyTo()}} to get it to work. If I use
{{message.reply_to}} or {{message.getReplyTo()}} I get a string instead, which
does not work.
If I use the reply-to queue name when creating the sender, a queue named
{{"temp-queue:"}} is created (the actual queue name is something like
{{"temp-queue://ID:myhostname-48781-1447769813910-2:47564:0"}}).
was:
I create a temporary queue by creating a receiver with {{"#"}} as queue name.
So far so good. The problem comes when I try to send a reply on that queue. If
I use the {{Address}}, then it works, but not if I use the resulting queue name.
In C++ this is easy to work around, just use the result from
{{receiver.getAddress()}} when setting the reply-to queue and use the sender
constructor that takes an {{Address}} object.
In Python this becomes a bit of a problem since the SWIG:ed methods gets rid of
the {{Address}} object and returns a string instead. I have to call the private
method {{message._getReplyTo()}} to get it to work. If I use
{{message.reply_to}} or {{message.getReplyTo()}} I get a string instead, which
does not work.
> [AMQP 1.0 C++ and Python Client] Temporary queues broken if using queue name
> instead of Address.
>
>
> Key: QPID-6952
> URL: https://issues.apache.org/jira/browse/QPID-6952
> Project: Qpid
> Issue Type: Bug
> Environment: Red Hat Enterprise Linux Server release 6.7 (Santiago)
> The _qpid-cpp_ code has been built with _qpid-proton_ version 0.10.
> The broker is ActiveMQ 5.12.1.
> The protocol used in AMQP 1.0.
>Reporter: Håkan Johansson
> Attachments: cpp_experiment.cc, experiment.py
>
>
> I create a temporary queue by creating a receiver with {{"#"}} as queue name.
> So far so good. The problem comes when I try to send a reply on that queue.
> If I use the {{Address}}, then it works, but not if I use the resulting queue
> name.
> In C++ this is easy to work around, just use the result from
> {{receiver.getAddress()}} when setting the reply-to queue and use the sender
> constructor that takes an {{Address}} object.
> In Python this becomes a bit of a problem since the SWIG:ed methods gets rid
> of the {{Address}} object and returns a string instead. I have to call the
> private method {{message._getReplyTo()}} to get it to work. If I use
> {{message.reply_to}} or {{message.getReplyTo()}} I get a string instead,
> which does not work.
> If I use the reply-to queue name when creating the sender, a queue named
> {{"temp-queue:"}} is created (the actual queue name is something like
> {{"temp-queue://ID:myhostname-48781-1447769813910-2:47564:0"}}).
--
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-6952) [AMQP 1.0 C++ and Python Client] Temporary queues broken if using queue name instead of Address.
[
https://issues.apache.org/jira/browse/QPID-6952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15057838#comment-15057838
]
Håkan Johansson commented on QPID-6952:
---
After doing some experiments I now believe that the error lies in the
{{Address}} class.
Example code (C++)
{code}
Address addr1;
addr1.setName("temp-queue://ID:myhost-48781-1447769813910-2:47564:0");
std::cout << "addr1.name:" << addr1.getName() << std::endl;
std::cout << "addr1.subject: " << addr1.getSubject() << std::endl;
Address addr2(addr1.str());
std::cout << "addr2.name:" << addr2.getName() << std::endl;
std::cout << "addr2.subject: " << addr2.getSubject() << std::endl;
{code}
Output:
{noformat}
addr1.name:temp-queue://ID:myhost-48781-1447769813910-2:47564:0
addr1.subject:
addr2.name:temp-queue:
addr2.subject: /ID:myhost-48781-1447769813910-2:47564:0
{noformat}
> [AMQP 1.0 C++ and Python Client] Temporary queues broken if using queue name
> instead of Address.
>
>
> Key: QPID-6952
> URL: https://issues.apache.org/jira/browse/QPID-6952
> Project: Qpid
> Issue Type: Bug
> Environment: Red Hat Enterprise Linux Server release 6.7 (Santiago)
> The _qpid-cpp_ code has been built with _qpid-proton_ version 0.10.
> The broker is ActiveMQ 5.12.1.
> The protocol used in AMQP 1.0.
>Reporter: Håkan Johansson
> Attachments: cpp_experiment.cc, experiment.py
>
>
> I create a temporary queue by creating a receiver with {{"#"}} as queue name.
> So far so good. The problem comes when I try to send a reply on that queue.
> If I use the {{Address}}, then it works, but not if I use the resulting queue
> name.
> In C++ this is easy to work around, just use the result from
> {{receiver.getAddress()}} when setting the reply-to queue and use the sender
> constructor that takes an {{Address}} object.
> In Python this becomes a bit of a problem since the SWIG:ed methods gets rid
> of the {{Address}} object and returns a string instead. I have to call the
> private method {{message._getReplyTo()}} to get it to work. If I use
> {{message.reply_to}} or {{message.getReplyTo()}} I get a string instead,
> which does not work.
> If I use the reply-to queue name when creating the sender, a queue named
> {{"temp-queue:"}} is created (the actual queue name is something like
> {{"temp-queue://ID:myhostname-48781-1447769813910-2:47564:0"}}).
--
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-6952) [AMQP 1.0 C++ and Python Client] Temporary queues broken if using queue name instead of Address.
[
https://issues.apache.org/jira/browse/QPID-6952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15057838#comment-15057838
]
Håkan Johansson edited comment on QPID-6952 at 12/15/15 10:50 AM:
--
After doing some experiments I now believe that the error lies in the
{{Address}} class.
Example code (C++)
{code}
Address addr1;
addr1.setName("temp-queue://ID:myhost-48781-1447769813910-2:47564:0");
std::cout << "addr1.name:" << addr1.getName() << std::endl;
std::cout << "addr1.subject: " << addr1.getSubject() << std::endl;
Address addr2(addr1.str());
std::cout << "addr2.name:" << addr2.getName() << std::endl;
std::cout << "addr2.subject: " << addr2.getSubject() << std::endl;
{code}
Output:
{noformat}
addr1.name:temp-queue://ID:myhost-48781-1447769813910-2:47564:0
addr1.subject:
addr2.name:temp-queue:
addr2.subject: /ID:myhost-48781-1447769813910-2:47564:0
{noformat}
The address I get from {{message.getReplyTo()}} looks like {{addr1}}.
was (Author: hakanj):
After doing some experiments I now believe that the error lies in the
{{Address}} class.
Example code (C++)
{code}
Address addr1;
addr1.setName("temp-queue://ID:myhost-48781-1447769813910-2:47564:0");
std::cout << "addr1.name:" << addr1.getName() << std::endl;
std::cout << "addr1.subject: " << addr1.getSubject() << std::endl;
Address addr2(addr1.str());
std::cout << "addr2.name:" << addr2.getName() << std::endl;
std::cout << "addr2.subject: " << addr2.getSubject() << std::endl;
{code}
Output:
{noformat}
addr1.name:temp-queue://ID:myhost-48781-1447769813910-2:47564:0
addr1.subject:
addr2.name:temp-queue:
addr2.subject: /ID:myhost-48781-1447769813910-2:47564:0
{noformat}
> [AMQP 1.0 C++ and Python Client] Temporary queues broken if using queue name
> instead of Address.
>
>
> Key: QPID-6952
> URL: https://issues.apache.org/jira/browse/QPID-6952
> Project: Qpid
> Issue Type: Bug
> Environment: Red Hat Enterprise Linux Server release 6.7 (Santiago)
> The _qpid-cpp_ code has been built with _qpid-proton_ version 0.10.
> The broker is ActiveMQ 5.12.1.
> The protocol used in AMQP 1.0.
>Reporter: Håkan Johansson
> Attachments: cpp_experiment.cc, experiment.py
>
>
> I create a temporary queue by creating a receiver with {{"#"}} as queue name.
> So far so good. The problem comes when I try to send a reply on that queue.
> If I use the {{Address}}, then it works, but not if I use the resulting queue
> name.
> In C++ this is easy to work around, just use the result from
> {{receiver.getAddress()}} when setting the reply-to queue and use the sender
> constructor that takes an {{Address}} object.
> In Python this becomes a bit of a problem since the SWIG:ed methods gets rid
> of the {{Address}} object and returns a string instead. I have to call the
> private method {{message._getReplyTo()}} to get it to work. If I use
> {{message.reply_to}} or {{message.getReplyTo()}} I get a string instead,
> which does not work.
> If I use the reply-to queue name when creating the sender, a queue named
> {{"temp-queue:"}} is created (the actual queue name is something like
> {{"temp-queue://ID:myhostname-48781-1447769813910-2:47564:0"}}).
--
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-6852) Allow perftests to be conveniently run against Qpid JMS AMQP 1.0 client
[ https://issues.apache.org/jira/browse/QPID-6852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15057915#comment-15057915 ] ASF subversion and git services commented on QPID-6852: --- Commit 1720121 from [~k-wall] in branch 'java/trunk' [ https://svn.apache.org/r1720121 ] QPID-6852: Allow perftests to be conveniently run against AMQP 1.0 client > Allow perftests to be conveniently run against Qpid JMS AMQP 1.0 client > --- > > Key: QPID-6852 > URL: https://issues.apache.org/jira/browse/QPID-6852 > Project: Qpid > Issue Type: Improvement > Components: Java Performance Tests >Reporter: Keith Wall >Assignee: Keith Wall > Attachments: > 0001-QPID-6852-Allow-perftests-to-be-run-against-AMQP-1.0.patch > > > Allow perftests to be run against Qpid JMS AMQP 1.0 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-6944) SelectorThread causing livelock
[
https://issues.apache.org/jira/browse/QPID-6944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15057978#comment-15057978
]
Keith Wall commented on QPID-6944:
--
Hi Mark
Glad to hear the lock wasn't a Java Broker issue. Could you update the jira
title to capture the remaining issue precisely?
I've done some testing this morning hoping to reproduce your issue. No luck so
far. I don't see CPU spiking to 100% during long running cycles of
publication/consuming.
Could you let me know:
# Which Qpid client you use? which version? I think you use
{{o.a.q:qpid-amqp-1-0-client-jms}} rather than {{o.a.q:qpid-jms-client}}, but
want to be sure.
# What is the approximate JMS message size and persistence setting? Are
transactions in use?
# What heap size and direct memory size are in use? (BRK-1011 report both on
startup)
If you have a small JMS program that reproduces the issue, that would be very
useful.
Also, it might also be informative to turn up logging level for org.apache.qpid
to DEBUG whilst the issue manifest. See attached screenshot.
> SelectorThread causing livelock
> ---
>
> Key: QPID-6944
> URL: https://issues.apache.org/jira/browse/QPID-6944
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.0
> Environment: Red Hat Enterprise Linux Server release 6.7 (Santiago)
> OpenJDK Runtime Environment (build 1.8.0_65-b17)
> OpenJDK 64-Bit Server VM (build 25.65-b01, mixed mode)
>Reporter: Mark Soderquist
> Attachments: qpid.0.32.png, qpid.6.0.png, qpid.cpu.png, qpid.cpu.png,
> threaddump-1449856663270.tdump
>
>
> The org.apache.qpid.server.transport.SelectorThread is causing live lock.
> While the application still functions it causes the CPU to run at nearly
> 100%. See attached thread dump.
--
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-6944) SelectorThread causing livelock
[ https://issues.apache.org/jira/browse/QPID-6944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-6944: - Attachment: enabledebug.png > SelectorThread causing livelock > --- > > Key: QPID-6944 > URL: https://issues.apache.org/jira/browse/QPID-6944 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.0 > Environment: Red Hat Enterprise Linux Server release 6.7 (Santiago) > OpenJDK Runtime Environment (build 1.8.0_65-b17) > OpenJDK 64-Bit Server VM (build 25.65-b01, mixed mode) >Reporter: Mark Soderquist > Attachments: enabledebug.png, qpid.0.32.png, qpid.6.0.png, > qpid.cpu.png, qpid.cpu.png, threaddump-1449856663270.tdump > > > The org.apache.qpid.server.transport.SelectorThread is causing live lock. > While the application still functions it causes the CPU to run at nearly > 100%. See attached thread dump. -- 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-6944) SelectorThread causing livelock
[
https://issues.apache.org/jira/browse/QPID-6944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15057978#comment-15057978
]
Keith Wall edited comment on QPID-6944 at 12/15/15 12:31 PM:
-
Hi Mark
Glad to hear the lock wasn't a Java Broker issue. Could you update the jira
title to capture the remaining issue precisely?
I've done some testing this morning hoping to reproduce your issue. No luck so
far. I don't see CPU spiking to 100% during long running cycles of
publication/consuming.
Could you let me know:
# Which Qpid client you use? which version? I think you use
{{o.a.q:qpid-amqp-1-0-client-jms}} rather than {{o.a.q:qpid-jms-client}}, but
want to be sure.
# What is the approximate JMS message size and persistence setting? Are
transactions in use?
# What heap size and direct memory size are in use? (BRK-1011 report both on
startup)
If you have a small JMS program that reproduces the issue, that would be very
useful.
Also, it might also be informative to turn up logging level for org.apache.qpid
to DEBUG whilst the issue manifests. See attached screenshot. You can do this
at runtime without restarting the Broker.
was (Author: k-wall):
Hi Mark
Glad to hear the lock wasn't a Java Broker issue. Could you update the jira
title to capture the remaining issue precisely?
I've done some testing this morning hoping to reproduce your issue. No luck so
far. I don't see CPU spiking to 100% during long running cycles of
publication/consuming.
Could you let me know:
# Which Qpid client you use? which version? I think you use
{{o.a.q:qpid-amqp-1-0-client-jms}} rather than {{o.a.q:qpid-jms-client}}, but
want to be sure.
# What is the approximate JMS message size and persistence setting? Are
transactions in use?
# What heap size and direct memory size are in use? (BRK-1011 report both on
startup)
If you have a small JMS program that reproduces the issue, that would be very
useful.
Also, it might also be informative to turn up logging level for org.apache.qpid
to DEBUG whilst the issue manifest. See attached screenshot.
> SelectorThread causing livelock
> ---
>
> Key: QPID-6944
> URL: https://issues.apache.org/jira/browse/QPID-6944
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.0
> Environment: Red Hat Enterprise Linux Server release 6.7 (Santiago)
> OpenJDK Runtime Environment (build 1.8.0_65-b17)
> OpenJDK 64-Bit Server VM (build 25.65-b01, mixed mode)
>Reporter: Mark Soderquist
> Attachments: enabledebug.png, qpid.0.32.png, qpid.6.0.png,
> qpid.cpu.png, qpid.cpu.png, threaddump-1449856663270.tdump
>
>
> The org.apache.qpid.server.transport.SelectorThread is causing live lock.
> While the application still functions it causes the CPU to run at nearly
> 100%. See attached thread dump.
--
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-6944) High CPU use sending message
[ https://issues.apache.org/jira/browse/QPID-6944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Soderquist updated QPID-6944: -- Summary: High CPU use sending message (was: SelectorThread causing livelock) > High CPU use sending message > > > Key: QPID-6944 > URL: https://issues.apache.org/jira/browse/QPID-6944 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.0 > Environment: Red Hat Enterprise Linux Server release 6.7 (Santiago) > OpenJDK Runtime Environment (build 1.8.0_65-b17) > OpenJDK 64-Bit Server VM (build 25.65-b01, mixed mode) >Reporter: Mark Soderquist > Attachments: enabledebug.png, qpid.0.32.png, qpid.6.0.png, > qpid.cpu.png, qpid.cpu.png, threaddump-1449856663270.tdump > > > The org.apache.qpid.server.transport.SelectorThread is causing live lock. > While the application still functions it causes the CPU to run at nearly > 100%. See attached thread dump. -- 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-6953) [Java Broker] Refactor AMQP 0-8/9/9-1 implementation to always use QpidByteBuffer for encoding output
Rob Godfrey created QPID-6953: - Summary: [Java Broker] Refactor AMQP 0-8/9/9-1 implementation to always use QpidByteBuffer for encoding output Key: QPID-6953 URL: https://issues.apache.org/jira/browse/QPID-6953 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Rob Godfrey Assignee: Rob Godfrey Fix For: qpid-java-6.1 Currently many parts of the AMQP 0-8/9/9-1 codec offer two methods for encoding, one which uses a "DataOutput" object, and one which uses a QpidByteBuffer or ByteBufferSender. Examples of the former should be removed, and the latter used exclusively. -- 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-6953) [Java Broker] Refactor AMQP 0-8/9/9-1 implementation to always use QpidByteBuffer for encoding output
[ https://issues.apache.org/jira/browse/QPID-6953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15058229#comment-15058229 ] ASF subversion and git services commented on QPID-6953: --- Commit 1720183 from [~godfrer] in branch 'java/trunk' [ https://svn.apache.org/r1720183 ] QPID-6953 : Remove use of DataOutput for AMQP 0-8/9/9-1 encoding > [Java Broker] Refactor AMQP 0-8/9/9-1 implementation to always use > QpidByteBuffer for encoding output > - > > Key: QPID-6953 > URL: https://issues.apache.org/jira/browse/QPID-6953 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Fix For: qpid-java-6.1 > > > Currently many parts of the AMQP 0-8/9/9-1 codec offer two methods for > encoding, one which uses a "DataOutput" object, and one which uses a > QpidByteBuffer or ByteBufferSender. Examples of the former should be > removed, and the latter used exclusively. -- 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-6948) Introduce REST API compatibility layer
[ https://issues.apache.org/jira/browse/QPID-6948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15058241#comment-15058241 ] Keith Wall commented on QPID-6948: -- Would the scope of this work: # include HTTP status code changes (for instance QPID-6449)? # elimination of the servlets /message and /message-content that became model operations? > Introduce REST API compatibility layer > -- > > Key: QPID-6948 > URL: https://issues.apache.org/jira/browse/QPID-6948 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall > > Make the REST API backwardly compatibility with model as used by 0.32. > In general the compatibility layer should: > For GET: > * attributes that are removed should be simulated > * new attributes/new types don't need to be hidden > For POST/PUT: > * on creation, new mandatory attributes should be given sensible defaults > * removed operations should be supported perhaps by rewriting the request in > terms of new operations. > When the model changes structurally, the compatibility layer should present > the old model. -- 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-6948) Introduce REST API compatibility layer
[ https://issues.apache.org/jira/browse/QPID-6948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-6948: - Description: Make the REST API backwardly compatibility with model as used by 0.32. In general the compatibility layer should: For GET: * attributes that are removed should be simulated (e.g. defaultVirtualHost) * new attributes/new types don't need to be hidden For POST/PUT: * on creation, new mandatory attributes should be given sensible defaults * removed operations should be supported perhaps by rewriting the request in terms of new operations. When the model changes structurally, the compatibility layer should present the old model. was: Make the REST API backwardly compatibility with model as used by 0.32. In general the compatibility layer should: For GET: * attributes that are removed should be simulated * new attributes/new types don't need to be hidden For POST/PUT: * on creation, new mandatory attributes should be given sensible defaults * removed operations should be supported perhaps by rewriting the request in terms of new operations. When the model changes structurally, the compatibility layer should present the old model. > Introduce REST API compatibility layer > -- > > Key: QPID-6948 > URL: https://issues.apache.org/jira/browse/QPID-6948 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall > > Make the REST API backwardly compatibility with model as used by 0.32. > In general the compatibility layer should: > For GET: > * attributes that are removed should be simulated (e.g. defaultVirtualHost) > * new attributes/new types don't need to be hidden > For POST/PUT: > * on creation, new mandatory attributes should be given sensible defaults > * removed operations should be supported perhaps by rewriting the request in > terms of new operations. > When the model changes structurally, the compatibility layer should present > the old model. -- 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-139) Message flow to JMS synchronous consumer unexpectedly ceases
[
https://issues.apache.org/jira/browse/QPIDJMS-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15058291#comment-15058291
]
Robbie Gemmell commented on QPIDJMS-139:
Added a test that uses the test peer to mimmicks the broker defect, which then
exposes the other issue in Proton, resulting in detection of the credit
mismatch on the wire. Also updated to proton-j 0.12.0-SNAPSHOT to get a fix
that makes proton, and in turn the client, able to handle the broker behaviour
more gracefully.
Will switch to proton 0.11.1 upon release.
> Message flow to JMS synchronous consumer unexpectedly ceases
>
>
> Key: QPIDJMS-139
> URL: https://issues.apache.org/jira/browse/QPIDJMS-139
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.6.0
>Reporter: Keith Wall
>Assignee: Robbie Gemmell
> Fix For: 0.7.0
>
>
> Testing the Qpid JMS Client together with the Java Broker + Perftest
> framework reveals a problem. Message flow to one or more consumers sometimes
> ceases unexpectedly.
> In the failure case, the Java Broker reports that the consumer has been is
> suspended (SUB-1003 messages) for an extended period, even though there are
> messages remaining on the queue. Investigation of a heap dump reveals that
> the last flow frame to be received from the client:
> * deliveryCount value which matched the deliveries sent by the Broker.
> * linkCredit zero
> * drain true.
> The Broker thus believes no more credit remains and suspends the consumer.
> 0.6.0 is affected. 0.7.0-SNAPSHOT is too. Rolling back to client 0.5.0
> resolves the problem, as does setting {{jms.receiveLocalOnly}} in the
> connection url with 0.6.0 or the 0.7.0 SNAPSHOT.
> There are more details on regard the reproduction on QPID-6863. Problem
> would not manifest with debug logging turned on.
--
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-139) Message flow to JMS synchronous consumer unexpectedly ceases
[
https://issues.apache.org/jira/browse/QPIDJMS-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15058278#comment-15058278
]
ASF subversion and git services commented on QPIDJMS-139:
-
Commit e489ebad66e9ccb6053db5e1a4a8f0e9fa41f0ab in qpid-jms's branch
refs/heads/master from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=e489eba ]
QPIDJMS-139: add test exercising underlying issue PROTON 1077 exposed by the
broker behaviour QPID 6947, update to proton 0.12.0-SNAPSHOT which includes
change to handle it better
> Message flow to JMS synchronous consumer unexpectedly ceases
>
>
> Key: QPIDJMS-139
> URL: https://issues.apache.org/jira/browse/QPIDJMS-139
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.6.0, 0.7.0
>Reporter: Keith Wall
>
> Testing the Qpid JMS Client together with the Java Broker + Perftest
> framework reveals a problem. Message flow to one or more consumers sometimes
> ceases unexpectedly.
> In the failure case, the Java Broker reports that the consumer has been is
> suspended (SUB-1003 messages) for an extended period, even though there are
> messages remaining on the queue. Investigation of a heap dump reveals that
> the last flow frame to be received from the client:
> * deliveryCount value which matched the deliveries sent by the Broker.
> * linkCredit zero
> * drain true.
> The Broker thus believes no more credit remains and suspends the consumer.
> 0.6.0 is affected. 0.7.0-SNAPSHOT is too. Rolling back to client 0.5.0
> resolves the problem, as does setting {{jms.receiveLocalOnly}} in the
> connection url with 0.6.0 or the 0.7.0 SNAPSHOT.
> There are more details on regard the reproduction on QPID-6863. Problem
> would not manifest with debug logging turned on.
--
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-139) Message flow to JMS synchronous consumer unexpectedly ceases
[
https://issues.apache.org/jira/browse/QPIDJMS-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell reassigned QPIDJMS-139:
--
Assignee: Robbie Gemmell
> Message flow to JMS synchronous consumer unexpectedly ceases
>
>
> Key: QPIDJMS-139
> URL: https://issues.apache.org/jira/browse/QPIDJMS-139
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.6.0, 0.7.0
>Reporter: Keith Wall
>Assignee: Robbie Gemmell
>
> Testing the Qpid JMS Client together with the Java Broker + Perftest
> framework reveals a problem. Message flow to one or more consumers sometimes
> ceases unexpectedly.
> In the failure case, the Java Broker reports that the consumer has been is
> suspended (SUB-1003 messages) for an extended period, even though there are
> messages remaining on the queue. Investigation of a heap dump reveals that
> the last flow frame to be received from the client:
> * deliveryCount value which matched the deliveries sent by the Broker.
> * linkCredit zero
> * drain true.
> The Broker thus believes no more credit remains and suspends the consumer.
> 0.6.0 is affected. 0.7.0-SNAPSHOT is too. Rolling back to client 0.5.0
> resolves the problem, as does setting {{jms.receiveLocalOnly}} in the
> connection url with 0.6.0 or the 0.7.0 SNAPSHOT.
> There are more details on regard the reproduction on QPID-6863. Problem
> would not manifest with debug logging turned on.
--
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-139) Message flow to JMS synchronous consumer unexpectedly ceases
[
https://issues.apache.org/jira/browse/QPIDJMS-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated QPIDJMS-139:
---
Affects Version/s: (was: 0.7.0)
> Message flow to JMS synchronous consumer unexpectedly ceases
>
>
> Key: QPIDJMS-139
> URL: https://issues.apache.org/jira/browse/QPIDJMS-139
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.6.0
>Reporter: Keith Wall
>Assignee: Robbie Gemmell
> Fix For: 0.7.0
>
>
> Testing the Qpid JMS Client together with the Java Broker + Perftest
> framework reveals a problem. Message flow to one or more consumers sometimes
> ceases unexpectedly.
> In the failure case, the Java Broker reports that the consumer has been is
> suspended (SUB-1003 messages) for an extended period, even though there are
> messages remaining on the queue. Investigation of a heap dump reveals that
> the last flow frame to be received from the client:
> * deliveryCount value which matched the deliveries sent by the Broker.
> * linkCredit zero
> * drain true.
> The Broker thus believes no more credit remains and suspends the consumer.
> 0.6.0 is affected. 0.7.0-SNAPSHOT is too. Rolling back to client 0.5.0
> resolves the problem, as does setting {{jms.receiveLocalOnly}} in the
> connection url with 0.6.0 or the 0.7.0 SNAPSHOT.
> There are more details on regard the reproduction on QPID-6863. Problem
> would not manifest with debug logging turned on.
--
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-139) Message flow to JMS synchronous consumer unexpectedly ceases
[
https://issues.apache.org/jira/browse/QPIDJMS-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated QPIDJMS-139:
---
Fix Version/s: 0.7.0
> Message flow to JMS synchronous consumer unexpectedly ceases
>
>
> Key: QPIDJMS-139
> URL: https://issues.apache.org/jira/browse/QPIDJMS-139
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.6.0
>Reporter: Keith Wall
>Assignee: Robbie Gemmell
> Fix For: 0.7.0
>
>
> Testing the Qpid JMS Client together with the Java Broker + Perftest
> framework reveals a problem. Message flow to one or more consumers sometimes
> ceases unexpectedly.
> In the failure case, the Java Broker reports that the consumer has been is
> suspended (SUB-1003 messages) for an extended period, even though there are
> messages remaining on the queue. Investigation of a heap dump reveals that
> the last flow frame to be received from the client:
> * deliveryCount value which matched the deliveries sent by the Broker.
> * linkCredit zero
> * drain true.
> The Broker thus believes no more credit remains and suspends the consumer.
> 0.6.0 is affected. 0.7.0-SNAPSHOT is too. Rolling back to client 0.5.0
> resolves the problem, as does setting {{jms.receiveLocalOnly}} in the
> connection url with 0.6.0 or the 0.7.0 SNAPSHOT.
> There are more details on regard the reproduction on QPID-6863. Problem
> would not manifest with debug logging turned on.
--
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-6944) High CPU use sending message
[ https://issues.apache.org/jira/browse/QPID-6944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15058383#comment-15058383 ] Mark Soderquist commented on QPID-6944: --- I have attached a project that is duplicating the issue. 1. We are using the qpid-amqp-1-0-client 0.32 libraries. 2. The messages are usually small. The test client I attached sends 20 byte messages but the issue is clearly visible in the CPU spikes. Transactions are not in use. I also noticed that the issue can be reproduced by just sending a message without consuming it. 3. Here are the log lines with versions and memory use: 2015-12-10 07:25:12,936 INFO [main] (broker.startup) - [Broker] BRK-1001 : Startup : Version: 0.32 Build: Unversioned directory 2015-12-10 07:25:12,943 INFO [main] (broker.platform) - [Broker] BRK-1010 : Platform : JVM : Oracle Corporation version: 1.7.0_91-mockbuild_2015_10_20_10_42-b00 OS : Linux version: 2.6.32-573.8.1.el6.x86_64 arch: amd64 2015-12-10 07:25:12,950 INFO [main] (broker.max_memory) - [Broker] BRK-1011 : Maximum Memory : 2,138,767,360 bytes I think it is important to note that we are using the Berkeley DB for persistence. We have used both versions 6.2.31 and 6.4.9 with the same CPU spike results. We also tried using Java 7 instead of Java 8 with the same CPU spike results. > High CPU use sending message > > > Key: QPID-6944 > URL: https://issues.apache.org/jira/browse/QPID-6944 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.0 > Environment: Red Hat Enterprise Linux Server release 6.7 (Santiago) > OpenJDK Runtime Environment (build 1.8.0_65-b17) > OpenJDK 64-Bit Server VM (build 25.65-b01, mixed mode) >Reporter: Mark Soderquist > Attachments: enabledebug.png, qpid.0.32.png, qpid.6.0.png, > qpid.cpu.png, qpid.cpu.png, qpid6944.zip, threaddump-1449856663270.tdump > > > The org.apache.qpid.server.transport.SelectorThread is causing live lock. > While the application still functions it causes the CPU to run at nearly > 100%. See attached thread dump. -- 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-141) Thread sync error can cause long blocking delay after message send
Chris Richardson created QPIDJMS-141:
Summary: Thread sync error can cause long blocking delay after
message send
Key: QPIDJMS-141
URL: https://issues.apache.org/jira/browse/QPIDJMS-141
Project: Qpid JMS
Issue Type: Bug
Components: qpid-jms-client
Affects Versions: 0.6.0
Reporter: Chris Richardson
Fix For: 0.7.0
There is a discontinuity in the thread synchronisation between the
JmsConnection and AmqpProvider classes when sending a message: the
JmsConnection class awaits a signal after requesting message transmission (line
615, "request.sync();") while the AmqpProvider does not send the expected
signal (lines 486/487,
if (couldSend && envelope.isSendAsync()) {
request.onSuccess();
)
This results in a ~1000ms blocking delay while the request.sync() times out.
This only happens in a scenario where the JmsSession determines that the
message should be sent synchronously (lines 668/669:
boolean sync = connection.isAlwaysSyncSend() ||
(!connection.isForceAsyncSend() && deliveryMode ==
DeliveryMode.PERSISTENT && !getTransacted());
).
One workaround for this is to set the MessageProducer deliveryMode to
DeliveryMode.NON_PERSISTENT, causing the JmsSession to evaluate the send
operation to be asynchronous and so the AmqpProvider signals the request as
expected by the JmsConnection. However this may have other side-effects...
--
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-141) Thread sync error can cause long blocking delay after message send
[
https://issues.apache.org/jira/browse/QPIDJMS-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15058507#comment-15058507
]
Robbie Gemmell commented on QPIDJMS-141:
Would you happen to be using the C++ broker with its persistent store and
durable queues?
> Thread sync error can cause long blocking delay after message send
> --
>
> Key: QPIDJMS-141
> URL: https://issues.apache.org/jira/browse/QPIDJMS-141
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.6.0
>Reporter: Chris Richardson
> Fix For: 0.7.0
>
>
> There is a discontinuity in the thread synchronisation between the
> JmsConnection and AmqpProvider classes when sending a message: the
> JmsConnection class awaits a signal after requesting message transmission
> (line 615, "request.sync();") while the AmqpProvider does not send the
> expected signal (lines 486/487,
> if (couldSend && envelope.isSendAsync()) {
> request.onSuccess();
> )
> This results in a ~1000ms blocking delay while the request.sync() times out.
> This only happens in a scenario where the JmsSession determines that the
> message should be sent synchronously (lines 668/669:
> boolean sync = connection.isAlwaysSyncSend() ||
>(!connection.isForceAsyncSend() && deliveryMode ==
> DeliveryMode.PERSISTENT && !getTransacted());
> ).
> One workaround for this is to set the MessageProducer deliveryMode to
> DeliveryMode.NON_PERSISTENT, causing the JmsSession to evaluate the send
> operation to be asynchronous and so the AmqpProvider signals the request as
> expected by the JmsConnection. However this may have other side-effects...
--
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
Re: [GitHub] qpid-dispatch pull request: NO-JIRA: Added dockerfiles that will h...
+1 on not being for production. There are number things besides what has been pointed out that we¹ve learned from running dispatch on Docker such as parameterization, config injection, security (both image & SSL) that need to be addressed. Though I am really, really happy the community is doing so I don¹t have to going forward. That being said, I hope y¹all didn¹t start from scratch on these ;) Jack Gibson Chief Architect Core Payments Platforms - PayPal On 12/14/15, 5:36 PM, "scholzj" wrote: >Github user scholzj commented on the pull request: > >https://github.com/apache/qpid-dispatch/pull/40#issuecomment-164594810 > >I think the idea is good for Dispatch development and testing. But >the images are IMHO not really sufficient for some "more serious" use >(because they are always based on the Git master, because they contain >all the compilers which are not necessary to run the image etc.). Maybe >the README.md should be more clear about that, so that nobody takes image >built using these docker files and uses it in production? > > >--- >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 > - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-141) Thread sync error can cause long blocking delay after message send
[
https://issues.apache.org/jira/browse/QPIDJMS-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15058516#comment-15058516
]
Chris Richardson commented on QPIDJMS-141:
--
That's very specific! I might possibly be doing exactly that...
> Thread sync error can cause long blocking delay after message send
> --
>
> Key: QPIDJMS-141
> URL: https://issues.apache.org/jira/browse/QPIDJMS-141
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.6.0
>Reporter: Chris Richardson
> Fix For: 0.7.0
>
>
> There is a discontinuity in the thread synchronisation between the
> JmsConnection and AmqpProvider classes when sending a message: the
> JmsConnection class awaits a signal after requesting message transmission
> (line 615, "request.sync();") while the AmqpProvider does not send the
> expected signal (lines 486/487,
> if (couldSend && envelope.isSendAsync()) {
> request.onSuccess();
> )
> This results in a ~1000ms blocking delay while the request.sync() times out.
> This only happens in a scenario where the JmsSession determines that the
> message should be sent synchronously (lines 668/669:
> boolean sync = connection.isAlwaysSyncSend() ||
>(!connection.isForceAsyncSend() && deliveryMode ==
> DeliveryMode.PERSISTENT && !getTransacted());
> ).
> One workaround for this is to set the MessageProducer deliveryMode to
> DeliveryMode.NON_PERSISTENT, causing the JmsSession to evaluate the send
> operation to be asynchronous and so the AmqpProvider signals the request as
> expected by the JmsConnection. However this may have other side-effects...
--
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-6944) High CPU use sending message
[ https://issues.apache.org/jira/browse/QPID-6944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Soderquist updated QPID-6944: -- Attachment: qpid.log.zip Log file with debug log level capturing two high cpu events. > High CPU use sending message > > > Key: QPID-6944 > URL: https://issues.apache.org/jira/browse/QPID-6944 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.0 > Environment: Red Hat Enterprise Linux Server release 6.7 (Santiago) > OpenJDK Runtime Environment (build 1.8.0_65-b17) > OpenJDK 64-Bit Server VM (build 25.65-b01, mixed mode) >Reporter: Mark Soderquist > Attachments: enabledebug.png, qpid.0.32.png, qpid.6.0.png, > qpid.cpu.png, qpid.cpu.png, qpid.log.zip, qpid6944.zip, > threaddump-1449856663270.tdump > > > The org.apache.qpid.server.transport.SelectorThread is causing live lock. > While the application still functions it causes the CPU to run at nearly > 100%. See attached thread dump. -- 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-141) Thread sync error can cause long blocking delay after message send
[
https://issues.apache.org/jira/browse/QPIDJMS-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved QPIDJMS-141.
Resolution: Not A Problem
Fix Version/s: (was: 0.7.0)
> Thread sync error can cause long blocking delay after message send
> --
>
> Key: QPIDJMS-141
> URL: https://issues.apache.org/jira/browse/QPIDJMS-141
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.6.0
>Reporter: Chris Richardson
>
> There is a discontinuity in the thread synchronisation between the
> JmsConnection and AmqpProvider classes when sending a message: the
> JmsConnection class awaits a signal after requesting message transmission
> (line 615, "request.sync();") while the AmqpProvider does not send the
> expected signal (lines 486/487,
> if (couldSend && envelope.isSendAsync()) {
> request.onSuccess();
> )
> This results in a ~1000ms blocking delay while the request.sync() times out.
> This only happens in a scenario where the JmsSession determines that the
> message should be sent synchronously (lines 668/669:
> boolean sync = connection.isAlwaysSyncSend() ||
>(!connection.isForceAsyncSend() && deliveryMode ==
> DeliveryMode.PERSISTENT && !getTransacted());
> ).
> One workaround for this is to set the MessageProducer deliveryMode to
> DeliveryMode.NON_PERSISTENT, causing the JmsSession to evaluate the send
> operation to be asynchronous and so the AmqpProvider signals the request as
> expected by the JmsConnection. However this may have other side-effects...
--
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-141) Thread sync error can cause long blocking delay after message send
[
https://issues.apache.org/jira/browse/QPIDJMS-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15058541#comment-15058541
]
Robbie Gemmell commented on QPIDJMS-141:
Yes, I expected as such based on the description, in which case this isnt a
client bug, but expected based on the broker behaviour.
In JMS send is meant to be synchronous (hence them adding a new async API in
JMS 2.0), so if you send persistent messages the client defaults to doing
exactly that. If you send non-persistent messages then you are kind of saying
you dont mind losing them anyway, and it cheekily defaults to sending them
asynchronously as you already noticed. There is config (jms.forceAsyncSend,
http://qpid.apache.org/releases/qpid-jms-0.6.0/docs/index.html#jms-configuration-options)
so you can use to force it to behave one way or the other with either delivery
mode.
The broker in this case has a sync period where it waits to flush persistent
messages (on durable queues) to disk, and only acknowledges receipt once it has
done that, so the delay here is from the broker not informing the client of
accepting the message. AMQP 0-x clients had functionality to explicitly
synchronously request 'completion' of protocol commands, so clients had a way
to force the sync on demand and the broker relied on that. AMQP 1.0 doesnt use
the same 'command' model and there isnt a direct equivalent of that, so the
broker is jsut waiting for its store flush timeout to expire before doing the
sync to disk. QPID-6730 made that period configurable, so you would drive the
period lower to avoid such lengthy delays but resulting in more frequent disk
syncs.
> Thread sync error can cause long blocking delay after message send
> --
>
> Key: QPIDJMS-141
> URL: https://issues.apache.org/jira/browse/QPIDJMS-141
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.6.0
>Reporter: Chris Richardson
> Fix For: 0.7.0
>
>
> There is a discontinuity in the thread synchronisation between the
> JmsConnection and AmqpProvider classes when sending a message: the
> JmsConnection class awaits a signal after requesting message transmission
> (line 615, "request.sync();") while the AmqpProvider does not send the
> expected signal (lines 486/487,
> if (couldSend && envelope.isSendAsync()) {
> request.onSuccess();
> )
> This results in a ~1000ms blocking delay while the request.sync() times out.
> This only happens in a scenario where the JmsSession determines that the
> message should be sent synchronously (lines 668/669:
> boolean sync = connection.isAlwaysSyncSend() ||
>(!connection.isForceAsyncSend() && deliveryMode ==
> DeliveryMode.PERSISTENT && !getTransacted());
> ).
> One workaround for this is to set the MessageProducer deliveryMode to
> DeliveryMode.NON_PERSISTENT, causing the JmsSession to evaluate the send
> operation to be asynchronous and so the AmqpProvider signals the request as
> expected by the JmsConnection. However this may have other side-effects...
--
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-141) Thread sync error can cause long blocking delay after message send
[
https://issues.apache.org/jira/browse/QPIDJMS-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15058568#comment-15058568
]
Chris Richardson commented on QPIDJMS-141:
--
Ah OK. Thanks for the explanation.
> Thread sync error can cause long blocking delay after message send
> --
>
> Key: QPIDJMS-141
> URL: https://issues.apache.org/jira/browse/QPIDJMS-141
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.6.0
>Reporter: Chris Richardson
>
> There is a discontinuity in the thread synchronisation between the
> JmsConnection and AmqpProvider classes when sending a message: the
> JmsConnection class awaits a signal after requesting message transmission
> (line 615, "request.sync();") while the AmqpProvider does not send the
> expected signal (lines 486/487,
> if (couldSend && envelope.isSendAsync()) {
> request.onSuccess();
> )
> This results in a ~1000ms blocking delay while the request.sync() times out.
> This only happens in a scenario where the JmsSession determines that the
> message should be sent synchronously (lines 668/669:
> boolean sync = connection.isAlwaysSyncSend() ||
>(!connection.isForceAsyncSend() && deliveryMode ==
> DeliveryMode.PERSISTENT && !getTransacted());
> ).
> One workaround for this is to set the MessageProducer deliveryMode to
> DeliveryMode.NON_PERSISTENT, causing the JmsSession to evaluate the send
> operation to be asynchronous and so the AmqpProvider signals the request as
> expected by the JmsConnection. However this may have other side-effects...
--
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-6944) High CPU use sending message
[ https://issues.apache.org/jira/browse/QPID-6944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Soderquist updated QPID-6944: -- Attachment: qpid6944.zip Simple project to duplicate broker high CPU problem. > High CPU use sending message > > > Key: QPID-6944 > URL: https://issues.apache.org/jira/browse/QPID-6944 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: qpid-java-6.0 > Environment: Red Hat Enterprise Linux Server release 6.7 (Santiago) > OpenJDK Runtime Environment (build 1.8.0_65-b17) > OpenJDK 64-Bit Server VM (build 25.65-b01, mixed mode) >Reporter: Mark Soderquist > Attachments: enabledebug.png, qpid.0.32.png, qpid.6.0.png, > qpid.cpu.png, qpid.cpu.png, qpid6944.zip, threaddump-1449856663270.tdump > > > The org.apache.qpid.server.transport.SelectorThread is causing live lock. > While the application still functions it causes the CPU to run at nearly > 100%. See attached thread dump. -- 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-199) Add Dockerfiles that launches the dispatch router inside a container for RHEL and Debian based systems
[ https://issues.apache.org/jira/browse/DISPATCH-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15058651#comment-15058651 ] Ganesh Murthy commented on DISPATCH-199: These dockerfiles should help anybody looking to get a quick start with dispatch router. These dockerfiles are not intended to be used in production environments. > Add Dockerfiles that launches the dispatch router inside a container for RHEL > and Debian based systems > -- > > Key: DISPATCH-199 > URL: https://issues.apache.org/jira/browse/DISPATCH-199 > Project: Qpid Dispatch > Issue Type: Improvement >Reporter: Ganesh Murthy > > Add sample dockerfiles that launch dispatch router inside a docker container. > Create dockerfiles for RHEL and Debian based systems. -- 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-6954) [Java Broker] Add the ability to define "policies" for node auto-creation based on address
[
https://issues.apache.org/jira/browse/QPID-6954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Godfrey updated QPID-6954:
--
Description:
See: [this
mail|http://mail-archives.apache.org/mod_mbox/qpid-users/201512.mbox/%3C55CF1C5A18D1B84CAE275B17381A7C6CC174E2825B%40winavi5.AviFN.local%3E]
and QPID-5251 (C++ Broker equivalent).
It is sometimes useful to be able to provide behaviours based on
namespaces/patterns such that queues/exchanges which match those patterns get
automatically created.
Add a new property to the virtualHost called "nodeAutoCreationPolicies", which
is a list of polices. A policy is an object with attributes "pattern",
"nodeType", "createdOnPublish", "createdOnConsume" and "attributes".
* pattern is a Java RegExp which will be matched against the name used by the
client for an incoming published message / consume request.
* nodeType is one of "queue" or "exchange".
* createdOnPublish is a boolean indicating whether the node should be created
when new messages are published (or an incoming link is created)
* createdOnConsume is a boolean indicating whether the node should be created
when a new consumer is created
* attributes is a map, containing the default attributes of the node to be
created. These attributes are the same used in the REST API for the node type.
The nodeAutoCreationPolicies can be set via the REST API, or (if you are using
a JSON VirtualHostNode) by hand editing the virtualHost configuration.
For instance here is a snippet from a JSON virtualHost configuration with
defined nodeAutoCreationPolicies:
{code:javascript}
{
"id" : "134c0b84-b1b2-46c8-ba2d-f05ba13be56f",
"name" : "default",
"type" : "BDB",
"modelVersion" : "6.1",
"nodeAutoCreationPolicies" : [ {
"pattern" : "rob\\.durable\\..*",
"createdOnPublish" : true,
"createdOnConsume" : true,
"nodeType" : "queue",
"attributes" : {
"durable" : true
}
}, {
"pattern" : "rob\\.exchange\\..*",
"createdOnPublish" : true,
"createdOnConsume" : false,
"nodeType" : "exchange",
"attributes" : {
"type" : "direct",
"durable" : true
}
} ],
"queue.deadLetterQueueEnabled" : false,
"exchanges" : [ {
"id" : "5fcbd3f5-fe7c-4ab0-9605-950d7784844c",
"name" : "amq.direct",
"type" : "direct"
}, {
"id" : "3f17dd6f-269b-43a6-868e-dd487271719a",
"name" : "amq.fanout",
"type" : "fanout"
}, {
"id" : "45e9eba0-3bcc-4634-b042-87a652447cbe",
"name" : "amq.match",
"type" : "headers"
}, {
"id" : "d7b703c4-0d64-4a44-8008-1314a18e30e7",
"name" : "amq.topic",
"type" : "topic"
} ],
{code}
was:
See: [this
mail|http://mail-archives.apache.org/mod_mbox/qpid-users/201512.mbox/%3C55CF1C5A18D1B84CAE275B17381A7C6CC174E2825B%40winavi5.AviFN.local%3E]
and QPID-5251 (C++ Broker equivalent).
It is sometimes useful to be able to provide behaviours based on
namespaces/patterns such that queues/exchanges which match those patterns get
automatically created.
Add a new property to the virtualHost called "nodeAutoCreationPolicies", which
is a list of polices. A policy is an object with attributes "pattern",
"nodeType", "createdOnPublish", "createdOnConsume" and "attributes".
* pattern is a Java RegExp which will be matched against the name used by the
client for an incoming published message / consume request.
* nodeType is one of "queue" or "exchange".
* createdOnPublish is a boolean indicating whether the node should be created
when new messages are published (or an incoming link is created)
* createdOnConsume is a boolean indicating whether the node should be created
when a new consumer is created
* attributes is a map, containing the default attributes of the node to be
created. These attributes are the same used in the REST API for the node type.
The nodeAutoCreationPolicies can be set via the REST API, or (if you are using
a JSON VirtualHostNode) by hand editing the virtualHost configuration.
For instance here is a snippet from a JSON virtualHost configuration with
defined nodeAutoCreationPolicies:
{code:javascript}
{
"id" : "134c0b84-b1b2-46c8-ba2d-f05ba13be56f",
"name" : "default",
"type" : "BDB",
"context" : {
"foo" : "1"
},
"modelVersion" : "6.1",
"nodeAutoCreationPolicies" : [ {
"pattern" : "rob\\.durable\\..*",
"createdOnPublish" : true,
"createdOnConsume" : true,
"nodeType" : "queue",
"attributes" : {
"durable" : true
}
}, {
"pattern" : "rob\\.exchange\\..*",
"createdOnPublish" : true,
"createdOnConsume" : false,
"nodeType" : "exchange",
"attributes" : {
"type" : "direct",
"durable" : true
}
} ],
"queue.deadLetterQueueEnabled" : false,
"exchanges" : [ {
"id" : "5fcbd3f5-fe7c-4ab0-9605-950d7784844c",
"name" : "amq.direct",
"type" : "direct"
}, {
"id" : "3f17dd6f-269b-43a6-868e-dd487271719a",
"name" :
[jira] [Commented] (QPID-6954) [Java Broker] Add the ability to define "policies" for node auto-creation based on address
[
https://issues.apache.org/jira/browse/QPID-6954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15058766#comment-15058766
]
ASF subversion and git services commented on QPID-6954:
---
Commit 1720243 from [~godfrer] in branch 'java/trunk'
[ https://svn.apache.org/r1720243 ]
QPID-6954 : Add the ability to define "policies" for node auto-creation based
on address
> [Java Broker] Add the ability to define "policies" for node auto-creation
> based on address
> --
>
> Key: QPID-6954
> URL: https://issues.apache.org/jira/browse/QPID-6954
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: qpid-java-6.1
>
>
> See: [this
> mail|http://mail-archives.apache.org/mod_mbox/qpid-users/201512.mbox/%3C55CF1C5A18D1B84CAE275B17381A7C6CC174E2825B%40winavi5.AviFN.local%3E]
> and QPID-5251 (C++ Broker equivalent).
> It is sometimes useful to be able to provide behaviours based on
> namespaces/patterns such that queues/exchanges which match those patterns get
> automatically created.
> Add a new property to the virtualHost called "nodeAutoCreationPolicies",
> which is a list of polices. A policy is an object with attributes "pattern",
> "nodeType", "createdOnPublish", "createdOnConsume" and "attributes".
> * pattern is a Java RegExp which will be matched against the name used by the
> client for an incoming published message / consume request.
> * nodeType is one of "queue" or "exchange".
> * createdOnPublish is a boolean indicating whether the node should be created
> when new messages are published (or an incoming link is created)
> * createdOnConsume is a boolean indicating whether the node should be created
> when a new consumer is created
> * attributes is a map, containing the default attributes of the node to be
> created. These attributes are the same used in the REST API for the node
> type.
> The nodeAutoCreationPolicies can be set via the REST API, or (if you are
> using a JSON VirtualHostNode) by hand editing the virtualHost configuration.
> For instance here is a snippet from a JSON virtualHost configuration with
> defined nodeAutoCreationPolicies:
> {code:javascript}
> {
> "id" : "134c0b84-b1b2-46c8-ba2d-f05ba13be56f",
> "name" : "default",
> "type" : "BDB",
> "modelVersion" : "6.1",
> "nodeAutoCreationPolicies" : [ {
> "pattern" : "rob\\.durable\\..*",
> "createdOnPublish" : true,
> "createdOnConsume" : true,
> "nodeType" : "queue",
> "attributes" : {
> "durable" : true
> }
> }, {
> "pattern" : "rob\\.exchange\\..*",
> "createdOnPublish" : true,
> "createdOnConsume" : false,
> "nodeType" : "exchange",
> "attributes" : {
> "type" : "direct",
> "durable" : true
> }
> } ],
> "queue.deadLetterQueueEnabled" : false,
> "exchanges" : [ {
> "id" : "5fcbd3f5-fe7c-4ab0-9605-950d7784844c",
> "name" : "amq.direct",
> "type" : "direct"
> }, {
> "id" : "3f17dd6f-269b-43a6-868e-dd487271719a",
> "name" : "amq.fanout",
> "type" : "fanout"
> }, {
> "id" : "45e9eba0-3bcc-4634-b042-87a652447cbe",
> "name" : "amq.match",
> "type" : "headers"
> }, {
> "id" : "d7b703c4-0d64-4a44-8008-1314a18e30e7",
> "name" : "amq.topic",
> "type" : "topic"
> } ],
> {code}
>
--
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-6954) [Java Broker] Add the ability to define "policies" for node auto-creation based on address
[
https://issues.apache.org/jira/browse/QPID-6954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15058768#comment-15058768
]
ASF subversion and git services commented on QPID-6954:
---
Commit 1720244 from [~godfrer] in branch 'java/trunk'
[ https://svn.apache.org/r1720244 ]
QPID-6954 : Revert inadvertantly committed files
> [Java Broker] Add the ability to define "policies" for node auto-creation
> based on address
> --
>
> Key: QPID-6954
> URL: https://issues.apache.org/jira/browse/QPID-6954
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: qpid-java-6.1
>
>
> See: [this
> mail|http://mail-archives.apache.org/mod_mbox/qpid-users/201512.mbox/%3C55CF1C5A18D1B84CAE275B17381A7C6CC174E2825B%40winavi5.AviFN.local%3E]
> and QPID-5251 (C++ Broker equivalent).
> It is sometimes useful to be able to provide behaviours based on
> namespaces/patterns such that queues/exchanges which match those patterns get
> automatically created.
> Add a new property to the virtualHost called "nodeAutoCreationPolicies",
> which is a list of polices. A policy is an object with attributes "pattern",
> "nodeType", "createdOnPublish", "createdOnConsume" and "attributes".
> * pattern is a Java RegExp which will be matched against the name used by the
> client for an incoming published message / consume request.
> * nodeType is one of "queue" or "exchange".
> * createdOnPublish is a boolean indicating whether the node should be created
> when new messages are published (or an incoming link is created)
> * createdOnConsume is a boolean indicating whether the node should be created
> when a new consumer is created
> * attributes is a map, containing the default attributes of the node to be
> created. These attributes are the same used in the REST API for the node
> type.
> The nodeAutoCreationPolicies can be set via the REST API, or (if you are
> using a JSON VirtualHostNode) by hand editing the virtualHost configuration.
> For instance here is a snippet from a JSON virtualHost configuration with
> defined nodeAutoCreationPolicies:
> {code:javascript}
> {
> "id" : "134c0b84-b1b2-46c8-ba2d-f05ba13be56f",
> "name" : "default",
> "type" : "BDB",
> "modelVersion" : "6.1",
> "nodeAutoCreationPolicies" : [ {
> "pattern" : "rob\\.durable\\..*",
> "createdOnPublish" : true,
> "createdOnConsume" : true,
> "nodeType" : "queue",
> "attributes" : {
> "durable" : true
> }
> }, {
> "pattern" : "rob\\.exchange\\..*",
> "createdOnPublish" : true,
> "createdOnConsume" : false,
> "nodeType" : "exchange",
> "attributes" : {
> "type" : "direct",
> "durable" : true
> }
> } ],
> "queue.deadLetterQueueEnabled" : false,
> "exchanges" : [ {
> "id" : "5fcbd3f5-fe7c-4ab0-9605-950d7784844c",
> "name" : "amq.direct",
> "type" : "direct"
> }, {
> "id" : "3f17dd6f-269b-43a6-868e-dd487271719a",
> "name" : "amq.fanout",
> "type" : "fanout"
> }, {
> "id" : "45e9eba0-3bcc-4634-b042-87a652447cbe",
> "name" : "amq.match",
> "type" : "headers"
> }, {
> "id" : "d7b703c4-0d64-4a44-8008-1314a18e30e7",
> "name" : "amq.topic",
> "type" : "topic"
> } ],
> {code}
>
--
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-6954) [Java Broker] Add the ability to define "policies" for node auto-creation based on address
Rob Godfrey created QPID-6954:
-
Summary: [Java Broker] Add the ability to define "policies" for
node auto-creation based on address
Key: QPID-6954
URL: https://issues.apache.org/jira/browse/QPID-6954
Project: Qpid
Issue Type: Improvement
Components: Java Broker
Reporter: Rob Godfrey
Assignee: Rob Godfrey
Fix For: qpid-java-6.1
See: [this
mail|http://mail-archives.apache.org/mod_mbox/qpid-users/201512.mbox/%3C55CF1C5A18D1B84CAE275B17381A7C6CC174E2825B%40winavi5.AviFN.local%3E]
and QPID-5251 (C++ Broker equivalent).
It is sometimes useful to be able to provide behaviours based on
namespaces/patterns such that queues/exchanges which match those patterns get
automatically created.
Add a new property to the virtualHost called "nodeAutoCreationPolicies", which
is a list of polices. A policy is an object with attributes "pattern",
"nodeType", "createdOnPublish", "createdOnConsume" and "attributes".
* pattern is a Java RegExp which will be matched against the name used by the
client for an incoming published message / consume request.
* nodeType is one of "queue" or "exchange".
* createdOnPublish is a boolean indicating whether the node should be created
when new messages are published (or an incoming link is created)
* createdOnConsume is a boolean indicating whether the node should be created
when a new consumer is created
* attributes is a map, containing the default attributes of the node to be
created. These attributes are the same used in the REST API for the node type.
The nodeAutoCreationPolicies can be set via the REST API, or (if you are using
a JSON VirtualHostNode) by hand editing the virtualHost configuration.
For instance here is a snippet from a JSON virtualHost configuration with
defined nodeAutoCreationPolicies:
{code:javascript}
{
"id" : "134c0b84-b1b2-46c8-ba2d-f05ba13be56f",
"name" : "default",
"type" : "BDB",
"context" : {
"foo" : "1"
},
"modelVersion" : "6.1",
"nodeAutoCreationPolicies" : [ {
"pattern" : "rob\\.durable\\..*",
"createdOnPublish" : true,
"createdOnConsume" : true,
"nodeType" : "queue",
"attributes" : {
"durable" : true
}
}, {
"pattern" : "rob\\.exchange\\..*",
"createdOnPublish" : true,
"createdOnConsume" : false,
"nodeType" : "exchange",
"attributes" : {
"type" : "direct",
"durable" : true
}
} ],
"queue.deadLetterQueueEnabled" : false,
"exchanges" : [ {
"id" : "5fcbd3f5-fe7c-4ab0-9605-950d7784844c",
"name" : "amq.direct",
"type" : "direct"
}, {
"id" : "3f17dd6f-269b-43a6-868e-dd487271719a",
"name" : "amq.fanout",
"type" : "fanout"
}, {
"id" : "45e9eba0-3bcc-4634-b042-87a652447cbe",
"name" : "amq.match",
"type" : "headers"
}, {
"id" : "d7b703c4-0d64-4a44-8008-1314a18e30e7",
"name" : "amq.topic",
"type" : "topic"
} ],
{code}
--
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] (QPIDIT-21) Add shims for C++ client
[ https://issues.apache.org/jira/browse/QPIDIT-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15058796#comment-15058796 ] ASF subversion and git services commented on QPIDIT-21: --- Commit 5f7ac58b029c7fe2294b0bbd1097bf2750b91653 in qpid-interop-test's branch refs/heads/master from [~kpvdr] [ https://git-wip-us.apache.org/repos/asf?p=qpid-interop-test.git;h=5f7ac58 ] QPIDIT-21: Add shims for C++ client > Add shims for C++ client > > > Key: QPIDIT-21 > URL: https://issues.apache.org/jira/browse/QPIDIT-21 > Project: Apache QPID IT > Issue Type: New Feature > Components: JmsMessageTest, SimpleTypeTest >Reporter: Kim van der Riet >Assignee: Kim van der Riet > > Add a set of shims for the Proton C++ client: > * Sender for SimpeTypeTest > * Receiver for SimpleTypeTest > * Sender for JmsMessageTest > * Receiver for JmsMessageTest -- 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] (QPIDIT-21) Add shims for C++ client
[ https://issues.apache.org/jira/browse/QPIDIT-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15058801#comment-15058801 ] Kim van der Riet commented on QPIDIT-21: Above checkin adds shims for JMS and AMQP types. The following is still outstanding: AMQP types (SimpleType Test): * Add test for AMQP Array type JMS (JmsMessage Test): * Add test for ObjectMessage type (although this is an obscure use-case as most non-JMS clients won't be in a position to stream Java objects). > Add shims for C++ client > > > Key: QPIDIT-21 > URL: https://issues.apache.org/jira/browse/QPIDIT-21 > Project: Apache QPID IT > Issue Type: New Feature > Components: JmsMessageTest, SimpleTypeTest >Reporter: Kim van der Riet >Assignee: Kim van der Riet > > Add a set of shims for the Proton C++ client: > * Sender for SimpeTypeTest > * Receiver for SimpleTypeTest > * Sender for JmsMessageTest > * Receiver for JmsMessageTest -- 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-6954) [Java Broker] Add the ability to define "policies" for node auto-creation based on address
[
https://issues.apache.org/jira/browse/QPID-6954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15058806#comment-15058806
]
ASF subversion and git services commented on QPID-6954:
---
Commit 1720249 from [~godfrer] in branch 'java/trunk'
[ https://svn.apache.org/r1720249 ]
QPID-6954 : Refactor to remove code duplication
> [Java Broker] Add the ability to define "policies" for node auto-creation
> based on address
> --
>
> Key: QPID-6954
> URL: https://issues.apache.org/jira/browse/QPID-6954
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Rob Godfrey
>Assignee: Rob Godfrey
> Fix For: qpid-java-6.1
>
>
> See: [this
> mail|http://mail-archives.apache.org/mod_mbox/qpid-users/201512.mbox/%3C55CF1C5A18D1B84CAE275B17381A7C6CC174E2825B%40winavi5.AviFN.local%3E]
> and QPID-5251 (C++ Broker equivalent).
> It is sometimes useful to be able to provide behaviours based on
> namespaces/patterns such that queues/exchanges which match those patterns get
> automatically created.
> Add a new property to the virtualHost called "nodeAutoCreationPolicies",
> which is a list of polices. A policy is an object with attributes "pattern",
> "nodeType", "createdOnPublish", "createdOnConsume" and "attributes".
> * pattern is a Java RegExp which will be matched against the name used by the
> client for an incoming published message / consume request.
> * nodeType is one of "queue" or "exchange".
> * createdOnPublish is a boolean indicating whether the node should be created
> when new messages are published (or an incoming link is created)
> * createdOnConsume is a boolean indicating whether the node should be created
> when a new consumer is created
> * attributes is a map, containing the default attributes of the node to be
> created. These attributes are the same used in the REST API for the node
> type.
> The nodeAutoCreationPolicies can be set via the REST API, or (if you are
> using a JSON VirtualHostNode) by hand editing the virtualHost configuration.
> For instance here is a snippet from a JSON virtualHost configuration with
> defined nodeAutoCreationPolicies:
> {code:javascript}
> {
> "id" : "134c0b84-b1b2-46c8-ba2d-f05ba13be56f",
> "name" : "default",
> "type" : "BDB",
> "modelVersion" : "6.1",
> "nodeAutoCreationPolicies" : [ {
> "pattern" : "rob\\.durable\\..*",
> "createdOnPublish" : true,
> "createdOnConsume" : true,
> "nodeType" : "queue",
> "attributes" : {
> "durable" : true
> }
> }, {
> "pattern" : "rob\\.exchange\\..*",
> "createdOnPublish" : true,
> "createdOnConsume" : false,
> "nodeType" : "exchange",
> "attributes" : {
> "type" : "direct",
> "durable" : true
> }
> } ],
> "queue.deadLetterQueueEnabled" : false,
> "exchanges" : [ {
> "id" : "5fcbd3f5-fe7c-4ab0-9605-950d7784844c",
> "name" : "amq.direct",
> "type" : "direct"
> }, {
> "id" : "3f17dd6f-269b-43a6-868e-dd487271719a",
> "name" : "amq.fanout",
> "type" : "fanout"
> }, {
> "id" : "45e9eba0-3bcc-4634-b042-87a652447cbe",
> "name" : "amq.match",
> "type" : "headers"
> }, {
> "id" : "d7b703c4-0d64-4a44-8008-1314a18e30e7",
> "name" : "amq.topic",
> "type" : "topic"
> } ],
> {code}
>
--
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-142) Clean up the IdGenerator used to create ID values for JMS resources
Timothy Bish created QPIDJMS-142: Summary: Clean up the IdGenerator used to create ID values for JMS resources Key: QPIDJMS-142 URL: https://issues.apache.org/jira/browse/QPIDJMS-142 Project: Qpid JMS Issue Type: Improvement Components: qpid-jms-client Affects Versions: 0.6.0 Reporter: Timothy Bish Assignee: Timothy Bish Priority: Minor Fix For: 0.7.0 The current IdGenerator implementation uses some less than optimal logic to create ID values for the JMS resources. We can streamline and simplify this using UUID values with some optional additional identifying bits. -- 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
