[jira] [Commented] (ARTEMIS-1904) Jmx Management Security Tests
[ https://issues.apache.org/jira/browse/ARTEMIS-1904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16501339#comment-16501339 ] ASF GitHub Bot commented on ARTEMIS-1904: - GitHub user gaohoward opened a pull request: https://github.com/apache/activemq-artemis/pull/2122 ARTEMIS-1904 Jmx Management Security Tests * Added tests for jmx security * Removed ArtemisRMIServerSocketFactory as it does nothing special (instead use default factory from jdk) You can merge this pull request into a Git repository by running: $ git pull https://github.com/gaohoward/activemq-artemis a_jmx Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2122.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 #2122 commit 95ecb071f08dcb8b406c2600d3c635047e415b20 Author: Howard Gao Date: 2018-06-05T06:13:30Z ARTEMIS-1904 Jmx Management Security Tests * Added tests for jmx security * Removed ArtemisRMIServerSocketFactory as it does nothing special (instead use default factory from jdk) > Jmx Management Security Tests > - > > Key: ARTEMIS-1904 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1904 > Project: ActiveMQ Artemis > Issue Type: Test > Components: Broker >Affects Versions: 2.6.1 >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Fix For: 2.7.0 > > > Adding tests for jmx security (authentication/authorization) functionalities. -- 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&focusedCommentId=16501323#comment-16501323
]
Lionel Cons commented on ARTEMIS-1900:
--
I've tried again this morning. I could trigger the error with queues and not
with topics.
> 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-1906) anycastPrefix and multicastPrefix should be kept in mapped addresses
[
https://issues.apache.org/jira/browse/ARTEMIS-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16501319#comment-16501319
]
Lionel Cons commented on ARTEMIS-1906:
--
After testing, it seems that the wildcard setting is problematic.
We need to have compatibility with ActiveMQ 5 destinations. They look like
{{/queue/foo.bar}} where {{/queue/}} really is only a prefix while {{foo.bar}}
is the usual string made of words joined by dots. We need to be able to use
wildcards there, with dot being the usual name separator.
So we cannot set the name separator to slash so the address settings do not
match.
The documentation
(https://activemq.apache.org/artemis/docs/latest/wildcard-syntax.html) is not
very detailed. Would it make sense to have the string {{abcdef}} match the
wildcard {{abc#}}? If yes then the address settings would match...
> anycastPrefix and multicastPrefix should be kept in mapped addresses
>
>
> Key: ARTEMIS-1906
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1906
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Lionel Cons
>Priority: Major
>
> For STOMP (at least), {{anycastPrefix}} and {{multicastPrefix}} are used to
> map destinations to addresses and routing types.
> In order to have compatibility with other brokers such as ActiveMQ 5 or
> RabbitMQ, these prefixes must be set to {{anycastPrefix=/queue/}} and
> {{multicastPrefix=/topic/}}. With these settings, a destination like
> {{/queue/foo}} works like a JMS queue while {{/topic/foo}} works like a JMS
> topic. So far, so good.
> Unfortunately, the current implementation removes these prefixes when mapping
> to addresses. This means that the two (completely unrelated, see
> ARTEMIS-1794) destinations {{/queue/foo}} and {{/topic/foo}} map to the exact
> same address named {{foo}}. Messaging does work as expected because the same
> address can have multiple routing types but monitoring and security become
> problematic.
> Security is defined per address so the two destinations {{/queue/foo}} and
> {{/topic/foo}} cannot have different security settings.
> Similarly, some monitoring information is attached to the address objects so
> {{/queue/foo}} and {{/topic/foo}} cannot have different monitoring metrics.
> It seems all these problems would disappear if prefixes would be kept when
> mapping STOMP destinations to addresses.
> Note: similar problems might exist with other protocols but I've tested it
> only using STOMP.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1906) anycastPrefix and multicastPrefix should be kept in mapped addresses
[
https://issues.apache.org/jira/browse/ARTEMIS-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16501296#comment-16501296
]
Lionel Cons commented on ARTEMIS-1906:
--
[~jbertram] thanks for pointing me to these settings.
I did check
https://activemq.apache.org/artemis/docs/latest/configuration-index.html#address-setting-type
before creating this Jira issue. It would make sense to list them in this
configuration reference page.
> anycastPrefix and multicastPrefix should be kept in mapped addresses
>
>
> Key: ARTEMIS-1906
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1906
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Lionel Cons
>Priority: Major
>
> For STOMP (at least), {{anycastPrefix}} and {{multicastPrefix}} are used to
> map destinations to addresses and routing types.
> In order to have compatibility with other brokers such as ActiveMQ 5 or
> RabbitMQ, these prefixes must be set to {{anycastPrefix=/queue/}} and
> {{multicastPrefix=/topic/}}. With these settings, a destination like
> {{/queue/foo}} works like a JMS queue while {{/topic/foo}} works like a JMS
> topic. So far, so good.
> Unfortunately, the current implementation removes these prefixes when mapping
> to addresses. This means that the two (completely unrelated, see
> ARTEMIS-1794) destinations {{/queue/foo}} and {{/topic/foo}} map to the exact
> same address named {{foo}}. Messaging does work as expected because the same
> address can have multiple routing types but monitoring and security become
> problematic.
> Security is defined per address so the two destinations {{/queue/foo}} and
> {{/topic/foo}} cannot have different security settings.
> Similarly, some monitoring information is attached to the address objects so
> {{/queue/foo}} and {{/topic/foo}} cannot have different monitoring metrics.
> It seems all these problems would disappear if prefixes would be kept when
> mapping STOMP destinations to addresses.
> Note: similar problems might exist with other protocols but I've tested it
> only using STOMP.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (ARTEMIS-1618) DeadLettering on AMQP ignores maxDeliveryAttempts endlessly redelivering of released messages
[ https://issues.apache.org/jira/browse/ARTEMIS-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish closed ARTEMIS-1618. - Resolution: Not A Problem The broker is behaving as the AMQP specification requires it to based on the configuration given. > DeadLettering on AMQP ignores maxDeliveryAttempts endlessly redelivering of > released messages > - > > Key: ARTEMIS-1618 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1618 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 2.4.0, 2.6.0 > Environment: Artemis 2.6.0 >Reporter: Johan Stenberg >Priority: Major > Attachments: Artemis1618_AmqpDeadLettering_Test.java > > > A rejected message gets infinitely redelivered, even if maxDeliveryAttempts > and dead letter queue are specified. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (ARTEMIS-1875) Redistribution of messages sometimes does not occur if original message sent using link routing via AMQP
[ https://issues.apache.org/jira/browse/ARTEMIS-1875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] clebert suconic closed ARTEMIS-1875. > Redistribution of messages sometimes does not occur if original message sent > using link routing via AMQP > > > Key: ARTEMIS-1875 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1875 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.0 >Reporter: Martyn Taylor >Assignee: Martyn Taylor >Priority: Critical > Fix For: 2.6.1, 2.7.0 > > > Message redistribution (to another broker in the cluster), relies on the > message sender address. However there are circumstances (such as using link > routing via AMQP) when this is not set. Messages may be lost under these > circumstances. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1618) DeadLettering on AMQP ignores maxDeliveryAttempts endlessly redelivering of released messages
[ https://issues.apache.org/jira/browse/ARTEMIS-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16501014#comment-16501014 ] Robbie Gemmell commented on ARTEMIS-1618: - Yep, using the client-side redelivery enforcement along with recover() (which is performed client-side to satisfy JMS stated ordering behaviour) but then specifically telling it to RELEASE in this way is really quite odd, leading it to repeat. Leaving the outcome configuration at its default will lead the server side delivery count to increment, and so is more likely to give you behaviour as you desire. > DeadLettering on AMQP ignores maxDeliveryAttempts endlessly redelivering of > released messages > - > > Key: ARTEMIS-1618 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1618 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 2.4.0, 2.6.0 > Environment: Artemis 2.6.0 >Reporter: Johan Stenberg >Priority: Major > Attachments: Artemis1618_AmqpDeadLettering_Test.java > > > A rejected message gets infinitely redelivered, even if maxDeliveryAttempts > and dead letter queue are specified. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=16500816#comment-16500816 ] ASF subversion and git services commented on ARTEMIS-1902: -- Commit db973cc2616749310be3dc21211d438b927e96fe in activemq-artemis's branch refs/heads/2.6.x from [~jbertram] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=db973cc ] ARTEMIS-1902 decrement before returning (cherry picked from commit be36d3078ceafe3df06a1686426f5d948dfadc2c) > 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.5.0, 2.6.0 >Reporter: Martyn Taylor >Assignee: Martyn Taylor >Priority: Critical > Fix For: 2.6.1, 2.7.0 > > > 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] [Commented] (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:comment-tabpanel&focusedCommentId=16500812#comment-16500812 ] ASF subversion and git services commented on ARTEMIS-1902: -- Commit be36d3078ceafe3df06a1686426f5d948dfadc2c in activemq-artemis's branch refs/heads/master from [~jbertram] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=be36d30 ] ARTEMIS-1902 decrement before returning > 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.5.0, 2.6.0 >Reporter: Martyn Taylor >Assignee: Martyn Taylor >Priority: Critical > Fix For: 2.6.1, 2.7.0 > > > 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] [Commented] (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:comment-tabpanel&focusedCommentId=16500814#comment-16500814 ] ASF GitHub Bot commented on ARTEMIS-1902: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2121 > 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.5.0, 2.6.0 >Reporter: Martyn Taylor >Assignee: Martyn Taylor >Priority: Critical > Fix For: 2.6.1, 2.7.0 > > > 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] [Commented] (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:comment-tabpanel&focusedCommentId=16500784#comment-16500784 ] ASF GitHub Bot commented on ARTEMIS-1902: - GitHub user jbertram opened a pull request: https://github.com/apache/activemq-artemis/pull/2121 ARTEMIS-1902 decrement before returning You can merge this pull request into a Git repository by running: $ git pull https://github.com/jbertram/activemq-artemis ARTEMIS-1902 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2121.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 #2121 commit be36d3078ceafe3df06a1686426f5d948dfadc2c Author: Justin Bertram Date: 2018-06-04T20:01:04Z ARTEMIS-1902 decrement before returning > 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.5.0, 2.6.0 >Reporter: Martyn Taylor >Assignee: Martyn Taylor >Priority: Critical > Fix For: 2.6.1, 2.7.0 > > > 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] [Commented] (ARTEMIS-1618) DeadLettering on AMQP ignores maxDeliveryAttempts endlessly redelivering of released messages
[ https://issues.apache.org/jira/browse/ARTEMIS-1618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16500738#comment-16500738 ] Timothy Bish commented on ARTEMIS-1618: --- Given that the test is using an outcome of RELEASED then broker is being instructed not to increment the delivery count in which case it would never be applying the maxDeliveries value as the message would always appear to it to be on it's first delivery. > DeadLettering on AMQP ignores maxDeliveryAttempts endlessly redelivering of > released messages > - > > Key: ARTEMIS-1618 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1618 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 2.4.0, 2.6.0 > Environment: Artemis 2.6.0 >Reporter: Johan Stenberg >Priority: Major > Attachments: Artemis1618_AmqpDeadLettering_Test.java > > > A rejected message gets infinitely redelivered, even if maxDeliveryAttempts > and dead letter queue are specified. -- 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&focusedCommentId=16500685#comment-16500685
]
Justin Bertram commented on ARTEMIS-1900:
-
Is the failure occurring when creating the subscription on a "/queue/" or
"/topic/" destination?
> 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] [Assigned] (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 reassigned ARTEMIS-1896:
---
Assignee: Justin Bertram
> 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
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.7.0
>
>
> 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] [Resolved] (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 resolved ARTEMIS-1896.
-
Resolution: Fixed
Fix Version/s: 2.7.0
> 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
> Fix For: 2.7.0
>
>
> 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] [Resolved] (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 resolved ARTEMIS-1903. - Resolution: Fixed Fix Version/s: 2.7.0 > 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 > Fix For: 2.7.0 > > > 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] [Resolved] (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 resolved ARTEMIS-1897. - Resolution: Fixed Fix Version/s: 2.7.0 > 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 > Fix For: 2.7.0 > > > 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] [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&focusedCommentId=16500583#comment-16500583
]
Justin Bertram commented on ARTEMIS-1742:
-
I can't reproduce the original issue. If the original problem still exists or
there are other problems I would need some way to reproduce the problem before
I could investigate further.
> 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] [Commented] (ARTEMIS-1906) anycastPrefix and multicastPrefix should be kept in mapped addresses
[
https://issues.apache.org/jira/browse/ARTEMIS-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16500577#comment-16500577
]
Justin Bertram commented on ARTEMIS-1906:
-
Changing the semantics of {{anycastPrefix}} and {{multicastPrefix}} would break
the use-case for which they were originally implemented so I don't think that's
a viable solution to the issue with your use-case.
However, I think you can solve your issue without using {{anycastPrefix}} or
{{multicastPrefix}} at all. Instead I think you should try using address
settings to control the routing types for auto-created addresses and queues.
For example:
{code:xml}
ANYCAST
ANYCAST
MULTICAST
MULTICAST
/
{code}
By using this method rather that the prefixes the {{/queue/}} addresses would
be 100% independent of the {{/topic/}} addresses which should solve your
monitoring and security issues.
> anycastPrefix and multicastPrefix should be kept in mapped addresses
>
>
> Key: ARTEMIS-1906
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1906
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Lionel Cons
>Priority: Major
>
> For STOMP (at least), {{anycastPrefix}} and {{multicastPrefix}} are used to
> map destinations to addresses and routing types.
> In order to have compatibility with other brokers such as ActiveMQ 5 or
> RabbitMQ, these prefixes must be set to {{anycastPrefix=/queue/}} and
> {{multicastPrefix=/topic/}}. With these settings, a destination like
> {{/queue/foo}} works like a JMS queue while {{/topic/foo}} works like a JMS
> topic. So far, so good.
> Unfortunately, the current implementation removes these prefixes when mapping
> to addresses. This means that the two (completely unrelated, see
> ARTEMIS-1794) destinations {{/queue/foo}} and {{/topic/foo}} map to the exact
> same address named {{foo}}. Messaging does work as expected because the same
> address can have multiple routing types but monitoring and security become
> problematic.
> Security is defined per address so the two destinations {{/queue/foo}} and
> {{/topic/foo}} cannot have different security settings.
> Similarly, some monitoring information is attached to the address objects so
> {{/queue/foo}} and {{/topic/foo}} cannot have different monitoring metrics.
> It seems all these problems would disappear if prefixes would be kept when
> mapping STOMP destinations to addresses.
> Note: similar problems might exist with other protocols but I've tested it
> only using STOMP.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-1905) When using JMS API over STOMP protocol only multicast destinations are created
[
https://issues.apache.org/jira/browse/ARTEMIS-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-1905.
-
Resolution: Not A Problem
bq. ...that is non-standard since there is no {{destination-type}} header
defined in STOMP protocol.
It doesn't make a lot of sense to talk about "standard" ways to define the
semantics of a destination in STOMP because there intentionally aren't any
standards regarding destination semantics (at least from what I can tell).
[When providing an overview of the protocol the STOMP 1.2 specification
says|https://stomp.github.io/stomp-specification-1.2.html#Protocol_Overview]:
bq. A STOMP server is modelled as a set of destinations to which messages can
be sent. The STOMP protocol treats destinations as opaque string and their
syntax is server implementation specific. Additionally STOMP does not define
what the delivery semantics of destinations should be. The delivery, or
"message exchange", semantics of destinations can vary from server to server
and even from destination to destination. This allows servers to be creative
with the semantics that they can support with STOMP.
Then [when discussing the destination header in the {{SEND}} frame it
says|https://stomp.github.io/stomp-specification-1.2.html#SEND]:
bq. Note that STOMP treats this destination as an opaque string and no delivery
semantics are assumed by the name of a destination. You should consult your
STOMP server's documentation to find out how to construct a destination name
which gives you the delivery semantics that your application needs.
Finally, [when discussing the {{SUBSCRIBE}} frame it
says|https://stomp.github.io/stomp-specification-1.2.html#SUBSCRIBE]:
bq. STOMP servers MAY support additional server specific headers to customize
the delivery semantics of the subscription. Consult your server's documentation
for details.
Therefore, the broker supports a handful of different ways to specify which
semantics are desired both on the client-side and broker-side.
On the client-side the user can specify the {{destination-type}} or
{{subscription-type}} headers for the {{SEND}} and {{SUBSCRIBE}} frames
respectively. These headers are discussed further in the "Mapping Stomp
destinations to addresses and queues" section of the [Protocols and
Interoperability|https://activemq.apache.org/artemis/docs/latest/protocols-interoperability.html]
chapter.
On the broker-side there are two main options:
# Using prefixes.
# Using address settings.
Using prefixes involves specifying the {{anycastPrefix}} and/or the
{{multicastPrefix}} on the acceptor which the STOMP client is using. For the
STOMP use-case these prefixes tell the broker that destinations using them
should be treated as anycast or multicast. For example, if the acceptor has
{{anycastPrefix=queue/}} then when a STOMP client sends a message to
{{destination:queue/foo}} the broker will auto-create the address {{foo}} and
queue {{foo}} appropriately as anycast. Additionally, if the acceptor has
{{multicastPrefix=topic/}} then when a STOMP client sends a message to
{{destination:topic/bar}} the broker will auto-create the address {{bar}} as
multicast, but it won't create a queue since multicast (i.e. pub/sub) semantics
require a client to explicitly create a subscription to receive those messages.
Using address settings involves defining address-setting elements whose match
corresponds with the destination names the clients will use along with the
proper delimiter to enabled matching. For example, broker.xml could use the
following:
{code:xml}
ANYCAST
ANYCAST
MULTICAST
MULTICAST
/
{code}
Then if a STOMP client sends a message to {{destination:queue/foo}} the broker
will auto-create the address {{queue/foo}} and queue {{queue/foo}}
appropriately as anycast. Additionally, if a STOMP client sends a message to
{{destination:topic/bar}} the broker will auto-create the address {{topic/bar}}
as multicast, but it won't create a queue as previously explained.
Note: Using prefixes and address settings ultimately results in different
address and queue names because using the prefixes will strip the prefix
whereas using the address settings won't.
> When using JMS API over STOMP protocol only multicast destinations are created
> --
>
> Key: ARTEMIS-1905
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1905
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker, STOMP
>Affects Versions: 2.6.0
>Reporter: Tom Ross
>Assignee: Justin Bertram
>Priority: Major
>
> When calling JMS API {{createQueue()}} only multicast destinations are
> created in the broker back end. The call to {{createQueue
[jira] [Updated] (ARTEMIS-1905) When using JMS API over STOMP protocol only multicast destinations are created
[
https://issues.apache.org/jira/browse/ARTEMIS-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-1905:
Description:
When calling JMS API {{createQueue()}} only multicast destinations are created
in the broker back end. The call to {{createQueue()}} should result in a
anycast destination to be created.
Also when sending a frame like would result in multicast destination.
{noformat}
SEND
destination:queue/foo
text
{noformat}
It's possible to add {{destination-type}} header to the frame
{noformat}
SEND
destination:queue/foo
destination-type:ANYCAST
text
{noformat}
However, that is non-standard since there is no {{destination-type}} header
defined in STOMP protocol.
was:
When calling JMS API {{createQueue()}} only multicast destinations are created
in the broker back end. The call to {{createQueue()}} should result in a
anycast destination to be created.
Also when sending a frame like would result in multicast destination.
{noformat}
SEND
destination:queue/foo
text
{noformat}
It's possible to add {{destination-type}} header to the frame
{noformat}
SEND
destination:queue/foo
destination-type:ANYCAST
text
{noformat}
However, that is non-standard since there is no {{destination-type}} header
defined in STOMP protocol.
> When using JMS API over STOMP protocol only multicast destinations are created
> --
>
> Key: ARTEMIS-1905
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1905
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker, STOMP
>Affects Versions: 2.6.0
>Reporter: Tom Ross
>Assignee: Justin Bertram
>Priority: Major
>
> When calling JMS API {{createQueue()}} only multicast destinations are
> created in the broker back end. The call to {{createQueue()}} should result
> in a anycast destination to be created.
> Also when sending a frame like would result in multicast destination.
> {noformat}
> SEND
> destination:queue/foo
> text
> {noformat}
> It's possible to add {{destination-type}} header to the frame
> {noformat}
> SEND
> destination:queue/foo
> destination-type:ANYCAST
> text
> {noformat}
> However, that is non-standard since there is no {{destination-type}} header
> defined in STOMP protocol.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1905) When using JMS API over STOMP protocol only multicast destinations are created
[
https://issues.apache.org/jira/browse/ARTEMIS-1905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram updated ARTEMIS-1905:
Description:
When calling JMS API {{createQueue()}} only multicast destinations are created
in the broker back end. The call to {{createQueue()}} should result in a
anycast destination to be created.
Also when sending a frame like would result in multicast destination.
{noformat}
SEND
destination:queue/foo
text
{noformat}
It's possible to add {{destination-type}} header to the frame
{noformat}
SEND
destination:queue/foo
destination-type:ANYCAST
text
{noformat}
However, that is non-standard since there is no {{destination-type}} header
defined in STOMP protocol.
was:
When calling JMS API createQueue() only multicast destinations are created in
the broker back end. The call to createQueue() should result in a anycast
destination to be created.
Also when sending a frame like would result in multicast destination.
"SEND\n" +
"destination:queue/foo\n" +
"\n" +
text +
END_OF_FRAME;
It's possible to add destination-type header to the frame
"SEND\n" +
"destination:queue/foo\n" +
"destination-type:ANYCAST\n" +
"\n" +
text +
END_OF_FRAME;
but that is non standart since there is no destination-type header defined in
STOMP protocol.
> When using JMS API over STOMP protocol only multicast destinations are created
> --
>
> Key: ARTEMIS-1905
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1905
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker, STOMP
>Affects Versions: 2.6.0
>Reporter: Tom Ross
>Assignee: Justin Bertram
>Priority: Major
>
> When calling JMS API {{createQueue()}} only multicast destinations are
> created in the broker back end. The call to {{createQueue()}} should result
> in a anycast destination to be created.
> Also when sending a frame like would result in multicast destination.
> {noformat}
> SEND
> destination:queue/foo
> text
> {noformat}
> It's possible to add {{destination-type}} header to the frame
> {noformat}
> SEND
> destination:queue/foo
> destination-type:ANYCAST
> text
> {noformat}
> However, that is non-standard since there is no {{destination-type}} header
> defined in STOMP protocol.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1897) STOMP should use core session for authentication
[ https://issues.apache.org/jira/browse/ARTEMIS-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16500422#comment-16500422 ] ASF subversion and git services commented on ARTEMIS-1897: -- Commit c1b0f1eb853c94e6a5bf31c0c0771025b7da7936 in activemq-artemis's branch refs/heads/master from [~jbertram] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=c1b0f1e ] ARTEMIS-1897 use core session for STOMP authn > 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] [Commented] (ARTEMIS-1896) Centralize logging of authentication failures
[
https://issues.apache.org/jira/browse/ARTEMIS-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16500421#comment-16500421
]
ASF subversion and git services commented on ARTEMIS-1896:
--
Commit ef6e3948fd416996059fdd83568388c2eb44ab53 in activemq-artemis's branch
refs/heads/master from [~jbertram]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=ef6e394 ]
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.
> 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] [Commented] (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:comment-tabpanel&focusedCommentId=16500423#comment-16500423 ] ASF subversion and git services commented on ARTEMIS-1903: -- Commit 5b7b84a1b3e1eb4a78cc2e391e0c77baa7e983f2 in activemq-artemis's branch refs/heads/master from [~jbertram] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=5b7b84a ] ARTEMIS-1903 Log STOMP ERROR frames at WARN > 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] [Commented] (ARTEMIS-1896) Centralize logging of authentication failures
[
https://issues.apache.org/jira/browse/ARTEMIS-1896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16500424#comment-16500424
]
ASF GitHub Bot commented on ARTEMIS-1896:
-
Github user asfgit closed the pull request at:
https://github.com/apache/activemq-artemis/pull/2118
> 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] [Resolved] (ARTEMIS-1892) Allow whitespace in
[
https://issues.apache.org/jira/browse/ARTEMIS-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-1892.
-
Resolution: Fixed
Fix Version/s: 2.7.0
> 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
> Fix For: 2.7.0
>
>
> 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&focusedCommentId=16500301#comment-16500301
]
ASF subversion and git services commented on ARTEMIS-1892:
--
Commit 9183172de348b1e376b46329da8bdcada8ff1bfc in activemq-artemis's branch
refs/heads/master from [~jbertram]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=9183172 ]
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
>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&focusedCommentId=16500303#comment-16500303
]
ASF GitHub Bot commented on ARTEMIS-1892:
-
Github user asfgit closed the pull request at:
https://github.com/apache/activemq-artemis/pull/2120
> 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] [Closed] (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 ] clebert suconic closed ARTEMIS-1902. Resolution: Fixed > 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.5.0, 2.6.0 >Reporter: Martyn Taylor >Assignee: Martyn Taylor >Priority: Critical > Fix For: 2.7.0, 2.6.1 > > > 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 ] clebert suconic updated ARTEMIS-1902: - Affects Version/s: (was: 2.6.1) 2.5.0 Fix Version/s: 2.6.1 2.7.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.5.0, 2.6.0 >Reporter: Martyn Taylor >Assignee: Martyn Taylor >Priority: Critical > Fix For: 2.6.1, 2.7.0 > > > 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] [Commented] (ARTEMIS-1895) Add duplicate metadata failure callback to ActiveMQServerPlugin
[ https://issues.apache.org/jira/browse/ARTEMIS-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16500256#comment-16500256 ] ASF GitHub Bot commented on ARTEMIS-1895: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2116 > Add duplicate metadata failure callback to ActiveMQServerPlugin > --- > > Key: ARTEMIS-1895 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1895 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.6.0 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Minor > Fix For: 2.7.0 > > > I have a usecase where it would be useful to have a callback as part of the > plugin api when there is duplicate session metadata detected (ie duplicate > clientId). This new callback will allow a user to add custom handling such > as logging, etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1895) Add duplicate metadata failure callback to ActiveMQServerPlugin
[ https://issues.apache.org/jira/browse/ARTEMIS-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16500255#comment-16500255 ] ASF subversion and git services commented on ARTEMIS-1895: -- Commit 40ade11981135709e7299a295d1f6c8b9de0f4b3 in activemq-artemis's branch refs/heads/master from [~cshannon] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=40ade11 ] ARTEMIS-1895 - Add duplicate metadata failure callback to ActiveMQServerPlugin Add a callback on duplicate metadata which will allow extra functionality to be added. > Add duplicate metadata failure callback to ActiveMQServerPlugin > --- > > Key: ARTEMIS-1895 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1895 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.6.0 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Minor > Fix For: 2.7.0 > > > I have a usecase where it would be useful to have a callback as part of the > plugin api when there is duplicate session metadata detected (ie duplicate > clientId). This new callback will allow a user to add custom handling such > as logging, etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=16500243#comment-16500243 ] ASF subversion and git services commented on ARTEMIS-1902: -- Commit a5fce98dadda9be6265ba79b771bdc83a3bef593 in activemq-artemis's branch refs/heads/2.6.x from [~martyntaylor] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=a5fce98 ] ARTEMIS-1902 Ensure ServerConsumer close done once Calling close multiple times on ServerConsumer can result in multiple notifications being routed around the cluster. This causes cluster topology info to become skewed. Which affects a number of components such as message redistribution, metrics and can eventually cause OOM should multiple queues be redistributing at the same time. (cherry picked from commit dde60b136a8ab2922bf9455abe6a78580ea0c442) > 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] [Commented] (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:comment-tabpanel&focusedCommentId=16500239#comment-16500239 ] ASF subversion and git services commented on ARTEMIS-1902: -- Commit dde60b136a8ab2922bf9455abe6a78580ea0c442 in activemq-artemis's branch refs/heads/master from [~martyntaylor] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=dde60b1 ] ARTEMIS-1902 Ensure ServerConsumer close done once Calling close multiple times on ServerConsumer can result in multiple notifications being routed around the cluster. This causes cluster topology info to become skewed. Which affects a number of components such as message redistribution, metrics and can eventually cause OOM should multiple queues be redistributing at the same time. > 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] [Commented] (ARTEMIS-1895) Add duplicate metadata failure callback to ActiveMQServerPlugin
[ https://issues.apache.org/jira/browse/ARTEMIS-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16500238#comment-16500238 ] ASF GitHub Bot commented on ARTEMIS-1895: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2116 thanks a lot.. merging > Add duplicate metadata failure callback to ActiveMQServerPlugin > --- > > Key: ARTEMIS-1895 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1895 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.6.0 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Minor > Fix For: 2.7.0 > > > I have a usecase where it would be useful to have a callback as part of the > plugin api when there is duplicate session metadata detected (ie duplicate > clientId). This new callback will allow a user to add custom handling such > as logging, etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1895) Add duplicate metadata failure callback to ActiveMQServerPlugin
[ https://issues.apache.org/jira/browse/ARTEMIS-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16500237#comment-16500237 ] ASF GitHub Bot commented on ARTEMIS-1895: - Github user cshannon commented on the issue: https://github.com/apache/activemq-artemis/pull/2116 The build looks good now > Add duplicate metadata failure callback to ActiveMQServerPlugin > --- > > Key: ARTEMIS-1895 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1895 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.6.0 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Minor > Fix For: 2.7.0 > > > I have a usecase where it would be useful to have a callback as part of the > plugin api when there is duplicate session metadata detected (ie duplicate > clientId). This new callback will allow a user to add custom handling such > as logging, etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-1907) Confusion between AIO and ASYNCIO
Lionel Cons created ARTEMIS-1907:
Summary: Confusion between AIO and ASYNCIO
Key: ARTEMIS-1907
URL: https://issues.apache.org/jira/browse/ARTEMIS-1907
Project: ActiveMQ Artemis
Issue Type: Bug
Reporter: Lionel Cons
It seems that, in the user manual at least, there is a confusion between
{{AIO}} and {{ASYNCIO}}.
For instance, https://activemq.apache.org/artemis/docs/latest/persistence.html
contains:
{quote}
The second implementation uses a thin native code wrapper to talk to the Linux
asynchronous IO library (AIO). With AIO, Apache ActiveMQ Artemis will [...]
{quote}
and further down:
{quote}
journal-type: Valid values are NIO, ASYNCIO or MAPPED
{quote}
In https://activemq.apache.org/artemis/docs/latest/using-server.html we even
have:
{quote}
--aio Sets the journal as asyncio.
{quote}
Looking at numbers, it seems that {{AIO}} is used more than {{ASYNCIO}}:
{code}
$ grep -wri aio docs/user-manual | wc -l
29
$ grep -wri asyncio docs/user-manual | wc -l
5
{code}
Using only one term everywhere would be more consistent and clearer for the
reader.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1895) Add duplicate metadata failure callback to ActiveMQServerPlugin
[ https://issues.apache.org/jira/browse/ARTEMIS-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16500155#comment-16500155 ] ASF GitHub Bot commented on ARTEMIS-1895: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2116 The easiest way to rebuild is to. Got commit —amend Got push -f > Add duplicate metadata failure callback to ActiveMQServerPlugin > --- > > Key: ARTEMIS-1895 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1895 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.6.0 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Minor > Fix For: 2.7.0 > > > I have a usecase where it would be useful to have a callback as part of the > plugin api when there is duplicate session metadata detected (ie duplicate > clientId). This new callback will allow a user to add custom handling such > as logging, etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-1906) anycastPrefix and multicastPrefix should be kept in mapped addresses
Lionel Cons created ARTEMIS-1906:
Summary: anycastPrefix and multicastPrefix should be kept in
mapped addresses
Key: ARTEMIS-1906
URL: https://issues.apache.org/jira/browse/ARTEMIS-1906
Project: ActiveMQ Artemis
Issue Type: Bug
Reporter: Lionel Cons
For STOMP (at least), {{anycastPrefix}} and {{multicastPrefix}} are used to map
destinations to addresses and routing types.
In order to have compatibility with other brokers such as ActiveMQ 5 or
RabbitMQ, these prefixes must be set to {{anycastPrefix=/queue/}} and
{{multicastPrefix=/topic/}}. With these settings, a destination like
{{/queue/foo}} works like a JMS queue while {{/topic/foo}} works like a JMS
topic. So far, so good.
Unfortunately, the current implementation removes these prefixes when mapping
to addresses. This means that the two (completely unrelated, see ARTEMIS-1794)
destinations {{/queue/foo}} and {{/topic/foo}} map to the exact same address
named {{foo}}. Messaging does work as expected because the same address can
have multiple routing types but monitoring and security become problematic.
Security is defined per address so the two destinations {{/queue/foo}} and
{{/topic/foo}} cannot have different security settings.
Similarly, some monitoring information is attached to the address objects so
{{/queue/foo}} and {{/topic/foo}} cannot have different monitoring metrics.
It seems all these problems would disappear if prefixes would be kept when
mapping STOMP destinations to addresses.
Note: similar problems might exist with other protocols but I've tested it only
using STOMP.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ARTEMIS-1905) When using JMS API over STOMP protocol only multicast destinations are created
Tom Ross created ARTEMIS-1905: - Summary: When using JMS API over STOMP protocol only multicast destinations are created Key: ARTEMIS-1905 URL: https://issues.apache.org/jira/browse/ARTEMIS-1905 Project: ActiveMQ Artemis Issue Type: Bug Components: Broker, STOMP Affects Versions: 2.6.0 Reporter: Tom Ross Assignee: Justin Bertram When calling JMS API createQueue() only multicast destinations are created in the broker back end. The call to createQueue() should result in a anycast destination to be created. Also when sending a frame like would result in multicast destination. "SEND\n" + "destination:queue/foo\n" + "\n" + text + END_OF_FRAME; It's possible to add destination-type header to the frame "SEND\n" + "destination:queue/foo\n" + "destination-type:ANYCAST\n" + "\n" + text + END_OF_FRAME; but that is non standart since there is no destination-type header defined in STOMP protocol. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1904) Jmx Management Security Tests
[ https://issues.apache.org/jira/browse/ARTEMIS-1904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Howard Gao updated ARTEMIS-1904: Affects Version/s: 2.6.1 > Jmx Management Security Tests > - > > Key: ARTEMIS-1904 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1904 > Project: ActiveMQ Artemis > Issue Type: Test > Components: Broker >Affects Versions: 2.6.1 >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Fix For: 2.7.0 > > > Adding tests for jmx security (authentication/authorization) functionalities. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1904) Jmx Management Security Tests
[ https://issues.apache.org/jira/browse/ARTEMIS-1904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Howard Gao updated ARTEMIS-1904: Fix Version/s: 2.7.0 > Jmx Management Security Tests > - > > Key: ARTEMIS-1904 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1904 > Project: ActiveMQ Artemis > Issue Type: Test > Components: Broker >Affects Versions: 2.6.1 >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > Fix For: 2.7.0 > > > Adding tests for jmx security (authentication/authorization) functionalities. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1904) Jmx Management Security Tests
[ https://issues.apache.org/jira/browse/ARTEMIS-1904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Howard Gao updated ARTEMIS-1904: Component/s: Broker > Jmx Management Security Tests > - > > Key: ARTEMIS-1904 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1904 > Project: ActiveMQ Artemis > Issue Type: Test > Components: Broker >Reporter: Howard Gao >Assignee: Howard Gao >Priority: Major > > Adding tests for jmx security (authentication/authorization) functionalities. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-1904) Jmx Management Security Tests
Howard Gao created ARTEMIS-1904: --- Summary: Jmx Management Security Tests Key: ARTEMIS-1904 URL: https://issues.apache.org/jira/browse/ARTEMIS-1904 Project: ActiveMQ Artemis Issue Type: Test Reporter: Howard Gao Assignee: Howard Gao Adding tests for jmx security (authentication/authorization) functionalities. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1895) Add duplicate metadata failure callback to ActiveMQServerPlugin
[ https://issues.apache.org/jira/browse/ARTEMIS-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16500113#comment-16500113 ] ASF GitHub Bot commented on ARTEMIS-1895: - Github user cshannon commented on the issue: https://github.com/apache/activemq-artemis/pull/2116 I don't think it's related as the test it failed on doesn't have a plugin registered. I tried to see if I could trigger it to re-run the build in travis ci but i didn't see a way to do that. > Add duplicate metadata failure callback to ActiveMQServerPlugin > --- > > Key: ARTEMIS-1895 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1895 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.6.0 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Minor > Fix For: 2.7.0 > > > I have a usecase where it would be useful to have a callback as part of the > plugin api when there is duplicate session metadata detected (ie duplicate > clientId). This new callback will allow a user to add custom handling such > as logging, etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1895) Add duplicate metadata failure callback to ActiveMQServerPlugin
[ https://issues.apache.org/jira/browse/ARTEMIS-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16500105#comment-16500105 ] ASF GitHub Bot commented on ARTEMIS-1895: - Github user cshannon commented on the issue: https://github.com/apache/activemq-artemis/pull/2116 @clebertsuconic - is this ok to merge? > Add duplicate metadata failure callback to ActiveMQServerPlugin > --- > > Key: ARTEMIS-1895 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1895 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.6.0 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Minor > Fix For: 2.7.0 > > > I have a usecase where it would be useful to have a callback as part of the > plugin api when there is duplicate session metadata detected (ie duplicate > clientId). This new callback will allow a user to add custom handling such > as logging, etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-6982) ActiveMQSslConnectionFactory createTransport overrides newly created SSL Context in finally block
[ https://issues.apache.org/jira/browse/AMQ-6982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16500101#comment-16500101 ] Christopher L. Shannon commented on AMQ-6982: - Without looking at it more I am not entirely sure why the context stuff was designed this way but I don't really think this is an issue. The SSL context is properly set and then the transport is created so it uses the proper settings. After the transport is created then it's set to the old value but I don't think that value is referenced anymore so it shouldn't matter. > ActiveMQSslConnectionFactory createTransport overrides newly created SSL > Context in finally block > - > > Key: AMQ-6982 > URL: https://issues.apache.org/jira/browse/AMQ-6982 > Project: ActiveMQ > Issue Type: Bug > Components: Transport >Affects Versions: 5.15.4 >Reporter: Lars Pfeil >Priority: Major > > The createTransport method overwrites the newly created SSL context in its > finally block. As the SSL context is usually initially null, it remains null. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
