[jira] [Commented] (ARTEMIS-2102) delete paging directory or table if address is removed
[ https://issues.apache.org/jira/browse/ARTEMIS-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16644773#comment-16644773 ] ASF GitHub Bot commented on ARTEMIS-2102: - Github user wy96f commented on the issue: https://github.com/apache/activemq-artemis/pull/2339 @clebertsuconic Could you look at this PR? > delete paging directory or table if address is removed > -- > > Key: ARTEMIS-2102 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2102 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.6.3 >Reporter: yangwei >Priority: Major > > Our app uses clientRequestor to get message count or other metrics. > When the broker is globally full(all addresses enters into paging mode), each > request by clientRequestor will create a temporary reply queue causing a new > paging directory is created. After each request clientRequestor is closed and > the temporary queue is deleted, the broker only purges the queue data. > We should delete paging directory to fix the problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2103) VirtualTopic doesn't work correctly with multiple consumers
[
https://issues.apache.org/jira/browse/ARTEMIS-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16644945#comment-16644945
]
ASF GitHub Bot commented on ARTEMIS-2103:
-
Github user PawelJ-PL commented on the issue:
https://github.com/apache/activemq-artemis/pull/2341
I've locally built Artemis from this branch and it's looks, that with this
fix virtual topics are working as expected.
> VirtualTopic doesn't work correctly with multiple consumers
> ---
>
> Key: ARTEMIS-2103
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2103
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker, OpenWire
>Affects Versions: 2.6.3
>Reporter: Pawel
>Assignee: Gary Tully
>Priority: Major
>
> It's impossibe to subscribe multiple virtual topics with the same consumer
> name.
> I've configured acceptor like described in documentation:
> {code:java}
> tcp://0.0.0.0:61616?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;virtualTopicConsumerWildcards=Consumer.*.%3E%3B2{code}
> When I'm connecting first consumer:
> *Consumer.cons1.VirtualTopic.t1*
> proper binding is created.
> Next I'm trying to connect second consumer with the same name:
> *Consumer.cons1.VirtualTopic.t2*
> But no binding is created.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2085) Improve validation of MDB activation config properties values
[
https://issues.apache.org/jira/browse/ARTEMIS-2085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16644976#comment-16644976
]
ASF GitHub Bot commented on ARTEMIS-2085:
-
Github user rpelisse commented on the issue:
https://github.com/apache/activemq-artemis/pull/2312
@michaelandrepearce I've updated this branch with my Unit tests. I did a
bit of refactor also, I hope it's fine with you and let me know if you want me
to change something!
> Improve validation of MDB activation config properties values
> -
>
> Key: ARTEMIS-2085
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2085
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Romain PELISSE
>Priority: Major
>
> Most of activation config properties values are not validated during MDB
> deploy. This might lead to successful deployment of misconfigured MDB without
> any warning.
> *Customer scenario*: Customer deploys MDB with misconfigured activation
> config property(wrong type, unsupported value). MDB deploys without any
> warning message. However, it doesn't work as expected. In worst case, MDB can
> not read any message.
> *Current validation status*
> Values of activation config properties are validated in
> \{{ActiveMQActivationSpec.validate()}} method. Validation covers only 3
> scenarios
> * not specified destination
> * wrong destination type (other than Queue / Topic)
> * no subscription name when MDB is durable topic subscriber
> Some \{{ActiveMQActivationSpec}} properties try to validate supported values
> in setters. For example \{{setAcknowledgeMode()}} throws
> \{{IllegalArgumentException}}. However these exceptions only log message on
> \{{finest}} level, which usually doesn't attract user's attention (see
> \{{BeenUtils.mapJavaBeanProperties}} in \{{jboss-common-beans}})
> Other parameters are not validated.
> *Possible issues*
> Not validated activation config properties can be set to any value without
> warning. There is a possibility of misconfiguration which can be detected
> during deploy time.
> _Examples_
> Value of \{{acknowledgeMode}} can be set to any string or number without
> warning. If that is the case, server uses default auto acknowledge. However,
> it doesn't warn user.
> If property \{{maxSessions}} is configured with negative value, no warning is
> logged and MDB is unable to consume messages.
> If \{{destination}} property specifies unknown destination, new destination
> with provided name is created. User should be informed about that at least on
> INFO log level (Currently it is debug in
> \{{ActiveMQActivation.setupDestination()}}).
> MDB unable to consume messages should not successfully deploy, and user
> should be informed about the misconfigured values.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (AMQ-7069) HTTP client don't handle XStream deserialization exception
Alexey Markevich created AMQ-7069: - Summary: HTTP client don't handle XStream deserialization exception Key: AMQ-7069 URL: https://issues.apache.org/jira/browse/AMQ-7069 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.15.6 Reporter: Alexey Markevich Attachments: after.log, before.log XStreamException is RuntimeException and cause error when shutting down ExecutorService [^before.log]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-6556) Support system property proxy settings for HTTP(S) client
[ https://issues.apache.org/jira/browse/AMQ-6556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16644998#comment-16644998 ] ASF GitHub Bot commented on AMQ-6556: - Github user amarkevich closed the pull request at: https://github.com/apache/activemq/pull/235 > Support system property proxy settings for HTTP(S) client > - > > Key: AMQ-6556 > URL: https://issues.apache.org/jira/browse/AMQ-6556 > Project: ActiveMQ > Issue Type: Improvement > Components: Transport >Affects Versions: 5.14.1, 5.14.3 >Reporter: Alexey Markevich >Priority: Major > Attachments: activemq-http.patch > > > Each broker URI should be updated with proxy setting. Using system proxy > settings make this transparent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7069) HTTP client don't handle XStream deserialization exception
[ https://issues.apache.org/jira/browse/AMQ-7069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16644999#comment-16644999 ] ASF GitHub Bot commented on AMQ-7069: - GitHub user amarkevich opened a pull request: https://github.com/apache/activemq/pull/305 AMQ-7069 HTTP client don't handle XStream deserialization exception You can merge this pull request into a Git repository by running: $ git pull https://github.com/amarkevich/activemq AMQ-7069 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq/pull/305.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 #305 commit b830894e690d317ba32019c00d7d4db01eadcc5d Author: amarkevich Date: 2018-10-10T13:57:49Z AMQ-7069 HTTP client don't handle XStream deserialization exception > HTTP client don't handle XStream deserialization exception > -- > > Key: AMQ-7069 > URL: https://issues.apache.org/jira/browse/AMQ-7069 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.15.6 >Reporter: Alexey Markevich >Priority: Minor > Attachments: after.log, before.log > > > XStreamException is RuntimeException and cause error when shutting down > ExecutorService [^before.log]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1987) Support configuring a default consumer window size via Address Settings
[ https://issues.apache.org/jira/browse/ARTEMIS-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645011#comment-16645011 ] ASF GitHub Bot commented on ARTEMIS-1987: - Github user PawelJ-PL commented on the issue: https://github.com/apache/activemq-artemis/pull/2191 Could You please briefly describe, how does the feature work? I need feature similar to queuePrefetch (http://activemq.apache.org/per-destination-policies.html) per destination (not whole connection). Is it something similar? I've set `0` on address but it looks, that not works (slow consumer is prefetching more messages). With URL `(tcp://127.0.0.1:61616)?consumerWindowSize=0` is's working as expected, but as I said, I need this setting for particular address, not whole connection. > Support configuring a default consumer window size via Address Settings > --- > > Key: ARTEMIS-1987 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1987 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.6.2 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 2.7.0 > > > In ActiveMQ 5.x a very useful feature is the ability to configure a prefetch > in a policy which then gets negotiated with an OpenWire client. This allows > changing the default prefetch setting by destination which is important > because different destinations will have different message types and data > flows. It's very useful to be able to configure it on the broker so that > each client doesn't need to configure their side and an administrator can set > a reasonable default (where the broker is shared by multiple > clients/customers) > To do this in Artemis I'm proposing creating a new window size negotiation as > part of the consumer creation. Essentially the address can be configured > with a different default window size if desired and if the client does not > set the window size then the new configured default will be sent to the > client which can be used instead of the standard 1 MiB. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1987) Support configuring a default consumer window size via Address Settings
[ https://issues.apache.org/jira/browse/ARTEMIS-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645030#comment-16645030 ] ASF GitHub Bot commented on ARTEMIS-1987: - Github user cshannon commented on the issue: https://github.com/apache/activemq-artemis/pull/2191 This is only available for version 2.7.0 which has not been released yet. There is documentation available for it as well that will be released with it > Support configuring a default consumer window size via Address Settings > --- > > Key: ARTEMIS-1987 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1987 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.6.2 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 2.7.0 > > > In ActiveMQ 5.x a very useful feature is the ability to configure a prefetch > in a policy which then gets negotiated with an OpenWire client. This allows > changing the default prefetch setting by destination which is important > because different destinations will have different message types and data > flows. It's very useful to be able to configure it on the broker so that > each client doesn't need to configure their side and an administrator can set > a reasonable default (where the broker is shared by multiple > clients/customers) > To do this in Artemis I'm proposing creating a new window size negotiation as > part of the consumer creation. Essentially the address can be configured > with a different default window size if desired and if the client does not > set the window size then the new configured default will be sent to the > client which can be used instead of the standard 1 MiB. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7067) KahaDB Recovery can experience a dangling transaction when prepare and commit occur on different data files.
[
https://issues.apache.org/jira/browse/AMQ-7067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645043#comment-16645043
]
Christopher L. Shannon commented on AMQ-7067:
-
[~jgoodyear] - i cherry-picked the existing 3 commits into the 5.15.x
branch...I will also move anymore from master after the ack compaction case is
sorted so we can do a 5.15.7 release soon as this is an important fix
> KahaDB Recovery can experience a dangling transaction when prepare and commit
> occur on different data files.
>
>
> Key: AMQ-7067
> URL: https://issues.apache.org/jira/browse/AMQ-7067
> Project: ActiveMQ
> Issue Type: Bug
> Components: KahaDB, XA
>Affects Versions: 5.15.6
>Reporter: Jamie goodyear
>Assignee: Gary Tully
>Priority: Critical
> Fix For: 5.16.0, 5.15.7
>
> Attachments: amq7067test.patch
>
>
> KahaDB Recovery can experience a dangling transaction when prepare and commit
> occur on different data files.
> Scenario:
> A XA Transaction is started, message is prepared and sent into Broker.
> We then send into broker enough messages to file page file (100 message with
> 512 * 1024 characters in message payload). This forces a new data file to be
> created.
> Commit the XA transaction. Commit will land on the new data file.
> Restart the Broker.
> Upon restart a KahaDB recovery is executed.
> The prepare in PageFile 1 is not matched to Commit on PageFile 2, as such, it
> will appear in recovered message state.
> Looking deeper into this scenario, it appears that the commit message is
> GC'd, hence the prepare & commit can not be matched.
> The MessageDatabase only checks the following for GC:
> {color:#808080}// Don't GC files referenced by in-progress
> tx{color}{color:#cc7832}if {color}(inProgressTxRange[{color:#6897bb}0{color}]
> != {color:#cc7832}null{color}) {
> {color:#cc7832}for {color}({color:#cc7832}int
> {color}pendingTx=inProgressTxRange[{color:#6897bb}0{color}].getDataFileId(){color:#cc7832};
> {color}pendingTx <=
> inProgressTxRange[{color:#6897bb}1{color}].getDataFileId(){color:#cc7832};
> {color}pendingTx++) {
> gcCandidateSet.remove(pendingTx){color:#cc7832};{color} }
> }
> We need to become aware of where the prepare & commits occur in pagefiles
> with respect to GCing files.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1987) Support configuring a default consumer window size via Address Settings
[ https://issues.apache.org/jira/browse/ARTEMIS-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645049#comment-16645049 ] ASF GitHub Bot commented on ARTEMIS-1987: - Github user PawelJ-PL commented on the issue: https://github.com/apache/activemq-artemis/pull/2191 I have build Artemis from master and I've tested it locally. Maybe I can't see any effect, because I have Artemis built from Master, but in test I'm using client 2.6.3. Does this feature require client in newest version, or everything is done on the server side? > Support configuring a default consumer window size via Address Settings > --- > > Key: ARTEMIS-1987 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1987 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.6.2 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 2.7.0 > > > In ActiveMQ 5.x a very useful feature is the ability to configure a prefetch > in a policy which then gets negotiated with an OpenWire client. This allows > changing the default prefetch setting by destination which is important > because different destinations will have different message types and data > flows. It's very useful to be able to configure it on the broker so that > each client doesn't need to configure their side and an administrator can set > a reasonable default (where the broker is shared by multiple > clients/customers) > To do this in Artemis I'm proposing creating a new window size negotiation as > part of the consumer creation. Essentially the address can be configured > with a different default window size if desired and if the client does not > set the window size then the new configured default will be sent to the > client which can be used instead of the standard 1 MiB. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1987) Support configuring a default consumer window size via Address Settings
[ https://issues.apache.org/jira/browse/ARTEMIS-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645058#comment-16645058 ] ASF GitHub Bot commented on ARTEMIS-1987: - Github user cshannon commented on the issue: https://github.com/apache/activemq-artemis/pull/2191 Yes you need the latest client as well. This feature works by retrieving the value from the server as part of a query on connect. The old client doesn't know to read the default configured value. > Support configuring a default consumer window size via Address Settings > --- > > Key: ARTEMIS-1987 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1987 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.6.2 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 2.7.0 > > > In ActiveMQ 5.x a very useful feature is the ability to configure a prefetch > in a policy which then gets negotiated with an OpenWire client. This allows > changing the default prefetch setting by destination which is important > because different destinations will have different message types and data > flows. It's very useful to be able to configure it on the broker so that > each client doesn't need to configure their side and an administrator can set > a reasonable default (where the broker is shared by multiple > clients/customers) > To do this in Artemis I'm proposing creating a new window size negotiation as > part of the consumer creation. Essentially the address can be configured > with a different default window size if desired and if the client does not > set the window size then the new configured default will be sent to the > client which can be used instead of the standard 1 MiB. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1987) Support configuring a default consumer window size via Address Settings
[ https://issues.apache.org/jira/browse/ARTEMIS-1987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645069#comment-16645069 ] ASF GitHub Bot commented on ARTEMIS-1987: - Github user PawelJ-PL commented on the issue: https://github.com/apache/activemq-artemis/pull/2191 Ok, thank You for clarification > Support configuring a default consumer window size via Address Settings > --- > > Key: ARTEMIS-1987 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1987 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.6.2 >Reporter: Christopher L. Shannon >Assignee: Christopher L. Shannon >Priority: Major > Fix For: 2.7.0 > > > In ActiveMQ 5.x a very useful feature is the ability to configure a prefetch > in a policy which then gets negotiated with an OpenWire client. This allows > changing the default prefetch setting by destination which is important > because different destinations will have different message types and data > flows. It's very useful to be able to configure it on the broker so that > each client doesn't need to configure their side and an administrator can set > a reasonable default (where the broker is shared by multiple > clients/customers) > To do this in Artemis I'm proposing creating a new window size negotiation as > part of the consumer creation. Essentially the address can be configured > with a different default window size if desired and if the client does not > set the window size then the new configured default will be sent to the > client which can be used instead of the standard 1 MiB. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-2121) Reload logging configuration at runtime
Justin Bertram created ARTEMIS-2121: --- Summary: Reload logging configuration at runtime Key: ARTEMIS-2121 URL: https://issues.apache.org/jira/browse/ARTEMIS-2121 Project: ActiveMQ Artemis Issue Type: New Feature Reporter: Justin Bertram Assignee: Justin Bertram -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2096) AMQP: Refactoring AMQPMessage abstraction for better consistency and performance
[ https://issues.apache.org/jira/browse/ARTEMIS-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645194#comment-16645194 ] ASF GitHub Bot commented on ARTEMIS-2096: - GitHub user clebertsuconic opened a pull request: https://github.com/apache/activemq-artemis/pull/2361 ARTEMIS-2096 Fixing DivertTopicToQueueTest This is fixing the test org.apache.activemq.artemis.tests.integration.amqp.DivertTopicToQueueTest This test was broken because the copy wouldn't use the Buffer view gotten by data.duplicate(). You can merge this pull request into a Git repository by running: $ git pull https://github.com/clebertsuconic/activemq-artemis ARTEMIS-2096 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2361.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 #2361 commit a454316f77b84570483092381016e8305cdeca0b Author: Clebert Suconic Date: 2018-10-10T16:09:40Z ARTEMIS-2096 Fixing DivertTopicToQueueTest This is fixing the test org.apache.activemq.artemis.tests.integration.amqp.DivertTopicToQueueTest This test was broken because the copy wouldn't use the Buffer view gotten by data.duplicate(). > AMQP: Refactoring AMQPMessage abstraction for better consistency and > performance > > > Key: ARTEMIS-2096 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2096 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.6.3 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Major > Fix For: 2.7.0 > > > The AMQPMessage abstraction used to wrap the AMQP message section has some > inconsistencies in how it manages the underlying data and the decoded AMQP > section obtained from the Proton-J codec as well as issues with state being > maintained in the presence of changes to the message made through the public > facing Message APIs > A refactoring of the AMQPMessage class to better utilize the proton-j codec > to manage the message data and how it is parsed and re-encoded on change > needs to be done to ensure no corrupt messages are sent and that we are not > decoding and encoding sections of the message we are not intending to read or > change on the sever (We currently can decode message bodies or footer is a > few cases where we intend not to). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2096) AMQP: Refactoring AMQPMessage abstraction for better consistency and performance
[ https://issues.apache.org/jira/browse/ARTEMIS-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645195#comment-16645195 ] ASF GitHub Bot commented on ARTEMIS-2096: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2361 @tabish121 can you review and merge it please? > AMQP: Refactoring AMQPMessage abstraction for better consistency and > performance > > > Key: ARTEMIS-2096 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2096 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.6.3 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Major > Fix For: 2.7.0 > > > The AMQPMessage abstraction used to wrap the AMQP message section has some > inconsistencies in how it manages the underlying data and the decoded AMQP > section obtained from the Proton-J codec as well as issues with state being > maintained in the presence of changes to the message made through the public > facing Message APIs > A refactoring of the AMQPMessage class to better utilize the proton-j codec > to manage the message data and how it is parsed and re-encoded on change > needs to be done to ensure no corrupt messages are sent and that we are not > decoding and encoding sections of the message we are not intending to read or > change on the sever (We currently can decode message bodies or footer is a > few cases where we intend not to). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2094) Configuration change loss after failover to slave
[ https://issues.apache.org/jira/browse/ARTEMIS-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645199#comment-16645199 ] ASF GitHub Bot commented on ARTEMIS-2094: - Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/2356 @clebertsuconic is this good to merge? > Configuration change loss after failover to slave > - > > Key: ARTEMIS-2094 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2094 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.3 >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > This is further cases discovered during testing network failures. > Essentially we have noticed when config settings are reloaded such as > address-setting or security-setting, the live node correctly reloads, but > after live failure the backup activates, the backup does not contain these > changes due to the configuration object held inside ActiveMQServerImpl is out > of date to when the backup server first started. > so further enhancements/bug fixes on top of ARTEMIS-1747 - Fix Configuration > change loss when network Issue. which fixed this for an active node. > Essentially we just need to keep the updating of the configuration object in > ActiveMQServerImpl outside the isActive check. > Also address-settings and security settings should be swap'd during > initialisation phase 2, so these are set to latest config after activation. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2094) Configuration change loss after failover to slave
[ https://issues.apache.org/jira/browse/ARTEMIS-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645205#comment-16645205 ] ASF GitHub Bot commented on ARTEMIS-2094: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2356 @michaelandrepearce the testsuite was still frozen when I ran it. I'm not sure it's related to this yet... I just wanted to keep it open until I figure it out. give me until the day of the day? > Configuration change loss after failover to slave > - > > Key: ARTEMIS-2094 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2094 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.3 >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > This is further cases discovered during testing network failures. > Essentially we have noticed when config settings are reloaded such as > address-setting or security-setting, the live node correctly reloads, but > after live failure the backup activates, the backup does not contain these > changes due to the configuration object held inside ActiveMQServerImpl is out > of date to when the backup server first started. > so further enhancements/bug fixes on top of ARTEMIS-1747 - Fix Configuration > change loss when network Issue. which fixed this for an active node. > Essentially we just need to keep the updating of the configuration object in > ActiveMQServerImpl outside the isActive check. > Also address-settings and security settings should be swap'd during > initialisation phase 2, so these are set to latest config after activation. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2094) Configuration change loss after failover to slave
[ https://issues.apache.org/jira/browse/ARTEMIS-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645207#comment-16645207 ] ASF GitHub Bot commented on ARTEMIS-2094: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2351 @jbertram can you close this please? > Configuration change loss after failover to slave > - > > Key: ARTEMIS-2094 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2094 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.3 >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > This is further cases discovered during testing network failures. > Essentially we have noticed when config settings are reloaded such as > address-setting or security-setting, the live node correctly reloads, but > after live failure the backup activates, the backup does not contain these > changes due to the configuration object held inside ActiveMQServerImpl is out > of date to when the backup server first started. > so further enhancements/bug fixes on top of ARTEMIS-1747 - Fix Configuration > change loss when network Issue. which fixed this for an active node. > Essentially we just need to keep the updating of the configuration object in > ActiveMQServerImpl outside the isActive check. > Also address-settings and security settings should be swap'd during > initialisation phase 2, so these are set to latest config after activation. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2085) Improve validation of MDB activation config properties values
[
https://issues.apache.org/jira/browse/ARTEMIS-2085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645208#comment-16645208
]
ASF GitHub Bot commented on ARTEMIS-2085:
-
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/2312#discussion_r224148249
--- Diff:
artemis-ra/src/main/java/org/apache/activemq/artemis/ra/inflow/ActiveMQActivation.java
---
@@ -556,7 +556,7 @@ protected void setupDestination() throws Exception {
calculatedDestinationName = spec.getQueuePrefix() +
calculatedDestinationName;
}
- logger.debug("Unable to retrieve " + destinationName + "
from JNDI. Creating a new " + destinationType.getName() + " named " +
calculatedDestinationName + " to be used by the MDB.");
+ logger.warn("Unable to retrieve " + destinationName + "
from JNDI. Creating a new " + destinationType.getName() + " named " +
calculatedDestinationName + " to be used by the MDB.");
--- End diff --
if this is no longer debug, it requires to user proper logger, with a
defined logger code.
> Improve validation of MDB activation config properties values
> -
>
> Key: ARTEMIS-2085
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2085
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Romain PELISSE
>Priority: Major
>
> Most of activation config properties values are not validated during MDB
> deploy. This might lead to successful deployment of misconfigured MDB without
> any warning.
> *Customer scenario*: Customer deploys MDB with misconfigured activation
> config property(wrong type, unsupported value). MDB deploys without any
> warning message. However, it doesn't work as expected. In worst case, MDB can
> not read any message.
> *Current validation status*
> Values of activation config properties are validated in
> \{{ActiveMQActivationSpec.validate()}} method. Validation covers only 3
> scenarios
> * not specified destination
> * wrong destination type (other than Queue / Topic)
> * no subscription name when MDB is durable topic subscriber
> Some \{{ActiveMQActivationSpec}} properties try to validate supported values
> in setters. For example \{{setAcknowledgeMode()}} throws
> \{{IllegalArgumentException}}. However these exceptions only log message on
> \{{finest}} level, which usually doesn't attract user's attention (see
> \{{BeenUtils.mapJavaBeanProperties}} in \{{jboss-common-beans}})
> Other parameters are not validated.
> *Possible issues*
> Not validated activation config properties can be set to any value without
> warning. There is a possibility of misconfiguration which can be detected
> during deploy time.
> _Examples_
> Value of \{{acknowledgeMode}} can be set to any string or number without
> warning. If that is the case, server uses default auto acknowledge. However,
> it doesn't warn user.
> If property \{{maxSessions}} is configured with negative value, no warning is
> logged and MDB is unable to consume messages.
> If \{{destination}} property specifies unknown destination, new destination
> with provided name is created. User should be informed about that at least on
> INFO log level (Currently it is debug in
> \{{ActiveMQActivation.setupDestination()}}).
> MDB unable to consume messages should not successfully deploy, and user
> should be informed about the misconfigured values.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2085) Improve validation of MDB activation config properties values
[
https://issues.apache.org/jira/browse/ARTEMIS-2085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645211#comment-16645211
]
ASF GitHub Bot commented on ARTEMIS-2085:
-
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/2312#discussion_r224148916
--- Diff:
artemis-ra/src/main/java/org/apache/activemq/artemis/ra/inflow/ActiveMQActivationSpec.java
---
@@ -603,7 +596,11 @@ public void setMaxSession(final Integer value) {
logger.trace("setMaxSession(" + value + ")");
}
- maxSession = value;
+ if ( value < 1 ) {
+ logger.warn("Invalid number of session (negative):" + value + ",
defaulting to 1.");
--- End diff --
this requires a declared logger in ActiveMQRALogger and logger code
> Improve validation of MDB activation config properties values
> -
>
> Key: ARTEMIS-2085
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2085
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Romain PELISSE
>Priority: Major
>
> Most of activation config properties values are not validated during MDB
> deploy. This might lead to successful deployment of misconfigured MDB without
> any warning.
> *Customer scenario*: Customer deploys MDB with misconfigured activation
> config property(wrong type, unsupported value). MDB deploys without any
> warning message. However, it doesn't work as expected. In worst case, MDB can
> not read any message.
> *Current validation status*
> Values of activation config properties are validated in
> \{{ActiveMQActivationSpec.validate()}} method. Validation covers only 3
> scenarios
> * not specified destination
> * wrong destination type (other than Queue / Topic)
> * no subscription name when MDB is durable topic subscriber
> Some \{{ActiveMQActivationSpec}} properties try to validate supported values
> in setters. For example \{{setAcknowledgeMode()}} throws
> \{{IllegalArgumentException}}. However these exceptions only log message on
> \{{finest}} level, which usually doesn't attract user's attention (see
> \{{BeenUtils.mapJavaBeanProperties}} in \{{jboss-common-beans}})
> Other parameters are not validated.
> *Possible issues*
> Not validated activation config properties can be set to any value without
> warning. There is a possibility of misconfiguration which can be detected
> during deploy time.
> _Examples_
> Value of \{{acknowledgeMode}} can be set to any string or number without
> warning. If that is the case, server uses default auto acknowledge. However,
> it doesn't warn user.
> If property \{{maxSessions}} is configured with negative value, no warning is
> logged and MDB is unable to consume messages.
> If \{{destination}} property specifies unknown destination, new destination
> with provided name is created. User should be informed about that at least on
> INFO log level (Currently it is debug in
> \{{ActiveMQActivation.setupDestination()}}).
> MDB unable to consume messages should not successfully deploy, and user
> should be informed about the misconfigured values.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2096) AMQP: Refactoring AMQPMessage abstraction for better consistency and performance
[ https://issues.apache.org/jira/browse/ARTEMIS-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645219#comment-16645219 ] ASF GitHub Bot commented on ARTEMIS-2096: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2361 > AMQP: Refactoring AMQPMessage abstraction for better consistency and > performance > > > Key: ARTEMIS-2096 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2096 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.6.3 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Major > Fix For: 2.7.0 > > > The AMQPMessage abstraction used to wrap the AMQP message section has some > inconsistencies in how it manages the underlying data and the decoded AMQP > section obtained from the Proton-J codec as well as issues with state being > maintained in the presence of changes to the message made through the public > facing Message APIs > A refactoring of the AMQPMessage class to better utilize the proton-j codec > to manage the message data and how it is parsed and re-encoded on change > needs to be done to ensure no corrupt messages are sent and that we are not > decoding and encoding sections of the message we are not intending to read or > change on the sever (We currently can decode message bodies or footer is a > few cases where we intend not to). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2085) Improve validation of MDB activation config properties values
[
https://issues.apache.org/jira/browse/ARTEMIS-2085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645221#comment-16645221
]
ASF GitHub Bot commented on ARTEMIS-2085:
-
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/2312#discussion_r224151461
--- Diff:
artemis-ra/src/main/java/org/apache/activemq/artemis/ra/inflow/ActiveMQActivationValidationUtils.java
---
@@ -0,0 +1,80 @@
+package org.apache.activemq.artemis.ra.inflow;
--- End diff --
RAT failure, requires license headers
> Improve validation of MDB activation config properties values
> -
>
> Key: ARTEMIS-2085
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2085
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Romain PELISSE
>Priority: Major
>
> Most of activation config properties values are not validated during MDB
> deploy. This might lead to successful deployment of misconfigured MDB without
> any warning.
> *Customer scenario*: Customer deploys MDB with misconfigured activation
> config property(wrong type, unsupported value). MDB deploys without any
> warning message. However, it doesn't work as expected. In worst case, MDB can
> not read any message.
> *Current validation status*
> Values of activation config properties are validated in
> \{{ActiveMQActivationSpec.validate()}} method. Validation covers only 3
> scenarios
> * not specified destination
> * wrong destination type (other than Queue / Topic)
> * no subscription name when MDB is durable topic subscriber
> Some \{{ActiveMQActivationSpec}} properties try to validate supported values
> in setters. For example \{{setAcknowledgeMode()}} throws
> \{{IllegalArgumentException}}. However these exceptions only log message on
> \{{finest}} level, which usually doesn't attract user's attention (see
> \{{BeenUtils.mapJavaBeanProperties}} in \{{jboss-common-beans}})
> Other parameters are not validated.
> *Possible issues*
> Not validated activation config properties can be set to any value without
> warning. There is a possibility of misconfiguration which can be detected
> during deploy time.
> _Examples_
> Value of \{{acknowledgeMode}} can be set to any string or number without
> warning. If that is the case, server uses default auto acknowledge. However,
> it doesn't warn user.
> If property \{{maxSessions}} is configured with negative value, no warning is
> logged and MDB is unable to consume messages.
> If \{{destination}} property specifies unknown destination, new destination
> with provided name is created. User should be informed about that at least on
> INFO log level (Currently it is debug in
> \{{ActiveMQActivation.setupDestination()}}).
> MDB unable to consume messages should not successfully deploy, and user
> should be informed about the misconfigured values.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2085) Improve validation of MDB activation config properties values
[
https://issues.apache.org/jira/browse/ARTEMIS-2085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645223#comment-16645223
]
ASF GitHub Bot commented on ARTEMIS-2085:
-
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/2312#discussion_r224151533
--- Diff:
artemis-ra/src/main/java/org/apache/activemq/artemis/ra/inflow/ActiveMQActivationValidationUtils.java
---
@@ -0,0 +1,80 @@
+package org.apache.activemq.artemis.ra.inflow;
+
+import java.beans.IntrospectionException;
+import java.beans.PropertyDescriptor;
+import java.util.ArrayList;
+import java.util.List;
+
+import javax.jms.Queue;
+import javax.jms.Session;
+import javax.jms.Topic;
+import javax.resource.spi.InvalidPropertyException;
+
+import org.apache.activemq.artemis.ra.ActiveMQRALogger;
+
+/**
+ * A set of validation methods, isolated here to be easily testable.
+ *
+ * @author rpelisse
--- End diff --
remove please
> Improve validation of MDB activation config properties values
> -
>
> Key: ARTEMIS-2085
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2085
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Romain PELISSE
>Priority: Major
>
> Most of activation config properties values are not validated during MDB
> deploy. This might lead to successful deployment of misconfigured MDB without
> any warning.
> *Customer scenario*: Customer deploys MDB with misconfigured activation
> config property(wrong type, unsupported value). MDB deploys without any
> warning message. However, it doesn't work as expected. In worst case, MDB can
> not read any message.
> *Current validation status*
> Values of activation config properties are validated in
> \{{ActiveMQActivationSpec.validate()}} method. Validation covers only 3
> scenarios
> * not specified destination
> * wrong destination type (other than Queue / Topic)
> * no subscription name when MDB is durable topic subscriber
> Some \{{ActiveMQActivationSpec}} properties try to validate supported values
> in setters. For example \{{setAcknowledgeMode()}} throws
> \{{IllegalArgumentException}}. However these exceptions only log message on
> \{{finest}} level, which usually doesn't attract user's attention (see
> \{{BeenUtils.mapJavaBeanProperties}} in \{{jboss-common-beans}})
> Other parameters are not validated.
> *Possible issues*
> Not validated activation config properties can be set to any value without
> warning. There is a possibility of misconfiguration which can be detected
> during deploy time.
> _Examples_
> Value of \{{acknowledgeMode}} can be set to any string or number without
> warning. If that is the case, server uses default auto acknowledge. However,
> it doesn't warn user.
> If property \{{maxSessions}} is configured with negative value, no warning is
> logged and MDB is unable to consume messages.
> If \{{destination}} property specifies unknown destination, new destination
> with provided name is created. User should be informed about that at least on
> INFO log level (Currently it is debug in
> \{{ActiveMQActivation.setupDestination()}}).
> MDB unable to consume messages should not successfully deploy, and user
> should be informed about the misconfigured values.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2085) Improve validation of MDB activation config properties values
[
https://issues.apache.org/jira/browse/ARTEMIS-2085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645224#comment-16645224
]
ASF GitHub Bot commented on ARTEMIS-2085:
-
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/2312#discussion_r224151789
--- Diff:
artemis-ra/src/test/java/org/apache/activemq/artemis/ra/inflow/ActiveMQActivationsSpecTest.java
---
@@ -0,0 +1,46 @@
+package org.apache.activemq.artemis.ra.inflow;
--- End diff --
RAT failure, requires license header
> Improve validation of MDB activation config properties values
> -
>
> Key: ARTEMIS-2085
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2085
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Reporter: Romain PELISSE
>Priority: Major
>
> Most of activation config properties values are not validated during MDB
> deploy. This might lead to successful deployment of misconfigured MDB without
> any warning.
> *Customer scenario*: Customer deploys MDB with misconfigured activation
> config property(wrong type, unsupported value). MDB deploys without any
> warning message. However, it doesn't work as expected. In worst case, MDB can
> not read any message.
> *Current validation status*
> Values of activation config properties are validated in
> \{{ActiveMQActivationSpec.validate()}} method. Validation covers only 3
> scenarios
> * not specified destination
> * wrong destination type (other than Queue / Topic)
> * no subscription name when MDB is durable topic subscriber
> Some \{{ActiveMQActivationSpec}} properties try to validate supported values
> in setters. For example \{{setAcknowledgeMode()}} throws
> \{{IllegalArgumentException}}. However these exceptions only log message on
> \{{finest}} level, which usually doesn't attract user's attention (see
> \{{BeenUtils.mapJavaBeanProperties}} in \{{jboss-common-beans}})
> Other parameters are not validated.
> *Possible issues*
> Not validated activation config properties can be set to any value without
> warning. There is a possibility of misconfiguration which can be detected
> during deploy time.
> _Examples_
> Value of \{{acknowledgeMode}} can be set to any string or number without
> warning. If that is the case, server uses default auto acknowledge. However,
> it doesn't warn user.
> If property \{{maxSessions}} is configured with negative value, no warning is
> logged and MDB is unable to consume messages.
> If \{{destination}} property specifies unknown destination, new destination
> with provided name is created. User should be informed about that at least on
> INFO log level (Currently it is debug in
> \{{ActiveMQActivation.setupDestination()}}).
> MDB unable to consume messages should not successfully deploy, and user
> should be informed about the misconfigured values.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2094) Configuration change loss after failover to slave
[ https://issues.apache.org/jira/browse/ARTEMIS-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645227#comment-16645227 ] ASF GitHub Bot commented on ARTEMIS-2094: - Github user jbertram closed the pull request at: https://github.com/apache/activemq-artemis/pull/2351 > Configuration change loss after failover to slave > - > > Key: ARTEMIS-2094 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2094 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.3 >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > This is further cases discovered during testing network failures. > Essentially we have noticed when config settings are reloaded such as > address-setting or security-setting, the live node correctly reloads, but > after live failure the backup activates, the backup does not contain these > changes due to the configuration object held inside ActiveMQServerImpl is out > of date to when the backup server first started. > so further enhancements/bug fixes on top of ARTEMIS-1747 - Fix Configuration > change loss when network Issue. which fixed this for an active node. > Essentially we just need to keep the updating of the configuration object in > ActiveMQServerImpl outside the isActive check. > Also address-settings and security settings should be swap'd during > initialisation phase 2, so these are set to latest config after activation. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2094) Configuration change loss after failover to slave
[ https://issues.apache.org/jira/browse/ARTEMIS-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645232#comment-16645232 ] ASF GitHub Bot commented on ARTEMIS-2094: - Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/2356 @clebertsuconic sure no worries, i have some feature work (currently on DO NOT MERGE pr atm) , thats behind this currently, and have some further feature work behind that (e.g. builds on some refactor bits in first feature work), I just have bit of a serialised queue forming :). > Configuration change loss after failover to slave > - > > Key: ARTEMIS-2094 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2094 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.3 >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > This is further cases discovered during testing network failures. > Essentially we have noticed when config settings are reloaded such as > address-setting or security-setting, the live node correctly reloads, but > after live failure the backup activates, the backup does not contain these > changes due to the configuration object held inside ActiveMQServerImpl is out > of date to when the backup server first started. > so further enhancements/bug fixes on top of ARTEMIS-1747 - Fix Configuration > change loss when network Issue. which fixed this for an active node. > Essentially we just need to keep the updating of the configuration object in > ActiveMQServerImpl outside the isActive check. > Also address-settings and security settings should be swap'd during > initialisation phase 2, so these are set to latest config after activation. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2094) Configuration change loss after failover to slave
[ https://issues.apache.org/jira/browse/ARTEMIS-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645372#comment-16645372 ] ASF GitHub Bot commented on ARTEMIS-2094: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2356 @michaelandrepearce I will merge this.. I'm not sure if there's still something broken yet... I will ping you here if I see anything else wrong, ok? > Configuration change loss after failover to slave > - > > Key: ARTEMIS-2094 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2094 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.3 >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > This is further cases discovered during testing network failures. > Essentially we have noticed when config settings are reloaded such as > address-setting or security-setting, the live node correctly reloads, but > after live failure the backup activates, the backup does not contain these > changes due to the configuration object held inside ActiveMQServerImpl is out > of date to when the backup server first started. > so further enhancements/bug fixes on top of ARTEMIS-1747 - Fix Configuration > change loss when network Issue. which fixed this for an active node. > Essentially we just need to keep the updating of the configuration object in > ActiveMQServerImpl outside the isActive check. > Also address-settings and security settings should be swap'd during > initialisation phase 2, so these are set to latest config after activation. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2094) Configuration change loss after failover to slave
[ https://issues.apache.org/jira/browse/ARTEMIS-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645378#comment-16645378 ] ASF GitHub Bot commented on ARTEMIS-2094: - Github user michaelandrepearce commented on the issue: https://github.com/apache/activemq-artemis/pull/2356 Sure beans > Configuration change loss after failover to slave > - > > Key: ARTEMIS-2094 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2094 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.3 >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > This is further cases discovered during testing network failures. > Essentially we have noticed when config settings are reloaded such as > address-setting or security-setting, the live node correctly reloads, but > after live failure the backup activates, the backup does not contain these > changes due to the configuration object held inside ActiveMQServerImpl is out > of date to when the backup server first started. > so further enhancements/bug fixes on top of ARTEMIS-1747 - Fix Configuration > change loss when network Issue. which fixed this for an active node. > Essentially we just need to keep the updating of the configuration object in > ActiveMQServerImpl outside the isActive check. > Also address-settings and security settings should be swap'd during > initialisation phase 2, so these are set to latest config after activation. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2094) Configuration change loss after failover to slave
[ https://issues.apache.org/jira/browse/ARTEMIS-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645379#comment-16645379 ] ASF GitHub Bot commented on ARTEMIS-2094: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2356 > Configuration change loss after failover to slave > - > > Key: ARTEMIS-2094 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2094 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.3 >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > This is further cases discovered during testing network failures. > Essentially we have noticed when config settings are reloaded such as > address-setting or security-setting, the live node correctly reloads, but > after live failure the backup activates, the backup does not contain these > changes due to the configuration object held inside ActiveMQServerImpl is out > of date to when the backup server first started. > so further enhancements/bug fixes on top of ARTEMIS-1747 - Fix Configuration > change loss when network Issue. which fixed this for an active node. > Essentially we just need to keep the updating of the configuration object in > ActiveMQServerImpl outside the isActive check. > Also address-settings and security settings should be swap'd during > initialisation phase 2, so these are set to latest config after activation. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AMQ-7070) Priority is not being respected when the cursor cache flips
Alan Protasio created AMQ-7070: -- Summary: Priority is not being respected when the cursor cache flips Key: AMQ-7070 URL: https://issues.apache.org/jira/browse/AMQ-7070 Project: ActiveMQ Issue Type: Test Components: Broker Reporter: Alan Protasio Messages are being dispatched with wrong priority when the cache is flipped. See: https://github.com/apache/activemq/blob/master/activemq-broker/src/main/java/org/apache/activemq/broker/region/cursors/AbstractStoreCursor.java#L258 All messages that could get cached in the cursor are dispatched before even though massages with higher priority is in the cache. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2117) Add QPID LVQ Features into Broker
[ https://issues.apache.org/jira/browse/ARTEMIS-2117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645514#comment-16645514 ] ASF GitHub Bot commented on ARTEMIS-2117: - GitHub user michaelandrepearce opened a pull request: https://github.com/apache/activemq-artemis/pull/2362 ARTEMIS-2117 Add custom LVQ Key and Non Destructive Queue into Broker Implement custom LVQ Key and Non-Destructive in broker - protocol agnostic Make feature configurable via broker.xml, core apis and activemqservercontrol Add last-value-key test cases Add non-destructive with lvq test cases Add non-destructive with expiry-delay test cases Update documents Add new methods to support create, update with new attributes Refactor to pass through queue-attributes in client side methods to reduce further method changes for adding new attributes in future and avoid methods with endless parameters. (note: in future this should prob be done server side too) Update existing test cases and fake impls for new methods/attributes You can merge this pull request into a Git repository by running: $ git pull https://github.com/michaelandrepearce/activemq-artemis qpid-lvq-feature Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2362.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 #2362 commit 2af8fc924cbf4c56746331bd98b7c1547162e905 Author: Michael André Pearce Date: 2018-10-10T00:07:02Z ARTEMIS-2117 Add custom LVQ Key and Non Destructive Queue into Broker Implement custom LVQ Key and Non-Destructive in broker - protocol agnostic Make feature configurable via broker.xml, core apis and activemqservercontrol Add last-value-key test cases Add non-destructive with lvq test cases Add non-destructive with expiry-delay test cases Update documents Add new methods to support create, update with new attributes Refactor to pass through queue-attributes in client side methods to reduce further method changes for adding new attributes in future and avoid methods with endless parameters. (note: in future this should prob be done server side too) Update existing test cases and fake impls for new methods/attributes > Add QPID LVQ Features into Broker > - > > Key: ARTEMIS-2117 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2117 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.6.3 >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > To assist users migrating from qpid to artemis. > Currently LVQ in artemis uses a fixed message property for the LVQ key, Qpid > supports queues to have custom/arbitrary message property to be the LVQ key, > this is more flexible. > [http://qpid.apache.org/releases/qpid-broker-j-7.0.1/book/Java-Broker-Concepts-Queues.html#Java-Broker-Concepts-Queues-Types-LVQ] > > Also an additional feature typically used with LVQ's in qpid is ability to > mark a queue non-destructive. > [http://qpid.apache.org/releases/qpid-broker-j-7.0.1/book/Java-Broker-Concepts-Queues.html#Java-Broker-Concepts-Queue-EnsureNonDestructiveConsumers] > > As such this is to add both support ability to use a arbitrary last-value-key > for LVQ and for support of setting a queue to be non-destructive, at the > broker level and via core apis. > Scope is to add basic feature into the broker and core apis, out of scope is > dynamic creation from a client via amqp which would be a later piece of work. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQ-7070) Priority is not being respected when the cursor cache flips
[ https://issues.apache.org/jira/browse/AMQ-7070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Protasio updated AMQ-7070: --- Attachment: AMQ7070Test.java > Priority is not being respected when the cursor cache flips > --- > > Key: AMQ-7070 > URL: https://issues.apache.org/jira/browse/AMQ-7070 > Project: ActiveMQ > Issue Type: Test > Components: Broker >Reporter: Alan Protasio >Priority: Minor > Attachments: AMQ7070Test.java > > > Messages are being dispatched with wrong priority when the cache is flipped. > See: > https://github.com/apache/activemq/blob/master/activemq-broker/src/main/java/org/apache/activemq/broker/region/cursors/AbstractStoreCursor.java#L258 > All messages that could get cached in the cursor are dispatched before even > though massages with higher priority is in the cache. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1898) [AMQP] sender is not granted credit once space on queue is available
[ https://issues.apache.org/jira/browse/ARTEMIS-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645630#comment-16645630 ] ASF GitHub Bot commented on ARTEMIS-1898: - GitHub user clebertsuconic opened a pull request: https://github.com/apache/activemq-artemis/pull/2364 ARTEMIS-1898 Proper fix on AtomicRunnables and avoiding leaks GlobalDiskFullTest was broken before this fix. Basically when using multiple addresses over a session you would miss flow credits on all your producers except to the first one that ran out of credit. You can merge this pull request into a Git repository by running: $ git pull https://github.com/clebertsuconic/activemq-artemis tosend Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2364.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 #2364 commit 39a5701964e506bc81e653ef05296356e3fcb610 Author: Clebert Suconic Date: 2018-10-10T22:09:28Z ARTEMIS-1898 Proper fix on AtomicRunnables and avoiding leaks GlobalDiskFullTest was broken before this fix. Basically when using multiple addresses over a session you would miss flow credits on all your producers except to the first one that ran out of credit. > [AMQP] sender is not granted credit once space on queue is available > > > Key: ARTEMIS-1898 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1898 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Gordon Sim >Assignee: Andy Taylor >Priority: Major > Fix For: 2.6.4 > > Attachments: drain.py, test_send.py > > > If an AMQP publisher sends to a queue that is full, with > address-full-policy=FAIL, it gets messages rejected and no credit issued as > expected. However if the queue is then drained, that existing sender link is > not granted any more credit. > To reproduce, configure a broker such that it has a queue called examples > with some fairly low max size (I set global-max-size to 100kb) and > address-full-policy of FAIL. Then run attached test_send.py with args e.g. -m > 10. The sender will eventually stall due to lack of credit. Then run the > attached drain.py which will drain the queue. This *should* allow the sender > to resume sending, but it does not. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1898) [AMQP] sender is not granted credit once space on queue is available
[ https://issues.apache.org/jira/browse/ARTEMIS-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645632#comment-16645632 ] ASF GitHub Bot commented on ARTEMIS-1898: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2364 I have the PR sent here for future conversations. But I plan to merge this myself as I am fixing the testsuite. I will wait the PR check and then merge it myself. (you have a short window if you disagree with something here. .but we can always change things later if you see anything wrong). > [AMQP] sender is not granted credit once space on queue is available > > > Key: ARTEMIS-1898 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1898 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Gordon Sim >Assignee: Andy Taylor >Priority: Major > Fix For: 2.6.4 > > Attachments: drain.py, test_send.py > > > If an AMQP publisher sends to a queue that is full, with > address-full-policy=FAIL, it gets messages rejected and no credit issued as > expected. However if the queue is then drained, that existing sender link is > not granted any more credit. > To reproduce, configure a broker such that it has a queue called examples > with some fairly low max size (I set global-max-size to 100kb) and > address-full-policy of FAIL. Then run attached test_send.py with args e.g. -m > 10. The sender will eventually stall due to lack of credit. Then run the > attached drain.py which will drain the queue. This *should* allow the sender > to resume sending, but it does not. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2094) Configuration change loss after failover to slave
[ https://issues.apache.org/jira/browse/ARTEMIS-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645642#comment-16645642 ] ASF GitHub Bot commented on ARTEMIS-2094: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2356 @michaelandrepearce really really thanks! It's all good now! > Configuration change loss after failover to slave > - > > Key: ARTEMIS-2094 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2094 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.3 >Reporter: Michael Andre Pearce >Assignee: Michael Andre Pearce >Priority: Major > > This is further cases discovered during testing network failures. > Essentially we have noticed when config settings are reloaded such as > address-setting or security-setting, the live node correctly reloads, but > after live failure the backup activates, the backup does not contain these > changes due to the configuration object held inside ActiveMQServerImpl is out > of date to when the backup server first started. > so further enhancements/bug fixes on top of ARTEMIS-1747 - Fix Configuration > change loss when network Issue. which fixed this for an active node. > Essentially we just need to keep the updating of the configuration object in > ActiveMQServerImpl outside the isActive check. > Also address-settings and security settings should be swap'd during > initialisation phase 2, so these are set to latest config after activation. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1898) [AMQP] sender is not granted credit once space on queue is available
[ https://issues.apache.org/jira/browse/ARTEMIS-1898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645643#comment-16645643 ] ASF GitHub Bot commented on ARTEMIS-1898: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2364 > [AMQP] sender is not granted credit once space on queue is available > > > Key: ARTEMIS-1898 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1898 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Gordon Sim >Assignee: Andy Taylor >Priority: Major > Fix For: 2.6.4 > > Attachments: drain.py, test_send.py > > > If an AMQP publisher sends to a queue that is full, with > address-full-policy=FAIL, it gets messages rejected and no credit issued as > expected. However if the queue is then drained, that existing sender link is > not granted any more credit. > To reproduce, configure a broker such that it has a queue called examples > with some fairly low max size (I set global-max-size to 100kb) and > address-full-policy of FAIL. Then run attached test_send.py with args e.g. -m > 10. The sender will eventually stall due to lack of credit. Then run the > attached drain.py which will drain the queue. This *should* allow the sender > to resume sending, but it does not. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2116) Set text message content on producer CLI command
[ https://issues.apache.org/jira/browse/ARTEMIS-2116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645646#comment-16645646 ] ASF GitHub Bot commented on ARTEMIS-2116: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2355 > Set text message content on producer CLI command > > > Key: ARTEMIS-2116 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2116 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Francesco Nigro >Assignee: Francesco Nigro >Priority: Minor > Fix For: 2.7.0, 2.6.4 > > > Implement the ability to set text message content on the producer CLI command -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2112) Remove JMX properties from start scripts
[
https://issues.apache.org/jira/browse/ARTEMIS-2112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645647#comment-16645647
]
ASF GitHub Bot commented on ARTEMIS-2112:
-
Github user asfgit closed the pull request at:
https://github.com/apache/activemq-artemis/pull/2348
> Remove JMX properties from start scripts
>
>
> Key: ARTEMIS-2112
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2112
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.6.3
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.7.0, 2.6.4
>
>
> JMX configuration is now done via {{management.xml}}. Configuring JMX via
> the start scripts could result in unexpected behavior since the
> {{authorisation}} configuration from {{management.xml}} would be ignored.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2111) ManagementContext can leak
[
https://issues.apache.org/jira/browse/ARTEMIS-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645649#comment-16645649
]
ASF GitHub Bot commented on ARTEMIS-2111:
-
Github user asfgit closed the pull request at:
https://github.com/apache/activemq-artemis/pull/2347
> ManagementContext can leak
> --
>
> Key: ARTEMIS-2111
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2111
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.6.3
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
>
> If a {{management-context}} {{connector}} is configured in {{management.xml}}
> (e.g. below) and
> {{org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl#stop(boolean,
> boolean, boolean)}} is called (e.g. due to criticalIOErrors) the JVM will
> not exit due to a handful of leaked RMI related threads for the MBean server
> implementation.
> {code:xml}
> http://activemq.org/schema";>
>
>...
>
> {code}
> Here's an example thread dump after the broker has stopped:
> {noformat}
> 2018-08-10 10:47:59
> Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.20-b23 mixed mode):
> "Attach Listener" #122 daemon prio=9 os_prio=31 tid=0x7fe609a37800
> nid=0x920f waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
>Locked ownable synchronizers:
> - None
> "DestroyJavaVM" #57 prio=5 os_prio=31 tid=0x7fe60a000800 nid=0x1c03
> waiting on condition [0x]
>java.lang.Thread.State: RUNNABLE
>Locked ownable synchronizers:
> - None
> "RMI RenewClean-[192.168.1.125:62416]" #20 daemon prio=5 os_prio=31
> tid=0x7fe609432800 nid=0x7f03 in Object.wait() [0x7672e000]
>java.lang.Thread.State: TIMED_WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x0007400d1e18> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142)
> - locked <0x0007400d1e18> (a java.lang.ref.ReferenceQueue$Lock)
> at
> sun.rmi.transport.DGCClient$EndpointEntry$RenewCleanThread.run(DGCClient.java:536)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - None
> "RMI Scheduler(0)" #19 daemon prio=5 os_prio=31 tid=0x7fe60c2c4000
> nid=0x7d03 waiting on condition [0x7662b000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00074017e5b8> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
> at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - None
> "GC Daemon" #17 daemon prio=2 os_prio=31 tid=0x7fe60c2bb000 nid=0x7903 in
> Object.wait() [0x76425000]
>java.lang.Thread.State: TIMED_WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x0007402b00c8> (a sun.misc.GC$LatencyLock)
> at sun.misc.GC$Daemon.run(GC.java:117)
> - locked <0x0007402b00c8> (a sun.misc.GC$LatencyLock)
>Locked ownable synchronizers:
> - None
> "RMI Reaper" #16 prio=5 os_prio=31 tid=0x7fe60d001800 nid=0x7703 in
> Object.wait() [0x76322000]
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x0007401d9310> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142)
> - locked <0x0007401d9310> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:158)
> at sun.rmi.transport.ObjectTable$Reaper.run(ObjectTable.java:351)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - None
> "RMI TCP Accept-0" #15 daemon prio=5 os_prio=31 tid=0x7fe60a902000
> nid=0x7503 runnable [0x7621f000]
>java.lang.Thread.State: RUNNABLE
> at java.net.PlainSocketImpl.so
[jira] [Commented] (ARTEMIS-2110) JDBC LeaseLocker repeated renew or renew after aquire can fail in error
[ https://issues.apache.org/jira/browse/ARTEMIS-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645650#comment-16645650 ] ASF GitHub Bot commented on ARTEMIS-2110: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2346 > JDBC LeaseLocker repeated renew or renew after aquire can fail in error > --- > > Key: ARTEMIS-2110 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2110 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.6.3 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Minor > Fix For: 2.7.0 > > > There is an intermittent failure in: > org.apache.activemq.artemis.core.server.impl.jdbc.JdbcLeaseLockTest#shouldRenewAcquiredLock > (seems to block pr ci, and reproduced for me 20% of the time) > if the db currentTime has not moved on, using the same lease time results in > a failure. A renew immediately after acquiring the lock is a sensible pattern > to verify the aquire. > > The lock renew needs >= in place or > on the WHERE clause to allow an > 'identity' lease to succeed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2108) Potential StackOverflowError when load balancing disabled
[ https://issues.apache.org/jira/browse/ARTEMIS-2108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645651#comment-16645651 ] ASF GitHub Bot commented on ARTEMIS-2108: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2345 > Potential StackOverflowError when load balancing disabled > - > > Key: ARTEMIS-2108 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2108 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > > It's possible that when a cluster has disabled message load balancing then a > message sent to a node that only has a corresponding remote queue binding > will trigger a stack overflow. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2106) Failures during broker start are not clearly logged
[ https://issues.apache.org/jira/browse/ARTEMIS-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645653#comment-16645653 ] ASF GitHub Bot commented on ARTEMIS-2106: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2343 > Failures during broker start are not clearly logged > --- > > Key: ARTEMIS-2106 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2106 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.6.3 >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Fix For: 2.7.0, 2.6.4 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2107) Clarify identity for authn failures in notification
[ https://issues.apache.org/jira/browse/ARTEMIS-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645652#comment-16645652 ] ASF GitHub Bot commented on ARTEMIS-2107: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2344 > Clarify identity for authn failures in notification > --- > > Key: ARTEMIS-2107 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2107 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2103) VirtualTopic doesn't work correctly with multiple consumers
[
https://issues.apache.org/jira/browse/ARTEMIS-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645680#comment-16645680
]
ASF GitHub Bot commented on ARTEMIS-2103:
-
Github user asfgit closed the pull request at:
https://github.com/apache/activemq-artemis/pull/2341
> VirtualTopic doesn't work correctly with multiple consumers
> ---
>
> Key: ARTEMIS-2103
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2103
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker, OpenWire
>Affects Versions: 2.6.3
>Reporter: Pawel
>Assignee: Gary Tully
>Priority: Major
>
> It's impossibe to subscribe multiple virtual topics with the same consumer
> name.
> I've configured acceptor like described in documentation:
> {code:java}
> tcp://0.0.0.0:61616?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=CORE,AMQP,STOMP,HORNETQ,MQTT,OPENWIRE;useEpoll=true;amqpCredits=1000;amqpLowCredits=300;virtualTopicConsumerWildcards=Consumer.*.%3E%3B2{code}
> When I'm connecting first consumer:
> *Consumer.cons1.VirtualTopic.t1*
> proper binding is created.
> Next I'm trying to connect second consumer with the same name:
> *Consumer.cons1.VirtualTopic.t2*
> But no binding is created.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1018) Duplicate error ids on different error messages
[
https://issues.apache.org/jira/browse/ARTEMIS-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645682#comment-16645682
]
ASF GitHub Bot commented on ARTEMIS-1018:
-
Github user asfgit closed the pull request at:
https://github.com/apache/activemq-artemis/pull/2340
> Duplicate error ids on different error messages
> ---
>
> Key: ARTEMIS-1018
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1018
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker
>Affects Versions: 2.0.0
>Reporter: Jiri Daněk
>Priority: Minor
>
> Some messages happen to have the same id, for example
> {noformat}
>@Message(id = 119019, value = "Session is closed")
>ActiveMQObjectClosedException sessionClosed();
> @Message(id = 119019, value = "Queue already exists {0}", format =
> Message.Format.MESSAGE_FORMAT)
>ActiveMQQueueExistsException queueAlreadyExists(SimpleString queueName);
> {noformat}
> (I stumbled upon this when trying to send message from
> artemis-jms-client-1.5.4 to artemis-server-2.0.0; I searched for the message
> code of the message I got and got two results, instead of one.)
> It may not be a problem, since one is ActiveMQClientMessageBundle and the
> other is ActiveMQMessage bundle, but still.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2102) delete paging directory or table if address is removed
[ https://issues.apache.org/jira/browse/ARTEMIS-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645684#comment-16645684 ] ASF GitHub Bot commented on ARTEMIS-2102: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2339 > delete paging directory or table if address is removed > -- > > Key: ARTEMIS-2102 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2102 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.6.3 >Reporter: yangwei >Priority: Major > > Our app uses clientRequestor to get message count or other metrics. > When the broker is globally full(all addresses enters into paging mode), each > request by clientRequestor will create a temporary reply queue causing a new > paging directory is created. After each request clientRequestor is closed and > the temporary queue is deleted, the broker only purges the queue data. > We should delete paging directory to fix the problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2105) Discovery group connectors can delay broker shutdown
[ https://issues.apache.org/jira/browse/ARTEMIS-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645686#comment-16645686 ] ASF GitHub Bot commented on ARTEMIS-2105: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2342 > Discovery group connectors can delay broker shutdown > > > Key: ARTEMIS-2105 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2105 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.6.3 >Reporter: Ingo Weiss >Priority: Major > > When there is a discovery group configured, shutting down the broker while it > is waiting on a broadcast response will wait for the discovery group timeout. > The total length of the timeout will depend on the number of connectors > configured. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7070) Priority is not being respected when the cursor cache flips
[ https://issues.apache.org/jira/browse/AMQ-7070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645841#comment-16645841 ] ASF GitHub Bot commented on AMQ-7070: - GitHub user alanprot opened a pull request: https://github.com/apache/activemq/pull/306 AMQ-7070 - Priority is not being respected when the cursor cache flips Messages are being dispatched with wrong priority when the cache is flipped. All messages that could get cached in the cursor are dispatched before even though massages with higher priority is in the cache. You can merge this pull request into a Git repository by running: $ git pull https://github.com/alanprot/activemq master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq/pull/306.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 #306 commit 4eaa0538d15da60caf170d1f099d2c6ca71a78b8 Author: Alan Protasio Date: 2018-10-09T21:59:02Z AMQ-7070 - Priority is not being respected when the cursor cache flips Messages are being dispatched with wrong priority when the cache is flipped. All messages that could get cached in the cursor are dispatched before even though massages with higher priority is in the cache. > Priority is not being respected when the cursor cache flips > --- > > Key: AMQ-7070 > URL: https://issues.apache.org/jira/browse/AMQ-7070 > Project: ActiveMQ > Issue Type: Test > Components: Broker >Reporter: Alan Protasio >Priority: Minor > Attachments: AMQ7070Test.java > > > Messages are being dispatched with wrong priority when the cache is flipped. > See: > https://github.com/apache/activemq/blob/master/activemq-broker/src/main/java/org/apache/activemq/broker/region/cursors/AbstractStoreCursor.java#L258 > All messages that could get cached in the cursor are dispatched before even > though massages with higher priority is in the cache. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7070) Priority is not being respected when the cursor cache flips
[ https://issues.apache.org/jira/browse/AMQ-7070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645848#comment-16645848 ] Alan Protasio commented on AMQ-7070: Unfortunately, the only solution that I found for this is discarding the messages from the cache. Maybe this is not a big deal this only happens when we are disabling the cache anyway and after the first time the the cache, we need to fill it back from the storage anyway until the cursor became empty again (size = 0). See: https://github.com/apache/activemq/blob/master/activemq-broker/src/main/java/org/apache/activemq/broker/region/cursors/AbstractStoreCursor.java#L286 I tried to only try to fill the cursor when each priority is exhausted (in theAbstractStoreCursor.hasNext method for example) but the problem is if we do this and messages are being sent with different priorities, we will be trying to fill the cursor from the storage all the time (to make sure that the next has the right priority). > Priority is not being respected when the cursor cache flips > --- > > Key: AMQ-7070 > URL: https://issues.apache.org/jira/browse/AMQ-7070 > Project: ActiveMQ > Issue Type: Test > Components: Broker >Reporter: Alan Protasio >Priority: Minor > Attachments: AMQ7070Test.java > > > Messages are being dispatched with wrong priority when the cache is flipped. > See: > https://github.com/apache/activemq/blob/master/activemq-broker/src/main/java/org/apache/activemq/broker/region/cursors/AbstractStoreCursor.java#L258 > All messages that could get cached in the cursor are dispatched before even > though massages with higher priority is in the cache. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2121) Reload logging configuration at runtime
[ https://issues.apache.org/jira/browse/ARTEMIS-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16645908#comment-16645908 ] ASF GitHub Bot commented on ARTEMIS-2121: - GitHub user jbertram opened a pull request: https://github.com/apache/activemq-artemis/pull/2365 ARTEMIS-2121 reload logging config at runtime Many thanks to James Perkins who supplied the guts of the reload logic. You can merge this pull request into a Git repository by running: $ git pull https://github.com/jbertram/activemq-artemis ARTEMIS-2121 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2365.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 #2365 commit 4e3b41016146a802b7da980dcaca022c7c030ded Author: Justin Bertram Date: 2018-09-29T02:37:58Z ARTEMIS-2121 reload logging config at runtime Many thanks to James Perkins who supplied the guts of the reload logic. > Reload logging configuration at runtime > --- > > Key: ARTEMIS-2121 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2121 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2028) Add OpenTracing support
[ https://issues.apache.org/jira/browse/ARTEMIS-2028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16646006#comment-16646006 ] Carsten Lohmann commented on ARTEMIS-2028: -- The [mailing list discussion|https://activemq-users.markmail.org/thread/wnhb3hpume2jt57r] a while back has had the result, that a solution as a broker plugin, kept outside of the Artemis repo, is seen as the preferred way to implement this (possibly contributed to "OpenTracing-contrib"). As for the necessary features to implement such a plugin, there's only ARTEMIS-2045 missing as of now - see [PR#2256|https://github.com/apache/activemq-artemis/pull/2256]. @[~jbertram]: Do you see a way for someone to have a look at that PR? > Add OpenTracing support > --- > > Key: ARTEMIS-2028 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2028 > Project: ActiveMQ Artemis > Issue Type: New Feature >Reporter: Carsten Lohmann >Priority: Major > Attachments: Artemis-OpenTracing.png, Artemis-OpenTracing2.png > > > In order to get an overview of the lifetime of a message going through > different messaging components, it would be good to have support for > distributed tracing in Artemis. > The [OpenTracing|http://opentracing.io/] standard defines an API for this, > facilitating the use of different (OpenTracing-compatible) tracing systems > (e.g. [Jaeger|https://jaegertracing.io/]). > This would mean more general distributed tracing support than the one > proposed in ARTEMIS-461. > To start out with, support could be added to the AMQP protocol, using AMQP > delivery annotations to get the OpenTracing SpanContext from incoming > messages and to put the SpanContext into outgoing messages. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
