Hi Pamod,
Do we allow multiple topic subscriptions with the same ClientID? As per my
observation we do not allow this.
So if we do not allow this, there is no point in keeping a stale
connection.
With Regards,
On Sat, Oct 3, 2015 at 3:55 PM, Pumudu Ruhunage wrote:
> Hi All,
Hi Yasassri,
According to the 3.1 specification its allowed to have multiple
subscriptions with the single connection,
In the SUBSCRIBE section under payload it specifies the following,
"The payload of a SUBSCRIBE message contains a list of topic names to which
the client wants to subscribe"
Hi Pamod,
Sry for the ambiguity :), I asked whether MB 3.0.0 supports this? I
couldn't get multiple subscriptions to work. When I try to subscribe to
multiple topics.
client.subscribe("topic1");
client.subscribe("topic2");
I got the following error, Am I missing something here?
ERROR
Congratulations Vijitha !!! Keep up the good work.
On Sat, Oct 3, 2015 at 3:31 PM, Prabath Ariyarathna
wrote:
> Congrats vijitha !!!
>
> On Sat, Oct 3, 2015 at 10:04 AM, Isuru Ranawaka wrote:
>
>> Congrats vijitha !!!
>>
>> On Sat, Oct 3, 2015 at 8:43 AM,
Hi All,
I used following SCM xml code for integrate wso2 G-Reg with SVN.
[cid:image004.png@01D0FDE8.D51EF440]
When I promote the service form development stage to Testing stage, service is
successfully promote. And also service is successfully copy to the SVN working
directory.
But after all
Congrats vijitha !!!
On Sat, Oct 3, 2015 at 10:04 AM, Isuru Ranawaka wrote:
> Congrats vijitha !!!
>
> On Sat, Oct 3, 2015 at 8:43 AM, Kasun Indrasiri wrote:
>
>> Hi devs,
>>
>> Its my pleasure to welcome Vijitha Ekanayake as a WSO2 Committer.
>> Vijitha,
Hi Malith,
>From the log it seems some thread is holding a table lock, which prevents
to acquire the lock when the executing the update command to the resource
content id. Check the process list from mysql and identify the thread which
is holding the lock. If that is a legitimate concurrent
I think whats more relevant is to make v 3.1.1 case correct.
On Sat, Oct 3, 2015 at 2:03 PM, Pamod Sylvester wrote:
> Both versions of the protocol are supported at the moment AFAIK.
>
> So for 3.1.1 sending the error code is adequate. As mentioned in the
> previous mail there
Hi All,
@pamod, I also agree disconnecting is not the ideal solution. just thought
from client side, since it's not getting any indication of not subscribing
to the topic.
Then implementation will be as follows.
MQTT 3.1- No error code send to client.
MQTT 3.1.1 - Send error code 0x80 to
the rpc library should come automatically whit with Feature tag for set
pref. no need to include it manually.
On Fri, Oct 2, 2015 at 7:36 PM, Sajith Abeywardhana
wrote:
> Hi Sameera,
>
> On Wed, Sep 30, 2015 at 1:12 PM, Sajith Abeywardhana
> wrote:
>
>>
Hi Isuruwan,
Thanks for the suggestion I will look at mysql logs for this.
Regards,
Malith
On Sat, Oct 3, 2015 at 7:29 PM, Isuruwan Herath wrote:
> Hi Malith,
>
> From the log it seems some thread is holding a table lock, which prevents
> to acquire the lock when the
Both versions of the protocol are supported at the moment AFAIK.
So for 3.1.1 sending the error code is adequate. As mentioned in the
previous mail there can be several topic subscriptions in one connection.
So disconnection might not be the ideal solution IMO. WDYT ?
On Saturday, October 3,
Hi All,
Since we have to support both protocols we need implement both behaviors
based on protocols? right ?
IMO for 3.1 we need to indicate that it's not subscribed to the topic by
disconnection if it's not subscribed. otherwise it gives false impression
that client successfully subscribed to
13 matches
Mail list logo