[jira] [Commented] (ARTEMIS-1286) Server stops responding and throws OutOfDirectMemoryError when sending & receiving lots of 2MB messages.

2018-03-05 Thread Phillip Jenkins (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16387314#comment-16387314
 ] 

Phillip Jenkins commented on ARTEMIS-1286:
--

[~jbertram], would it be possible to get together over webex or similar to walk 
thru a demo of the error?

> Server stops responding and throws OutOfDirectMemoryError when sending & 
> receiving lots of 2MB messages.
> 
>
> Key: ARTEMIS-1286
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1286
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker, MQTT
>Affects Versions: 2.1.0
>Reporter: Phillip Jenkins
>Assignee: Martyn Taylor
>Priority: Blocker
> Fix For: unscheduled
>
> Attachments: MQTTBasicPubSubExample2.zip, artemis log showing v2.4 
> still having trouble handling large messages.log, broker.xml, 
> image-2018-02-24-19-54-00-892.png, mqtt.zip
>
>
> Originally seen in v2.1 and present in v2.2.
> If you send and receive a lot of 2MB messages in short time thru Artemis via 
> Netty connector, the server throws the following OutOfDirectMemoryError 
> exception. The server stops responding and will not (any longer) accept 
> connections without throwing exceptions in an infinite loop.
> {code:java}
> 11:24:07,434 INFO  [org.apache.activemq.artemis] AMQ241001: HTTP Server 
> started at http://localhost:8161
> 11:24:07,434 INFO  [org.apache.activemq.artemis] AMQ241002: Artemis Jolokia 
> REST API available at http://localhost:8161/jolokia
> 11:58:35,991 WARN  [org.apache.activemq.artemis.core.server] AMQ222151: 
> removing consumer which did not handle a message, consumer=ServerConsumerImpl 
> [id=2229, filter=null, binding=LocalQueueBinding 
> [address=SOAP.S.PRN.ACBCAF6238234680, 
> queue=QueueImpl[name=ACBCAF6238234680.SOAP.S.PRN.ACBCAF6238234680, 
> postOffice=PostOfficeImpl 
> [server=ActiveMQServerImpl::serverUUID=afa7de73-67e7-11e7-a231-54ee7505882d], 
> temp=false]@46adc2a5, filter=FilterImpl [sfilterString=NOT ((AMQAddress = 
> 'activemq.management') OR (AMQAddress = 'activemq.notifications'))], 
> name=ACBCAF6238234680.SOAP.S.PRN.ACBCAF6238234680, 
> clusterName=ACBCAF6238234680.SOAP.S.PRN.ACBCAF6238234680afa7de73-67e7-11e7-a231-54ee7505882d]],
>  
> message=Reference[3551]:NON-RELIABLE:CoreMessage[messageID=3551,durable=false,userID=null,priority=0,
>  timestamp=0,expiration=0, durable=false, 
> address=SOAP.S.PRN.ACBCAF6238234680,properties=TypedProperties[mqtt.message.retain=false,mqtt.qos.level=0]]@1305748199:
>  io.netty.util.internal.OutOfDirectMemoryError: failed to allocate 3729415 
> byte(s) of direct memory (used: 1070952692, max: 1073741824)
>   at 
> io.netty.util.internal.PlatformDependent.incrementMemoryCounter(PlatformDependent.java:585)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.util.internal.PlatformDependent.allocateDirectNoCleaner(PlatformDependent.java:539)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledUnsafeNoCleanerDirectByteBuf.allocateDirect(UnpooledUnsafeNoCleanerDirectByteBuf.java:30)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeNoCleanerDirectByteBuf.allocateDirect(UnpooledByteBufAllocator.java:169)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledUnsafeDirectByteBuf.(UnpooledUnsafeDirectByteBuf.java:68)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledUnsafeNoCleanerDirectByteBuf.(UnpooledUnsafeNoCleanerDirectByteBuf.java:25)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeNoCleanerDirectByteBuf.(UnpooledByteBufAllocator.java:164)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledByteBufAllocator.newDirectBuffer(UnpooledByteBufAllocator.java:73)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:181)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:117)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:828) 
> [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at io.netty.buffer.WrappedByteBuf.readBytes(WrappedByteBuf.java:616) 
> [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> org.apache.activemq.artemis.core.buffers.impl.ChannelBufferWrapper.readBytes(ChannelBufferWrapper.java:315)
>  [artemis-commons-2.2.0-SNAPSHOT.jar:2.2.0-SNAPSHOT]
>   at 
>

[jira] [Created] (AMQ-6910) We have integrated with Active mq with IBM integration bus ,have a problem with failure message backout .how can i define backout for active mq at consumer side

2018-03-05 Thread Satheesh (JIRA) 
Satheesh created AMQ-6910:
-

 Summary: We have integrated with Active mq with IBM integration 
bus ,have a problem with failure message backout .how can i define backout for 
active mq at consumer side
 Key: AMQ-6910
 URL: https://issues.apache.org/jira/browse/AMQ-6910
 Project: ActiveMQ
  Issue Type: Task
  Components: Message Store
Reporter: Satheesh


Hi ,

   We have integrated our project which is been developed in IBM integration 
bus to have some financial transaction .we have problem with message which have 
been received from provider some of the message we are loosing because of some 
failure which we are not able to find out .is there any option having the 
failed message by specifying BackOut Destination at consumer side if possible 
can you help us to resolve this issue .

 

Quick response is highly appreciated ...

 

Thanks

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1719) Update Netty to 4-1-22-Final

2018-03-05 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16387199#comment-16387199
 ] 

ASF GitHub Bot commented on ARTEMIS-1719:
-

GitHub user jbertram opened a pull request:

https://github.com/apache/activemq-artemis/pull/1931

ARTEMIS-1719 fix threadleakrule after Netty upgrade



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jbertram/activemq-artemis ARTEMIS-1719

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/1931.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1931


commit 59dd43bbb6616d4251a8d936d647ba86d41110e0
Author: Justin Bertram 
Date:   2018-03-06T03:11:51Z

ARTEMIS-1719 fix threadleakrule after Netty upgrade




> Update Netty to 4-1-22-Final
> 
>
> Key: ARTEMIS-1719
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1719
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Michael Andre Pearce
>Assignee: Michael Andre Pearce
>Priority: Minor
>
> Update netty to the latest release



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (ARTEMIS-1724) Create Artemis Openwire Client Karaf feature

2018-03-05 Thread Justin Bertram (JIRA) 

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Bertram resolved ARTEMIS-1724.
-
   Resolution: Fixed
Fix Version/s: 2.5.0

> Create Artemis Openwire Client Karaf feature
> 
>
> Key: ARTEMIS-1724
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1724
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: osgi
>Affects Versions: 2.4.0
>Reporter: John Poth
>Priority: Major
> Fix For: 2.5.0
>
>
> It would be nice to have an Apache Karaf feature for an Openwire client. I 
> can take care of the PR.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1724) Create Artemis Openwire Client Karaf feature

2018-03-05 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386774#comment-16386774
 ] 

ASF GitHub Bot commented on ARTEMIS-1724:
-

Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/1922


> Create Artemis Openwire Client Karaf feature
> 
>
> Key: ARTEMIS-1724
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1724
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: osgi
>Affects Versions: 2.4.0
>Reporter: John Poth
>Priority: Major
>
> It would be nice to have an Apache Karaf feature for an Openwire client. I 
> can take care of the PR.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (ARTEMIS-1730) Server leaks memory when messages are expired without an expiry-address

2018-03-05 Thread Justin Bertram (JIRA) 

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-1730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Bertram resolved ARTEMIS-1730.
-
   Resolution: Fixed
Fix Version/s: 2.5.0

> Server leaks memory when messages are expired without an expiry-address
> ---
>
> Key: ARTEMIS-1730
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1730
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.4.0
>Reporter: Ilkka Virolainen
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.5.0
>
>
> When messages are being expired from an address that has an empty 
> expiry-address they should be dropped. At the moment what happens is that the 
> broker logs a message indicating that the message is being dropped:
> AMQ222146: Message has expired. No bindings for Expiry Address  so dropping 
> it 
> However, the messages are never acknowledged so they end up showing as in 
> delivery. ExpiredCount for the queue is never incremented while 
> DeliveringCount is. This results in increased memory consumption and as the 
> amount of expiring messages increase the broker eventually runs out of memory.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1545) JMS MessageProducer fails to expose exception on send when message is sent non-persistent, but not authorised

2018-03-05 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386703#comment-16386703
 ] 

ASF GitHub Bot commented on ARTEMIS-1545:
-

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/1733
  
@clebertsuconic nudge nudge wink wink :)


> JMS MessageProducer fails to expose exception on send when message is sent 
> non-persistent, but not authorised
> -
>
> Key: ARTEMIS-1545
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1545
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Michael Andre Pearce
>Priority: Major
>
> When sending persistent, behaviour is blocking and a Security exception is 
> thrown. The same behaviour that the client is exposed to the client when 
> sending non-persistent, so that a client could log or take action 
> asynchronously. 
> This can be recreated easily by the following:
> Add the following security section , that means guest is not auth'd to send 
> to "guest.cannot.send"
> activemq-artemis/tests/jms-tests/src/test/resources/broker.xml
>  
>
>
>
>
>
>
>
>
> Then add the following tests to this test (first is proving exception 
> correctly is thrown when persistent is sent using jms api, and second shows 
> behaviour difference and no error):
> activemq-artemis/tests/jms-tests/src/test/java/org/apache/activemq/artemis/jms/tests/SecurityTest.java
>   /**
> * Login with valid user and password
> * But try send to address not authorised - Persistent
> * Should not allow and should throw exception
> */
>@Test
>public void testLoginValidUserAndPasswordButNotAuthorisedToSend() throws 
> Exception {
>   ConnectionFactory connectionFactory = new 
> ActiveMQConnectionFactory("tcp://localhost:61616");
>   Connection connection = connectionFactory.createConnection("guest", 
> "guest");
>   Session session = connection.createSession();
>   Destination destination = session.createQueue("guest.cannot.send");
>   MessageProducer messageProducer = session.createProducer(destination);
>   try {
>  messageProducer.send(session.createTextMessage("hello"));
>  fail("JMSSecurityException expected as guest is not allowed to 
> send");
>   } catch (JMSSecurityException activeMQSecurityException){
>  //pass
>   }
>   connection.close();
>}
>/**
> * Login with valid user and password
> * But try send to address not authorised - Non Persistent.
> * Should have same behaviour as Persistent with exception on send.
> */
>@Test
>public void 
> testLoginValidUserAndPasswordButNotAuthorisedToSendNonPersistent() throws 
> Exception {
>   ConnectionFactory connectionFactory = new 
> ActiveMQConnectionFactory("tcp://localhost:61616");
>   Connection connection = connectionFactory.createConnection("guest", 
> "guest");
>   Session session = connection.createSession();
>   Destination destination = session.createQueue("guest.cannot.send");
>   MessageProducer messageProducer = session.createProducer(destination);
>   messageProducer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);
>   try {
>  messageProducer.send(session.createTextMessage("hello"));
>  fail("JMSSecurityException expected as guest is not allowed to 
> send");
>   } catch (JMSSecurityException activeMQSecurityException){
>  //pass
>   }
>   connection.close();
>}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1715) Disable to remove a divert from hawtio console

2018-03-05 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386695#comment-16386695
 ] 

ASF GitHub Bot commented on ARTEMIS-1715:
-

Github user michaelandrepearce commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/1913#discussion_r172316744
  
--- Diff: 
artemis-hawtio/artemis-plugin/src/main/webapp/plugin/js/artemisPlugin.js ---
@@ -231,6 +234,17 @@ var ARTEMIS = (function(ARTEMIS) {
  }
   });
 
+  workspace.subLevelTabs.push({
--- End diff --

If the intent is not to delete a divert as per reply to previous comment, 
then this should not be added


> Disable to remove a divert from hawtio console
> --
>
> Key: ARTEMIS-1715
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1715
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Major
>
> Removing divert is broken (broker tries to remove diverted address, not 
> divert itself). It should be disabled to remove divert.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1715) Disable to remove a divert from hawtio console

2018-03-05 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386697#comment-16386697
 ] 

ASF GitHub Bot commented on ARTEMIS-1715:
-

Github user michaelandrepearce commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/1913#discussion_r172316762
  
--- Diff: 
artemis-hawtio/artemis-plugin/src/main/webapp/plugin/js/artemisPlugin.js ---
@@ -96,6 +96,9 @@ var ARTEMIS = (function(ARTEMIS) {
  .when('/artemis/deleteAddress', {
templateUrl: ARTEMIS.templatePath + 'deleteAddress.html'
  })
+ .when('/artemis/deleteDivert', {
--- End diff --

If the intent is not to delete a divert as per reply to previous comment, 
then this should not be added


> Disable to remove a divert from hawtio console
> --
>
> Key: ARTEMIS-1715
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1715
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Major
>
> Removing divert is broken (broker tries to remove diverted address, not 
> divert itself). It should be disabled to remove divert.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1730) Server leaks memory when messages are expired without an expiry-address

2018-03-05 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386667#comment-16386667
 ] 

ASF GitHub Bot commented on ARTEMIS-1730:
-

Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/1930


> Server leaks memory when messages are expired without an expiry-address
> ---
>
> Key: ARTEMIS-1730
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1730
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.4.0
>Reporter: Ilkka Virolainen
>Assignee: Justin Bertram
>Priority: Major
>
> When messages are being expired from an address that has an empty 
> expiry-address they should be dropped. At the moment what happens is that the 
> broker logs a message indicating that the message is being dropped:
> AMQ222146: Message has expired. No bindings for Expiry Address  so dropping 
> it 
> However, the messages are never acknowledged so they end up showing as in 
> delivery. ExpiredCount for the queue is never incremented while 
> DeliveringCount is. This results in increased memory consumption and as the 
> amount of expiring messages increase the broker eventually runs out of memory.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-528) The "lock" directory should be configurable

2018-03-05 Thread Justin Bertram (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARTEMIS-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386541#comment-16386541
 ] 

Justin Bertram commented on ARTEMIS-528:


bq. The instance directory ($ARTEMIS_INSTANCE) we use does not have a lock 
subdirectory. This is because it is managed the same way as for ActiveMQ 5.x.

I'm not clear on the functional requirement here.  Are you saying you want to 
be able to managed Artemis like you manage 5.x?  If so, can you elaborate on 
your management strategy?  Is the problem that the {{lock}} subdirectory of 
$ARTEMIS_INSTANCE can't be created dynamically in your environment?

I'm still trying to understand if there may be a way to meet your functional 
requirement without changing the lock's location.

bq. IMHO, the danger of messing up with the lock directory is not worse than 
messing up with the data directories.

I see what you're saying, but I think there is a key difference.  If you 
specify different {{data}} directories then you're operating on two different 
sets of data and there is no risk to data integrity since the directories are 
independent of each other.  However, in the case of a wrong lock then 2 
processes are operating on the same data which does pose a risk to data 
integrity.

> The "lock" directory should be configurable
> ---
>
> Key: ARTEMIS-528
> URL: https://issues.apache.org/jira/browse/ARTEMIS-528
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>Priority: Major
>
> Artemis allows the broker owner to change most of the paths used, see for 
> instance the "*-directory" elements like "paging-directory". There is one 
> major exception though.
> The directory holding the {{cli.lock}} file is currently hard-coded in 
> {{artemis-cli/src/main/java/org/apache/activemq/artemis/cli/commands/Configurable.java}}
>  (sic):
> {code}
>protected File getLockPlace() throws Exception {
>   String brokerInstance = getBrokerInstance();
>   if (brokerInstance != null) {
>  return new File(new File(brokerInstance),"lock");
>   }
>   else {
>  return null;
>   }
>}
> {code}
> Could you please allow changing the name of this directory?
> Ideally, it could appear like the other "*-directory" elements in 
> {{broker.xml}}. If this is too late, it could come from a Java property such 
> as {{artemis.lockdir}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1559) Repeated retries of unencrypted traffic to SSL-enabled broker causes OOM exception

2018-03-05 Thread Tommy Lillehagen (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386488#comment-16386488
 ] 

Tommy Lillehagen commented on ARTEMIS-1559:
---

Hi again [~jbertram],

I've pushed a separate, smaller example reproducing the issue described above. 
The culprit seems to be how we set {{reconnectAttempts}} to {{-1}} (unlimited) 
on the {{ServerLocator}}.

You can find the project and the basic steps to reproduce here: 
[https://github.com/tlil/scratchpad/tree/tlil/ARTEMIS-1559/artemis-oom-repro]

Let me know if anything is unclear.

Cheers,
 Tommy

> Repeated retries of unencrypted traffic to SSL-enabled broker causes OOM 
> exception
> --
>
> Key: ARTEMIS-1559
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1559
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.3.0, 2.4.0
>Reporter: Tommy Lillehagen
>Priority: Major
>  Labels: memory-leak
> Attachments: mem-leak-source.png, mem-leak.png
>
>
> Repro steps:
>  * We have a broker (A) set up with SSL enabled (using Artemis v2.4 / v2.3)
>  * A client (B) set up to use plain (non-TLS) communication (same version of 
> Artemis)
>  * Trying to establish a connection between (B) and (A) triggers multiple 
> retries
>  * Each message gets, from what I can tell, rejected quickly by (A), but each 
> iteration leaks heap memory
>  * Due to the number of retries in a short amount a time (~1000s from what I 
> can tell) causes the above to grow the heap by 470M or so within less than 10 
> seconds (the set timeout)
>  * This consequently results in an out of memory exception
> The above behaviour is observed in both version 2.3 and 2.4.
> We've tested older versions (2.1 and 2.2), and neither of those manifest the 
> same problem.
> I've run some profiling on (A), and {{NettyAcceptor.initChannel}} 
> ({{getSslHandler()}}) seems to be a critical point (will include screenshots).
> That being said, most of the accumulated heap memory seems to be claimable 
> and is mostly collected during the next GC cycle in the tests that I've run.
> Source: https://github.com/corda/corda/pull/2252



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1719) Update Netty to 4-1-22-Final

2018-03-05 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386433#comment-16386433
 ] 

ASF GitHub Bot commented on ARTEMIS-1719:
-

Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/1917


> Update Netty to 4-1-22-Final
> 
>
> Key: ARTEMIS-1719
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1719
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Michael Andre Pearce
>Assignee: Michael Andre Pearce
>Priority: Minor
>
> Update netty to the latest release



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (ARTEMIS-1730) Server leaks memory when messages are expired without an expiry-address

2018-03-05 Thread Justin Bertram (JIRA) 

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-1730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Bertram reassigned ARTEMIS-1730:
---

Assignee: Justin Bertram

> Server leaks memory when messages are expired without an expiry-address
> ---
>
> Key: ARTEMIS-1730
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1730
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.4.0, 2.5.0
>Reporter: Ilkka Virolainen
>Assignee: Justin Bertram
>Priority: Major
>
> When messages are being expired from an address that has an empty 
> expiry-address they should be dropped. At the moment what happens is that the 
> broker logs a message indicating that the message is being dropped:
> AMQ222146: Message has expired. No bindings for Expiry Address  so dropping 
> it 
> However, the messages are never acknowledged so they end up showing as in 
> delivery. ExpiredCount for the queue is never incremented while 
> DeliveringCount is. This results in increased memory consumption and as the 
> amount of expiring messages increase the broker eventually runs out of memory.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1730) Server leaks memory when messages are expired without an expiry-address

2018-03-05 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386421#comment-16386421
 ] 

ASF GitHub Bot commented on ARTEMIS-1730:
-

GitHub user jbertram opened a pull request:

https://github.com/apache/activemq-artemis/pull/1930

ARTEMIS-1730 fix expiry without address or bindings



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jbertram/activemq-artemis ARTEMIS-1730

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/1930.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1930


commit 1a317354692dd4f23ec3c703ac169b5b9bafaff6
Author: Justin Bertram 
Date:   2018-03-05T17:39:58Z

ARTEMIS-1730 fix expiry without address or bindings




> Server leaks memory when messages are expired without an expiry-address
> ---
>
> Key: ARTEMIS-1730
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1730
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.4.0
>Reporter: Ilkka Virolainen
>Assignee: Justin Bertram
>Priority: Major
>
> When messages are being expired from an address that has an empty 
> expiry-address they should be dropped. At the moment what happens is that the 
> broker logs a message indicating that the message is being dropped:
> AMQ222146: Message has expired. No bindings for Expiry Address  so dropping 
> it 
> However, the messages are never acknowledged so they end up showing as in 
> delivery. ExpiredCount for the queue is never incremented while 
> DeliveringCount is. This results in increased memory consumption and as the 
> amount of expiring messages increase the broker eventually runs out of memory.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ARTEMIS-1730) Server leaks memory when messages are expired without an expiry-address

2018-03-05 Thread Justin Bertram (JIRA) 

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-1730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Bertram updated ARTEMIS-1730:

External issue URL: 
http://mail-archives.apache.org/mod_mbox/activemq-users/201802.mbox/%3cf9edeca99c924bfe90faddbc5bde5...@exchange.intra.bitwise.fi%3e

> Server leaks memory when messages are expired without an expiry-address
> ---
>
> Key: ARTEMIS-1730
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1730
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.4.0, 2.5.0
>Reporter: Ilkka Virolainen
>Assignee: Justin Bertram
>Priority: Major
>
> When messages are being expired from an address that has an empty 
> expiry-address they should be dropped. At the moment what happens is that the 
> broker logs a message indicating that the message is being dropped:
> AMQ222146: Message has expired. No bindings for Expiry Address  so dropping 
> it 
> However, the messages are never acknowledged so they end up showing as in 
> delivery. ExpiredCount for the queue is never incremented while 
> DeliveringCount is. This results in increased memory consumption and as the 
> amount of expiring messages increase the broker eventually runs out of memory.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ARTEMIS-1730) Server leaks memory when messages are expired without an expiry-address

2018-03-05 Thread Justin Bertram (JIRA) 

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-1730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Bertram updated ARTEMIS-1730:

Affects Version/s: (was: 2.5.0)

> Server leaks memory when messages are expired without an expiry-address
> ---
>
> Key: ARTEMIS-1730
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1730
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.4.0
>Reporter: Ilkka Virolainen
>Assignee: Justin Bertram
>Priority: Major
>
> When messages are being expired from an address that has an empty 
> expiry-address they should be dropped. At the moment what happens is that the 
> broker logs a message indicating that the message is being dropped:
> AMQ222146: Message has expired. No bindings for Expiry Address  so dropping 
> it 
> However, the messages are never acknowledged so they end up showing as in 
> delivery. ExpiredCount for the queue is never incremented while 
> DeliveringCount is. This results in increased memory consumption and as the 
> amount of expiring messages increase the broker eventually runs out of memory.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1727) Broker should close socket on failed connection attempt using OpenWire

2018-03-05 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386223#comment-16386223
 ] 

ASF subversion and git services commented on ARTEMIS-1727:
--

Commit 29250466ae3b29ea87e61dc637149fe1fb7f82eb in activemq-artemis's branch 
refs/heads/master from [~cshannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=2925046 ]

ARTEMIS-1727 - Make sure transport is stopped on failed OpenWire
connection

To prevent a socket from hanging open by a bad client the broker should
make sure to stop the transport if a connection attempt fails by an
OpenWire client


> Broker should close socket on failed connection attempt using OpenWire
> --
>
> Key: ARTEMIS-1727
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1727
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: OpenWire
>Affects Versions: 2.4.0
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 2.5.0
>
>
> This is related to a patch I did for 5.x : AMQ-6561
> The OpenWire client will only close a connection failed connection attempt 
> automatically on a security error but not other JMSExceptions such as Invalid 
> client ids.  Because of this it's possible a misbehaving client can leave 
> open sockets that won't be closed.  The broker should detect a failed open 
> wire connection attempt and make sure the socket is killed.
> Note that the CORE client does not seem to have this problem because it does 
> properly handle all JMS exceptions on initial connect/authorization and close 
> itself.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1727) Broker should close socket on failed connection attempt using OpenWire

2018-03-05 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386224#comment-16386224
 ] 

ASF GitHub Bot commented on ARTEMIS-1727:
-

Github user asfgit closed the pull request at:

https://github.com/apache/activemq-artemis/pull/1925


> Broker should close socket on failed connection attempt using OpenWire
> --
>
> Key: ARTEMIS-1727
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1727
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: OpenWire
>Affects Versions: 2.4.0
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 2.5.0
>
>
> This is related to a patch I did for 5.x : AMQ-6561
> The OpenWire client will only close a connection failed connection attempt 
> automatically on a security error but not other JMSExceptions such as Invalid 
> client ids.  Because of this it's possible a misbehaving client can leave 
> open sockets that won't be closed.  The broker should detect a failed open 
> wire connection attempt and make sure the socket is killed.
> Note that the CORE client does not seem to have this problem because it does 
> properly handle all JMS exceptions on initial connect/authorization and close 
> itself.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ARTEMIS-1730) Server leaks memory when messages are expired without an expiry-address

2018-03-05 Thread Ilkka Virolainen (JIRA) 
Ilkka Virolainen created ARTEMIS-1730:
-

 Summary: Server leaks memory when messages are expired without an 
expiry-address
 Key: ARTEMIS-1730
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1730
 Project: ActiveMQ Artemis
  Issue Type: Bug
  Components: Broker
Affects Versions: 2.4.0, 2.5.0
Reporter: Ilkka Virolainen


When messages are being expired from an address that has an empty 
expiry-address they should be dropped. At the moment what happens is that the 
broker logs a message indicating that the message is being dropped:

AMQ222146: Message has expired. No bindings for Expiry Address  so dropping it 

However, the messages are never acknowledged so they end up showing as in 
delivery. ExpiredCount for the queue is never incremented while DeliveringCount 
is. This results in increased memory consumption and as the amount of expiring 
messages increase the broker eventually runs out of memory.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1286) Server stops responding and throws OutOfDirectMemoryError when sending & receiving lots of 2MB messages.

2018-03-05 Thread Justin Bertram (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386028#comment-16386028
 ] 

Justin Bertram commented on ARTEMIS-1286:
-

[~pwjenkins], I let it run all the way through (i.e. to 200) both times.

> Server stops responding and throws OutOfDirectMemoryError when sending & 
> receiving lots of 2MB messages.
> 
>
> Key: ARTEMIS-1286
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1286
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker, MQTT
>Affects Versions: 2.1.0
>Reporter: Phillip Jenkins
>Assignee: Martyn Taylor
>Priority: Blocker
> Fix For: unscheduled
>
> Attachments: MQTTBasicPubSubExample2.zip, artemis log showing v2.4 
> still having trouble handling large messages.log, broker.xml, 
> image-2018-02-24-19-54-00-892.png, mqtt.zip
>
>
> Originally seen in v2.1 and present in v2.2.
> If you send and receive a lot of 2MB messages in short time thru Artemis via 
> Netty connector, the server throws the following OutOfDirectMemoryError 
> exception. The server stops responding and will not (any longer) accept 
> connections without throwing exceptions in an infinite loop.
> {code:java}
> 11:24:07,434 INFO  [org.apache.activemq.artemis] AMQ241001: HTTP Server 
> started at http://localhost:8161
> 11:24:07,434 INFO  [org.apache.activemq.artemis] AMQ241002: Artemis Jolokia 
> REST API available at http://localhost:8161/jolokia
> 11:58:35,991 WARN  [org.apache.activemq.artemis.core.server] AMQ222151: 
> removing consumer which did not handle a message, consumer=ServerConsumerImpl 
> [id=2229, filter=null, binding=LocalQueueBinding 
> [address=SOAP.S.PRN.ACBCAF6238234680, 
> queue=QueueImpl[name=ACBCAF6238234680.SOAP.S.PRN.ACBCAF6238234680, 
> postOffice=PostOfficeImpl 
> [server=ActiveMQServerImpl::serverUUID=afa7de73-67e7-11e7-a231-54ee7505882d], 
> temp=false]@46adc2a5, filter=FilterImpl [sfilterString=NOT ((AMQAddress = 
> 'activemq.management') OR (AMQAddress = 'activemq.notifications'))], 
> name=ACBCAF6238234680.SOAP.S.PRN.ACBCAF6238234680, 
> clusterName=ACBCAF6238234680.SOAP.S.PRN.ACBCAF6238234680afa7de73-67e7-11e7-a231-54ee7505882d]],
>  
> message=Reference[3551]:NON-RELIABLE:CoreMessage[messageID=3551,durable=false,userID=null,priority=0,
>  timestamp=0,expiration=0, durable=false, 
> address=SOAP.S.PRN.ACBCAF6238234680,properties=TypedProperties[mqtt.message.retain=false,mqtt.qos.level=0]]@1305748199:
>  io.netty.util.internal.OutOfDirectMemoryError: failed to allocate 3729415 
> byte(s) of direct memory (used: 1070952692, max: 1073741824)
>   at 
> io.netty.util.internal.PlatformDependent.incrementMemoryCounter(PlatformDependent.java:585)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.util.internal.PlatformDependent.allocateDirectNoCleaner(PlatformDependent.java:539)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledUnsafeNoCleanerDirectByteBuf.allocateDirect(UnpooledUnsafeNoCleanerDirectByteBuf.java:30)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeNoCleanerDirectByteBuf.allocateDirect(UnpooledByteBufAllocator.java:169)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledUnsafeDirectByteBuf.(UnpooledUnsafeDirectByteBuf.java:68)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledUnsafeNoCleanerDirectByteBuf.(UnpooledUnsafeNoCleanerDirectByteBuf.java:25)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeNoCleanerDirectByteBuf.(UnpooledByteBufAllocator.java:164)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledByteBufAllocator.newDirectBuffer(UnpooledByteBufAllocator.java:73)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:181)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:117)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:828) 
> [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at io.netty.buffer.WrappedByteBuf.readBytes(WrappedByteBuf.java:616) 
> [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> org.apache.activemq.artemis.core.buffers.impl.ChannelBufferWrapper.readBytes(ChannelBufferWrapper.java:315)
>  [artemis-commons-2.2.0-SNAPSHOT.jar:2.2.0-SNAPSHOT]
>   at 
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTPublishManager.sendServerMessage(MQTTPublishManager.java:277)
>

[jira] [Commented] (ARTEMIS-1727) Broker should close socket on failed connection attempt using OpenWire

2018-03-05 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386025#comment-16386025
 ] 

ASF GitHub Bot commented on ARTEMIS-1727:
-

Github user cshannon commented on the issue:

https://github.com/apache/activemq-artemis/pull/1925
  
@tabish121 - PR has been updated to use the broker's scheduled pool


> Broker should close socket on failed connection attempt using OpenWire
> --
>
> Key: ARTEMIS-1727
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1727
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: OpenWire
>Affects Versions: 2.4.0
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 2.5.0
>
>
> This is related to a patch I did for 5.x : AMQ-6561
> The OpenWire client will only close a connection failed connection attempt 
> automatically on a security error but not other JMSExceptions such as Invalid 
> client ids.  Because of this it's possible a misbehaving client can leave 
> open sockets that won't be closed.  The broker should detect a failed open 
> wire connection attempt and make sure the socket is killed.
> Note that the CORE client does not seem to have this problem because it does 
> properly handle all JMS exceptions on initial connect/authorization and close 
> itself.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1728) Reclaim memory when page cursor complete

2018-03-05 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16385923#comment-16385923
 ] 

ASF GitHub Bot commented on ARTEMIS-1728:
-

Github user franz1981 commented on the issue:

https://github.com/apache/activemq-artemis/pull/1929
  
Good catch!! 


> Reclaim memory when page cursor complete
> 
>
> Key: ARTEMIS-1728
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1728
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Reporter: shoukun huai
>Priority: Minor
>
> Reclaim memory when page cursor completes.
> There are two hash set used to hold page position for acks and removed 
> message references. Both are cleared when page cursor is marked done. While 
> clear a hash set does not reclaim memory the under line hash map claimed 
> before.
> Things go bad when you have an address with many bindings and one of them 
> consumes slowly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1728) Reclaim memory when page cursor complete

2018-03-05 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16385868#comment-16385868
 ] 

ASF GitHub Bot commented on ARTEMIS-1728:
-

GitHub user shoukunhuai opened a pull request:

https://github.com/apache/activemq-artemis/pull/1929

ARTEMIS-1728 Reclaim memory when page cursor complete

Free hash set used to hold page position for acks and removed refs.
The two set is cleared, but they still hold a big array.

It is safe to replace the old one with empty set.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/shoukunhuai/activemq-artemis reclaim_hashmap

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/1929.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1929


commit 6d445c5d6485ed5ca65ea5718905a84ca6d5eb9b
Author: huaishk 
Date:   2018-03-05T09:32:29Z

ARTEMIS-1728 Reclaim memory when page cursor complete

Free hash set used to hold page position for acks and removed refs.
The two set is cleared, but they still hold a big array.

It is safe to replace the old one with empty set.




> Reclaim memory when page cursor complete
> 
>
> Key: ARTEMIS-1728
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1728
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Reporter: shoukun huai
>Priority: Minor
>
> Reclaim memory when page cursor completes.
> There are two hash set used to hold page position for acks and removed 
> message references. Both are cleared when page cursor is marked done. While 
> clear a hash set does not reclaim memory the under line hash map claimed 
> before.
> Things go bad when you have an address with many bindings and one of them 
> consumes slowly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (ARTEMIS-1725) Broken browsing in hawtio console under JMX tab has been observed at non listing tabs

2018-03-05 Thread Stanislav Knot (JIRA) 

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stanislav Knot resolved ARTEMIS-1725.
-
Resolution: Fixed

> Broken browsing in hawtio console under JMX tab has been observed at non 
> listing tabs
> -
>
> Key: ARTEMIS-1725
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1725
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Minor
>
> 1. create & start broker
>  2. go to JMX tab of hawtio console
>  3. [create] and choose queue
>  4. select (for example) addresses tab
>  5. you are redirected to attributes (before that, you are redirected to 
> Artemis/addresses)
>  6. select browse
>  7. back to step 4 - now works fine
> It goes to Artemis tab and back to JMX attributes. Table data are fetched 
> correctly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1715) Disable to remove a divert from hawtio console

2018-03-05 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16385821#comment-16385821
 ] 

ASF GitHub Bot commented on ARTEMIS-1715:
-

Github user michaelandrepearce commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/1913#discussion_r172121469
  
--- Diff: 
artemis-hawtio/artemis-plugin/src/main/webapp/plugin/html/deleteDivert.html ---
@@ -0,0 +1,24 @@
+
+
--- End diff --

Eg there is code in this pr that signifies otherwise


> Disable to remove a divert from hawtio console
> --
>
> Key: ARTEMIS-1715
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1715
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Major
>
> Removing divert is broken (broker tries to remove diverted address, not 
> divert itself). It should be disabled to remove divert.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1715) Disable to remove a divert from hawtio console

2018-03-05 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16385819#comment-16385819
 ] 

ASF GitHub Bot commented on ARTEMIS-1715:
-

Github user michaelandrepearce commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/1913#discussion_r172121106
  
--- Diff: 
artemis-hawtio/artemis-plugin/src/main/webapp/plugin/html/deleteDivert.html ---
@@ -0,0 +1,24 @@
+
+
--- End diff --

If that’s the case please close this pr 


> Disable to remove a divert from hawtio console
> --
>
> Key: ARTEMIS-1715
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1715
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Major
>
> Removing divert is broken (broker tries to remove diverted address, not 
> divert itself). It should be disabled to remove divert.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ARTEMIS-1729) Automatically check for broken documentation links

2018-03-05 Thread Lionel Cons (JIRA) 
Lionel Cons created ARTEMIS-1729:


 Summary: Automatically check for broken documentation links
 Key: ARTEMIS-1729
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1729
 Project: ActiveMQ Artemis
  Issue Type: Bug
Reporter: Lionel Cons


The Artemis GitBook documentation sometimes contains broken (internal) links. 
See for instance ARTEMIS-1076 or ARTEMIS-1721.

It would be good to automatically check for broken links as part of the Maven 
{{test}} task.

One way to do this would be to have a Maven task to run a webserver serving the 
generated documentation (Python can trivially do it with '{{python -m 
SimpleHTTPServer 8000}}' but an equivalent Java-based solution is probably 
better) and then a crawler checking for broken links ({{wget}} can easily be 
used for this as described in ARTEMIS-1076 but here again a Java-based solution 
is maybe better).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-528) The "lock" directory should be configurable

2018-03-05 Thread Lionel Cons (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARTEMIS-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16385799#comment-16385799
 ] 

Lionel Cons commented on ARTEMIS-528:
-

The instance directory ({{$ARTEMIS_INSTANCE}}) we use does not have a {{lock}} 
subdirectory. This is because it is managed the same way as for ActiveMQ 5.x.

We could change this but it is a pity that all the directory names under 
{{$ARTEMIS_INSTANCE}} can be customized except one...

IMHO, the danger of messing up with the lock directory is not worse than 
messing up with the data directories.

> The "lock" directory should be configurable
> ---
>
> Key: ARTEMIS-528
> URL: https://issues.apache.org/jira/browse/ARTEMIS-528
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>Priority: Major
>
> Artemis allows the broker owner to change most of the paths used, see for 
> instance the "*-directory" elements like "paging-directory". There is one 
> major exception though.
> The directory holding the {{cli.lock}} file is currently hard-coded in 
> {{artemis-cli/src/main/java/org/apache/activemq/artemis/cli/commands/Configurable.java}}
>  (sic):
> {code}
>protected File getLockPlace() throws Exception {
>   String brokerInstance = getBrokerInstance();
>   if (brokerInstance != null) {
>  return new File(new File(brokerInstance),"lock");
>   }
>   else {
>  return null;
>   }
>}
> {code}
> Could you please allow changing the name of this directory?
> Ideally, it could appear like the other "*-directory" elements in 
> {{broker.xml}}. If this is too late, it could come from a Java property such 
> as {{artemis.lockdir}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1715) Disable to remove a divert from hawtio console

2018-03-05 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARTEMIS-1715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16385786#comment-16385786
 ] 

ASF GitHub Bot commented on ARTEMIS-1715:
-

Github user stanlyDoge commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/1913#discussion_r172115995
  
--- Diff: 
artemis-hawtio/artemis-plugin/src/main/webapp/plugin/html/deleteDivert.html ---
@@ -0,0 +1,24 @@
+
+
--- End diff --

Hi Michael. After discussion with @andytaylor we decided that divert should 
not be deletable from web console, so there is no need to have pop-up.


> Disable to remove a divert from hawtio console
> --
>
> Key: ARTEMIS-1715
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1715
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Major
>
> Removing divert is broken (broker tries to remove diverted address, not 
> divert itself). It should be disabled to remove divert.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ARTEMIS-1728) Reclaim memory when page cursor complete

2018-03-05 Thread shoukun huai (JIRA) 
shoukun huai created ARTEMIS-1728:
-

 Summary: Reclaim memory when page cursor complete
 Key: ARTEMIS-1728
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1728
 Project: ActiveMQ Artemis
  Issue Type: Improvement
  Components: Broker
Reporter: shoukun huai


Reclaim memory when page cursor completes.

There are two hash set used to hold page position for acks and removed message 
references. Both are cleared when page cursor is marked done. While clear a 
hash set does not reclaim memory the under line hash map claimed before.

Things go bad when you have an address with many bindings and one of them 
consumes slowly.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)