date:20170806

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

2017-08-06 Thread Phillip Jenkins (JIRA)


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

Phillip Jenkins commented on ARTEMIS-1286:
--

[~martyntaylor], checking to see if there's been any work on this yet. Any 
progress? Any estimate on when it might get to resolution?

> 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: 2.3.0
>
> Attachments: broker.xml, 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)
>  [artemis-mqtt-protocol-2.2.0-SNAPSHOT.jar:]
>   at 
>

[jira] [Commented] (ARTEMIS-1308) Client Acknowledge not performant

2017-08-06 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-1308:
-

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/1428
  
@franz1981 thanks, we've got a succesfull build post my rebase, and squash 
anyhow :).

@ all this i think is in a state to look to merge, tests all passing in PR 
build.


> Client Acknowledge not performant
> -
>
> Key: ARTEMIS-1308
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1308
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: Michael Andre Pearce
>Assignee: Michael Andre Pearce
>Priority: Critical
> Fix For: 2.3.0
>
>
> Artemis recommendation in docs is to use CLIENT_ACKNOWLEDGE instead of 
> AUTO_ACKNOWLEDGE, on perf testing it seems this is not the case.
> On checking code it seems the reason for this is because ActiveMQMessage 
> acknowledge actually calls session.commit, causing a full session commit all 
> the time.
> On checking Core API, calling message.acknowledge it seems to behave as 
> expected, as such believe this to be an issue in JMS api wrapper, that it 
> should just be delegating to the ClientMessage.acknowledge method and this is 
> the cause of the perf issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1324) Critical Analysis and deadlock detection on broker

2017-08-06 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-1324:
-

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

https://github.com/apache/activemq-artemis/pull/1443#discussion_r131552826
  
--- Diff: docs/user-manual/en/critical-analysis.md ---
@@ -0,0 +1,32 @@
+# Critical Analysis of the broker
+
+There are a few things that can go wrong on a production environment:
+
+- Bugs, for more than we try they still happen! We always try to correct 
them, but that's the only constant in software development.
+- IO Errors, disks and hardware can go bad
+- Memory issues, the CPU can go crazy by another process
+
+For cases like this, we added a protection to the broker to shut itself 
down when bad things happen.
+
+We measure time response in places like:
+
+- Queue delivery (add to the queue)
+- Journal storage
+- Paging operations
+
+If the response time goes beyond a configured timeout, the broker is 
considered unstable and an action will be taken to either shutdown the broker 
or halt the VM.
+
+You can use these following configuration options on broker.xml to 
configure how the critical analysis is performed.
+
+
+Name | Description
+:--- | :---
+analyze-critical | Enable or disable the critical analysis (default true)
+analyze-critical-timeout | Timeout used to do the critical analysis 
(default 12 milliseconds)
+analyze-critical-check-period | Time used to check the response times 
(default half of analyze-critical-timeout)
+analyze-critical-halt | Should the VM be halted upon failures (default 
false)
--- End diff --

i would imagine a health monitor/critical analysers threads are independent 
of core flow, as such it should detect and action if a component isn't 
responding or non healthy state. As such it should be able to declare that 
state back. 

e.g. if JVM bad state due to deadlock, that deadlock should only be 
affecting the threads/flow where the deadlock is , as such this component 
should still be servicing.


> Critical Analysis and deadlock detection on broker
> --
>
> Key: ARTEMIS-1324
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1324
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Reporter: clebert suconic
>Assignee: clebert suconic
>Priority: Critical
> Fix For: 2.3.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1324) Critical Analysis and deadlock detection on broker

2017-08-06 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-1324:
-

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

https://github.com/apache/activemq-artemis/pull/1443#discussion_r131552744
  
--- Diff: 
artemis-commons/src/main/java/org/apache/activemq/artemis/utils/critical/CriticalAnalyzerImpl.java
 ---
@@ -0,0 +1,182 @@
+/**
+ * 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.utils.critical;
+
+import java.util.ConcurrentModificationException;
+import java.util.concurrent.CopyOnWriteArrayList;
+import java.util.concurrent.Semaphore;
+import java.util.concurrent.TimeUnit;
+
+import org.apache.activemq.artemis.utils.collections.ConcurrentHashSet;
+import org.jboss.logging.Logger;
+
+public class CriticalAnalyzerImpl implements CriticalAnalyzer {
+
+   private final Logger logger = Logger.getLogger(CriticalAnalyzer.class);
+
+   private volatile long timeout;
+
+   private volatile long checkTime;
+
+   @Override
+   public void clear() {
+  actions.clear();
+  components.clear();
+   }
+
+   private CopyOnWriteArrayList actions = new 
CopyOnWriteArrayList<>();
+
+   private Thread thread;
+
+   private final Semaphore running = new Semaphore(1);
+
+   private final ConcurrentHashSet components = new 
ConcurrentHashSet<>();
+
+   @Override
+   public void add(CriticalComponent component) {
+  components.add(component);
+   }
+
+   @Override
+   public void remove(CriticalComponent component) {
+  components.remove(component);
+   }
+
+   @Override
+   public CriticalAnalyzer setCheckTime(long timeout) {
+  this.checkTime = timeout;
+  return this;
+   }
+
+   @Override
+   public long getCheckTime() {
+  if (checkTime == 0) {
+ checkTime = getTimeout() / 2;
+  }
+  return checkTime;
+   }
+
+   @Override
+   public CriticalAnalyzer setTimeout(long timeout) {
+  this.timeout = timeout;
+  return this;
+   }
+
+   @Override
+   public long getTimeout() {
+  if (timeout == 0) {
+ timeout = TimeUnit.MINUTES.toMillis(2);
+  }
+  return timeout;
+   }
+
+   @Override
+   public CriticalAnalyzer addAction(CriticalAction action) {
+  this.actions.add(action);
+  return this;
+   }
+
+   @Override
+   public void check() {
+  boolean retry = true;
+  while (retry) {
+ try {
+for (CriticalComponent component : components) {
+
+   int pathReturned = component.isExpired(timeout);
+   if (pathReturned >= 0) {
+  fireAction(component, pathReturned);
+  // no need to keep running if there's already a 
component failed
+  return;
+   }
+}
+retry = false; // got to the end of the list, no need to retry
+ } catch (ConcurrentModificationException dontCare) {
+// lets retry on the loop
+ }
+  }
+   }
+
+   private void fireAction(CriticalComponent component, int path) {
+  for (CriticalAction action: actions) {
+ try {
+action.run(component, path);
+ } catch (Throwable e) {
+logger.warn(e.getMessage(), e);
+ }
+  }
+   }
+
+   @Override
+   public void start() {
+
+  if (!running.tryAcquire()) {
+ // already running
+ return;
+  }
+
+  // we are not using any Thread Pool or any Scheduled Executors from 
the ArtemisServer
+  // as that would defeat the purpose,
+  // as

[jira] [Commented] (ARTEMIS-1324) Critical Analysis and deadlock detection on broker

2017-08-06 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-1324:
-

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

https://github.com/apache/activemq-artemis/pull/1443#discussion_r131541817
  
--- Diff: docs/user-manual/en/critical-analysis.md ---
@@ -0,0 +1,32 @@
+# Critical Analysis of the broker
+
+There are a few things that can go wrong on a production environment:
+
+- Bugs, for more than we try they still happen! We always try to correct 
them, but that's the only constant in software development.
+- IO Errors, disks and hardware can go bad
+- Memory issues, the CPU can go crazy by another process
+
+For cases like this, we added a protection to the broker to shut itself 
down when bad things happen.
+
+We measure time response in places like:
+
+- Queue delivery (add to the queue)
+- Journal storage
+- Paging operations
+
+If the response time goes beyond a configured timeout, the broker is 
considered unstable and an action will be taken to either shutdown the broker 
or halt the VM.
+
+You can use these following configuration options on broker.xml to 
configure how the critical analysis is performed.
+
+
+Name | Description
+:--- | :---
+analyze-critical | Enable or disable the critical analysis (default true)
+analyze-critical-timeout | Timeout used to do the critical analysis 
(default 12 milliseconds)
+analyze-critical-check-period | Time used to check the response times 
(default half of analyze-critical-timeout)
+analyze-critical-halt | Should the VM be halted upon failures (default 
false)
--- End diff --

I can use management.  

I wasn't sure it would be useful. As if the JVM is in bad state would the 
message arrive ?


> Critical Analysis and deadlock detection on broker
> --
>
> Key: ARTEMIS-1324
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1324
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Reporter: clebert suconic
>Assignee: clebert suconic
>Priority: Critical
> Fix For: 2.3.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1324) Critical Analysis and deadlock detection on broker

2017-08-06 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-1324:
-

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/1443
  
I will make some changes here tomorrow. 


> Critical Analysis and deadlock detection on broker
> --
>
> Key: ARTEMIS-1324
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1324
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Reporter: clebert suconic
>Assignee: clebert suconic
>Priority: Critical
> Fix For: 2.3.0
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1324) Critical Analysis and deadlock detection on broker

2017-08-06 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-1324:
-

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

https://github.com/apache/activemq-artemis/pull/1443#discussion_r131541803
  
--- Diff: 
artemis-commons/src/main/java/org/apache/activemq/artemis/utils/critical/CriticalAnalyzerImpl.java
 ---
@@ -0,0 +1,182 @@
+/**
+ * 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.utils.critical;
+
+import java.util.ConcurrentModificationException;
+import java.util.concurrent.CopyOnWriteArrayList;
+import java.util.concurrent.Semaphore;
+import java.util.concurrent.TimeUnit;
+
+import org.apache.activemq.artemis.utils.collections.ConcurrentHashSet;
+import org.jboss.logging.Logger;
+
+public class CriticalAnalyzerImpl implements CriticalAnalyzer {
+
+   private final Logger logger = Logger.getLogger(CriticalAnalyzer.class);
+
+   private volatile long timeout;
+
+   private volatile long checkTime;
+
+   @Override
+   public void clear() {
+  actions.clear();
+  components.clear();
+   }
+
+   private CopyOnWriteArrayList actions = new 
CopyOnWriteArrayList<>();
+
+   private Thread thread;
+
+   private final Semaphore running = new Semaphore(1);
+
+   private final ConcurrentHashSet components = new 
ConcurrentHashSet<>();
+
+   @Override
+   public void add(CriticalComponent component) {
+  components.add(component);
+   }
+
+   @Override
+   public void remove(CriticalComponent component) {
+  components.remove(component);
+   }
+
+   @Override
+   public CriticalAnalyzer setCheckTime(long timeout) {
+  this.checkTime = timeout;
+  return this;
+   }
+
+   @Override
+   public long getCheckTime() {
+  if (checkTime == 0) {
+ checkTime = getTimeout() / 2;
+  }
+  return checkTime;
+   }
+
+   @Override
+   public CriticalAnalyzer setTimeout(long timeout) {
+  this.timeout = timeout;
+  return this;
+   }
+
+   @Override
+   public long getTimeout() {
+  if (timeout == 0) {
+ timeout = TimeUnit.MINUTES.toMillis(2);
+  }
+  return timeout;
+   }
+
+   @Override
+   public CriticalAnalyzer addAction(CriticalAction action) {
+  this.actions.add(action);
+  return this;
+   }
+
+   @Override
+   public void check() {
+  boolean retry = true;
+  while (retry) {
+ try {
+for (CriticalComponent component : components) {
+
+   int pathReturned = component.isExpired(timeout);
+   if (pathReturned >= 0) {
+  fireAction(component, pathReturned);
+  // no need to keep running if there's already a 
component failed
+  return;
+   }
+}
+retry = false; // got to the end of the list, no need to retry
+ } catch (ConcurrentModificationException dontCare) {
+// lets retry on the loop
+ }
+  }
+   }
+
+   private void fireAction(CriticalComponent component, int path) {
+  for (CriticalAction action: actions) {
+ try {
+action.run(component, path);
+ } catch (Throwable e) {
+logger.warn(e.getMessage(), e);
+ }
+  }
+   }
+
+   @Override
+   public void start() {
+
+  if (!running.tryAcquire()) {
+ // already running
+ return;
+  }
+
+  // we are not using any Thread Pool or any Scheduled Executors from 
the ArtemisServer
+  // as that would defeat the purpose,
+  // as in

[jira] [Commented] (ARTEMIS-1308) Client Acknowledge not performant

2017-08-06 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-1308:
-

Github user franz1981 commented on the issue:

https://github.com/apache/activemq-artemis/pull/1428
  
@michaelandrepearce I've made a fix for that test here: 
https://github.com/apache/activemq-artemis/pull/1444


> Client Acknowledge not performant
> -
>
> Key: ARTEMIS-1308
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1308
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.2.0
>Reporter: Michael Andre Pearce
>Assignee: Michael Andre Pearce
>Priority: Critical
> Fix For: 2.3.0
>
>
> Artemis recommendation in docs is to use CLIENT_ACKNOWLEDGE instead of 
> AUTO_ACKNOWLEDGE, on perf testing it seems this is not the case.
> On checking code it seems the reason for this is because ActiveMQMessage 
> acknowledge actually calls session.commit, causing a full session commit all 
> the time.
> On checking Core API, calling message.acknowledge it seems to behave as 
> expected, as such believe this to be an issue in JMS api wrapper, that it 
> should just be delegating to the ClientMessage.acknowledge method and this is 
> the cause of the perf issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (ARTEMIS-1326) testTimeOnTimedBuffer incorrect timeout count

2017-08-06 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on ARTEMIS-1326:
-

GitHub user franz1981 opened a pull request:

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

ARTEMIS-1326 testTimeOnTimedBuffer incorrect timeout count

The original test wasn't correctly counting the timeout expiration during 
the burst of writes.
Now the test is considering the timeout expirations between 2 consecutive 
bursts of writes in order to verify if the timeout is correctly handled.

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

$ git pull https://github.com/franz1981/activemq-artemis ARTEMIS-1326

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

https://github.com/apache/activemq-artemis/pull/1444.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 #1444


commit 3d29886724d4b506494a392c20973084af84766b
Author: Francesco Nigro 
Date:   2017-08-06T09:55:41Z

ARTEMIS-1326 testTimeOnTimedBuffer incorrect timeout count




> testTimeOnTimedBuffer incorrect timeout count
> -
>
> Key: ARTEMIS-1326
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1326
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Francesco Nigro
>Assignee: Francesco Nigro
>
> The test isn't evaluating the timeout expiration while writing in batches 
> into the TimedBuffer



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (ARTEMIS-1326) testTimeOnTimedBuffer incorrect timeout count

2017-08-06 Thread Francesco Nigro (JIRA)

Francesco Nigro created ARTEMIS-1326:


 Summary: testTimeOnTimedBuffer incorrect timeout count
 Key: ARTEMIS-1326
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1326
 Project: ActiveMQ Artemis
  Issue Type: Bug
Reporter: Francesco Nigro
Assignee: Francesco Nigro


The test isn't evaluating the timeout expiration while writing in batches into 
the TimedBuffer



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (ARTEMIS-1308) Client Acknowledge not performant

[jira] [Commented] (ARTEMIS-1324) Critical Analysis and deadlock detection on broker

[jira] [Commented] (ARTEMIS-1324) Critical Analysis and deadlock detection on broker

[jira] [Commented] (ARTEMIS-1324) Critical Analysis and deadlock detection on broker

[jira] [Commented] (ARTEMIS-1324) Critical Analysis and deadlock detection on broker

[jira] [Commented] (ARTEMIS-1324) Critical Analysis and deadlock detection on broker

[jira] [Commented] (ARTEMIS-1308) Client Acknowledge not performant

[jira] [Commented] (ARTEMIS-1326) testTimeOnTimedBuffer incorrect timeout count

[jira] [Created] (ARTEMIS-1326) testTimeOnTimedBuffer incorrect timeout count

10 matches

Site Navigation

Mail list logo

Footer information