[jira] [Comment Edited] (ARTEMIS-1742) possible problem with embedded broker and vm acceptor/connector
[
https://issues.apache.org/jira/browse/ARTEMIS-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16498588#comment-16498588
]
Andrea Tarocchi edited comment on ARTEMIS-1742 at 6/1/18 9:15 PM:
--
Hi [~jbertram], finally had the time to implement your suggestions and run the
whole test suite.
Something has definitely improved: less flaky tests overall usually 1 or 2 per
run but still the flaky one are random; suggesting there still might be some
race condition issue going on?
On top of that I have 2 permanently failing test that I'll investigate,
probably some difference between 2.30.0 and 2.5.0.
was (Author: valdar):
Hi [~jbertram], finally had the time to implement your suggestions and run the
whole test suite.
Something has definitely improved: less flaky tests overall usually 1 or 2 per
run but still the flaky one are random; suggesting there still might be some
race condition issue going on?
On topo of that I have 2 permanently failing test that I'll investigate,
probably some difference between 2.30.0 and 2.5.0.
> possible problem with embedded broker and vm acceptor/connector
> ---
>
> Key: ARTEMIS-1742
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1742
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.3.0
>Reporter: Andrea Tarocchi
>Priority: Major
> Attachments: camel-jms.zip
>
>
> In camel-jms component we keep having some random failing tests using
> embedded artemis broker.
> Basically the same tests are run using embedded artemis broker and embedded
> amq broker and the same test is re ran up to 3 times if it has a failure (in
> that case is marked as flaky), we keep experiencing flaky tests for artemis
> and not for amq.
> I've attached a simplified as possible reproducer which run the same test 50
> times only using artemis embedded broker (is a pretty simple write and read
> from a temp queue).
> Running it a couple of times with: \{{mvn clean test}} should manifest the
> flaky behaviour.
> Might be we init/destroy the embedded broker in the wrong way?
> {code:java}
> public ConnectionFactory createConnectionFactory(final int
> maximumRedeliveries, final boolean persistent) {
> int id = BROKER_COUNT.incrementAndGet();
> String baseDir = DATA_DIR + File.separator + id;
> final Configuration configuration;
> try {
> configuration = new ConfigurationImpl()
> .setPersistenceEnabled(persistent)
> .setSecurityEnabled(false)
> .setBindingsDirectory(baseDir + File.separator + "bindings")
> .setJournalDirectory(baseDir + File.separator + "journal")
> .setPagingDirectory(baseDir + File.separator + "paging")
> .setLargeMessagesDirectory(baseDir + File.separator +
> "largemessages")
> .setCheckForLiveServer(false)
> .setEnabledAsyncConnectionExecution(false)
> .setManagementNotificationAddress( new
> SimpleString("activemq.notifications") )
> .setCheckForLiveServer(false)
> .setClusterConfigurations( new ArrayList<>() )
> .addAcceptorConfiguration("invm", "vm://" + id)
> .addConnectorConfiguration("invm", "vm://" + id);
> } catch (final Exception e) {
> throw new ExceptionInInitializerError(e);
> }
> final ConnectionFactoryConfiguration cfConfig = new
> ConnectionFactoryConfigurationImpl().setName("cf")
> .setConnectorNames("invm").setBindings("cf");
> final JMSConfiguration jmsConfig = new JMSConfigurationImpl()
> .setConnectionFactoryConfigurations(singletonList(cfConfig));
> EmbeddedJMS broker = new
> EmbeddedJMS().setConfiguration(configuration).setJmsConfiguration(jmsConfig);
> try {
> broker.start();
> } catch (final Exception e) {
> throw new ExceptionInInitializerError(e);
> }
> final AddressSettings addressSettings = new AddressSettings()
>
> .setMaxDeliveryAttempts(maximumRedeliveries)
>
> .setDeadLetterAddress(new SimpleString("jms.queue.deadletter"))
> .setExpiryAddress(new
> SimpleString("jms.queue.expired"))
> .setAutoCreateAddresses(true)
>
> .setAutoCreateQueues(true);
>
> broker.getActiveMQServer().getAddressSettingsRepository().addMatch("#",
> addressSettings);
> TransportConfiguration transportConfigs =
[jira] [Commented] (ARTEMIS-1742) possible problem with embedded broker and vm acceptor/connector
[
https://issues.apache.org/jira/browse/ARTEMIS-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16498588#comment-16498588
]
Andrea Tarocchi commented on ARTEMIS-1742:
--
Hi [~jbertram], finally had the time to implement your suggestions and run the
whole test suite.
Something has definitely improved: less flaky tests overall usually 1 or 2 per
run but still the flaky one are random; suggesting there still might be some
race condition issue going on?
On topo of that I have 2 permanently failing test that I'll investigate,
probably some difference between 2.30.0 and 2.5.0.
> possible problem with embedded broker and vm acceptor/connector
> ---
>
> Key: ARTEMIS-1742
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1742
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.3.0
>Reporter: Andrea Tarocchi
>Priority: Major
> Attachments: camel-jms.zip
>
>
> In camel-jms component we keep having some random failing tests using
> embedded artemis broker.
> Basically the same tests are run using embedded artemis broker and embedded
> amq broker and the same test is re ran up to 3 times if it has a failure (in
> that case is marked as flaky), we keep experiencing flaky tests for artemis
> and not for amq.
> I've attached a simplified as possible reproducer which run the same test 50
> times only using artemis embedded broker (is a pretty simple write and read
> from a temp queue).
> Running it a couple of times with: \{{mvn clean test}} should manifest the
> flaky behaviour.
> Might be we init/destroy the embedded broker in the wrong way?
> {code:java}
> public ConnectionFactory createConnectionFactory(final int
> maximumRedeliveries, final boolean persistent) {
> int id = BROKER_COUNT.incrementAndGet();
> String baseDir = DATA_DIR + File.separator + id;
> final Configuration configuration;
> try {
> configuration = new ConfigurationImpl()
> .setPersistenceEnabled(persistent)
> .setSecurityEnabled(false)
> .setBindingsDirectory(baseDir + File.separator + "bindings")
> .setJournalDirectory(baseDir + File.separator + "journal")
> .setPagingDirectory(baseDir + File.separator + "paging")
> .setLargeMessagesDirectory(baseDir + File.separator +
> "largemessages")
> .setCheckForLiveServer(false)
> .setEnabledAsyncConnectionExecution(false)
> .setManagementNotificationAddress( new
> SimpleString("activemq.notifications") )
> .setCheckForLiveServer(false)
> .setClusterConfigurations( new ArrayList<>() )
> .addAcceptorConfiguration("invm", "vm://" + id)
> .addConnectorConfiguration("invm", "vm://" + id);
> } catch (final Exception e) {
> throw new ExceptionInInitializerError(e);
> }
> final ConnectionFactoryConfiguration cfConfig = new
> ConnectionFactoryConfigurationImpl().setName("cf")
> .setConnectorNames("invm").setBindings("cf");
> final JMSConfiguration jmsConfig = new JMSConfigurationImpl()
> .setConnectionFactoryConfigurations(singletonList(cfConfig));
> EmbeddedJMS broker = new
> EmbeddedJMS().setConfiguration(configuration).setJmsConfiguration(jmsConfig);
> try {
> broker.start();
> } catch (final Exception e) {
> throw new ExceptionInInitializerError(e);
> }
> final AddressSettings addressSettings = new AddressSettings()
>
> .setMaxDeliveryAttempts(maximumRedeliveries)
>
> .setDeadLetterAddress(new SimpleString("jms.queue.deadletter"))
> .setExpiryAddress(new
> SimpleString("jms.queue.expired"))
> .setAutoCreateAddresses(true)
>
> .setAutoCreateQueues(true);
>
> broker.getActiveMQServer().getAddressSettingsRepository().addMatch("#",
> addressSettings);
> TransportConfiguration transportConfigs = new
> TransportConfiguration(InVMConnectorFactory.class.getName());
>
> transportConfigs.getParams().put(TransportConstants.SERVER_ID_PROP_NAME, id);
> ServerLocator serviceLocator =
> ActiveMQClient.createServerLocator(false, transportConfigs);
> ActiveMQConnectionFactory acf = new
> ActiveMQConnectionFactory(serviceLocator);
> return acf;
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (ARTEMIS-1892) Allow whitespace in
[
https://issues.apache.org/jira/browse/ARTEMIS-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram reassigned ARTEMIS-1892:
---
Assignee: Justin Bertram
> Allow whitespace in
> --
>
> Key: ARTEMIS-1892
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1892
> Project: ActiveMQ Artemis
> Issue Type: New Feature
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>Priority: Minor
>
> When tuning the acceptors, the {{}} elements can quickly become
> very long and hard to read.
> Here is an example from the default configuration:
> {code}
>
>name="artemis">tcp://0.0.0.0:61616?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300
> {code}
> It would be nice to be able to add whitespace to make the {{broker.xml}}
> easier to read and manage. For instance:
> {code}
>
>
> tcp://0.0.0.0:61616?
> tcpSendBufferSize=1048576;
> tcpReceiveBufferSize=1048576;
> protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;
> useEpoll=true;
> amqpCredits=1000;
> amqpLowCredits=300
>
> {code}
> It seems that stripping whitespace from the {{}} elements text
> should be enough to make it work...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1892) Allow whitespace in
[
https://issues.apache.org/jira/browse/ARTEMIS-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16498291#comment-16498291
]
ASF GitHub Bot commented on ARTEMIS-1892:
-
GitHub user jbertram opened a pull request:
https://github.com/apache/activemq-artemis/pull/2120
ARTEMIS-1892 allow whitespace in acceptor and connector URIs
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/jbertram/activemq-artemis ARTEMIS-1892
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/activemq-artemis/pull/2120.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #2120
commit b3f9f51b1d507b4dea2894aeef78fd515c0fcf4e
Author: Justin Bertram
Date: 2018-06-01T17:26:12Z
ARTEMIS-1892 allow whitespace in acceptor and connector URIs
> Allow whitespace in
> --
>
> Key: ARTEMIS-1892
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1892
> Project: ActiveMQ Artemis
> Issue Type: New Feature
>Reporter: Lionel Cons
>Priority: Minor
>
> When tuning the acceptors, the {{}} elements can quickly become
> very long and hard to read.
> Here is an example from the default configuration:
> {code}
>
>name="artemis">tcp://0.0.0.0:61616?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300
> {code}
> It would be nice to be able to add whitespace to make the {{broker.xml}}
> easier to read and manage. For instance:
> {code}
>
>
> tcp://0.0.0.0:61616?
> tcpSendBufferSize=1048576;
> tcpReceiveBufferSize=1048576;
> protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;
> useEpoll=true;
> amqpCredits=1000;
> amqpLowCredits=300
>
> {code}
> It seems that stripping whitespace from the {{}} elements text
> should be enough to make it work...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1892) Allow whitespace in
[
https://issues.apache.org/jira/browse/ARTEMIS-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-1892:
Priority: Minor (was: Major)
> Allow whitespace in
> --
>
> Key: ARTEMIS-1892
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1892
> Project: ActiveMQ Artemis
> Issue Type: New Feature
>Reporter: Lionel Cons
>Priority: Minor
>
> When tuning the acceptors, the {{}} elements can quickly become
> very long and hard to read.
> Here is an example from the default configuration:
> {code}
>
>name="artemis">tcp://0.0.0.0:61616?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300
> {code}
> It would be nice to be able to add whitespace to make the {{broker.xml}}
> easier to read and manage. For instance:
> {code}
>
>
> tcp://0.0.0.0:61616?
> tcpSendBufferSize=1048576;
> tcpReceiveBufferSize=1048576;
> protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;
> useEpoll=true;
> amqpCredits=1000;
> amqpLowCredits=300
>
> {code}
> It seems that stripping whitespace from the {{}} elements text
> should be enough to make it work...
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1900) Unexpected STOMP subscription errors (AMQ339016+AMQ119017)
[
https://issues.apache.org/jira/browse/ARTEMIS-1900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16498187#comment-16498187
]
Justin Bertram commented on ARTEMIS-1900:
-
I opened (and linked) ARTEMIS-1903 to deal with the logging issue.
> Unexpected STOMP subscription errors (AMQ339016+AMQ119017)
> --
>
> Key: ARTEMIS-1900
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1900
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Lionel Cons
>Priority: Major
>
> When stress testing Artemis (latest snapshot) using STOMP, I sometimes see
> subscription creation errors (AMQ339016). This is not reproducible so this is
> probably a concurrency issue.
> The STOMP client receives an {{ERROR}} frame that contains in its {{message}}
> header:
> {code}
> AMQ339016 Error creating subscription xyz
> {code}
> and in its body:
> {code}
> AMQ119017: Queue abc does not exist.
> {code}
> Also, this error is only sent to the client and not logged by the broker.
> IMHO, every time the broker reports a fatal client error (i.e. STOMP
> {{ERROR}} frame) it should also log this as a warning on its side. Let me
> know if this is specific to this case or if I should log a separate Jira
> issue to track this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1903) Log STOMP ERROR frames at WARN on the broker
[ https://issues.apache.org/jira/browse/ARTEMIS-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-1903: Priority: Minor (was: Major) > Log STOMP ERROR frames at WARN on the broker > > > Key: ARTEMIS-1903 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1903 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: STOMP >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Minor > > When the broker sends an ERROR frame to a client it should log a WARN with > the details. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-1903) Log STOMP ERROR frames at WARN on the broker
Justin Bertram created ARTEMIS-1903: --- Summary: Log STOMP ERROR frames at WARN on the broker Key: ARTEMIS-1903 URL: https://issues.apache.org/jira/browse/ARTEMIS-1903 Project: ActiveMQ Artemis Issue Type: Improvement Components: STOMP Reporter: Justin Bertram Assignee: Justin Bertram When the broker sends an ERROR frame to a client it should log a WARN with the details. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ARTEMIS-1902) Message redistribution is not stopped when consumers count on remote node reaches 0 (AMQP)
[ https://issues.apache.org/jira/browse/ARTEMIS-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martyn Taylor reassigned ARTEMIS-1902: -- Assignee: Martyn Taylor > Message redistribution is not stopped when consumers count on remote node > reaches 0 (AMQP) > -- > > Key: ARTEMIS-1902 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1902 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.0, 2.6.1 >Reporter: Martyn Taylor >Assignee: Martyn Taylor >Priority: Major > > With redistribution enabled and load balancing set to ON_DEMAND there is a > case where a consumer count on a remote node reaches 0, however the local > broker continues redistributing. This can cause a whole magnitude of issues > if the both brokers get in the same state. Messages are redistributed back > and forth between each other and never hit the local queue, resulting in > message loss and potentially an OOM as each time the message is redistributed > a copy is made. > The issue looks to be caused by the cluster getting into a state where > consumer counts are below 0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-1902) Message redistribution is not stopped when consumers count on remote node reaches 0 (AMQP)
Martyn Taylor created ARTEMIS-1902: -- Summary: Message redistribution is not stopped when consumers count on remote node reaches 0 (AMQP) Key: ARTEMIS-1902 URL: https://issues.apache.org/jira/browse/ARTEMIS-1902 Project: ActiveMQ Artemis Issue Type: Bug Reporter: Martyn Taylor With redistribution enabled and load balancing set to ON_DEMAND there is a case where a consumer count on a remote node reaches 0, however the local broker continues redistributing. This can cause a whole magnitude of issues if the both brokers get in the same state. Messages are redistributed back and forth between each other and never hit the local queue, resulting in message loss and potentially an OOM as each time the message is redistributed a copy is made. The issue looks to be caused by the cluster getting into a state where consumer counts are below 0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1902) Message redistribution is not stopped when consumers count on remote node reaches 0 (AMQP)
[ https://issues.apache.org/jira/browse/ARTEMIS-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martyn Taylor updated ARTEMIS-1902: --- Priority: Critical (was: Major) > Message redistribution is not stopped when consumers count on remote node > reaches 0 (AMQP) > -- > > Key: ARTEMIS-1902 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1902 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.0, 2.6.1 >Reporter: Martyn Taylor >Assignee: Martyn Taylor >Priority: Critical > > With redistribution enabled and load balancing set to ON_DEMAND there is a > case where a consumer count on a remote node reaches 0, however the local > broker continues redistributing. This can cause a whole magnitude of issues > if the both brokers get in the same state. Messages are redistributed back > and forth between each other and never hit the local queue, resulting in > message loss and potentially an OOM as each time the message is redistributed > a copy is made. > The issue looks to be caused by the cluster getting into a state where > consumer counts are below 0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1902) Message redistribution is not stopped when consumers count on remote node reaches 0 (AMQP)
[ https://issues.apache.org/jira/browse/ARTEMIS-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martyn Taylor updated ARTEMIS-1902: --- Affects Version/s: 2.6.0 > Message redistribution is not stopped when consumers count on remote node > reaches 0 (AMQP) > -- > > Key: ARTEMIS-1902 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1902 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.0, 2.6.1 >Reporter: Martyn Taylor >Assignee: Martyn Taylor >Priority: Major > > With redistribution enabled and load balancing set to ON_DEMAND there is a > case where a consumer count on a remote node reaches 0, however the local > broker continues redistributing. This can cause a whole magnitude of issues > if the both brokers get in the same state. Messages are redistributed back > and forth between each other and never hit the local queue, resulting in > message loss and potentially an OOM as each time the message is redistributed > a copy is made. > The issue looks to be caused by the cluster getting into a state where > consumer counts are below 0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1902) Message redistribution is not stopped when consumers count on remote node reaches 0 (AMQP)
[ https://issues.apache.org/jira/browse/ARTEMIS-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martyn Taylor updated ARTEMIS-1902: --- Affects Version/s: 2.6.1 > Message redistribution is not stopped when consumers count on remote node > reaches 0 (AMQP) > -- > > Key: ARTEMIS-1902 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1902 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.0, 2.6.1 >Reporter: Martyn Taylor >Assignee: Martyn Taylor >Priority: Major > > With redistribution enabled and load balancing set to ON_DEMAND there is a > case where a consumer count on a remote node reaches 0, however the local > broker continues redistributing. This can cause a whole magnitude of issues > if the both brokers get in the same state. Messages are redistributed back > and forth between each other and never hit the local queue, resulting in > message loss and potentially an OOM as each time the message is redistributed > a copy is made. > The issue looks to be caused by the cluster getting into a state where > consumer counts are below 0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1896) Centralize logging of authentication failures
[
https://issues.apache.org/jira/browse/ARTEMIS-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-1896:
Component/s: STOMP
> Centralize logging of authentication failures
> -
>
> Key: ARTEMIS-1896
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1896
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: STOMP
>Reporter: Lionel Cons
>Priority: Major
>
> In case of authentication failure with any protocol Artemis should log a
> warning with the faulty user name. This logging currently happens for core
> clients, but not for STOMP clients (and likely others as well).
> In my tests, the client does get a {{User name [foo] or password is invalid}}
> {{ERROR}} frame but the broker does not log anything.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1896) Centralize logging of authentication failures
[
https://issues.apache.org/jira/browse/ARTEMIS-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-1896:
Description:
In case of authentication failure with any protocol Artemis should log a
warning with the faulty user name. This logging currently happens for core
clients, but not for STOMP clients (and likely others as well).
In my tests, the client does get a {{User name [foo] or password is invalid}}
{{ERROR}} frame but the broker does not log anything.
was:
In case of authentication failure, Artemis should log a warning with the faulty
user name.
This is currently not the case, at least not when using STOMP.
In my tests, the client does get a "{{User name [foo] or password is invalid}}"
{{ERROR}} frame but the broker does not log anything in {{artemis.log}}.
> Centralize logging of authentication failures
> -
>
> Key: ARTEMIS-1896
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1896
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Lionel Cons
>Priority: Major
>
> In case of authentication failure with any protocol Artemis should log a
> warning with the faulty user name. This logging currently happens for core
> clients, but not for STOMP clients (and likely others as well).
> In my tests, the client does get a {{User name [foo] or password is invalid}}
> {{ERROR}} frame but the broker does not log anything.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1896) Centralize logging of authentication failures
[
https://issues.apache.org/jira/browse/ARTEMIS-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-1896:
Summary: Centralize logging of authentication failures (was: STOMP
authentication failures should be logged)
> Centralize logging of authentication failures
> -
>
> Key: ARTEMIS-1896
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1896
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Lionel Cons
>Priority: Major
>
> In case of authentication failure, Artemis should log a warning with the
> faulty user name.
> This is currently not the case, at least not when using STOMP.
> In my tests, the client does get a "{{User name [foo] or password is
> invalid}}" {{ERROR}} frame but the broker does not log anything in
> {{artemis.log}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1896) STOMP authentication failures should be logged
[
https://issues.apache.org/jira/browse/ARTEMIS-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16498108#comment-16498108
]
ASF GitHub Bot commented on ARTEMIS-1896:
-
GitHub user jbertram opened a pull request:
https://github.com/apache/activemq-artemis/pull/2118
STOMP work
Work for ARTEMIS-1896 and ARTEMIS-1897.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/jbertram/activemq-artemis ARTEMIS-1896
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/activemq-artemis/pull/2118.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #2118
commit 953c38a99d526e1cefe3c7c20689ab98467e4c6b
Author: Justin Bertram
Date: 2018-05-31T15:20:09Z
ARTEMIS-1896 centralize authn failure logging
Authentication failures are currently only logged for CORE clients.
This change puts the logging in a central location which all protocols
use for authentication so that authentication failures are logged for
all protocols.
commit 98288e91a91bf899679bbca885e62cc54c1f54d9
Author: Justin Bertram
Date: 2018-06-01T13:42:22Z
NO-JIRA allow enabling security at runtime
commit c9b335e99eb505f41ee4e8345917476b259828bb
Author: Justin Bertram
Date: 2018-06-01T13:42:47Z
ARTEMIS-1897 use core session for STOMP authn
> STOMP authentication failures should be logged
> --
>
> Key: ARTEMIS-1896
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1896
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Lionel Cons
>Priority: Major
>
> In case of authentication failure, Artemis should log a warning with the
> faulty user name.
> This is currently not the case, at least not when using STOMP.
> In my tests, the client does get a "{{User name [foo] or password is
> invalid}}" {{ERROR}} frame but the broker does not log anything in
> {{artemis.log}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1897) STOMP should use core session for authentication
[ https://issues.apache.org/jira/browse/ARTEMIS-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-1897: Description: The STOMP protocol manager duplicates some code that already exists in the SecurityStore implementation. Rather than using either the SecurityStore or SecurityManager directly it should simply rely on the authentication already being done through the creation of the core session. (was: The STOMP protocol manager duplicates some code that already exists in the SecurityStore implementation. It should use the SecurityStore like the other protocol heads rather than the SecurityManager (which is encapsulated in the SecurityStore already).) > STOMP should use core session for authentication > > > Key: ARTEMIS-1897 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1897 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: STOMP >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > > The STOMP protocol manager duplicates some code that already exists in the > SecurityStore implementation. Rather than using either the SecurityStore or > SecurityManager directly it should simply rely on the authentication already > being done through the creation of the core session. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1897) STOMP should use core session for authentication
[ https://issues.apache.org/jira/browse/ARTEMIS-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram updated ARTEMIS-1897: Summary: STOMP should use core session for authentication (was: STOMP protocol manager should use SecurityStore rather than SecurityManager) > STOMP should use core session for authentication > > > Key: ARTEMIS-1897 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1897 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: STOMP >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > > The STOMP protocol manager duplicates some code that already exists in the > SecurityStore implementation. It should use the SecurityStore like the other > protocol heads rather than the SecurityManager (which is encapsulated in the > SecurityStore already). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1901) Facing issue in “apache-artemis-2.6.0” while sending message in queue through REST API using JMS
[ https://issues.apache.org/jira/browse/ARTEMIS-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16498027#comment-16498027 ] Justin Bertram commented on ARTEMIS-1901: - Couple of questions... * Does it work on Artemis 2.5.0? * Can you provide a simple reproducer? The screenshots you've provided are quite limited. * Are you using auto-created or statically created queues? > Facing issue in “apache-artemis-2.6.0” while sending message in queue through > REST API using JMS > > > Key: ARTEMIS-1901 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1901 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.0 >Reporter: Sumit kumar sinha >Priority: Major > Attachments: consumer.JPG, producer.JPG > > > *We are facing issue on “apache-artemis-2.6.0” while using JMS.* > We have running environment for “apache-artemis-2.6.0” and written two java > application i.e consumer and producer. We are able to send the message from > Artemis console (send option) and consumer java application is able to show > the same (we checked using logs). > We have developed REST API in producer java application but that particular > message is not visible in Consumer java application console. > > +*The same application is running while using different version of Artemis > i.e. “apache-artemis-2.4.0”.*+ > > Below are code snippet for same (as an attachment) : > > +*Producer REST API :*+ > !producer.JPG!!consumer.JPG! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1900) Unexpected STOMP subscription errors (AMQ339016+AMQ119017)
[
https://issues.apache.org/jira/browse/ARTEMIS-1900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16498022#comment-16498022
]
Justin Bertram commented on ARTEMIS-1900:
-
Are the consumers running the whole time or are they stopping & starting during
the test? Does each consumer create its own subscription?
> Unexpected STOMP subscription errors (AMQ339016+AMQ119017)
> --
>
> Key: ARTEMIS-1900
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1900
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Lionel Cons
>Priority: Major
>
> When stress testing Artemis (latest snapshot) using STOMP, I sometimes see
> subscription creation errors (AMQ339016). This is not reproducible so this is
> probably a concurrency issue.
> The STOMP client receives an {{ERROR}} frame that contains in its {{message}}
> header:
> {code}
> AMQ339016 Error creating subscription xyz
> {code}
> and in its body:
> {code}
> AMQ119017: Queue abc does not exist.
> {code}
> Also, this error is only sent to the client and not logged by the broker.
> IMHO, every time the broker reports a fatal client error (i.e. STOMP
> {{ERROR}} frame) it should also log this as a warning on its side. Let me
> know if this is specific to this case or if I should log a separate Jira
> issue to track this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1900) Unexpected STOMP subscription errors (AMQ339016+AMQ119017)
[
https://issues.apache.org/jira/browse/ARTEMIS-1900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16498017#comment-16498017
]
Lionel Cons commented on ARTEMIS-1900:
--
There are several tests that occasionally trigger this error and the simplest
one is multiple concurrent producers sending random messages at the same time
to the same destination as well as several concurrent consumers, all running at
the same time. All the clients use STOMP. The clients and the broker run on
different two machines.
> Unexpected STOMP subscription errors (AMQ339016+AMQ119017)
> --
>
> Key: ARTEMIS-1900
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1900
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Lionel Cons
>Priority: Major
>
> When stress testing Artemis (latest snapshot) using STOMP, I sometimes see
> subscription creation errors (AMQ339016). This is not reproducible so this is
> probably a concurrency issue.
> The STOMP client receives an {{ERROR}} frame that contains in its {{message}}
> header:
> {code}
> AMQ339016 Error creating subscription xyz
> {code}
> and in its body:
> {code}
> AMQ119017: Queue abc does not exist.
> {code}
> Also, this error is only sent to the client and not logged by the broker.
> IMHO, every time the broker reports a fatal client error (i.e. STOMP
> {{ERROR}} frame) it should also log this as a warning on its side. Let me
> know if this is specific to this case or if I should log a separate Jira
> issue to track this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1900) Unexpected STOMP subscription errors (AMQ339016+AMQ119017)
[
https://issues.apache.org/jira/browse/ARTEMIS-1900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16497989#comment-16497989
]
Justin Bertram commented on ARTEMIS-1900:
-
Can you elaborate any further on the actual use-case from your stress test?
Clearly you have a client attempting to create a subscription, but I assume
that's not all the test is doing. Without more details there's not much
guidance to conduct an investigation.
> Unexpected STOMP subscription errors (AMQ339016+AMQ119017)
> --
>
> Key: ARTEMIS-1900
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1900
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Lionel Cons
>Priority: Major
>
> When stress testing Artemis (latest snapshot) using STOMP, I sometimes see
> subscription creation errors (AMQ339016). This is not reproducible so this is
> probably a concurrency issue.
> The STOMP client receives an {{ERROR}} frame that contains in its {{message}}
> header:
> {code}
> AMQ339016 Error creating subscription xyz
> {code}
> and in its body:
> {code}
> AMQ119017: Queue abc does not exist.
> {code}
> Also, this error is only sent to the client and not logged by the broker.
> IMHO, every time the broker reports a fatal client error (i.e. STOMP
> {{ERROR}} frame) it should also log this as a warning on its side. Let me
> know if this is specific to this case or if I should log a separate Jira
> issue to track this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMQ-5129) Substitute TimeTask with ScheduledExecutorService in org.apache.activemq.thread.Scheduler
[ https://issues.apache.org/jira/browse/AMQ-5129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16497915#comment-16497915 ] Gary Tully commented on AMQ-5129: - it may still be no harm to introduce the scheduled executor even with a pool of one. It would ensure the thread stays alive but with the changes in AMQ-6979 it is less likely. > Substitute TimeTask with ScheduledExecutorService in > org.apache.activemq.thread.Scheduler > - > > Key: AMQ-5129 > URL: https://issues.apache.org/jira/browse/AMQ-5129 > Project: ActiveMQ > Issue Type: Wish >Affects Versions: 5.9.0 >Reporter: matteo rulli >Priority: Major > Attachments: proposed-patch.txt > > > Since Timer has only one execution thread, long-running task can affect other > scheduled tasks. Besides, runtime exceptions thrown in TimerTasks kill the > only one running thread, bringing down the entire Scheduler. > I have the suspect that all this could relate to AMQ-3938: sometimes in very > busy environments I experience exaclty the same problem: a slow leakeage due > to temp queues that are not deleted. Since > org.apache.activemq.broker.region.RegionBroker uses a Scheduler to activate > the purgeInactiveDestinations, a crashed timer could explain why > purgeInactiveDestinations stops working. > I attached a tentative patch to migrate timer to ScheduledExecutorService. > Hope this helps. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (AMQ-6979) consumer message pull timeout being effected by long running scheduled tasks
[ https://issues.apache.org/jira/browse/AMQ-6979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved AMQ-6979. - Resolution: Fixed > consumer message pull timeout being effected by long running scheduled tasks > > > Key: AMQ-6979 > URL: https://issues.apache.org/jira/browse/AMQ-6979 > Project: ActiveMQ > Issue Type: Bug > Components: JMS client, Message Store >Affects Versions: 5.15.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 5.16.0 > > > The messagePull timeout, used for prefetch=0 consumers with > consumer.receive(timeout) is not reliable in the event that the broker > scheduler timer task is busy with long running tasks. > If an existing task exceeds the timeout then the pull response is delayed. > In the main, scheduled tasks should be short lived and in the case of message > expiry processing for topic durable subs, they may not be, depending on the > amount of durable subs and their backlog. > > The expiryProcessing scheduler task should simply signal the start of the > task such that it can return and leave the real work to the taskExecutor -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-6824) PrefetchExtension growth with transacted consumers
[ https://issues.apache.org/jira/browse/AMQ-6824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16497886#comment-16497886 ] ASF subversion and git services commented on AMQ-6824: -- Commit 63b71affbc22f2186ec6b02baeed34a77cbeb27b in activemq's branch refs/heads/master from [~gtully] [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=63b71af ] AMQ-6824 - harden test > PrefetchExtension growth with transacted consumers > -- > > Key: AMQ-6824 > URL: https://issues.apache.org/jira/browse/AMQ-6824 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 5.15.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 5.16.0 > > > With a transacted consumer on either a topic or queue the prefetch extension > increments only. This leads to flow control failing b/c the subscription is > never full. Messages can accumulate on the subscription dispatch channel if > the consumer is blocked or slow. As a result, memory usage limits can be > exceeded for topics. > There is a similar issue with client_ack mode and prefetch. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-5837) Add inflight message size to SubscriptionStatistics
[
https://issues.apache.org/jira/browse/AMQ-5837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16497875#comment-16497875
]
ASF subversion and git services commented on AMQ-5837:
--
Commit 8b4062483793a554b5cf8f65c66d2365a99c1014 in activemq's branch
refs/heads/master from [~gtully]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=8b40624 ]
AMQ-5837 - ensure test timeout > wait timeout for assertions so failures are
visible
> Add inflight message size to SubscriptionStatistics
> ---
>
> Key: AMQ-5837
> URL: https://issues.apache.org/jira/browse/AMQ-5837
> Project: ActiveMQ
> Issue Type: New Feature
> Components: Broker
>Affects Versions: 5.11.1
>Reporter: Christopher L. Shannon
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 5.12.0
>
>
> It would be useful to know the total message size of messages that are
> inflight (besides just the count) on a Subscription for monitoring and
> metrics purposes. This value can be added to {{SubscriptionStatistics}} and
> kept in up to date so it can be displayed without blocking.
> A future enhancement when AMQ-5748 is done could be to add a pending message
> statistics. AMQ-5748 is required first to be able to recover message sizes
> across a broker restart.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (AMQ-6977) JDBC Failure: Connection PoolingConnection:
[ https://issues.apache.org/jira/browse/AMQ-6977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16497791#comment-16497791 ] Robert Jin commented on AMQ-6977: - Hi Gary, here is the connection pool configuration: ... > JDBC Failure: Connection PoolingConnection: > > > Key: AMQ-6977 > URL: https://issues.apache.org/jira/browse/AMQ-6977 > Project: ActiveMQ > Issue Type: Bug > Components: JDBC >Affects Versions: 5.15.2 > Environment: Red Hat Enterprise Linux Server release 7.2 >Reporter: Robert Jin >Priority: Blocker > > The log like following appeared every other time(1h~several days). After four > months, the mq didn't work anymore. > 2018-02-03 09:16:32,028 | WARN | JDBC Failure: Connection PoolingConnection: > org.apache.commons.pool.impl.GenericKeyedObjectPool@1697db40 is closed. | > org.apache.activemq.store.jdbc.JDBCPersistenceAdapter | ActiveMQ Transport: > tcp:///172.31.56.153:38168@61616 > java.sql.SQLException: Connection PoolingConnection: > org.apache.commons.pool.impl.GenericKeyedObjectPool@20e135f1 is closed. > at > org.apache.commons.dbcp.DelegatingConnection.checkOpen(DelegatingConnection.java:519)[commons-dbcp-1.5.jar:1.5-SNAPSHOT] > at > org.apache.commons.dbcp.DelegatingConnection.prepareStatement(DelegatingConnection.java:286)[commons-dbcp-1.5.jar:1.5-SNAPSHOT] > at > org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.prepareStatement(PoolingDataSource.java:322)[commons-dbcp-1.5.jar:1.5-SNAPSHOT] > at > org.apache.activemq.store.jdbc.TransactionContext$UnlockOnCloseConnection.prepareStatement(TransactionContext.java:308)[activemq-jdbc-store-5.15.2.jar:5.15.2] > at > org.apache.activemq.store.jdbc.adapter.DefaultJDBCAdapter.doAddMessage(DefaultJDBCAdapter.java:227)[activemq-jdbc-store-5.15.2.jar:5.15.2] > at > org.apache.activemq.store.jdbc.JDBCMessageStore.addMessage(JDBCMessageStore.java:158)[activemq-jdbc-store-5.15.2.jar:5.15.2] > at > org.apache.activemq.store.memory.MemoryTransactionStore.addMessage(MemoryTransactionStore.java:352)[activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.store.memory.MemoryTransactionStore$1.asyncAddQueueMessage(MemoryTransactionStore.java:159)[activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.Queue.doMessageSend(Queue.java:854)[activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.Queue.send(Queue.java:743)[activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.AbstractRegion.send(AbstractRegion.java:505)[activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.region.RegionBroker.send(RegionBroker.java:459)[activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.jmx.ManagedRegionBroker.send(ManagedRegionBroker.java:293)[activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.BrokerFilter.send(BrokerFilter.java:154)[activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.CompositeDestinationBroker.send(CompositeDestinationBroker.java:96)[activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.TransactionBroker.send(TransactionBroker.java:293)[activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.BrokerFilter.send(BrokerFilter.java:154)[activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.BrokerFilter.send(BrokerFilter.java:154)[activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.TransportConnection.processMessage(TransportConnection.java:572)[activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:768)[activemq-client-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:330)[activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:194)[activemq-broker-5.15.2.jar:5.15.2] > at > org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50)[activemq-client-5.15.2.jar:5.15.2] > at > org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:125)[activemq-client-5.15.2.jar:5.15.2] > at > org.apache.activemq.transport.AbstractInactivityMonitor.onCommand(AbstractInactivityMonitor.java:301)[activemq-client-5.15.2.jar:5.15.2] > at > org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83)[activemq-client-5.15.2.jar:5.15.2] > at > org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:233)[activemq-client-5.15.2.jar:5.15.2] > at > org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:215)[activemq-client-5.15.2.jar:5.15.2] > at java.lang.Thread.run(Thread.java:745)[:1.8.0_65] > 2018-02-03 09:16:32,030 | WARN | Error while
[jira] [Commented] (ARTEMIS-1890) # any-word wildcard doesn't match zero words if not used at the end of a wildcard expression
[
https://issues.apache.org/jira/browse/ARTEMIS-1890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16497761#comment-16497761
]
ASF GitHub Bot commented on ARTEMIS-1890:
-
Github user mtaylor commented on the issue:
https://github.com/apache/activemq-artemis/pull/2113
I see it's already merged. This is an enhancement not a bug. But, +1 on
the change and it landing in 2.7.0 there's a clear use case for it.
I think the important thing here is review the documentation, as both
interpretations from @michaelandrepearce and @jostbg are reasonable.
> # any-word wildcard doesn't match zero words if not used at the end of a
> wildcard expression
>
>
> Key: ARTEMIS-1890
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1890
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.6.0
>Reporter: Johan Stenberg
>Priority: Major
> Attachments: Artemis1890_AnyWordWildCard_Test.java
>
>
> [https://activemq.apache.org/artemis/docs/latest/wildcard-syntax.html] states
> that the {{#}} wildcard character means _"match any sequence of *zero* or
> more words"_. This however is only true if the wild card is the last
> character in a wildcard expression. If any word comes after the wildcard
> character then the actual behavior is _"match any sequence of *one* or more
> words"_
> This means, the pattern {{topics.#.FOO}} matches {{topics.abc.FOO}} but not
> {{topics.FOO}}
> I am attaching a test case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ARTEMIS-1901) Facing issue in “apache-artemis-2.6.0” while sending message in queue through REST API using JMS
Sumit kumar sinha created ARTEMIS-1901: -- Summary: Facing issue in “apache-artemis-2.6.0” while sending message in queue through REST API using JMS Key: ARTEMIS-1901 URL: https://issues.apache.org/jira/browse/ARTEMIS-1901 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 2.6.0 Reporter: Sumit kumar sinha Attachments: consumer.JPG, producer.JPG *We are facing issue on “apache-artemis-2.6.0” while using JMS.* We have running environment for “apache-artemis-2.6.0” and written two java application i.e consumer and producer. We are able to send the message from Artemis console (send option) and consumer java application is able to show the same (we checked using logs). We have developed REST API in producer java application but that particular message is not visible in Consumer java application console. +*The same application is running while using different version of Artemis i.e. “apache-artemis-2.4.0”.*+ Below are code snippet for same (as an attachment) : +*Producer REST API :*+ !producer.JPG!!consumer.JPG! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-1900) Unexpected STOMP subscription errors (AMQ339016+AMQ119017)
Lionel Cons created ARTEMIS-1900:
Summary: Unexpected STOMP subscription errors (AMQ339016+AMQ119017)
Key: ARTEMIS-1900
URL: https://issues.apache.org/jira/browse/ARTEMIS-1900
Project: ActiveMQ Artemis
Issue Type: Bug
Reporter: Lionel Cons
When stress testing Artemis (latest snapshot) using STOMP, I sometimes see
subscription creation errors (AMQ339016). This is not reproducible so this is
probably a concurrency issue.
The STOMP client receives an {{ERROR}} frame that contains in its {{message}}
header:
{code}
AMQ339016 Error creating subscription xyz
{code}
and in its body:
{code}
AMQ119017: Queue abc does not exist.
{code}
Also, this error is only sent to the client and not logged by the broker. IMHO,
every time the broker reports a fatal client error (i.e. STOMP {{ERROR}} frame)
it should also log this as a warning on its side. Let me know if this is
specific to this case or if I should log a separate Jira issue to track this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
