Re: java.lang.IllegalStateException: Timer already cancelled

As luck would have it, I ran into an instance of this issue myself (but against 5.10.0) after we were unable to allocate a thread because we hit the OS's process (thread) limit. Several other people commented that the same thing happened to them afte

Re: Kahadb index updates taking too much time on ActiveMQ 5.11

I've not seen anyone describe this set of symptoms, so I don't have anything to suggest right from the outset, but I may be able to help you figure out what's going on. Could you attach a CPU sampler such as JVisualVM to the broker process and capture CPU sampling (not profiling if this is an oper

Re: Slow consumer acknowledgment timeout

nvm, I got it. read the docs, son. :-) -- Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: wildfly-10.1.0.Final integration for MQTT not working

> Any chance the WF10-problem could also be a configuration error on my end? I think so. > So my question is basically: do you see the same NPE when connecting to WF-10.1.0 No. I don't see the NPE when using Wildfly 10.1.0.Final. I used the same config as before, but included the Netty MQTT co

Re: wildfly-10.1.0.Final integration for MQTT not working

The Wildfly tests, and the wildfly dev team are focused on JEE (J2EE or whatever is names these days). The Wildfly team is not doing any testing on any other protocols or advanced messaging features available in other protocols. Artemis in wildfly is meant to provide wildfly with the requirement f

Re: wildfly-10.1.0.Final integration for MQTT not working

Justin, If I use your configuration on WF-11, I don't have the errors anymore. So I probably messed up there. However, I don't succeed in connecting with MQTT-box (connection-error). Connecting to the standalone-artemis works without any issue. I assume this will be a problem on my end, I haven't

Re: java.lang.IllegalStateException: Timer already cancelled

Hi I've exactly this problem with ActiveMQ 5.10.2 server I'm running Old karaf 2.2.2 with camel 2.8.1 (like servicemix 4) the camel component compatible with this version of camel is activemq-camel 5.5.1 A+JYT -- Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: wildfly-10.1.0.Final integration for MQTT not working

I also just tested with the MQTTBox Chrome plugin and it worked fine as well. Justin On Tue, Sep 26, 2017 at 11:28 AM, Justin Bertram wrote: > Here's my module.xml: > > > > /> > > > > > > > > > > > I added this to standalone-fu

Re: wildfly-10.1.0.Final integration for MQTT not working

Here's my module.xml: I added this to standalone-full.xml: ... ... ... ... ...

Re: wildfly-10.1.0.Final integration for MQTT not working

FWIW I just integrated MQTT with Wildfly 11.0.0.CR1 and ran org.apache.activemq.artemis.tests.integration.mqtt.imported.MQTTTest#testSendAndReceiveMQTT against it and everything worked. Justin On Tue, Sep 26, 2017 at 10:55 AM, Justin Bertram wrote: > The Artemis integration code for Wildfly i

Re: wildfly-10.1.0.Final integration for MQTT not working

The Artemis integration code for Wildfly is in the Wildfly project [1]. The problem you hit in Wildfly 11.0.0.CR1 looks odd to me. The class io.netty.handler.codec.mqtt.MqttEncoder from Netty 4.1.9.Final (which ships in Wildfly) does, in fact, contain the field "INSTANCE" so I'm not sure why you

Re: wildfly-10.1.0.Final integration for MQTT not working

* using artemis-1.1.0 standalone works out-of-the-box: it has by default support for MQTT in the config, and it works if I connect using an MQTT-client * using Wildfly-11.0.0.CR1: 2017-09-26 17:12:25,837 WARNING [io.netty.channel.DefaultChannelPipeline] (Thread-2 (activemq-netty-threads)) An excep

Re: Artemis with JGroups server discovery (live+backup)

> On the other hand I see that org.apache.activemq.artemis.core.server.cluster.impl.BroadcastGroupImpl#broadcastConnectors method is being called constantly (I configured it to be called every second), yet the receiver endpoint there is always null. I'm not exactly sure what you're describing here

Kahadb index updates taking too much time on ActiveMQ 5.11

In production with ActiveMQ 5.11 with multi-kahadb per destination on NFSv4 M|S (Linux 7.1), we're seeing the following log messages intermittently during operations: *Slow KahaDB access: Journal append took: 2 ms, Index update took 16901 ms* Also, on startup, we see the following in our kahadb

Re: Slow consumer acknowledgment timeout

Tim, If, by default, the broker has no slow consumer strategy configured, does that also mean the broker will not publish slow consumer advisory messages? Are the strategy and advisory linked together? If not, under what conditions does the broker publish slow consumer advisories? -- Sent from: