Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 73A10200B5E for ; Wed, 10 Aug 2016 14:37:18 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 72341160A93; Wed, 10 Aug 2016 12:37:18 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 40535160A90 for ; Wed, 10 Aug 2016 14:37:17 +0200 (CEST) Received: (qmail 16258 invoked by uid 500); 10 Aug 2016 12:37:16 -0000 Mailing-List: contact users-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@activemq.apache.org Delivered-To: mailing list users@activemq.apache.org Received: (qmail 16247 invoked by uid 99); 10 Aug 2016 12:37:16 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 10 Aug 2016 12:37:16 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 7AE1A1804B4 for ; Wed, 10 Aug 2016 12:37:15 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.282 X-Spam-Level: *** X-Spam-Status: No, score=3.282 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=2, KAM_BADIPHTTP=2, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=disabled Received: from mx2-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id vDPTiN2y1cGU for ; Wed, 10 Aug 2016 12:37:08 +0000 (UTC) Received: from mail-it0-f54.google.com (mail-it0-f54.google.com [209.85.214.54]) by mx2-lw-eu.apache.org (ASF Mail Server at mx2-lw-eu.apache.org) with ESMTPS id 85DCB5F255 for ; Wed, 10 Aug 2016 12:37:07 +0000 (UTC) Received: by mail-it0-f54.google.com with SMTP id x130so42888438ite.1 for ; Wed, 10 Aug 2016 05:37:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=TRMl6iAJxXvbUrFQuWsboL5SbUdRocxb3sau3pBSOXs=; b=mXNZwszciq43ielfPlGv4Hf7U+UdWp0kptVR3WxUAkBh5QukWBMeMw7wIPfeK4FiJw PHQGNPTBk59psYgft0hE780S/w4IPvU8rpm5eJnNG8qwQ4tT3BprEYpKRuQNqeH3NuTL moHNiPJ5wTOFualsp5kjkWET1muNgmhqo7QbBQpohHgw8rdcqwHvXxzgm8pbfRComNUh t3OklBjM9u4d+ChkM+xO/6CtcjFVkxnBqZ7MryPc7Gh4AzItbSt7nzJHGkK7eYt3YtW0 8CMvXK6JBNf6QI2/57ts21ZrMqgkkIvh6WVrUVnI8EcEisVCdH0S9dvA3sYa/aYwmNgK G8Iw== X-Gm-Message-State: AEkooutEPxbkOtdfUJii0H+1T7sM64mJ8IM08qHDEsXzFy6L/kgmMn6g+lxuyU4SDPRWXynWV1otbAP2YX7gBHBk X-Received: by 10.36.137.139 with SMTP id s133mr2877780itd.93.1470832626170; Wed, 10 Aug 2016 05:37:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.36.205 with HTTP; Wed, 10 Aug 2016 05:37:05 -0700 (PDT) In-Reply-To: References: From: Martyn Taylor Date: Wed, 10 Aug 2016 13:37:05 +0100 Message-ID: Subject: Re: Artemis as multiprotocol broker To: users@activemq.apache.org Content-Type: multipart/alternative; boundary=94eb2c05fc4a3548080539b6e8eb archived-at: Wed, 10 Aug 2016 12:37:18 -0000 --94eb2c05fc4a3548080539b6e8eb Content-Type: text/plain; charset=UTF-8 Hi Luca, The log message you were seeing is due to Artemis not supporting the websocket subprotocol ID that is getting passed in by the client. In my tests this didn't make a difference, the message was logged and the protocol carried on as normal. I see "CONNECTED" being logged in the console and the broker handling MQTT PING packets sent from your client. Which tells me it's all working OK. Perhaps this websocket protocol ID handshake issue is causing problems for your browser. I've sent a fix to handle it properly, I'll let you know once it's merged so you can try it out. Regards Martyn On Wed, Aug 10, 2016 at 8:52 AM, Luca Capra wrote: > Just to close the loop, > the subprotocol name used by the library is *mqtt *for v3.1.1 > > Regards > > 2016-08-10 9:35 GMT+02:00 Luca Capra : > > > Hi Martyn, > > thank you, indeed I corrected the client code (I exported the wrong code > > with some paramters experiments) > > > > I prepared a running example here (output is all in the browser console) > > > > - This run the 1.3.0 version > > http://46.101.120.189/?url=mqtt://api.raptorbox.eu:1883 > > > > - This runs 1.4 snapshot from my pc > > http://46.101.120.189/?url=mqtt://localhost:1883 > > > > > > On the client side I get such error > > Error during WebSocket handshake: Sent non-empty 'Sec-WebSocket-Protocol' > > header but no response was received > > > > and both of them refuse to connect with the same notice on artemis side > > Requested subprotocol(s) not supported: mqttv3.1 > > > > I noticed the library actually set the subprotocol as a constant here for > > broser connections: > > https://github.com/mqttjs/MQTT.js/blob/master/lib/connect/ws.js#L78 > > > > so it may be a library issue / decision. > > > > What I cannot get is to use MQTT as subprotocol modifying the above > > constant to something meaningful for artemis. > > > > Best > > Luca > > > > 2016-08-09 16:30 GMT+02:00 Martyn Taylor : > > > >> Hi Luca, > >> > >> The feature is supported. The issue was how you were configuring your > >> client. > >> > >> There are two versions of MQTT that are supported in Artemis: 3.1 and > >> 3.1.1. In 3.1.1 the protocol handshake (or ID), the first couple of > bytes > >> sent by the client changed. So, you must specify the corresponding > >> version > >> and protocol ID in your client. > >> > >> // For MQTT 3.1.1 this is > >> protocolId: "MQTT" > >> protocolVersion: 4 > >> > >> or > >> > >> // For MQTT 3.1 - old version > >> protocolId: MQIsdp > >> protocolVersion: 3 > >> > >> The issue was that your client was specifying: > >> > >> protocolId: MQTT > >> protocolVersion: 3 > >> > >> This does not match any protocol, hence the error you are seeing. > >> > >> I modified your javascript to configure your client like below and it > >> worked for me. > >> > >> var client = mqtt.connect('ws://localhost:1883', { > >> protocolId: 'MQTT' > >> , protocolVersion: 4 > >> }); > >> > >> Can you update accordingly and let me know if it works. > >> > >> Thanks > >> Martyn > >> > >> On Tue, Aug 9, 2016 at 3:11 PM, Luca Capra > wrote: > >> > >> > Hi Martyn, all > >> > > >> > sorry for taking on from such an old thread, but as of today with > >> > 1.4-SNAPSHOT I've not been able to have MQTT over websocket to work > >> > > >> > I continue to receive a debug notice like this > >> > > >> > - Requested subprotocol(s) not supported: MQTT > >> > - Requested subprotocol(s) not supported: mqttv3.1.1 > >> > - Requested subprotocol(s) not supported: mqtt > >> > - ... many other tentatives > >> > > >> > Is it the subprotcol name that is not matching or is this feature > >> actually > >> > not supported? > >> > > >> > I'm trying to have the broker to talk from a web browser to the broker > >> and > >> > still mqtt over ws seems the best way. > >> > Do you have any suggestion ? > >> > > >> > Thank you! > >> > > >> > > >> > > >> > 2016-05-31 18:50 GMT+02:00 Martyn Taylor : > >> > > >> > > Hi Luca, > >> > > > >> > > You are seeing the error because you are not setting the correct > >> version > >> > > and protocol header in your client. Your client should set: > >> > > > >> > > ProtocolID="MQTT" and ProtocolVersion=4 // 3.1.1 > >> > > or > >> > > ProtocolID="MQlsdp" and ProtocolVersion=3 // 3,1 > >> > > > >> > > Artemis will accept both protocol versions (which are practically > >> > > identical) but both point to the 3.1.1 implementation. Your mileage > >> may > >> > > vary with 3.1. I suggest always using 3.1.1. > >> > > > >> > > line 15853 of your js should be: > >> > > > >> > > var client = mqtt.connect('ws://localhost:1883', { > >> > > protocolId: 'MQTT > >> > > , protocolVersion: 4 > >> > > }); > >> > > > >> > > Instead of: > >> > > > >> > > var client = mqtt.connect('ws://localhost:1883', { > >> > > protocolId: 'MQTT' // or 'MQIsdp' in MQTT 3.1.1 > >> > > , protocolVersion: 4 // or 3 in MQTT 3.1 > >> > > }); // you add a ws:// url here > >> > > > >> > > Note the protocol ID in 3.1.1 is "MQTT". > >> > > > >> > > I made these changes locally and it works fine for me. > >> > > > >> > > Thanks > >> > > Martyn > >> > > > >> > > On Tue, May 31, 2016 at 2:04 PM, Luca Capra > >> > wrote: > >> > > > >> > > > Hi, > >> > > > > >> > > > I tried to setup the mqttjs library and run it in a browser. > >> > > > Unfortunately, it tries to connect over websocket and artemis > cannot > >> > > > recognize the subprotocol > >> > > > > >> > > > The source is here: http://pastebin.com/Jgeijbz9 > >> > > > > >> > > > [Thread-10 (activemq-netty-threads-2076099910)] [DEBUG] > >> > > > io.netty.handler.codec.http.websocketx.WebSocketServerHandshaker > - > >> > [id: > >> > > > 0x8958b0d5, /127.0.0.1:60138 => /127.0.0.1:1883] WebSocket > version > >> V13 > >> > > > server handshake > >> > > > [Thread-10 (activemq-netty-threads-2076099910)] [DEBUG] > >> > > > io.netty.handler.codec.http.websocketx.WebSocketServerHandshaker > - > >> > > > WebSocket version 13 server handshake key: > pJTCBulMMJvyCoIpj2wEPg==, > >> > > > response: 6vRlkIXEqz7ihckJ2TFuB6V9uhY= > >> > > > [Thread-10 (activemq-netty-threads-2076099910)] [DEBUG] > >> > > > io.netty.handler.codec.http.websocketx.WebSocketServerHandshaker > - > >> > > > Requested subprotocol(s) not supported: mqttv3.1 > >> > > > > >> > > > > >> > > > In the latest master the issue with the client disconnecting is > >> still > >> > > > there, but the error message is slightly different. In 1.2 it used > >> to > >> > > work > >> > > > > >> > > > [Thread-3 (activemq-netty-threads-2076099910)] [DEBUG] > >> > > > io.netty.util.internal.JavassistTypeParameterMatcherGenerator - > >> > > Generated: > >> > > > > >> > > > io.netty.util.internal.__matchers__.io.netty.handler. > >> > > codec.mqtt.MqttMessageMatcher > >> > > > [Thread-3 (activemq-netty-threads-2076099910)] [DEBUG] > >> > > > org.apache.activemq.artemis.core.protocol.mqtt - SESSION CREATED: > >> > > > d2cd94e9-3d23-4a85-bb53-53528cd9fcb1 > >> > > > [Thread-3 (activemq-netty-threads-2076099910)] [DEBUG] > >> > > > org.apache.activemq.artemis.core.protocol.mqtt - Bad Message > >> > > Disconnecting > >> > > > Client > >> > > > > >> > > > > >> > > > Thank you > >> > > > > >> > > > Regards > >> > > > Luca > >> > > > > >> > > > > >> > > > 2016-05-27 13:25 GMT+02:00 Luca Capra : > >> > > > > >> > > > > Hi Martyn, > >> > > > > I will bundle the js all in a page for testing. > >> > > > > > >> > > > > I think the js library will try to interact with "mqtt over > >> > websockets" > >> > > > > from the browser. > >> > > > > (See just one line above here, > >> > > > > https://github.com/mqttjs/MQTT.js#contributing) > >> > > > > > >> > > > > Is it supposed to work in Artemis? (.. Nice feature btw!) > >> > > > > > >> > > > > I can either provide you the client wrapped in docker or vagrant > >> vm > >> > if > >> > > it > >> > > > > works for you. > >> > > > > > >> > > > > Thanks > >> > > > > Luca > >> > > > > > >> > > > > > >> > > > > 2016-05-27 11:56 GMT+02:00 Martyn Taylor : > >> > > > > > >> > > > >> Hi Luca, > >> > > > >> > >> > > > >> I had a play around with the JS you supplied but didn't get it > >> > > working. > >> > > > >> Any chance you could browsify the test so I can run it without > >> > having > >> > > a > >> > > > >> NodeJS environment set up, (A bash script would do if that's > >> > > > possible). I > >> > > > >> just need to see the issue in the broker. > >> > > > >> > >> > > > >> Thanks > >> > > > >> > >> > > > >> On Thu, May 26, 2016 at 10:18 AM, Luca Capra < > >> luca.capra@gmail.com> > >> > > > >> wrote: > >> > > > >> > >> > > > >> > Ok, I will double check on the client side. > >> > > > >> > > >> > > > >> > > >> > > > >> > If you have the time, here the test case > >> > > > >> > > >> > > > >> > The nodejs client code > >> > > > >> > https://gist.github.com/muka/b6374610618978948f39d83e5248ff > 7e > >> > > > >> > > >> > > > >> > The broker implementation (raptor-broker) is here (branch > >> artemis) > >> > > > >> > > >> > > > >> > https://github.com/muka/raptor/tree/artemis > >> > > > >> > > >> > > > >> > To run it should just require to mvn install and run the > >> > mainClass. > >> > > It > >> > > > >> > requires artemis modules of 1.3-SNAPSHOT in the local > >> repository.. > >> > > I'm > >> > > > >> > pretty sure you have them already :) > >> > > > >> > > >> > > > >> > It tries to load configurations (avail in repository > ./config) > >> > from > >> > > > >> > /etc/raptor or from system property -DconfigDir= > >> > > > >> > > >> > > > >> > Thank you for the precious help! > >> > > > >> > > >> > > > >> > Regards > >> > > > >> > Luca > >> > > > >> > > >> > > > >> > > >> > > > >> > 2016-05-26 10:42 GMT+02:00 Martyn Taylor >: > >> > > > >> > > >> > > > >> > > Hi Luca, > >> > > > >> > > > >> > > > >> > > Only 3.1.1 is supported in Artemis. We've not tested > against > >> > > older > >> > > > >> > > versions. Could you ensure you are setting the version > >> properly > >> > > in > >> > > > >> your > >> > > > >> > > client. > >> > > > >> > > > >> > > > >> > > Error processing control packet usually means the client is > >> > doing > >> > > > >> > something > >> > > > >> > > wrong. If you send me your test case / reproducer, I will > >> take > >> > a > >> > > > >> look. > >> > > > >> > > > >> > > > >> > > Thanks > >> > > > >> > > Martyn > >> > > > >> > > > >> > > > >> > > On Thu, May 26, 2016 at 9:06 AM, Luca Capra < > >> > luca.capra@gmail.com > >> > > > > >> > > > >> > wrote: > >> > > > >> > > > >> > > > >> > > > Hi Martyn, > >> > > > >> > > > thank you for your feedback! > >> > > > >> > > > > >> > > > >> > > > I had in fact two different acceptor on my broker.xml. > I'm > >> now > >> > > > using > >> > > > >> > just > >> > > > >> > > > one now. I've also moved to latest master 1.3-SNAPSHOT > from > >> > git > >> > > > >> > > > > >> > > > >> > > > I noticed I get this exception now on connection via mqtt > >> > > > >> > > > > >> > > > >> > > > WARN: Error processing Control Packet, Disconnecting > >> Client2 > >> > > > >> > > > > >> > > > >> > > > From the debugger I can see it is an > >> ArrayOutOfBoundException > >> > > > which > >> > > > >> > > happens > >> > > > >> > > > somewhere around ctx.flush() in MqttProtocolHandler. > >> > sendConnack > >> > > > >> > > > > >> > > > >> > > > The client is mqttjs a nodejs based module implementing 3 > >> -> > >> > > 3.1.1 > >> > > > >> mqtt > >> > > > >> > > > version > >> > > > >> > > > > >> > > > >> > > > I'm using a custom SecurityManager, but should not be at > >> the > >> > > cause > >> > > > >> of > >> > > > >> > > such > >> > > > >> > > > issue > >> > > > >> > > > > >> > > > >> > > > Need to investigate better > >> > > > >> > > > > >> > > > >> > > > Best > >> > > > >> > > > Luca > >> > > > >> > > > > >> > > > >> > > > 2016-05-25 21:40 GMT+02:00 Martyn Taylor < > >> mtaylor@redhat.com > >> > >: > >> > > > >> > > > > >> > > > >> > > > > Hi Luca, > >> > > > >> > > > > > >> > > > >> > > > > You don't need any specific configuration to do this. > >> You > >> > can > >> > > > >> just > >> > > > >> > set > >> > > > >> > > > up > >> > > > >> > > > > a MQTT Client and a STOMP client and start > >> sending/receiving > >> > > > from > >> > > > >> the > >> > > > >> > > > same > >> > > > >> > > > > address. > >> > > > >> > > > > > >> > > > >> > > > > There are a couple of issues with Artemis versions > >> <=1.2.0. > >> > > > I've > >> > > > >> > fixed > >> > > > >> > > > > these issues on master and will be doing a 1.3.0 > release > >> > very > >> > > > >> soon, > >> > > > >> > it > >> > > > >> > > > > should be available in the next week or so, your best > >> bet is > >> > > to > >> > > > >> wait > >> > > > >> > > for > >> > > > >> > > > > this. > >> > > > >> > > > > > >> > > > >> > > > > I've also added a simple test to that shows this > working. > >> > > See: > >> > > > >> > > > > > >> > > > >> > > > > > >> > > > >> > > > > >> > > > >> > > > >> > > > >> > > >> > > > >> > >> > > > https://github.com/apache/activemq-artemis/pull/543/commits/ > >> > > 62d284d7765218ced2d0f441cf26ffaaaf3c26f2 > >> > > > >> > > > > > >> > > > >> > > > > Thanks > >> > > > >> > > > > Martyn > >> > > > >> > > > > > >> > > > >> > > > > > >> > > > >> > > > > On Wed, May 25, 2016 at 3:58 PM, Luca Capra < > >> > > > luca.capra@gmail.com > >> > > > >> > > >> > > > >> > > > wrote: > >> > > > >> > > > > > >> > > > >> > > > > > Hi all, > >> > > > >> > > > > > on a project I'm working on I've switched from Apollo > >> to > >> > > > >> Artemis. > >> > > > >> > > > > > > >> > > > >> > > > > > I'm running Artemis as an embed server and would like > >> to > >> > > have > >> > > > >> > > > > > inter-protocol communication between stomp and mqtt. > >> > > > >> > > > > > > >> > > > >> > > > > > What I'm missing is if this can be done from > >> configuration > >> > > or > >> > > > >> > > creating > >> > > > >> > > > an > >> > > > >> > > > > > mqtt and stomp client each one to deliver messages > the > >> > other > >> > > > >> one. > >> > > > >> > > > > > > >> > > > >> > > > > > Thank you > >> > > > >> > > > > > Luca > >> > > > >> > > > > > > >> > > > >> > > > > > >> > > > >> > > > > >> > > > >> > > > >> > > > >> > > >> > > > >> > >> > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > > > > > --94eb2c05fc4a3548080539b6e8eb--