wildfly-10.1.0.Final integration for MQTT not working

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

wildfly-10.1.0.Final integration for MQTT not working

thoutekier
Hi,

I'm trying to get MQTT working on wildfly-10.1.0.Final. WF10 contains
activemq embedded and should, as advertise, support MQTT.
However, I hit a nullpointerexception why I try to connect with a MQTT
client.
I already posted this in the wildfly-forum:
https://developer.jboss.org/message/976007
<https://developer.jboss.org/message/976007>  

Anyone has any experience using MQTT in combination with embedded activemq
on wildfly?
Any input is appreciated
Thanks!
Thomas



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Reply | Threaded
Open this post in threaded view
|

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

Tim Bain
It appears from your stack trace that this is embedded Artemis, not
embedded ActiveMQ 5.x. Is that right?

On Sep 13, 2017 4:36 AM, "[hidden email]" <
[hidden email]> wrote:

> Hi,
>
> I'm trying to get MQTT working on wildfly-10.1.0.Final. WF10 contains
> activemq embedded and should, as advertise, support MQTT.
> However, I hit a nullpointerexception why I try to connect with a MQTT
> client.
> I already posted this in the wildfly-forum:
> https://developer.jboss.org/message/976007
> <https://developer.jboss.org/message/976007>
>
> Anyone has any experience using MQTT in combination with embedded activemq
> on wildfly?
> Any input is appreciated
> Thanks!
> Thomas
>
>
>
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-
> f2341805.html
>
Reply | Threaded
Open this post in threaded view
|

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

aragoubi
In reply to this post by thoutekier
Reply | Threaded
Open this post in threaded view
|

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

Martyn Taylor
This is using a very old version of Artemis.  I would recommend you bump
the Artemis dependency version to at least the latest version of 1.x
 (currently 1.5.5).

On Wed, Sep 13, 2017 at 1:40 PM, aragoubi <[hidden email]> wrote:

> I got the same problem, I think it's not yet implemented.
> https://developer.jboss.org/message/974758#974758
> <https://developer.jboss.org/message/974758#974758>
>
>
>
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-
> f2341805.html
>
Reply | Threaded
Open this post in threaded view
|

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

thoutekier
Thanks for the input!
Yes indeed, it seems to be embedded artemis. It is not obvious to me what
the difference is between ActiveMQ and ActiveMQ artemis. The names are
sometimes interchanged, so it seems.

It's possible that it is an old version. Probably 1.1.0. That is however not
very clear if you check the releasenotes of WF10:
http://wildfly.org/news/2016/01/29/WildFly10-Released/

I will try and upgrade, but I'm not sure if that will be possible in WF10.
Wildlfy 11 seems to use artemis 1.5.5. Would that be a better fit for MQTT?





--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Reply | Threaded
Open this post in threaded view
|

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

thoutekier
In reply to this post by Martyn Taylor
Martyn Taylor wrote
> This is using a very old version of Artemis.  I would recommend you bump
> the Artemis dependency version to at least the latest version of 1.x
>  (currently 1.5.5).

Hi Martyn,

I just tried that: I upgraded the artemis-implementation in Wildfly-10 to
1.5.5 (I took the artemis-module as it is packaged in wilfdly-11-RC1. I also
had to upgrade netty.io to 4.1.19 instead of 4.0.33 to make it work)
I hit the exact same error:

/Sep:13,15:55:11,656 WARNING (:Thread-2 (activemq-netty-threads):)
[io.netty.channel.DefaultChannelPipeline] An exceptionCaught() event was
fired, and it reached at the tail of the pipeline. It usually means the last
handler in the pipeline did not handle the exception.:
io.netty.handler.codec.DecoderException: java.lang.NullPointerException
        at
io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:442)
[netty-all-4.1.9.Final.jar:4.1.9.Final]
        at
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:248)
[netty-all-4.1.9.Final.jar:4.1.9.Final]
        at
org.apache.activemq.artemis.core.protocol.ProtocolHandler$ProtocolDecoder.channelRead(ProtocolHandler.java:128)
[artemis-server-1.5.5.jbossorg-007.jar:1.5.5.jbossorg-007]
        at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
[netty-all-4.1.9.Final.jar:4.1.9.Final]
        at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
[netty-all-4.1.9.Final.jar:4.1.9.Final]
        at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
[netty-all-4.1.9.Final.jar:4.1.9.Final]
        at
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1334)
[netty-all-4.1.9.Final.jar:4.1.9.Final]
        at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
[netty-all-4.1.9.Final.jar:4.1.9.Final]
        at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
[netty-all-4.1.9.Final.jar:4.1.9.Final]
        at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:926)
[netty-all-4.1.9.Final.jar:4.1.9.Final]
        at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:134)
[netty-all-4.1.9.Final.jar:4.1.9.Final]
        at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:624)
[netty-all-4.1.9.Final.jar:4.1.9.Final]
        at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:559)
[netty-all-4.1.9.Final.jar:4.1.9.Final]
        at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:476)
[netty-all-4.1.9.Final.jar:4.1.9.Final]
        at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:438)
[netty-all-4.1.9.Final.jar:4.1.9.Final]
        at
io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858)
[netty-all-4.1.9.Final.jar:4.1.9.Final]
        at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_112]
Caused by: java.lang.NullPointerException
        at
org.apache.activemq.artemis.core.protocol.ProtocolHandler$ProtocolDecoder.decode(ProtocolHandler.java:181)
[artemis-server-1.5.5.jbossorg-007.jar:1.5.5.jbossorg-007]
        at
io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411)
[netty-all-4.1.9.Final.jar:4.1.9.Final]
        ... 16 more/

Any idea I can try next? Any suggestion is appreciated. Thanks!



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Reply | Threaded
Open this post in threaded view
|

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

Tim Bain
In reply to this post by thoutekier
The plan/hope is that Artemis will become ActiveMQ 6.x succeeding ActiveMQ
5.x, but for right now they are sibling products within the overarching
ActiveMQ project.

On Sep 13, 2017 7:03 AM, "[hidden email]" <
[hidden email]> wrote:

> Thanks for the input!
> Yes indeed, it seems to be embedded artemis. It is not obvious to me what
> the difference is between ActiveMQ and ActiveMQ artemis. The names are
> sometimes interchanged, so it seems.
>
> It's possible that it is an old version. Probably 1.1.0. That is however
> not
> very clear if you check the releasenotes of WF10:
> http://wildfly.org/news/2016/01/29/WildFly10-Released/
>
> I will try and upgrade, but I'm not sure if that will be possible in WF10.
> Wildlfy 11 seems to use artemis 1.5.5. Would that be a better fit for MQTT?
>
>
>
>
>
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-
> f2341805.html
>
Reply | Threaded
Open this post in threaded view
|

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

thoutekier
As suggested on the jboss-forum, I created an issue for this on both wildfly
and artemis projects, with steps to reproduce the problem.
https://issues.apache.org/jira/browse/ARTEMIS-1430
https://issues.jboss.org/browse/WFLY-9372





--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Reply | Threaded
Open this post in threaded view
|

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

Justin Bertram
Have you tried using standalone Artemis 2.3.0?


Justin

On Thu, Sep 21, 2017 at 2:01 PM, thoutekier <[hidden email]>
wrote:

> As suggested on the jboss-forum, I created an issue for this on both
> wildfly
> and artemis projects, with steps to reproduce the problem.
> https://issues.apache.org/jira/browse/ARTEMIS-1430
> https://issues.jboss.org/browse/WFLY-9372
>
>
>
>
>
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-
> f2341805.html
>
Reply | Threaded
Open this post in threaded view
|

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

thoutekier
No, I haven't actually.
It is not usefull for me. I don't want an 'out-of-process' MQTT broker, when
I have one available in the wildfly that I'm using.

Thomas



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Reply | Threaded
Open this post in threaded view
|

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

Justin Bertram
I guess my point is that you *don't* have one available in the Wildfly that
you're using due to these issues you're running into (regardless of whether
or not they are legitimate bugs).

Wildfly embeds Artemis in order to fulfill the JMS implementation
requirement of Java EE.  Wildfly isn't trying provide a multi-protocol
broker, per se, so there's little to no testing around that kind of
integration.


Justin

On Thu, Sep 21, 2017 at 2:11 PM, thoutekier <[hidden email]>
wrote:

> No, I haven't actually.
> It is not usefull for me. I don't want an 'out-of-process' MQTT broker,
> when
> I have one available in the wildfly that I'm using.
>
> Thomas
>
>
>
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-
> f2341805.html
>
Reply | Threaded
Open this post in threaded view
|

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

thoutekier
yes, I understand. It certainly looks like that :-)
But, since artemis has mqtt-support (according the documentation anyway, as
I said I didn't try it myself), and since the protocols (stomp, amps, ...)
in artemis are pluggable, it might just work in wildfly too.

I must say that the wildfly documentation doesn't explicitly mentions MQTT,
but the protocol and codec-implementation for that particular
artemis-wildfly integration version are available.
(https://mvnrepository.com/artifact/org.apache.activemq/artemis-mqtt-protocol/1.1.0.wildfly-017
and
https://mvnrepository.com/artifact/io.netty/netty-codec-mqtt/5.0.0.Alpha2
So I guess it is supposed to work on wildfly too.



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Reply | Threaded
Open this post in threaded view
|

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

Justin Bertram
To be clear, I would expect it to work.  There's no explicit reason MQTT
shouldn't work in Artemis embedded in Wildfly.  There's a bug somewhere
preventing it from working.  I'm just trying to give you options to
work-around the issue given I don't have a lot of motivation to fix it
since there is ostensibly a fairly simple work-around (i.e. use Artemis
standalone).


Justin

On Fri, Sep 22, 2017 at 1:45 AM, thoutekier <[hidden email]>
wrote:

> yes, I understand. It certainly looks like that :-)
> But, since artemis has mqtt-support (according the documentation anyway, as
> I said I didn't try it myself), and since the protocols (stomp, amps, ...)
> in artemis are pluggable, it might just work in wildfly too.
>
> I must say that the wildfly documentation doesn't explicitly mentions MQTT,
> but the protocol and codec-implementation for that particular
> artemis-wildfly integration version are available.
> (https://mvnrepository.com/artifact/org.apache.activemq/
> artemis-mqtt-protocol/1.1.0.wildfly-017
> and
> https://mvnrepository.com/artifact/io.netty/netty-codec-mqtt/5.0.0.Alpha2
> So I guess it is supposed to work on wildfly too.
>
>
>
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-
> f2341805.html
>
Reply | Threaded
Open this post in threaded view
|

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

thoutekier
Hi Justin,

I appreciate the suggestion, but I don't consider that an option.
What I want to do is expose the queues and topic of the internal jms-bus
over MQTT. JMS is used extensively in my application and I currently expose
access to those messages outside of the server using a http-wrapper: a
pub/sub implementation using long-polling.
I want to replace that with mqtt.
Adding an external broker next to wildfly just to have MQTT-support, adds
too much complexity:  I'll have to synchronize the wildfly-internal jms-bus
with this external one, in both directions.
Or, alternatively, don't use the internal artemis anymore, and only rely on
the external. That is probably even more work.
Deployment doesn't become easier either.
So you see, even if it is possible, it isn't all that simple, so it doesn't
really help me :-)

Bottomline is, if I can't get MQTT up and running in wildfly, I won't be
using it at all.
Thomas




--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Reply | Threaded
Open this post in threaded view
|

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

Justin Bertram
> Or, alternatively, don't use the internal artemis anymore, and only rely
on the external. That is probably even more work.

Assuming you're using managed resources (e.g. MDBs for consuming and
pooled-connection-factory for sending) and don't have connection
configuration details littered through your code then switching completely
to an external broker should actually be pretty simple - just a matter of
changing a bit of XML.

In any case, I think the underlying issue with MQTT + Wildfly is probably
fairly simple.  It's just a matter of setting aside some time to reproduce
the issue and dig into it.  You could, of course, crack open the broker in
the debugger yourself and take a peek.  This is open-source after all.
Contributions are always welcome.


Justin

On Fri, Sep 22, 2017 at 7:17 AM, thoutekier <[hidden email]>
wrote:

> Hi Justin,
>
> I appreciate the suggestion, but I don't consider that an option.
> What I want to do is expose the queues and topic of the internal jms-bus
> over MQTT. JMS is used extensively in my application and I currently expose
> access to those messages outside of the server using a http-wrapper: a
> pub/sub implementation using long-polling.
> I want to replace that with mqtt.
> Adding an external broker next to wildfly just to have MQTT-support, adds
> too much complexity:  I'll have to synchronize the wildfly-internal jms-bus
> with this external one, in both directions.
> Or, alternatively, don't use the internal artemis anymore, and only rely on
> the external. That is probably even more work.
> Deployment doesn't become easier either.
> So you see, even if it is possible, it isn't all that simple, so it doesn't
> really help me :-)
>
> Bottomline is, if I can't get MQTT up and running in wildfly, I won't be
> using it at all.
> Thomas
>
>
>
>
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-
> f2341805.html
>
Reply | Threaded
Open this post in threaded view
|

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

Tim Bain
In reply to this post by thoutekier
I think there's still value in you determining whether this use case works
in standalone Artemis. If your existing code works as expected against
standalone Artemis but not against Artemis embedded in Wildfly, you'll have
demonstrated that the problem is within Wildfly, which might make it more
likely that they will fix the Wildfly bug you submitted. If not, then
either there's a bug in the Artemis code or a bug in your MQTT code, and
we'd need to figure out which one. If it was a bug in the Artemis code, the
devs are very responsive, so you'd get a fix quickly, and if it's in your
code, then you control your own destiny. But it all starts with you
determining whether your code works with standalone Artemis.

Note that I'm not proposing that you have to run that way in production, or
that you have to convert every single piece of your application to use the
standalone broker; just do enough to show whether it works or not.

Tim

On Sep 22, 2017 6:18 AM, "thoutekier" <[hidden email]> wrote:

> Hi Justin,
>
> I appreciate the suggestion, but I don't consider that an option.
> What I want to do is expose the queues and topic of the internal jms-bus
> over MQTT. JMS is used extensively in my application and I currently expose
> access to those messages outside of the server using a http-wrapper: a
> pub/sub implementation using long-polling.
> I want to replace that with mqtt.
> Adding an external broker next to wildfly just to have MQTT-support, adds
> too much complexity:  I'll have to synchronize the wildfly-internal jms-bus
> with this external one, in both directions.
> Or, alternatively, don't use the internal artemis anymore, and only rely on
> the external. That is probably even more work.
> Deployment doesn't become easier either.
> So you see, even if it is possible, it isn't all that simple, so it doesn't
> really help me :-)
>
> Bottomline is, if I can't get MQTT up and running in wildfly, I won't be
> using it at all.
> Thomas
>
>
>
>
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-
> f2341805.html
>
Reply | Threaded
Open this post in threaded view
|

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

thoutekier
* 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 exceptionCaught() event was fired,
and it reached at the tail of the pipeline. It usually means the last
handler in the pipeline did not handle the exception.:
io.netty.handler.codec.DecoderException: java.lang.NoSuchFieldError:
INSTANCE
        at
io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:442)
        at
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:248)
        at
org.apache.activemq.artemis.core.protocol.ProtocolHandler$ProtocolDecoder.channelRead(ProtocolHandler.java:128)
        at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
        at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
        at
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
        at
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1334)
        at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
        at
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
        at
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:926)
        at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:134)
        at
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:624)
        at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:559)
        at
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:476)
        at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:438)
        at
io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858)
        at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NoSuchFieldError: INSTANCE
        at
org.apache.activemq.artemis.core.protocol.mqtt.MQTTProtocolManager.addChannelHandlers(MQTTProtocolManager.java:113)
        at
org.apache.activemq.artemis.core.protocol.ProtocolHandler$ProtocolDecoder.decode(ProtocolHandler.java:181)
        at
io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411)
        ... 16 more


So it seems that it is in fact a problem in Wildfly.
Any idea where I could find the code for the artemis-integration in wildly?
I don't find any branch/tag on
https://github.com/apache/activemq-artemis/tree/1.x/artemis-protocols/artemis-mqtt-protocol
for "artemis-mqtt-protocol-1.1.0.wildfly-017"





--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Reply | Threaded
Open this post in threaded view
|

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

Justin Bertram
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 would be getting this exception unless there was something odd
going on with the classloading or something.

Also, the integration instructions in the WFLY-9372 JIRA say to
copy netty-codec-mqtt-5.0.0.Alpha2.jar into
the org.apache.activemq.artemis.protocol.mqtt module, but that shouldn't be
necessary in Wildfly 11.0.0.CR1 as the io.netty module already contains
those classes.  I also don't see why
the org.apache.activemq.artemis.protocol.mqtt module would need
dependencies on javax.jms.api, javax.api, or org.slf4j.


Justin

[1] https://github.com/wildfly/wildfly (see the "messaging-activemq" module)

On Tue, Sep 26, 2017 at 10:17 AM, thoutekier <[hidden email]>
wrote:

> * 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 exceptionCaught() event was fired,
> and it reached at the tail of the pipeline. It usually means the last
> handler in the pipeline did not handle the exception.:
> io.netty.handler.codec.DecoderException: java.lang.NoSuchFieldError:
> INSTANCE
>         at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(
> ByteToMessageDecoder.java:442)
>         at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(
> ByteToMessageDecoder.java:248)
>         at
> org.apache.activemq.artemis.core.protocol.ProtocolHandler$
> ProtocolDecoder.channelRead(ProtocolHandler.java:128)
>         at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(
> AbstractChannelHandlerContext.java:362)
>         at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(
> AbstractChannelHandlerContext.java:348)
>         at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(
> AbstractChannelHandlerContext.java:340)
>         at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(
> DefaultChannelPipeline.java:1334)
>         at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(
> AbstractChannelHandlerContext.java:362)
>         at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(
> AbstractChannelHandlerContext.java:348)
>         at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(
> DefaultChannelPipeline.java:926)
>         at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(
> AbstractNioByteChannel.java:134)
>         at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(
> NioEventLoop.java:624)
>         at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(
> NioEventLoop.java:559)
>         at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(
> NioEventLoop.java:476)
>         at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:438)
>         at
> io.netty.util.concurrent.SingleThreadEventExecutor$5.
> run(SingleThreadEventExecutor.java:858)
>         at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NoSuchFieldError: INSTANCE
>         at
> org.apache.activemq.artemis.core.protocol.mqtt.MQTTProtocolManager.
> addChannelHandlers(MQTTProtocolManager.java:113)
>         at
> org.apache.activemq.artemis.core.protocol.ProtocolHandler$
> ProtocolDecoder.decode(ProtocolHandler.java:181)
>         at
> io.netty.handler.codec.ByteToMessageDecoder.callDecode(
> ByteToMessageDecoder.java:411)
>         ... 16 more
>
>
> So it seems that it is in fact a problem in Wildfly.
> Any idea where I could find the code for the artemis-integration in wildly?
> I don't find any branch/tag on
> https://github.com/apache/activemq-artemis/tree/1.x/
> artemis-protocols/artemis-mqtt-protocol
> for "artemis-mqtt-protocol-1.1.0.wildfly-017"
>
>
>
>
>
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-
> f2341805.html
>
Reply | Threaded
Open this post in threaded view
|

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

Justin Bertram
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 <[hidden email]>
wrote:

> 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 would be getting this exception unless there was something
> odd going on with the classloading or something.
>
> Also, the integration instructions in the WFLY-9372 JIRA say to
> copy netty-codec-mqtt-5.0.0.Alpha2.jar into the org.apache.activemq.artemis.protocol.mqtt
> module, but that shouldn't be necessary in Wildfly 11.0.0.CR1 as the
> io.netty module already contains those classes.  I also don't see why
> the org.apache.activemq.artemis.protocol.mqtt module would need
> dependencies on javax.jms.api, javax.api, or org.slf4j.
>
>
> Justin
>
> [1] https://github.com/wildfly/wildfly (see the "messaging-activemq"
> module)
>
> On Tue, Sep 26, 2017 at 10:17 AM, thoutekier <[hidden email]>
> wrote:
>
>> * 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 exceptionCaught() event was fired,
>> and it reached at the tail of the pipeline. It usually means the last
>> handler in the pipeline did not handle the exception.:
>> io.netty.handler.codec.DecoderException: java.lang.NoSuchFieldError:
>> INSTANCE
>>         at
>> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteT
>> oMessageDecoder.java:442)
>>         at
>> io.netty.handler.codec.ByteToMessageDecoder.channelRead(Byte
>> ToMessageDecoder.java:248)
>>         at
>> org.apache.activemq.artemis.core.protocol.ProtocolHandler$Pr
>> otocolDecoder.channelRead(ProtocolHandler.java:128)
>>         at
>> io.netty.channel.AbstractChannelHandlerContext.invokeChannel
>> Read(AbstractChannelHandlerContext.java:362)
>>         at
>> io.netty.channel.AbstractChannelHandlerContext.invokeChannel
>> Read(AbstractChannelHandlerContext.java:348)
>>         at
>> io.netty.channel.AbstractChannelHandlerContext.fireChannelRe
>> ad(AbstractChannelHandlerContext.java:340)
>>         at
>> io.netty.channel.DefaultChannelPipeline$HeadContext.
>> channelRead(DefaultChannelPipeline.java:1334)
>>         at
>> io.netty.channel.AbstractChannelHandlerContext.invokeChannel
>> Read(AbstractChannelHandlerContext.java:362)
>>         at
>> io.netty.channel.AbstractChannelHandlerContext.invokeChannel
>> Read(AbstractChannelHandlerContext.java:348)
>>         at
>> io.netty.channel.DefaultChannelPipeline.fireChannelRead(Defa
>> ultChannelPipeline.java:926)
>>         at
>> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.
>> read(AbstractNioByteChannel.java:134)
>>         at
>> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEven
>> tLoop.java:624)
>>         at
>> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimiz
>> ed(NioEventLoop.java:559)
>>         at
>> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEve
>> ntLoop.java:476)
>>         at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:438)
>>         at
>> io.netty.util.concurrent.SingleThreadEventExecutor$5.run(
>> SingleThreadEventExecutor.java:858)
>>         at java.lang.Thread.run(Thread.java:745)
>> Caused by: java.lang.NoSuchFieldError: INSTANCE
>>         at
>> org.apache.activemq.artemis.core.protocol.mqtt.MQTTProtocolM
>> anager.addChannelHandlers(MQTTProtocolManager.java:113)
>>         at
>> org.apache.activemq.artemis.core.protocol.ProtocolHandler$Pr
>> otocolDecoder.decode(ProtocolHandler.java:181)
>>         at
>> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteT
>> oMessageDecoder.java:411)
>>         ... 16 more
>>
>>
>> So it seems that it is in fact a problem in Wildfly.
>> Any idea where I could find the code for the artemis-integration in
>> wildly?
>> I don't find any branch/tag on
>> https://github.com/apache/activemq-artemis/tree/1.x/artemis-
>> protocols/artemis-mqtt-protocol
>> for "artemis-mqtt-protocol-1.1.0.wildfly-017"
>>
>>
>>
>>
>>
>> --
>> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805
>> .html
>>
>
>
Reply | Threaded
Open this post in threaded view
|

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

Justin Bertram
Here's my module.xml:

<module xmlns="urn:jboss:module:1.5"
name="org.apache.activemq.artemis.protocol.mqtt">
    <resources>
        <resource-root path="artemis-mqtt-protocol-1.5.5.jbossorg-007.jar"
/>
    </resources>

    <dependencies>
        <module name="io.netty"/>
        <!-- required to load ActiveMQ protocol SPI -->
        <module name="org.apache.activemq.artemis"/>
        <module name="org.jboss.logging"/>
    </dependencies>
</module>

I added this to standalone-full.xml:

    <profile>
        ...
        <subsystem xmlns="urn:jboss:domain:messaging-activemq:2.0">
            ...
                <security enabled="false"/>
                ...
                <remote-acceptor name="mqtt-acceptor"
socket-binding="mqtt">
                 <param name="protocols" value="MQTT"/>
                </remote-acceptor>
            ...
        </subsystem>
        ...
    </profile>
    ...
    <socket-binding-group name="standard-sockets"
default-interface="public"
port-offset="${jboss.socket.binding.port-offset:0}">
        ...
        <socket-binding name="mqtt" port="1883"/>
    </socket-binding-group>


Justin


On Tue, Sep 26, 2017 at 11:18 AM, Justin Bertram <[hidden email]>
wrote:

> 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 <[hidden email]>
> wrote:
>
>> 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 would be getting this exception unless there was something
>> odd going on with the classloading or something.
>>
>> Also, the integration instructions in the WFLY-9372 JIRA say to copy
>> netty-codec-mqtt-5.0.0.Alpha2.jar into the org.apache.activemq.artemis.protocol.mqtt
>> module, but that shouldn't be necessary in Wildfly 11.0.0.CR1 as the
>> io.netty module already contains those classes.  I also don't see why
>> the org.apache.activemq.artemis.protocol.mqtt module would need
>> dependencies on javax.jms.api, javax.api, or org.slf4j.
>>
>>
>> Justin
>>
>> [1] https://github.com/wildfly/wildfly (see the "messaging-activemq"
>> module)
>>
>> On Tue, Sep 26, 2017 at 10:17 AM, thoutekier <[hidden email]>
>> wrote:
>>
>>> * 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.DefaultChann
>>> elPipeline]
>>> (Thread-2 (activemq-netty-threads)) An exceptionCaught() event was fired,
>>> and it reached at the tail of the pipeline. It usually means the last
>>> handler in the pipeline did not handle the exception.:
>>> io.netty.handler.codec.DecoderException: java.lang.NoSuchFieldError:
>>> INSTANCE
>>>         at
>>> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteT
>>> oMessageDecoder.java:442)
>>>         at
>>> io.netty.handler.codec.ByteToMessageDecoder.channelRead(Byte
>>> ToMessageDecoder.java:248)
>>>         at
>>> org.apache.activemq.artemis.core.protocol.ProtocolHandler$Pr
>>> otocolDecoder.channelRead(ProtocolHandler.java:128)
>>>         at
>>> io.netty.channel.AbstractChannelHandlerContext.invokeChannel
>>> Read(AbstractChannelHandlerContext.java:362)
>>>         at
>>> io.netty.channel.AbstractChannelHandlerContext.invokeChannel
>>> Read(AbstractChannelHandlerContext.java:348)
>>>         at
>>> io.netty.channel.AbstractChannelHandlerContext.fireChannelRe
>>> ad(AbstractChannelHandlerContext.java:340)
>>>         at
>>> io.netty.channel.DefaultChannelPipeline$HeadContext.channelR
>>> ead(DefaultChannelPipeline.java:1334)
>>>         at
>>> io.netty.channel.AbstractChannelHandlerContext.invokeChannel
>>> Read(AbstractChannelHandlerContext.java:362)
>>>         at
>>> io.netty.channel.AbstractChannelHandlerContext.invokeChannel
>>> Read(AbstractChannelHandlerContext.java:348)
>>>         at
>>> io.netty.channel.DefaultChannelPipeline.fireChannelRead(Defa
>>> ultChannelPipeline.java:926)
>>>         at
>>> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.re
>>> ad(AbstractNioByteChannel.java:134)
>>>         at
>>> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEven
>>> tLoop.java:624)
>>>         at
>>> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimiz
>>> ed(NioEventLoop.java:559)
>>>         at
>>> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEve
>>> ntLoop.java:476)
>>>         at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:438)
>>>         at
>>> io.netty.util.concurrent.SingleThreadEventExecutor$5.run(Sin
>>> gleThreadEventExecutor.java:858)
>>>         at java.lang.Thread.run(Thread.java:745)
>>> Caused by: java.lang.NoSuchFieldError: INSTANCE
>>>         at
>>> org.apache.activemq.artemis.core.protocol.mqtt.MQTTProtocolM
>>> anager.addChannelHandlers(MQTTProtocolManager.java:113)
>>>         at
>>> org.apache.activemq.artemis.core.protocol.ProtocolHandler$Pr
>>> otocolDecoder.decode(ProtocolHandler.java:181)
>>>         at
>>> io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteT
>>> oMessageDecoder.java:411)
>>>         ... 16 more
>>>
>>>
>>> So it seems that it is in fact a problem in Wildfly.
>>> Any idea where I could find the code for the artemis-integration in
>>> wildly?
>>> I don't find any branch/tag on
>>> https://github.com/apache/activemq-artemis/tree/1.x/artemis-
>>> protocols/artemis-mqtt-protocol
>>> for "artemis-mqtt-protocol-1.1.0.wildfly-017"
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805
>>> .html
>>>
>>
>>
>
12