[jira] [Work logged] (ARTEMIS-2453) DeadLock between server.destroyQueue and server.removeAddressInfo
[ https://issues.apache.org/jira/browse/ARTEMIS-2453?focusedWorklogId=296075&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-296075 ] ASF GitHub Bot logged work on ARTEMIS-2453: --- Author: ASF GitHub Bot Created on: 16/Aug/19 04:57 Start Date: 16/Aug/19 04:57 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on pull request #2799: ARTEMIS-2453 Fixing deadLock between destroyQueue and removeAddressInfo URL: https://github.com/apache/activemq-artemis/pull/2799#discussion_r314583108 ## File path: artemis-server/src/main/java/org/apache/activemq/artemis/core/postoffice/impl/PostOfficeImpl.java ## @@ -484,7 +482,7 @@ public QueueBinding updateQueue(SimpleString name, Long delayBeforeDispatch, SimpleString user, Boolean configurationManaged) throws Exception { - synchronized (addressLock) { + synchronized (this) { Review comment: Why not make synchronized method for these methods if the whole block is syncd? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 296075) Time Spent: 1h 10m (was: 1h) > DeadLock between server.destroyQueue and server.removeAddressInfo > - > > Key: ARTEMIS-2453 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2453 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: clebert suconic >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > "Thread-0 > (ActiveMQ-remoting-threads-ActiveMQServerImpl::serverUUID=349ac51e-bf5e-11e9-9661-ecf4bbced624-2058174333)": > at > org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.getAddressInfo(PostOfficeImpl.java:652) > - waiting to lock <0x0005be7a5488> (a java.lang.Object) at > org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.removeBinding(PostOfficeImpl.java:749) > - locked <0x0005bb0702c8> (a > org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl) at > org.apache.activemq.artemis.core.server.impl.QueueImpl.deleteQueue(QueueImpl.java:1962) > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2142) > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2090) > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2081) > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2061) > at > org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.run(ServerSessionImpl.java:986) > at > org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.connectionFailed(ServerSessionImpl.java:1001) > at > org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.connectionFailed(ServerSessionImpl.java:1006) > at > org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.callFailureListeners(AbstractRemotingConnection.java:77) > at > org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:220) > at > org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.fail(AbstractRemotingConnection.java:220) > at > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.issueFailure(RemotingServiceImpl.java:572) > at > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.connectionDestroyed(RemotingServiceImpl.java:553) > at > org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptor$Listener.connectionDestroyed(NettyAcceptor.java:897) > at > org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.lambda$channelInactive$0(ActiveMQChannelHandler.java:83) > at > org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler$$Lambda$56/1250509089.run(Unknown > Source) at > org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42) > at > org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31) > at > org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66) > at > org.apache.activemq.artemis.utils.actors.ProcessorBase$$Lambda$2/323326
[jira] [Work logged] (ARTEMIS-2399) Improve performance when there are a lot of subscribers
[ https://issues.apache.org/jira/browse/ARTEMIS-2399?focusedWorklogId=296074&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-296074 ] ASF GitHub Bot logged work on ARTEMIS-2399: --- Author: ASF GitHub Bot Created on: 16/Aug/19 04:56 Start Date: 16/Aug/19 04:56 Worklog Time Spent: 10m Work Description: wy96f commented on issue #2750: ARTEMIS-2399 Improve performance when there are a lot of subscribers URL: https://github.com/apache/activemq-artemis/pull/2750#issuecomment-521883667 @michaelandrepearce Can you wait a moment? When the browse cursor iterators(like the one created by QueueControl::browse, browse only consumer, etc) are closed, the page opened by them is not closed. I would push another commit to fix this. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 296074) Time Spent: 17h 10m (was: 17h) > Improve performance when there are a lot of subscribers > --- > > Key: ARTEMIS-2399 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2399 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.9.0 > Environment: broker 2.9.0 > cpu: 4 cores, memory: 8G, disk: ssd 500G > broker.xml: > 60 > > 51Mb > 50Mb > 1 > PAGE > > -1 >Reporter: yangwei >Priority: Major > Time Spent: 17h 10m > Remaining Estimate: 0h > > We noticed that there was a significant drop in performance when entering > page mode in the case of multiple subscribers. > We created a topic and 100 queues bound to it. We ran our _GrinderRunner > test_ in our inner test infra cluster with 500 threads producing message and > 560 threads, each one picked a random queue to subscribe. The test showed > performance is bad: 13000 msg/s sent and 5000 msg/s received. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2399) Improve performance when there are a lot of subscribers
[ https://issues.apache.org/jira/browse/ARTEMIS-2399?focusedWorklogId=296071&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-296071 ] ASF GitHub Bot logged work on ARTEMIS-2399: --- Author: ASF GitHub Bot Created on: 16/Aug/19 04:48 Start Date: 16/Aug/19 04:48 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2750: ARTEMIS-2399 Improve performance when there are a lot of subscribers URL: https://github.com/apache/activemq-artemis/pull/2750#issuecomment-521882489 @wy96f can you squash commits so we can merge? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 296071) Time Spent: 17h (was: 16h 50m) > Improve performance when there are a lot of subscribers > --- > > Key: ARTEMIS-2399 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2399 > Project: ActiveMQ Artemis > Issue Type: Improvement > Components: Broker >Affects Versions: 2.9.0 > Environment: broker 2.9.0 > cpu: 4 cores, memory: 8G, disk: ssd 500G > broker.xml: > 60 > > 51Mb > 50Mb > 1 > PAGE > > -1 >Reporter: yangwei >Priority: Major > Time Spent: 17h > Remaining Estimate: 0h > > We noticed that there was a significant drop in performance when entering > page mode in the case of multiple subscribers. > We created a topic and 100 queues bound to it. We ran our _GrinderRunner > test_ in our inner test infra cluster with 500 threads producing message and > 560 threads, each one picked a random queue to subscribe. The test showed > performance is bad: 13000 msg/s sent and 5000 msg/s received. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2442) throw ActiveMQResourceLimitException if session/queue limit is reached
[ https://issues.apache.org/jira/browse/ARTEMIS-2442?focusedWorklogId=296068&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-296068 ] ASF GitHub Bot logged work on ARTEMIS-2442: --- Author: ASF GitHub Bot Created on: 16/Aug/19 04:46 Start Date: 16/Aug/19 04:46 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on pull request #2785: ARTEMIS-2442 throw ActiveMQResourceLimitException if session/queue limit is reached URL: https://github.com/apache/activemq-artemis/pull/2785#discussion_r314581735 ## File path: artemis-commons/src/main/java/org/apache/activemq/artemis/api/core/ActiveMQExceptionType.java ## @@ -261,6 +261,12 @@ public ActiveMQException createException(String msg) { public ActiveMQException createException(String msg) { return new ActiveMQReplicationTimeooutException(msg); } + }, + RESOURCE_LIMIT_REACHED(221) { Review comment: People can use native core client. Not everyone uses jms. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 296068) Time Spent: 1h 10m (was: 1h) > throw ActiveMQResourceLimitException if session/queue limit is reached > -- > > Key: ARTEMIS-2442 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2442 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Reporter: yangwei >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > Now ActiveMQSessionCreationException is thrown when session/queue limit is > reached. ActiveMQSessionCreationException is used to indicate server is > starting. It would cause session recreation retries all the time. Session > creation should fail fast when limit is reached so client can try to connect > other brokers in cluster. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2442) throw ActiveMQResourceLimitException if session/queue limit is reached
[ https://issues.apache.org/jira/browse/ARTEMIS-2442?focusedWorklogId=296067&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-296067 ] ASF GitHub Bot logged work on ARTEMIS-2442: --- Author: ASF GitHub Bot Created on: 16/Aug/19 04:45 Start Date: 16/Aug/19 04:45 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on pull request #2785: ARTEMIS-2442 throw ActiveMQResourceLimitException if session/queue limit is reached URL: https://github.com/apache/activemq-artemis/pull/2785#discussion_r314581585 ## File path: artemis-commons/src/main/java/org/apache/activemq/artemis/api/core/ActiveMQResourceLimitException.java ## @@ -0,0 +1,30 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.activemq.artemis.api.core; + +public final class ActiveMQResourceLimitException extends ActiveMQException { + Review comment: Theyre independent comments. E.g. this is as well as the other This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 296067) Time Spent: 1h (was: 50m) > throw ActiveMQResourceLimitException if session/queue limit is reached > -- > > Key: ARTEMIS-2442 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2442 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Reporter: yangwei >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > Now ActiveMQSessionCreationException is thrown when session/queue limit is > reached. ActiveMQSessionCreationException is used to indicate server is > starting. It would cause session recreation retries all the time. Session > creation should fail fast when limit is reached so client can try to connect > other brokers in cluster. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2442) throw ActiveMQResourceLimitException if session/queue limit is reached
[ https://issues.apache.org/jira/browse/ARTEMIS-2442?focusedWorklogId=295975&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295975 ] ASF GitHub Bot logged work on ARTEMIS-2442: --- Author: ASF GitHub Bot Created on: 16/Aug/19 02:41 Start Date: 16/Aug/19 02:41 Worklog Time Spent: 10m Work Description: wy96f commented on pull request #2785: ARTEMIS-2442 throw ActiveMQResourceLimitException if session/queue limit is reached URL: https://github.com/apache/activemq-artemis/pull/2785#discussion_r314566368 ## File path: artemis-commons/src/main/java/org/apache/activemq/artemis/api/core/ActiveMQResourceLimitException.java ## @@ -0,0 +1,30 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.activemq.artemis.api.core; + +public final class ActiveMQResourceLimitException extends ActiveMQException { + Review comment: Do you mean ActiveMQResourceLimitException extends ActiveMQSessionCreationException, and with RESOURCE_LIMIT_REACHED ActiveMQExceptionType? If so, older client still can't understand new exception by new ActiveMQExceptionType code when the code is passed back to client. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295975) Time Spent: 50m (was: 40m) > throw ActiveMQResourceLimitException if session/queue limit is reached > -- > > Key: ARTEMIS-2442 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2442 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Reporter: yangwei >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > Now ActiveMQSessionCreationException is thrown when session/queue limit is > reached. ActiveMQSessionCreationException is used to indicate server is > starting. It would cause session recreation retries all the time. Session > creation should fail fast when limit is reached so client can try to connect > other brokers in cluster. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2442) throw ActiveMQResourceLimitException if session/queue limit is reached
[ https://issues.apache.org/jira/browse/ARTEMIS-2442?focusedWorklogId=295973&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295973 ] ASF GitHub Bot logged work on ARTEMIS-2442: --- Author: ASF GitHub Bot Created on: 16/Aug/19 02:41 Start Date: 16/Aug/19 02:41 Worklog Time Spent: 10m Work Description: wy96f commented on pull request #2785: ARTEMIS-2442 throw ActiveMQResourceLimitException if session/queue limit is reached URL: https://github.com/apache/activemq-artemis/pull/2785#discussion_r314566358 ## File path: artemis-commons/src/main/java/org/apache/activemq/artemis/api/core/ActiveMQExceptionType.java ## @@ -261,6 +261,12 @@ public ActiveMQException createException(String msg) { public ActiveMQException createException(String msg) { return new ActiveMQReplicationTimeooutException(msg); } + }, + RESOURCE_LIMIT_REACHED(221) { Review comment: For older client that don't understand, "ActiveMQException"(type code is GENERIC_EXCEPTION) would be decoded and thrown. There are two places where ActiveMQExceptionType.SESSION_CREATION_REJECTED is judged, one is ActiveMQSessionContext::recreateSession(), the other is BridgeImpl::connect(). For both of them, the logic is same in the case of GENERIC_EXCEPTION(old client) and RESOURCE_LIMIT_EXCEEDED(new client). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295973) Time Spent: 40m (was: 0.5h) > throw ActiveMQResourceLimitException if session/queue limit is reached > -- > > Key: ARTEMIS-2442 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2442 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Reporter: yangwei >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Now ActiveMQSessionCreationException is thrown when session/queue limit is > reached. ActiveMQSessionCreationException is used to indicate server is > starting. It would cause session recreation retries all the time. Session > creation should fail fast when limit is reached so client can try to connect > other brokers in cluster. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2450) page-size-bytes should not be greater than Integer.MAX_VALUE
[ https://issues.apache.org/jira/browse/ARTEMIS-2450?focusedWorklogId=295928&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295928 ] ASF GitHub Bot logged work on ARTEMIS-2450: --- Author: ASF GitHub Bot Created on: 16/Aug/19 01:36 Start Date: 16/Aug/19 01:36 Worklog Time Spent: 10m Work Description: wy96f commented on pull request #2791: ARTEMIS-2450 page-size-bytes should not be greater than Integer.MAX_VALUE URL: https://github.com/apache/activemq-artemis/pull/2791#discussion_r314557230 ## File path: artemis-server/src/test/java/org/apache/activemq/artemis/core/config/impl/FileConfigurationParserTest.java ## @@ -257,6 +257,26 @@ public void testParsingDefaultServerConfigWithENCMaskedPwd() throws Exception { assertEquals("helloworld", bconfig.getPassword()); } + @Test + public void testParsingOverflowPageSize() throws Exception { + FileConfigurationParser parser = new FileConfigurationParser(); Review comment: > E.g. other sizes are quite happily long currently also. Why is this special I see in Page::write()/Page::read() all operations are limited to int range, such as PagingStoreImpl::currentPageSize, Page::size, and local variables like fileSize, processedBytes in Page::readFromSequentialFile(), etc. > This test, test the new change, but doesnt test for what we are protecting from. E.g whats the underlying issue being fixed I'm not sure what you mean. We're protecting page-size-bytes from being greater than Integer.MAX_VALUE(2147483647). So if we set page-size-bytes to 2147483648, the broker is expected to fail fast to throw exception , correct? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295928) Time Spent: 1h (was: 50m) > page-size-bytes should not be greater than Integer.MAX_VALUE > > > Key: ARTEMIS-2450 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2450 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Reporter: yangwei >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2450) page-size-bytes should not be greater than Integer.MAX_VALUE
[ https://issues.apache.org/jira/browse/ARTEMIS-2450?focusedWorklogId=295919&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295919 ] ASF GitHub Bot logged work on ARTEMIS-2450: --- Author: ASF GitHub Bot Created on: 16/Aug/19 01:16 Start Date: 16/Aug/19 01:16 Worklog Time Spent: 10m Work Description: wy96f commented on pull request #2791: ARTEMIS-2450 page-size-bytes should not be greater than Integer.MAX_VALUE URL: https://github.com/apache/activemq-artemis/pull/2791#discussion_r314554334 ## File path: artemis-server/src/main/java/org/apache/activemq/artemis/core/settings/impl/AddressSettings.java ## @@ -505,6 +505,9 @@ public long getPageSizeBytes() { } public AddressSettings setPageSizeBytes(final long pageSize) { + if (pageSize > Integer.MAX_VALUE) { + throw new IllegalArgumentException("pageSize must be < " + Integer.MAX_VALUE); Review comment: The AddressSettings maybe persisted in disk, and if we change long to int, we would incorrectly decode it. Does it make sense? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295919) Time Spent: 50m (was: 40m) > page-size-bytes should not be greater than Integer.MAX_VALUE > > > Key: ARTEMIS-2450 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2450 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Reporter: yangwei >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (AMQ-7252) SEV2 Vulnerabilities: Apache ActiveMQ Server libraries: commons-net-3.6.jar and velocity-1.7.jar
[ https://issues.apache.org/jira/browse/AMQ-7252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16908530#comment-16908530 ] Vipin commented on AMQ-7252: [~jbonofre], I checked the apache velocity project and it appears that 2.1 is available (https://velocity.apache.org/news.html#engine21), could you please see if this can be updated to counter the reported vulnerability? > SEV2 Vulnerabilities: Apache ActiveMQ Server libraries: commons-net-3.6.jar > and velocity-1.7.jar > > > Key: AMQ-7252 > URL: https://issues.apache.org/jira/browse/AMQ-7252 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.15.9 >Reporter: Vipin >Assignee: Jean-Baptiste Onofré >Priority: Major > Labels: security-issue, vulnerabilities > Fix For: 5.16.0, 5.15.11 > > > SEV2 Vulnerabilities: Apache ActiveMQ Server libraries: commons-net-3.6.jar > and velocity-1.7.jar > > commons-net-3.6.jar > * Apache Commons Net contains a flaw in the changeWorkingDirectory() > function in ftpClient.java that is triggered as user-supplied input is not > properly sanitized. This may allow a remote attacker to use a newline > character in a specially crafted string to execute arbitrary commands. > > velocity-1.7.jar > * Apache Commons FileUpload contains flaw that is due to > ParametersInterceptor allowing access to the 'class' parameter. This may > allow a remote attacker to manipulate the ClassLoader and execute arbitrary > Java code. > > * Apache Commons Collections contains a flaw in the InvokerTransformer > class. This issue is triggered when handling Java code, which may invoke > unsafe deserialize calls. This may allow a remote attacker to execute > arbitrary code. > > * Apache Velocity contains a flaw that allows traversing outside of a > restricted path. The issue is due to VelocityLayoutServlet not properly > sanitizing user input, specifically path traversal style attacks (e.g. '../') > supplied via the 'layout' parameter. With a specially crafted request, a > remote attacker can gain access to potentially sensitive information. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (ARTEMIS-2453) DeadLock between server.destroyQueue and server.removeAddressInfo
[ https://issues.apache.org/jira/browse/ARTEMIS-2453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16908371#comment-16908371 ] ASF subversion and git services commented on ARTEMIS-2453: -- Commit 144c21fb6f9489174fc8ee0e8a37459a657b2b7a in activemq-artemis's branch refs/heads/master from Clebert Suconic [ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=144c21f ] ARTEMIS-2453 Fixing deadLock between destroyQueue and removeAddressInfo > DeadLock between server.destroyQueue and server.removeAddressInfo > - > > Key: ARTEMIS-2453 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2453 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: clebert suconic >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > "Thread-0 > (ActiveMQ-remoting-threads-ActiveMQServerImpl::serverUUID=349ac51e-bf5e-11e9-9661-ecf4bbced624-2058174333)": > at > org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.getAddressInfo(PostOfficeImpl.java:652) > - waiting to lock <0x0005be7a5488> (a java.lang.Object) at > org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.removeBinding(PostOfficeImpl.java:749) > - locked <0x0005bb0702c8> (a > org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl) at > org.apache.activemq.artemis.core.server.impl.QueueImpl.deleteQueue(QueueImpl.java:1962) > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2142) > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2090) > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2081) > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2061) > at > org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.run(ServerSessionImpl.java:986) > at > org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.connectionFailed(ServerSessionImpl.java:1001) > at > org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.connectionFailed(ServerSessionImpl.java:1006) > at > org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.callFailureListeners(AbstractRemotingConnection.java:77) > at > org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:220) > at > org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.fail(AbstractRemotingConnection.java:220) > at > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.issueFailure(RemotingServiceImpl.java:572) > at > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.connectionDestroyed(RemotingServiceImpl.java:553) > at > org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptor$Listener.connectionDestroyed(NettyAcceptor.java:897) > at > org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.lambda$channelInactive$0(ActiveMQChannelHandler.java:83) > at > org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler$$Lambda$56/1250509089.run(Unknown > Source) at > org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42) > at > org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31) > at > org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66) > at > org.apache.activemq.artemis.utils.actors.ProcessorBase$$Lambda$2/323326911.run(Unknown > Source) at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at > org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) > "Thread-1 > (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@4a55a6e8)": > at > org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.removeBinding(PostOfficeImpl.java:724) > - waiting to lock <0x0005bb0702c8> (a > org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl) at > org.apache.activemq.artemis.core.server.impl.QueueImpl.deleteQueue(QueueImpl.java:1962) > at > org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.removeAddressInfo(PostOfficeImpl.java:631) > - locked <0x0005be7a5488> (a java.lang.Object) at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.removeAddressInfo(ActiveMQServerImpl.java:3231) > at > org.apache.activemq.artemis.core.management.impl.ActiveMQServerCo
[jira] [Work logged] (ARTEMIS-2453) DeadLock between server.destroyQueue and server.removeAddressInfo
[ https://issues.apache.org/jira/browse/ARTEMIS-2453?focusedWorklogId=295633&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295633 ] ASF GitHub Bot logged work on ARTEMIS-2453: --- Author: ASF GitHub Bot Created on: 15/Aug/19 18:06 Start Date: 15/Aug/19 18:06 Worklog Time Spent: 10m Work Description: asfgit commented on pull request #2799: ARTEMIS-2453 Fixing deadLock between destroyQueue and removeAddressInfo URL: https://github.com/apache/activemq-artemis/pull/2799 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295633) Time Spent: 1h (was: 50m) > DeadLock between server.destroyQueue and server.removeAddressInfo > - > > Key: ARTEMIS-2453 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2453 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: clebert suconic >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > "Thread-0 > (ActiveMQ-remoting-threads-ActiveMQServerImpl::serverUUID=349ac51e-bf5e-11e9-9661-ecf4bbced624-2058174333)": > at > org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.getAddressInfo(PostOfficeImpl.java:652) > - waiting to lock <0x0005be7a5488> (a java.lang.Object) at > org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.removeBinding(PostOfficeImpl.java:749) > - locked <0x0005bb0702c8> (a > org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl) at > org.apache.activemq.artemis.core.server.impl.QueueImpl.deleteQueue(QueueImpl.java:1962) > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2142) > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2090) > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2081) > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2061) > at > org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.run(ServerSessionImpl.java:986) > at > org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.connectionFailed(ServerSessionImpl.java:1001) > at > org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.connectionFailed(ServerSessionImpl.java:1006) > at > org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.callFailureListeners(AbstractRemotingConnection.java:77) > at > org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:220) > at > org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.fail(AbstractRemotingConnection.java:220) > at > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.issueFailure(RemotingServiceImpl.java:572) > at > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.connectionDestroyed(RemotingServiceImpl.java:553) > at > org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptor$Listener.connectionDestroyed(NettyAcceptor.java:897) > at > org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.lambda$channelInactive$0(ActiveMQChannelHandler.java:83) > at > org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler$$Lambda$56/1250509089.run(Unknown > Source) at > org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42) > at > org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31) > at > org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66) > at > org.apache.activemq.artemis.utils.actors.ProcessorBase$$Lambda$2/323326911.run(Unknown > Source) at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at > org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) > "Thread-1 > (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@4a55a6e8)": > at > org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.removeBinding(PostOfficeImpl.java:724) > - waiting to lock <0x0005bb0702c8> (a > org.apache.activemq.artemis.core.postoffi
[jira] [Updated] (AMQ-7276) Unable to establish mutual authentication through HTTPS transport
[ https://issues.apache.org/jira/browse/AMQ-7276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diptesh Chakraborty updated AMQ-7276: - Affects Version/s: 5.15.9 > Unable to establish mutual authentication through HTTPS transport > - > > Key: AMQ-7276 > URL: https://issues.apache.org/jira/browse/AMQ-7276 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.11.0, 5.15.9 >Reporter: Diptesh Chakraborty >Priority: Major > Labels: mutualSSL > > I am trying to establish mutual authentication over HTTPS transport but found > that only the one way authentication is established. > Below is my code snippet: > > +*Client Java Program:*+ > {code:java} > System.setProperty("javax.net.ssl.keyStore", > "D://project//test//POC//client.ks"); > System.setProperty("javax.net.ssl.keyStorePassword", "password"); > System.setProperty("javax.net.ssl.trustStore", > "D://project//test//POC//client.ts"); > System.setProperty("javax.net.ssl.trustStorePassword", "password"); > cf=new ActiveMQConnectionFactory("https://localhost:8443";); > con=cf.createConnection(); > Session s=con.createSession(false,Session.AUTO_ACKNOWLEDGE); > Destination d; > d=s.createQueue("TestQueue"); > MessageProducer mp; > mp=s.createProducer(d); > con.start(); > // prepare the message > mp.send(message){code} > +*Active MQ configuration*+ > > {code:java} > uri="https://localhost:8443?transport.needClientAuth=true"/> > > keyStorePassword="password" > trustStore="file:D:/project/test/POC/broker.ts" > trustStorePassword="password"/> > {code} > > While running the program, the message is being sent successfully but I am > not finding any difference in the logs if "*needClientAuth*" is set to > *false*. > If the transport connector is changed from https to ssl, I can view the > detailed ssl handshake logs which implies that "Mutual Authentication" has > been established -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (AMQ-7276) Unable to establish mutual authentication through HTTPS transport
[ https://issues.apache.org/jira/browse/AMQ-7276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16908252#comment-16908252 ] Diptesh Chakraborty commented on AMQ-7276: -- I have upgraded the version to 5.15.9 but no change in behavior > Unable to establish mutual authentication through HTTPS transport > - > > Key: AMQ-7276 > URL: https://issues.apache.org/jira/browse/AMQ-7276 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.11.0 >Reporter: Diptesh Chakraborty >Priority: Major > Labels: mutualSSL > > I am trying to establish mutual authentication over HTTPS transport but found > that only the one way authentication is established. > Below is my code snippet: > > +*Client Java Program:*+ > {code:java} > System.setProperty("javax.net.ssl.keyStore", > "D://project//test//POC//client.ks"); > System.setProperty("javax.net.ssl.keyStorePassword", "password"); > System.setProperty("javax.net.ssl.trustStore", > "D://project//test//POC//client.ts"); > System.setProperty("javax.net.ssl.trustStorePassword", "password"); > cf=new ActiveMQConnectionFactory("https://localhost:8443";); > con=cf.createConnection(); > Session s=con.createSession(false,Session.AUTO_ACKNOWLEDGE); > Destination d; > d=s.createQueue("TestQueue"); > MessageProducer mp; > mp=s.createProducer(d); > con.start(); > // prepare the message > mp.send(message){code} > +*Active MQ configuration*+ > > {code:java} > uri="https://localhost:8443?transport.needClientAuth=true"/> > > keyStorePassword="password" > trustStore="file:D:/project/test/POC/broker.ts" > trustStorePassword="password"/> > {code} > > While running the program, the message is being sent successfully but I am > not finding any difference in the logs if "*needClientAuth*" is set to > *false*. > If the transport connector is changed from https to ssl, I can view the > detailed ssl handshake logs which implies that "Mutual Authentication" has > been established -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2453) DeadLock between server.destroyQueue and server.removeAddressInfo
[ https://issues.apache.org/jira/browse/ARTEMIS-2453?focusedWorklogId=295505&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295505 ] ASF GitHub Bot logged work on ARTEMIS-2453: --- Author: ASF GitHub Bot Created on: 15/Aug/19 15:40 Start Date: 15/Aug/19 15:40 Worklog Time Spent: 10m Work Description: clebertsuconic commented on pull request #2799: ARTEMIS-2453 Fixing deadLock between destroyQueue and removeAddressInfo URL: https://github.com/apache/activemq-artemis/pull/2799#discussion_r314370749 ## File path: artemis-server/src/main/java/org/apache/activemq/artemis/core/postoffice/impl/PostOfficeImpl.java ## @@ -649,9 +647,7 @@ public AddressInfo removeAddressInfo(SimpleString address, boolean force) throws @Override public AddressInfo getAddressInfo(SimpleString addressName) { - synchronized (addressLock) { - return addressManager.getAddressInfo(addressName); - } + return addressManager.getAddressInfo(addressName); Review comment: @jbertram thanks.. that confirms what I thought. I'm running the whole testsuite to confirm it. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295505) Time Spent: 50m (was: 40m) > DeadLock between server.destroyQueue and server.removeAddressInfo > - > > Key: ARTEMIS-2453 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2453 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: clebert suconic >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > "Thread-0 > (ActiveMQ-remoting-threads-ActiveMQServerImpl::serverUUID=349ac51e-bf5e-11e9-9661-ecf4bbced624-2058174333)": > at > org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.getAddressInfo(PostOfficeImpl.java:652) > - waiting to lock <0x0005be7a5488> (a java.lang.Object) at > org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.removeBinding(PostOfficeImpl.java:749) > - locked <0x0005bb0702c8> (a > org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl) at > org.apache.activemq.artemis.core.server.impl.QueueImpl.deleteQueue(QueueImpl.java:1962) > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2142) > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2090) > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2081) > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2061) > at > org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.run(ServerSessionImpl.java:986) > at > org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.connectionFailed(ServerSessionImpl.java:1001) > at > org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.connectionFailed(ServerSessionImpl.java:1006) > at > org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.callFailureListeners(AbstractRemotingConnection.java:77) > at > org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:220) > at > org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.fail(AbstractRemotingConnection.java:220) > at > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.issueFailure(RemotingServiceImpl.java:572) > at > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.connectionDestroyed(RemotingServiceImpl.java:553) > at > org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptor$Listener.connectionDestroyed(NettyAcceptor.java:897) > at > org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.lambda$channelInactive$0(ActiveMQChannelHandler.java:83) > at > org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler$$Lambda$56/1250509089.run(Unknown > Source) at > org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42) > at > org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31) > at > org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66) > at > org.apache.activemq.artemis.utils.actors.Processor
[jira] [Commented] (AMQ-7276) Unable to establish mutual authentication through HTTPS transport
[ https://issues.apache.org/jira/browse/AMQ-7276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16908204#comment-16908204 ] Timothy Bish commented on AMQ-7276: --- 5.11.0 is not a supported release so first thing to do is upgrade your broker to the latest 5.15.9 and try from there. > Unable to establish mutual authentication through HTTPS transport > - > > Key: AMQ-7276 > URL: https://issues.apache.org/jira/browse/AMQ-7276 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.11.0 >Reporter: Diptesh Chakraborty >Priority: Major > Labels: mutualSSL > > I am trying to establish mutual authentication over HTTPS transport but found > that only the one way authentication is established. > Below is my code snippet: > > +*Client Java Program:*+ > {code:java} > System.setProperty("javax.net.ssl.keyStore", > "D://project//test//POC//client.ks"); > System.setProperty("javax.net.ssl.keyStorePassword", "password"); > System.setProperty("javax.net.ssl.trustStore", > "D://project//test//POC//client.ts"); > System.setProperty("javax.net.ssl.trustStorePassword", "password"); > cf=new ActiveMQConnectionFactory("https://localhost:8443";); > con=cf.createConnection(); > Session s=con.createSession(false,Session.AUTO_ACKNOWLEDGE); > Destination d; > d=s.createQueue("TestQueue"); > MessageProducer mp; > mp=s.createProducer(d); > con.start(); > // prepare the message > mp.send(message){code} > +*Active MQ configuration*+ > > {code:java} > uri="https://localhost:8443?transport.needClientAuth=true"/> > > keyStorePassword="password" > trustStore="file:D:/project/test/POC/broker.ts" > trustStorePassword="password"/> > {code} > > While running the program, the message is being sent successfully but I am > not finding any difference in the logs if "*needClientAuth*" is set to > *false*. > If the transport connector is changed from https to ssl, I can view the > detailed ssl handshake logs which implies that "Mutual Authentication" has > been established -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (AMQ-7276) Unable to establish mutual authentication through HTTPS transport
[ https://issues.apache.org/jira/browse/AMQ-7276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated AMQ-7276: -- Priority: Major (was: Critical) > Unable to establish mutual authentication through HTTPS transport > - > > Key: AMQ-7276 > URL: https://issues.apache.org/jira/browse/AMQ-7276 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.11.0 >Reporter: Diptesh Chakraborty >Priority: Major > Labels: mutualSSL > > I am trying to establish mutual authentication over HTTPS transport but found > that only the one way authentication is established. > Below is my code snippet: > > +*Client Java Program:*+ > {code:java} > System.setProperty("javax.net.ssl.keyStore", > "D://project//test//POC//client.ks"); > System.setProperty("javax.net.ssl.keyStorePassword", "password"); > System.setProperty("javax.net.ssl.trustStore", > "D://project//test//POC//client.ts"); > System.setProperty("javax.net.ssl.trustStorePassword", "password"); > cf=new ActiveMQConnectionFactory("https://localhost:8443";); > con=cf.createConnection(); > Session s=con.createSession(false,Session.AUTO_ACKNOWLEDGE); > Destination d; > d=s.createQueue("TestQueue"); > MessageProducer mp; > mp=s.createProducer(d); > con.start(); > // prepare the message > mp.send(message){code} > +*Active MQ configuration*+ > > {code:java} > uri="https://localhost:8443?transport.needClientAuth=true"/> > > keyStorePassword="password" > trustStore="file:D:/project/test/POC/broker.ts" > trustStorePassword="password"/> > {code} > > While running the program, the message is being sent successfully but I am > not finding any difference in the logs if "*needClientAuth*" is set to > *false*. > If the transport connector is changed from https to ssl, I can view the > detailed ssl handshake logs which implies that "Mutual Authentication" has > been established -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2453) DeadLock between server.destroyQueue and server.removeAddressInfo
[ https://issues.apache.org/jira/browse/ARTEMIS-2453?focusedWorklogId=295502&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295502 ] ASF GitHub Bot logged work on ARTEMIS-2453: --- Author: ASF GitHub Bot Created on: 15/Aug/19 15:33 Start Date: 15/Aug/19 15:33 Worklog Time Spent: 10m Work Description: jbertram commented on pull request #2799: ARTEMIS-2453 Fixing deadLock between destroyQueue and removeAddressInfo URL: https://github.com/apache/activemq-artemis/pull/2799#discussion_r314367295 ## File path: artemis-server/src/main/java/org/apache/activemq/artemis/core/postoffice/impl/PostOfficeImpl.java ## @@ -649,9 +647,7 @@ public AddressInfo removeAddressInfo(SimpleString address, boolean force) throws @Override public AddressInfo getAddressInfo(SimpleString addressName) { - synchronized (addressLock) { - return addressManager.getAddressInfo(addressName); - } + return addressManager.getAddressInfo(addressName); Review comment: I don't see a need for the `synchronized (addressLock)` given that the underlying data structure in the address manager is a `ConcurrentHashMap` and no other operations are being done (unlike in the other places which use `addressLock`). I think this fix looks good. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295502) Time Spent: 40m (was: 0.5h) > DeadLock between server.destroyQueue and server.removeAddressInfo > - > > Key: ARTEMIS-2453 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2453 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: clebert suconic >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > "Thread-0 > (ActiveMQ-remoting-threads-ActiveMQServerImpl::serverUUID=349ac51e-bf5e-11e9-9661-ecf4bbced624-2058174333)": > at > org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.getAddressInfo(PostOfficeImpl.java:652) > - waiting to lock <0x0005be7a5488> (a java.lang.Object) at > org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.removeBinding(PostOfficeImpl.java:749) > - locked <0x0005bb0702c8> (a > org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl) at > org.apache.activemq.artemis.core.server.impl.QueueImpl.deleteQueue(QueueImpl.java:1962) > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2142) > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2090) > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2081) > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2061) > at > org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.run(ServerSessionImpl.java:986) > at > org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.connectionFailed(ServerSessionImpl.java:1001) > at > org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.connectionFailed(ServerSessionImpl.java:1006) > at > org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.callFailureListeners(AbstractRemotingConnection.java:77) > at > org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:220) > at > org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.fail(AbstractRemotingConnection.java:220) > at > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.issueFailure(RemotingServiceImpl.java:572) > at > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.connectionDestroyed(RemotingServiceImpl.java:553) > at > org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptor$Listener.connectionDestroyed(NettyAcceptor.java:897) > at > org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.lambda$channelInactive$0(ActiveMQChannelHandler.java:83) > at > org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler$$Lambda$56/1250509089.run(Unknown > Source) at > org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42) > at > org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31) > a
[jira] [Work logged] (ARTEMIS-2451) Limit size of destination cache
[ https://issues.apache.org/jira/browse/ARTEMIS-2451?focusedWorklogId=295497&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295497 ] ASF GitHub Bot logged work on ARTEMIS-2451: --- Author: ASF GitHub Bot Created on: 15/Aug/19 15:30 Start Date: 15/Aug/19 15:30 Worklog Time Spent: 10m Work Description: jbertram commented on issue #2796: ARTEMIS-2451 remove need for knownDestination Cache URL: https://github.com/apache/activemq-artemis/pull/2796#issuecomment-521683921 It's *possible* that `tempQueues` could grow like `knownDestinations`. However, entries are only added to `tempQueues` for temporary destinations that the client actually creates and entries from `tempQueues` get removed when the corresponding temporary destination is deleted from the broker. An entry is added to `knownDestinations` for every unique destination to which a client sends a message and those entries *never* get removed unless they are temporary destinations which the client itself deletes. In my mind these facts make the pathological growth much less likely. Also, in JMS terms the lifetime of a temporary destination is actually the lifetime of the *connection* that created it, not the session. The temporary destinations need to be tracked somehow so that the client implementation can delete them implicitly when the connection is closed in the case that the application doesn't delete them explicitly. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295497) Time Spent: 5h 10m (was: 5h) > Limit size of destination cache > --- > > Key: ARTEMIS-2451 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2451 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 5h 10m > Remaining Estimate: 0h > > This is the client-side version of ARTEMIS-2449. Simply put, there is no > limit on the destination cache for a core JMS client. For a long-lived > connection sending to lots of different destinations (e.g. in a request-reply > use-case involving temporary queues) this can present a significant problem. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (AMQ-7276) Unable to establish mutual authentication through HTTPS transport
[ https://issues.apache.org/jira/browse/AMQ-7276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diptesh Chakraborty updated AMQ-7276: - Priority: Critical (was: Major) > Unable to establish mutual authentication through HTTPS transport > - > > Key: AMQ-7276 > URL: https://issues.apache.org/jira/browse/AMQ-7276 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.11.0 >Reporter: Diptesh Chakraborty >Priority: Critical > Labels: mutualSSL > > I am trying to establish mutual authentication over HTTPS transport but found > that only the one way authentication is established. > Below is my code snippet: > > +*Client Java Program:*+ > {code:java} > System.setProperty("javax.net.ssl.keyStore", > "D://project//test//POC//client.ks"); > System.setProperty("javax.net.ssl.keyStorePassword", "password"); > System.setProperty("javax.net.ssl.trustStore", > "D://project//test//POC//client.ts"); > System.setProperty("javax.net.ssl.trustStorePassword", "password"); > cf=new ActiveMQConnectionFactory("https://localhost:8443";); > con=cf.createConnection(); > Session s=con.createSession(false,Session.AUTO_ACKNOWLEDGE); > Destination d; > d=s.createQueue("TestQueue"); > MessageProducer mp; > mp=s.createProducer(d); > con.start(); > // prepare the message > mp.send(message){code} > +*Active MQ configuration*+ > > {code:java} > uri="https://localhost:8443?transport.needClientAuth=true"/> > > keyStorePassword="password" > trustStore="file:D:/project/test/POC/broker.ts" > trustStorePassword="password"/> > {code} > > While running the program, the message is being sent successfully but I am > not finding any difference in the logs if "*needClientAuth*" is set to > *false*. > If the transport connector is changed from https to ssl, I can view the > detailed ssl handshake logs which implies that "Mutual Authentication" has > been established -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2453) DeadLock between server.destroyQueue and server.removeAddressInfo
[ https://issues.apache.org/jira/browse/ARTEMIS-2453?focusedWorklogId=295490&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295490 ] ASF GitHub Bot logged work on ARTEMIS-2453: --- Author: ASF GitHub Bot Created on: 15/Aug/19 15:25 Start Date: 15/Aug/19 15:25 Worklog Time Spent: 10m Work Description: clebertsuconic commented on pull request #2799: ARTEMIS-2453 Fixing deadLock between destroyQueue and removeAddressInfo URL: https://github.com/apache/activemq-artemis/pull/2799 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295490) Time Spent: 10m Remaining Estimate: 0h > DeadLock between server.destroyQueue and server.removeAddressInfo > - > > Key: ARTEMIS-2453 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2453 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: clebert suconic >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > "Thread-0 > (ActiveMQ-remoting-threads-ActiveMQServerImpl::serverUUID=349ac51e-bf5e-11e9-9661-ecf4bbced624-2058174333)": > at > org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.getAddressInfo(PostOfficeImpl.java:652) > - waiting to lock <0x0005be7a5488> (a java.lang.Object) at > org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.removeBinding(PostOfficeImpl.java:749) > - locked <0x0005bb0702c8> (a > org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl) at > org.apache.activemq.artemis.core.server.impl.QueueImpl.deleteQueue(QueueImpl.java:1962) > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2142) > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2090) > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2081) > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2061) > at > org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.run(ServerSessionImpl.java:986) > at > org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.connectionFailed(ServerSessionImpl.java:1001) > at > org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.connectionFailed(ServerSessionImpl.java:1006) > at > org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.callFailureListeners(AbstractRemotingConnection.java:77) > at > org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:220) > at > org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.fail(AbstractRemotingConnection.java:220) > at > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.issueFailure(RemotingServiceImpl.java:572) > at > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.connectionDestroyed(RemotingServiceImpl.java:553) > at > org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptor$Listener.connectionDestroyed(NettyAcceptor.java:897) > at > org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.lambda$channelInactive$0(ActiveMQChannelHandler.java:83) > at > org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler$$Lambda$56/1250509089.run(Unknown > Source) at > org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42) > at > org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31) > at > org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66) > at > org.apache.activemq.artemis.utils.actors.ProcessorBase$$Lambda$2/323326911.run(Unknown > Source) at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at > org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) > "Thread-1 > (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@4a55a6e8)": > at > org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.removeBinding(PostOfficeImpl.java:724) > - waiting to lock <0x0005bb0702c8> (a >
[jira] [Work logged] (ARTEMIS-2453) DeadLock between server.destroyQueue and server.removeAddressInfo
[ https://issues.apache.org/jira/browse/ARTEMIS-2453?focusedWorklogId=295491&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295491 ] ASF GitHub Bot logged work on ARTEMIS-2453: --- Author: ASF GitHub Bot Created on: 15/Aug/19 15:25 Start Date: 15/Aug/19 15:25 Worklog Time Spent: 10m Work Description: clebertsuconic commented on pull request #2799: ARTEMIS-2453 Fixing deadLock between destroyQueue and removeAddressInfo URL: https://github.com/apache/activemq-artemis/pull/2799#discussion_r314363162 ## File path: artemis-server/src/main/java/org/apache/activemq/artemis/core/postoffice/impl/PostOfficeImpl.java ## @@ -649,9 +647,7 @@ public AddressInfo removeAddressInfo(SimpleString address, boolean force) throws @Override public AddressInfo getAddressInfo(SimpleString addressName) { - synchronized (addressLock) { - return addressManager.getAddressInfo(addressName); - } + return addressManager.getAddressInfo(addressName); Review comment: There's no need to lock here? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295491) Time Spent: 20m (was: 10m) > DeadLock between server.destroyQueue and server.removeAddressInfo > - > > Key: ARTEMIS-2453 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2453 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: clebert suconic >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > "Thread-0 > (ActiveMQ-remoting-threads-ActiveMQServerImpl::serverUUID=349ac51e-bf5e-11e9-9661-ecf4bbced624-2058174333)": > at > org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.getAddressInfo(PostOfficeImpl.java:652) > - waiting to lock <0x0005be7a5488> (a java.lang.Object) at > org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.removeBinding(PostOfficeImpl.java:749) > - locked <0x0005bb0702c8> (a > org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl) at > org.apache.activemq.artemis.core.server.impl.QueueImpl.deleteQueue(QueueImpl.java:1962) > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2142) > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2090) > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2081) > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2061) > at > org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.run(ServerSessionImpl.java:986) > at > org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.connectionFailed(ServerSessionImpl.java:1001) > at > org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.connectionFailed(ServerSessionImpl.java:1006) > at > org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.callFailureListeners(AbstractRemotingConnection.java:77) > at > org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:220) > at > org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.fail(AbstractRemotingConnection.java:220) > at > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.issueFailure(RemotingServiceImpl.java:572) > at > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.connectionDestroyed(RemotingServiceImpl.java:553) > at > org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptor$Listener.connectionDestroyed(NettyAcceptor.java:897) > at > org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.lambda$channelInactive$0(ActiveMQChannelHandler.java:83) > at > org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler$$Lambda$56/1250509089.run(Unknown > Source) at > org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42) > at > org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31) > at > org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66) > at > org.apache.activemq.artemis.utils.actors.ProcessorBase$$Lambda$2/323326911.run(Unknown > Source) at > java.util.concurren
[jira] [Work logged] (ARTEMIS-2453) DeadLock between server.destroyQueue and server.removeAddressInfo
[ https://issues.apache.org/jira/browse/ARTEMIS-2453?focusedWorklogId=295492&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295492 ] ASF GitHub Bot logged work on ARTEMIS-2453: --- Author: ASF GitHub Bot Created on: 15/Aug/19 15:25 Start Date: 15/Aug/19 15:25 Worklog Time Spent: 10m Work Description: clebertsuconic commented on pull request #2799: ARTEMIS-2453 Fixing deadLock between destroyQueue and removeAddressInfo URL: https://github.com/apache/activemq-artemis/pull/2799#discussion_r314363282 ## File path: artemis-server/src/main/java/org/apache/activemq/artemis/core/postoffice/impl/PostOfficeImpl.java ## @@ -649,9 +647,7 @@ public AddressInfo removeAddressInfo(SimpleString address, boolean force) throws @Override public AddressInfo getAddressInfo(SimpleString addressName) { - synchronized (addressLock) { - return addressManager.getAddressInfo(addressName); - } + return addressManager.getAddressInfo(addressName); Review comment: @jbertram What do you think about this? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295492) Time Spent: 0.5h (was: 20m) > DeadLock between server.destroyQueue and server.removeAddressInfo > - > > Key: ARTEMIS-2453 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2453 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: clebert suconic >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > "Thread-0 > (ActiveMQ-remoting-threads-ActiveMQServerImpl::serverUUID=349ac51e-bf5e-11e9-9661-ecf4bbced624-2058174333)": > at > org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.getAddressInfo(PostOfficeImpl.java:652) > - waiting to lock <0x0005be7a5488> (a java.lang.Object) at > org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.removeBinding(PostOfficeImpl.java:749) > - locked <0x0005bb0702c8> (a > org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl) at > org.apache.activemq.artemis.core.server.impl.QueueImpl.deleteQueue(QueueImpl.java:1962) > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2142) > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2090) > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2081) > at > org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2061) > at > org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.run(ServerSessionImpl.java:986) > at > org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.connectionFailed(ServerSessionImpl.java:1001) > at > org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.connectionFailed(ServerSessionImpl.java:1006) > at > org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.callFailureListeners(AbstractRemotingConnection.java:77) > at > org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:220) > at > org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.fail(AbstractRemotingConnection.java:220) > at > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.issueFailure(RemotingServiceImpl.java:572) > at > org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.connectionDestroyed(RemotingServiceImpl.java:553) > at > org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptor$Listener.connectionDestroyed(NettyAcceptor.java:897) > at > org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.lambda$channelInactive$0(ActiveMQChannelHandler.java:83) > at > org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler$$Lambda$56/1250509089.run(Unknown > Source) at > org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42) > at > org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31) > at > org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66) > at > org.apache.activemq.artemis.utils.actors.ProcessorBase$$Lambda$2/323326911.run(Unknown > Source) at > java.ut
[jira] [Created] (ARTEMIS-2453) DeadLock between server.destroyQueue and server.removeAddressInfo
clebert suconic created ARTEMIS-2453: Summary: DeadLock between server.destroyQueue and server.removeAddressInfo Key: ARTEMIS-2453 URL: https://issues.apache.org/jira/browse/ARTEMIS-2453 Project: ActiveMQ Artemis Issue Type: Bug Reporter: clebert suconic "Thread-0 (ActiveMQ-remoting-threads-ActiveMQServerImpl::serverUUID=349ac51e-bf5e-11e9-9661-ecf4bbced624-2058174333)": at org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.getAddressInfo(PostOfficeImpl.java:652) - waiting to lock <0x0005be7a5488> (a java.lang.Object) at org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.removeBinding(PostOfficeImpl.java:749) - locked <0x0005bb0702c8> (a org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl) at org.apache.activemq.artemis.core.server.impl.QueueImpl.deleteQueue(QueueImpl.java:1962) at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2142) at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2090) at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2081) at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.destroyQueue(ActiveMQServerImpl.java:2061) at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.run(ServerSessionImpl.java:986) at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.connectionFailed(ServerSessionImpl.java:1001) at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl$TempQueueCleanerUpper.connectionFailed(ServerSessionImpl.java:1006) at org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.callFailureListeners(AbstractRemotingConnection.java:77) at org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:220) at org.apache.activemq.artemis.spi.core.protocol.AbstractRemotingConnection.fail(AbstractRemotingConnection.java:220) at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.issueFailure(RemotingServiceImpl.java:572) at org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.connectionDestroyed(RemotingServiceImpl.java:553) at org.apache.activemq.artemis.core.remoting.impl.netty.NettyAcceptor$Listener.connectionDestroyed(NettyAcceptor.java:897) at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.lambda$channelInactive$0(ActiveMQChannelHandler.java:83) at org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler$$Lambda$56/1250509089.run(Unknown Source) at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42) at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31) at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66) at org.apache.activemq.artemis.utils.actors.ProcessorBase$$Lambda$2/323326911.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) "Thread-1 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$6@4a55a6e8)": at org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.removeBinding(PostOfficeImpl.java:724) - waiting to lock <0x0005bb0702c8> (a org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl) at org.apache.activemq.artemis.core.server.impl.QueueImpl.deleteQueue(QueueImpl.java:1962) at org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.removeAddressInfo(PostOfficeImpl.java:631) - locked <0x0005be7a5488> (a java.lang.Object) at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.removeAddressInfo(ActiveMQServerImpl.java:3231) at org.apache.activemq.artemis.core.management.impl.ActiveMQServerControlImpl.deleteAddress(ActiveMQServerControlImpl.java:866) at sun.reflect.GeneratedMethodAccessor94.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.apache.activemq.artemis.core.server.management.impl.ManagementServiceImpl.invokeOperation(ManagementServiceImpl.java:787) at org.apache.activemq.artemis.core.server.management.impl.ManagementServiceImpl.handleMessage(ManagementServiceImpl.java:415) at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.handleManagementMessage(ServerSessionImpl.java:1913) at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.send(ServerSessionImpl.java:1682)
[jira] [Updated] (AMQ-7276) Unable to establish mutual authentication through HTTPS transport
[ https://issues.apache.org/jira/browse/AMQ-7276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diptesh Chakraborty updated AMQ-7276: - Description: I am trying to establish mutual authentication over HTTPS transport but found that only the one way authentication is established. Below is my code snippet: +*Client Java Program:*+ {code:java} System.setProperty("javax.net.ssl.keyStore", "D://project//test//POC//client.ks"); System.setProperty("javax.net.ssl.keyStorePassword", "password"); System.setProperty("javax.net.ssl.trustStore", "D://project//test//POC//client.ts"); System.setProperty("javax.net.ssl.trustStorePassword", "password"); cf=new ActiveMQConnectionFactory("https://localhost:8443";); con=cf.createConnection(); Session s=con.createSession(false,Session.AUTO_ACKNOWLEDGE); Destination d; d=s.createQueue("TestQueue"); MessageProducer mp; mp=s.createProducer(d); con.start(); // prepare the message mp.send(message){code} +*Active MQ configuration*+ {code:java} https://localhost:8443?transport.needClientAuth=true"/> {code} While running the program, the message is being sent successfully but I am not finding any difference in the logs if "*needClientAuth*" is set to *false*. If the transport connector is changed from https to ssl, I can view the detailed ssl handshake logs which implies that "Mutual Authentication" has been established was: I am trying to establish mutual authentication over HTTPS transport but found that only the one way authentication is established. Below is my code snippet: +*Client Java Program:*+ {code:java} System.setProperty("javax.net.ssl.keyStore", "D://project//test//POC//client.ks"); System.setProperty("javax.net.ssl.keyStorePassword", "password"); System.setProperty("javax.net.ssl.trustStore", "D://project//test//POC//client.ts"); System.setProperty("javax.net.ssl.trustStorePassword", "password"); cf=new ActiveMQConnectionFactory("https://localhost:8443";); con=cf.createConnection(); Session s=con.createSession(false,Session.AUTO_ACKNOWLEDGE); Destination d; d=s.createQueue("TestQueue"); MessageProducer mp; mp=s.createProducer(d); con.start(); // prepare the message mp.send(message){code} +*Active MQ configuration*+ {code:java} // https://localhost:8443?transport.needClientAuth=true"/> {code} While running the program, the message is being sent successfully but I am not finding any difference in the logs if "*needClientAuth*" is set to *false*. If the transport connector is changed from https to ssl, I can view the detailed ssl handshake logs which implies that "Mutual Authentication" has been established > Unable to establish mutual authentication through HTTPS transport > - > > Key: AMQ-7276 > URL: https://issues.apache.org/jira/browse/AMQ-7276 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.11.0 >Reporter: Diptesh Chakraborty >Priority: Major > Labels: mutualSSL > > I am trying to establish mutual authentication over HTTPS transport but found > that only the one way authentication is established. > Below is my code snippet: > > +*Client Java Program:*+ > {code:java} > System.setProperty("javax.net.ssl.keyStore", > "D://project//test//POC//client.ks"); > System.setProperty("javax.net.ssl.keyStorePassword", "password"); > System.setProperty("javax.net.ssl.trustStore", > "D://project//test//POC//client.ts"); > System.setProperty("javax.net.ssl.trustStorePassword", "password"); > cf=new ActiveMQConnectionFactory("https://localhost:8443";); > con=cf.createConnection(); > Session s=con.createSession(false,Session.AUTO_ACKNOWLEDGE); > Destination d; > d=s.createQueue("TestQueue"); > MessageProducer mp; > mp=s.createProducer(d); > con.start(); > // prepare the message > mp.send(message){code} > +*Active MQ configuration*+ > > {code:java} > uri="https://localhost:8443?transport.needClientAuth=true"/> > > keyStorePassword="password" > trustStore="file:D:/project/test/POC/broker.ts" > trustStorePassword="password"/> > {code} > > While running the program, the message is being sent successfully but I am > not finding any difference in the logs if "*needClientAuth*" is set to > *false*. > If the transport connector is changed from https to ssl, I can view the > detailed ssl handshake logs which implies that "Mutual Authentication" has > been established -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (AMQ-7276) Unable to establish mutual authentication through HTTPS transport
Diptesh Chakraborty created AMQ-7276: Summary: Unable to establish mutual authentication through HTTPS transport Key: AMQ-7276 URL: https://issues.apache.org/jira/browse/AMQ-7276 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.11.0 Reporter: Diptesh Chakraborty I am trying to establish mutual authentication over HTTPS transport but found that only the one way authentication is established. Below is my code snippet: +*Client Java Program:*+ {code:java} System.setProperty("javax.net.ssl.keyStore", "D://project//test//POC//client.ks"); System.setProperty("javax.net.ssl.keyStorePassword", "password"); System.setProperty("javax.net.ssl.trustStore", "D://project//test//POC//client.ts"); System.setProperty("javax.net.ssl.trustStorePassword", "password"); cf=new ActiveMQConnectionFactory("https://localhost:8443";); con=cf.createConnection(); Session s=con.createSession(false,Session.AUTO_ACKNOWLEDGE); Destination d; d=s.createQueue("TestQueue"); MessageProducer mp; mp=s.createProducer(d); con.start(); // prepare the message mp.send(message){code} +*Active MQ configuration*+ {code:java} // https://localhost:8443?transport.needClientAuth=true"/> {code} While running the program, the message is being sent successfully but I am not finding any difference in the logs if "*needClientAuth*" is set to *false*. If the transport connector is changed from https to ssl, I can view the detailed ssl handshake logs which implies that "Mutual Authentication" has been established -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (AMQ-7275) Update Commons BeanUtils
[ https://issues.apache.org/jira/browse/AMQ-7275?focusedWorklogId=295453&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295453 ] ASF GitHub Bot logged work on AMQ-7275: --- Author: ASF GitHub Bot Created on: 15/Aug/19 14:17 Start Date: 15/Aug/19 14:17 Worklog Time Spent: 10m Work Description: coheigea commented on pull request #389: AMQ-7275 - Update Commons BeanUtils URL: https://github.com/apache/activemq/pull/389 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295453) Time Spent: 10m Remaining Estimate: 0h > Update Commons BeanUtils > > > Key: AMQ-7275 > URL: https://issues.apache.org/jira/browse/AMQ-7275 > Project: ActiveMQ > Issue Type: Improvement >Reporter: Colm O hEigeartaigh >Priority: Major > Fix For: 5.15.10 > > Time Spent: 10m > Remaining Estimate: 0h > > We should update Commons BeanUtils due to CVE-2019-10086 -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (AMQ-7275) Update Commons BeanUtils
Colm O hEigeartaigh created AMQ-7275: Summary: Update Commons BeanUtils Key: AMQ-7275 URL: https://issues.apache.org/jira/browse/AMQ-7275 Project: ActiveMQ Issue Type: Improvement Reporter: Colm O hEigeartaigh Fix For: 5.15.10 We should update Commons BeanUtils due to CVE-2019-10086 -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (AMQNET-601) Add test toolkit for frame based assertions
Krzysztof Porebski created AMQNET-601: - Summary: Add test toolkit for frame based assertions Key: AMQNET-601 URL: https://issues.apache.org/jira/browse/AMQNET-601 Project: ActiveMQ .Net Issue Type: Improvement Components: AMQP, NMS Affects Versions: 1.8.0 Reporter: Krzysztof Porebski Fix For: 1.8.0 During the work on transactions support, I realized that the current approach to integration testing is not comprehensive enough, and we will need something more sophisticated to cover all required scenarios with confidence that all is working as it is expected to. The general idea is to build frame based assertion toolkit, the same way as qpid jms does. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2451) Limit size of destination cache
[ https://issues.apache.org/jira/browse/ARTEMIS-2451?focusedWorklogId=295313&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295313 ] ASF GitHub Bot logged work on ARTEMIS-2451: --- Author: ASF GitHub Bot Created on: 15/Aug/19 08:41 Start Date: 15/Aug/19 08:41 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2796: ARTEMIS-2451 remove need for knownDestination Cache URL: https://github.com/apache/activemq-artemis/pull/2796#issuecomment-521563091 @jbertram re: > BTW, the issue I saw wasn't a leak, per se. It was simply unwanted accumulation based on the way it was designed. Won't we get similar issue on the tempoary queue set thats used to track temp queues in connection? I guess that could probably move into the session object, so theyre cleaned up as a session is closed, which is anyhow the lifetime of a temporary queue anyhow. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295313) Time Spent: 5h (was: 4h 50m) > Limit size of destination cache > --- > > Key: ARTEMIS-2451 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2451 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 5h > Remaining Estimate: 0h > > This is the client-side version of ARTEMIS-2449. Simply put, there is no > limit on the destination cache for a core JMS client. For a long-lived > connection sending to lots of different destinations (e.g. in a request-reply > use-case involving temporary queues) this can present a significant problem. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2451) Limit size of destination cache
[ https://issues.apache.org/jira/browse/ARTEMIS-2451?focusedWorklogId=295312&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295312 ] ASF GitHub Bot logged work on ARTEMIS-2451: --- Author: ASF GitHub Bot Created on: 15/Aug/19 08:40 Start Date: 15/Aug/19 08:40 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2796: ARTEMIS-2451 remove need for knownDestination Cache URL: https://github.com/apache/activemq-artemis/pull/2796#issuecomment-521563091 @jbertram re: > BTW, the issue I saw wasn't a leak, per se. It was simply unwanted accumulation based on the way it was designed. Won't we get similar issue on the tempoary queue set thats used to track temp queues? I guess that could probably move into the session object, so theyre cleaned up as a session is closed, which is anyhow the lifetime of a temporary queue anyhow. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295312) Time Spent: 4h 50m (was: 4h 40m) > Limit size of destination cache > --- > > Key: ARTEMIS-2451 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2451 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 4h 50m > Remaining Estimate: 0h > > This is the client-side version of ARTEMIS-2449. Simply put, there is no > limit on the destination cache for a core JMS client. For a long-lived > connection sending to lots of different destinations (e.g. in a request-reply > use-case involving temporary queues) this can present a significant problem. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2451) Limit size of destination cache
[ https://issues.apache.org/jira/browse/ARTEMIS-2451?focusedWorklogId=295308&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295308 ] ASF GitHub Bot logged work on ARTEMIS-2451: --- Author: ASF GitHub Bot Created on: 15/Aug/19 08:39 Start Date: 15/Aug/19 08:39 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2796: ARTEMIS-2451 remove need for knownDestination Cache URL: https://github.com/apache/activemq-artemis/pull/2796#issuecomment-521563091 @jbertram re: > BTW, the issue I saw wasn't a leak, per se. It was simply unwanted accumulation based on the way it was designed. Won't we get similar issue on the tempoary queue set thats used to track temp queues? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295308) Time Spent: 4.5h (was: 4h 20m) > Limit size of destination cache > --- > > Key: ARTEMIS-2451 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2451 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 4.5h > Remaining Estimate: 0h > > This is the client-side version of ARTEMIS-2449. Simply put, there is no > limit on the destination cache for a core JMS client. For a long-lived > connection sending to lots of different destinations (e.g. in a request-reply > use-case involving temporary queues) this can present a significant problem. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2451) Limit size of destination cache
[ https://issues.apache.org/jira/browse/ARTEMIS-2451?focusedWorklogId=295310&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295310 ] ASF GitHub Bot logged work on ARTEMIS-2451: --- Author: ASF GitHub Bot Created on: 15/Aug/19 08:39 Start Date: 15/Aug/19 08:39 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2796: ARTEMIS-2451 remove need for knownDestination Cache URL: https://github.com/apache/activemq-artemis/pull/2796#issuecomment-521563091 @jbertram re: > BTW, the issue I saw wasn't a leak, per se. It was simply unwanted accumulation based on the way it was designed. Won't we get similar issue on the tempoary queue set thats used to track temp queues? I guess that could probably move into the session object, so theyre cleaned up as a session is closed. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295310) Time Spent: 4h 40m (was: 4.5h) > Limit size of destination cache > --- > > Key: ARTEMIS-2451 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2451 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 4h 40m > Remaining Estimate: 0h > > This is the client-side version of ARTEMIS-2449. Simply put, there is no > limit on the destination cache for a core JMS client. For a long-lived > connection sending to lots of different destinations (e.g. in a request-reply > use-case involving temporary queues) this can present a significant problem. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2452) group-name ignored in shared store colocated setup
[ https://issues.apache.org/jira/browse/ARTEMIS-2452?focusedWorklogId=295306&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295306 ] ASF GitHub Bot logged work on ARTEMIS-2452: --- Author: ASF GitHub Bot Created on: 15/Aug/19 08:39 Start Date: 15/Aug/19 08:39 Worklog Time Spent: 10m Work Description: franz1981 commented on issue #2793: ARTEMIS-2452 group-name ignored in shared store colocated setup URL: https://github.com/apache/activemq-artemis/pull/2793#issuecomment-521563027 Yes, sure and will provide proper yes and coverage too as it deserves :) Thanks for the suggestions Michael!! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295306) Time Spent: 3.5h (was: 3h 20m) > group-name ignored in shared store colocated setup > -- > > Key: ARTEMIS-2452 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2452 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.9.0 >Reporter: Francesco Nigro >Priority: Major > Time Spent: 3.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2452) group-name ignored in shared store colocated setup
[ https://issues.apache.org/jira/browse/ARTEMIS-2452?focusedWorklogId=295309&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295309 ] ASF GitHub Bot logged work on ARTEMIS-2452: --- Author: ASF GitHub Bot Created on: 15/Aug/19 08:39 Start Date: 15/Aug/19 08:39 Worklog Time Spent: 10m Work Description: franz1981 commented on issue #2793: ARTEMIS-2452 group-name ignored in shared store colocated setup URL: https://github.com/apache/activemq-artemis/pull/2793#issuecomment-521563027 Yes, sure and will provide proper test coverage too as it deserves :) Thanks for the suggestions Michael!! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295309) Time Spent: 3h 40m (was: 3.5h) > group-name ignored in shared store colocated setup > -- > > Key: ARTEMIS-2452 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2452 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.9.0 >Reporter: Francesco Nigro >Priority: Major > Time Spent: 3h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2451) Limit size of destination cache
[ https://issues.apache.org/jira/browse/ARTEMIS-2451?focusedWorklogId=295303&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295303 ] ASF GitHub Bot logged work on ARTEMIS-2451: --- Author: ASF GitHub Bot Created on: 15/Aug/19 08:37 Start Date: 15/Aug/19 08:37 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2796: ARTEMIS-2451 remove need for knownDestination Cache URL: https://github.com/apache/activemq-artemis/pull/2796#issuecomment-521562542 @jbertram this was a quick scrap togeather of what i was trying to describe in review comment on your pr. Im happy to complete it fully for you, but it wont be till next week. Im more than happy if you wish to just take it and complete it (e.g. dont worry about keeping my authorship) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295303) Time Spent: 4h 10m (was: 4h) > Limit size of destination cache > --- > > Key: ARTEMIS-2451 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2451 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 4h 10m > Remaining Estimate: 0h > > This is the client-side version of ARTEMIS-2449. Simply put, there is no > limit on the destination cache for a core JMS client. For a long-lived > connection sending to lots of different destinations (e.g. in a request-reply > use-case involving temporary queues) this can present a significant problem. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2451) Limit size of destination cache
[ https://issues.apache.org/jira/browse/ARTEMIS-2451?focusedWorklogId=295305&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295305 ] ASF GitHub Bot logged work on ARTEMIS-2451: --- Author: ASF GitHub Bot Created on: 15/Aug/19 08:37 Start Date: 15/Aug/19 08:37 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2796: ARTEMIS-2451 remove need for knownDestination Cache URL: https://github.com/apache/activemq-artemis/pull/2796#issuecomment-521562542 @jbertram this was a quick scrap togeather of what i was trying to describe in review comment on your pr. Im happy to complete it fully for you, but it wont be till next week. Im more than happy if you need this done faster and wish to just take it and complete it (e.g. dont worry about keeping my authorship) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295305) Time Spent: 4h 20m (was: 4h 10m) > Limit size of destination cache > --- > > Key: ARTEMIS-2451 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2451 > Project: ActiveMQ Artemis > Issue Type: Improvement >Reporter: Justin Bertram >Assignee: Justin Bertram >Priority: Major > Time Spent: 4h 20m > Remaining Estimate: 0h > > This is the client-side version of ARTEMIS-2449. Simply put, there is no > limit on the destination cache for a core JMS client. For a long-lived > connection sending to lots of different destinations (e.g. in a request-reply > use-case involving temporary queues) this can present a significant problem. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2452) group-name ignored in shared store colocated setup
[ https://issues.apache.org/jira/browse/ARTEMIS-2452?focusedWorklogId=295300&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295300 ] ASF GitHub Bot logged work on ARTEMIS-2452: --- Author: ASF GitHub Bot Created on: 15/Aug/19 08:30 Start Date: 15/Aug/19 08:30 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2793: ARTEMIS-2452 group-name ignored in shared store colocated setup URL: https://github.com/apache/activemq-artemis/pull/2793#issuecomment-521560596 @franz1981 i assume you're going to have a think on this and re-work bits? e.g. no further comments needed for now right? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295300) Time Spent: 3h 20m (was: 3h 10m) > group-name ignored in shared store colocated setup > -- > > Key: ARTEMIS-2452 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2452 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.9.0 >Reporter: Francesco Nigro >Priority: Major > Time Spent: 3h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2452) group-name ignored in shared store colocated setup
[ https://issues.apache.org/jira/browse/ARTEMIS-2452?focusedWorklogId=295297&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295297 ] ASF GitHub Bot logged work on ARTEMIS-2452: --- Author: ASF GitHub Bot Created on: 15/Aug/19 08:24 Start Date: 15/Aug/19 08:24 Worklog Time Spent: 10m Work Description: franz1981 commented on issue #2793: ARTEMIS-2452 group-name ignored in shared store colocated setup URL: https://github.com/apache/activemq-artemis/pull/2793#issuecomment-521559226 I understand your comment now, my comment was related to the code itself,not the feature as a whole: I see that there exists cases where it can work.. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295297) Time Spent: 3h 10m (was: 3h) > group-name ignored in shared store colocated setup > -- > > Key: ARTEMIS-2452 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2452 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.9.0 >Reporter: Francesco Nigro >Priority: Major > Time Spent: 3h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2452) group-name ignored in shared store colocated setup
[ https://issues.apache.org/jira/browse/ARTEMIS-2452?focusedWorklogId=295293&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295293 ] ASF GitHub Bot logged work on ARTEMIS-2452: --- Author: ASF GitHub Bot Created on: 15/Aug/19 08:19 Start Date: 15/Aug/19 08:19 Worklog Time Spent: 10m Work Description: franz1981 commented on issue #2793: ARTEMIS-2452 group-name ignored in shared store colocated setup URL: https://github.com/apache/activemq-artemis/pull/2793#issuecomment-521557724 The feature of shared store colocated is not totally broken, but the shared store colocation using group names, yes. But is normal, if the were not using at all group names in their logic I believe that's ok.. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295293) Time Spent: 3h (was: 2h 50m) > group-name ignored in shared store colocated setup > -- > > Key: ARTEMIS-2452 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2452 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.9.0 >Reporter: Francesco Nigro >Priority: Major > Time Spent: 3h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2452) group-name ignored in shared store colocated setup
[ https://issues.apache.org/jira/browse/ARTEMIS-2452?focusedWorklogId=295291&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295291 ] ASF GitHub Bot logged work on ARTEMIS-2452: --- Author: ASF GitHub Bot Created on: 15/Aug/19 08:17 Start Date: 15/Aug/19 08:17 Worklog Time Spent: 10m Work Description: franz1981 commented on pull request #2793: ARTEMIS-2452 group-name ignored in shared store colocated setup URL: https://github.com/apache/activemq-artemis/pull/2793#discussion_r314213953 ## File path: artemis-server/src/main/java/org/apache/activemq/artemis/core/server/cluster/ha/ColocatedHAManager.java ## @@ -163,6 +174,23 @@ private synchronized boolean activateSharedStoreBackup(String journalDirectory, return true; } + private TopologyMember validateBackupGroupName(SimpleString nodeID) { + // Older versions of artemis don't send the nodeID in BackupRequestMessage: + // in this case we cannot trust the request, making the requesting server Review comment: It was working fine because you haven't had any other member of topology with a group name and been lucky, I believe :P This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295291) Time Spent: 2h 50m (was: 2h 40m) > group-name ignored in shared store colocated setup > -- > > Key: ARTEMIS-2452 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2452 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.9.0 >Reporter: Francesco Nigro >Priority: Major > Time Spent: 2h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2452) group-name ignored in shared store colocated setup
[ https://issues.apache.org/jira/browse/ARTEMIS-2452?focusedWorklogId=295290&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295290 ] ASF GitHub Bot logged work on ARTEMIS-2452: --- Author: ASF GitHub Bot Created on: 15/Aug/19 08:17 Start Date: 15/Aug/19 08:17 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2793: ARTEMIS-2452 group-name ignored in shared store colocated setup URL: https://github.com/apache/activemq-artemis/pull/2793#issuecomment-521556891 Well it can't be totally broken, theres users out there using it (mostly because they are forming single groups or ensuring clusters are rign fenced, therefor group name isnt really mandatory there, yes theres a bug if you need multiple, and thats not ideal, but its not totally broken as you say, This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295290) Time Spent: 2h 40m (was: 2.5h) > group-name ignored in shared store colocated setup > -- > > Key: ARTEMIS-2452 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2452 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.9.0 >Reporter: Francesco Nigro >Priority: Major > Time Spent: 2h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2452) group-name ignored in shared store colocated setup
[ https://issues.apache.org/jira/browse/ARTEMIS-2452?focusedWorklogId=295289&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295289 ] ASF GitHub Bot logged work on ARTEMIS-2452: --- Author: ASF GitHub Bot Created on: 15/Aug/19 08:16 Start Date: 15/Aug/19 08:16 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2793: ARTEMIS-2452 group-name ignored in shared store colocated setup URL: https://github.com/apache/activemq-artemis/pull/2793#issuecomment-521556891 Well it can't be totally broken, theres users out there using it (mostly because they are forming single groups or ensuring clusters are rign fenced), yes theres a bug thats not ideal. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295289) Time Spent: 2.5h (was: 2h 20m) > group-name ignored in shared store colocated setup > -- > > Key: ARTEMIS-2452 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2452 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.9.0 >Reporter: Francesco Nigro >Priority: Major > Time Spent: 2.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2452) group-name ignored in shared store colocated setup
[ https://issues.apache.org/jira/browse/ARTEMIS-2452?focusedWorklogId=295287&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295287 ] ASF GitHub Bot logged work on ARTEMIS-2452: --- Author: ASF GitHub Bot Created on: 15/Aug/19 08:14 Start Date: 15/Aug/19 08:14 Worklog Time Spent: 10m Work Description: franz1981 commented on issue #2793: ARTEMIS-2452 group-name ignored in shared store colocated setup URL: https://github.com/apache/activemq-artemis/pull/2793#issuecomment-521556443 The version proposal is probably the best solution indeed: the reason why the old logic breaks the new one is that the old one just ignored the group names and let any requesting server that arrive first to be able to form a pair on any group name regardless both the requesting server group name and the target server. It was just totally broken... This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295287) Time Spent: 2h 10m (was: 2h) > group-name ignored in shared store colocated setup > -- > > Key: ARTEMIS-2452 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2452 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.9.0 >Reporter: Francesco Nigro >Priority: Major > Time Spent: 2h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2452) group-name ignored in shared store colocated setup
[ https://issues.apache.org/jira/browse/ARTEMIS-2452?focusedWorklogId=295288&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295288 ] ASF GitHub Bot logged work on ARTEMIS-2452: --- Author: ASF GitHub Bot Created on: 15/Aug/19 08:14 Start Date: 15/Aug/19 08:14 Worklog Time Spent: 10m Work Description: franz1981 commented on issue #2793: ARTEMIS-2452 group-name ignored in shared store colocated setup URL: https://github.com/apache/activemq-artemis/pull/2793#issuecomment-521556443 The version proposal is probably the best solution indeed: the reason why the old logic breaks the new one is that the old one just ignores the group names and let any requesting server that arrive first to be able to form a pair on any group name regardless both the requesting server group name and the target server. It was just totally broken... This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295288) Time Spent: 2h 20m (was: 2h 10m) > group-name ignored in shared store colocated setup > -- > > Key: ARTEMIS-2452 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2452 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.9.0 >Reporter: Francesco Nigro >Priority: Major > Time Spent: 2h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2452) group-name ignored in shared store colocated setup
[ https://issues.apache.org/jira/browse/ARTEMIS-2452?focusedWorklogId=295285&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295285 ] ASF GitHub Bot logged work on ARTEMIS-2452: --- Author: ASF GitHub Bot Created on: 15/Aug/19 08:13 Start Date: 15/Aug/19 08:13 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on pull request #2793: ARTEMIS-2452 group-name ignored in shared store colocated setup URL: https://github.com/apache/activemq-artemis/pull/2793#discussion_r314212795 ## File path: artemis-server/src/main/java/org/apache/activemq/artemis/core/server/cluster/ha/ColocatedHAManager.java ## @@ -163,6 +174,23 @@ private synchronized boolean activateSharedStoreBackup(String journalDirectory, return true; } + private TopologyMember validateBackupGroupName(SimpleString nodeID) { + // Older versions of artemis don't send the nodeID in BackupRequestMessage: + // in this case we cannot trust the request, making the requesting server Review comment: Why can't we, we know we had old servers and setups working fine, as such why be so strict, simply fail back (or even tter have a v1 and v2 version of the message, that way if all v2 cluster you can be fully strict, else in a v1/v2 mix you can be less strict This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295285) Time Spent: 2h (was: 1h 50m) > group-name ignored in shared store colocated setup > -- > > Key: ARTEMIS-2452 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2452 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.9.0 >Reporter: Francesco Nigro >Priority: Major > Time Spent: 2h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2452) group-name ignored in shared store colocated setup
[ https://issues.apache.org/jira/browse/ARTEMIS-2452?focusedWorklogId=295284&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295284 ] ASF GitHub Bot logged work on ARTEMIS-2452: --- Author: ASF GitHub Bot Created on: 15/Aug/19 08:10 Start Date: 15/Aug/19 08:10 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on pull request #2793: ARTEMIS-2452 group-name ignored in shared store colocated setup URL: https://github.com/apache/activemq-artemis/pull/2793#discussion_r314211592 ## File path: artemis-server/src/main/java/org/apache/activemq/artemis/core/protocol/core/impl/wireformat/BackupRequestMessage.java ## @@ -34,12 +34,14 @@ public BackupRequestMessage() { } public BackupRequestMessage(int backupSize, + SimpleString nodeID, String journalDirectory, String bindingsDirectory, String largeMessagesDirectory, String pagingDirectory) { super(BACKUP_REQUEST); this.backupSize = backupSize; + this.nodeID = nodeID; Review comment: Please make a v2 version, this would be a breaking change, for anyone with existing clusters This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295284) Time Spent: 1h 50m (was: 1h 40m) > group-name ignored in shared store colocated setup > -- > > Key: ARTEMIS-2452 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2452 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.9.0 >Reporter: Francesco Nigro >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2452) group-name ignored in shared store colocated setup
[ https://issues.apache.org/jira/browse/ARTEMIS-2452?focusedWorklogId=295283&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295283 ] ASF GitHub Bot logged work on ARTEMIS-2452: --- Author: ASF GitHub Bot Created on: 15/Aug/19 08:09 Start Date: 15/Aug/19 08:09 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on pull request #2793: ARTEMIS-2452 group-name ignored in shared store colocated setup URL: https://github.com/apache/activemq-artemis/pull/2793#discussion_r314211592 ## File path: artemis-server/src/main/java/org/apache/activemq/artemis/core/protocol/core/impl/wireformat/BackupRequestMessage.java ## @@ -34,12 +34,14 @@ public BackupRequestMessage() { } public BackupRequestMessage(int backupSize, + SimpleString nodeID, String journalDirectory, String bindingsDirectory, String largeMessagesDirectory, String pagingDirectory) { super(BACKUP_REQUEST); this.backupSize = backupSize; + this.nodeID = nodeID; Review comment: Please make a v2 version, this would be a breaking change, for anyone with existing clusters This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295283) Time Spent: 1h 40m (was: 1.5h) > group-name ignored in shared store colocated setup > -- > > Key: ARTEMIS-2452 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2452 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.9.0 >Reporter: Francesco Nigro >Priority: Major > Time Spent: 1h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2452) group-name ignored in shared store colocated setup
[ https://issues.apache.org/jira/browse/ARTEMIS-2452?focusedWorklogId=295282&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295282 ] ASF GitHub Bot logged work on ARTEMIS-2452: --- Author: ASF GitHub Bot Created on: 15/Aug/19 08:07 Start Date: 15/Aug/19 08:07 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2793: ARTEMIS-2452 group-name ignored in shared store colocated setup URL: https://github.com/apache/activemq-artemis/pull/2793#issuecomment-521554151 Also why would having old logic break new? Another option is to version the message, and if you get v1 do old logic, if you get new v2 message do new. Then no need even for a flag. This way in a brand new setup it will all be good, but ln an old / partially transitioned setup you get same guarentees as old, until all fully upgraded after which you're all good. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295282) Time Spent: 1.5h (was: 1h 20m) > group-name ignored in shared store colocated setup > -- > > Key: ARTEMIS-2452 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2452 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.9.0 >Reporter: Francesco Nigro >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2452) group-name ignored in shared store colocated setup
[ https://issues.apache.org/jira/browse/ARTEMIS-2452?focusedWorklogId=295280&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295280 ] ASF GitHub Bot logged work on ARTEMIS-2452: --- Author: ASF GitHub Bot Created on: 15/Aug/19 08:05 Start Date: 15/Aug/19 08:05 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2793: ARTEMIS-2452 group-name ignored in shared store colocated setup URL: https://github.com/apache/activemq-artemis/pull/2793#issuecomment-521554151 Also why would having old logic break new? Another option is to version the message, and if you get v1 do old logic, if you get new v2 message do new. Then no need even for a flag. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295280) Time Spent: 1h 20m (was: 1h 10m) > group-name ignored in shared store colocated setup > -- > > Key: ARTEMIS-2452 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2452 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.9.0 >Reporter: Francesco Nigro >Priority: Major > Time Spent: 1h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2452) group-name ignored in shared store colocated setup
[ https://issues.apache.org/jira/browse/ARTEMIS-2452?focusedWorklogId=295277&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295277 ] ASF GitHub Bot logged work on ARTEMIS-2452: --- Author: ASF GitHub Bot Created on: 15/Aug/19 07:59 Start Date: 15/Aug/19 07:59 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2793: ARTEMIS-2452 group-name ignored in shared store colocated setup URL: https://github.com/apache/activemq-artemis/pull/2793#issuecomment-521552397 Why not have a setting that makes it behave as old version, then once all servers uograded the setting can change to strict..making the flag dynamic would also mean the last change can be done without need for further bounces This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295277) Time Spent: 1h 10m (was: 1h) > group-name ignored in shared store colocated setup > -- > > Key: ARTEMIS-2452 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2452 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.9.0 >Reporter: Francesco Nigro >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2452) group-name ignored in shared store colocated setup
[ https://issues.apache.org/jira/browse/ARTEMIS-2452?focusedWorklogId=295275&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295275 ] ASF GitHub Bot logged work on ARTEMIS-2452: --- Author: ASF GitHub Bot Created on: 15/Aug/19 07:58 Start Date: 15/Aug/19 07:58 Worklog Time Spent: 10m Work Description: michaelandrepearce commented on issue #2793: ARTEMIS-2452 group-name ignored in shared store colocated setup URL: https://github.com/apache/activemq-artemis/pull/2793#issuecomment-521552397 Why not have a setting that makes it behave as old version, then once all servers uograded the setting can change to strict and then simply another round or rolling bounces. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295275) Time Spent: 1h (was: 50m) > group-name ignored in shared store colocated setup > -- > > Key: ARTEMIS-2452 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2452 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.9.0 >Reporter: Francesco Nigro >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Work logged] (ARTEMIS-2452) group-name ignored in shared store colocated setup
[ https://issues.apache.org/jira/browse/ARTEMIS-2452?focusedWorklogId=295268&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-295268 ] ASF GitHub Bot logged work on ARTEMIS-2452: --- Author: ASF GitHub Bot Created on: 15/Aug/19 07:50 Start Date: 15/Aug/19 07:50 Worklog Time Spent: 10m Work Description: franz1981 commented on issue #2793: ARTEMIS-2452 group-name ignored in shared store colocated setup URL: https://github.com/apache/activemq-artemis/pull/2793#issuecomment-521550401 @michaelandrepearce Agree, but nonetheless my comment on the code hold: ``` // Older versions of artemis don't send the nodeID in BackupRequestMessage: // in this case we cannot trust the request, making the requesting server // to pair with this server in any case. ``` Old servers cannot be trusted, because they don't provide enough information to pair with new ones ie the colocated shared store with group name wasn't a feature correctly implemented. If I let them behave as before it can break a new cluster: atm i can't see solutions to preserve a partial cluster upgrade. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 295268) Time Spent: 50m (was: 40m) > group-name ignored in shared store colocated setup > -- > > Key: ARTEMIS-2452 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2452 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.9.0 >Reporter: Francesco Nigro >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016)