Re: [Dev] [DEV][MB][MQTT] How to handle permission denied to subscribe a topic due to tenancy

[Yasassri Ratnayake]

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,
>
> @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 client.
>
> Thanks,
> Pumudu
>
> On Sat, Oct 3, 2015 at 3:44 PM, Ramith Jayasinghe  wrote:
>
>> 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 can be several topic subscriptions in one connection.
>>> So disconnection might not be the ideal solution IMO. WDYT ?
>>>
>>>
>>> On Saturday, October 3, 2015, Pumudu Ruhunage  wrote:
>>>
 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 given topic.

 So can we agree on following implementation?
 MQTT 3.1- No error code send to client. Disconnect client
 from broker.
 MQTT 3.1.1 - Send error code 0x80 to client. (Is error code enough ?
 should we disconnect client from broker ?)

 WDYT ?

 Thanks,
 Pumudu



 On Sat, Oct 3, 2015 at 10:18 AM, Pamod Sylvester 
 wrote:

> The CONNECT and SUBSCRIBE are two different command messages. The
> subscription phase comes after the connection.
>
> Also the other fact is a single connection could involve multiple
> topic subscriptions. So lets say if a given tenant sends a list of topic
> subscriptions there could be subscriptions which the tenant could be
> authorised among that list. So closing/refusing the entire connection 
> might
> not be appropriate in this case.
>
> - 0x05 (Connection Refused: not authorized) is sent as an
> acknowledgement for CONNECT message (CONNACK).  i.e a given client has
> provided unauthorised credentials etc.
>
> During this phase the subscription will not occur, we only could
> validate whether a given tenants credentials are correct or not.
>
> - When the subscription happens based on my understanding of the spec
> it has passed the CONNACK stage. The only way we could indicate an error
> related to subscription is through SUBACK.
>
>   # The MQTT 3.1 specification has a limitation where error codes
> cannot be sent with SUBACK. Hence for 3.1 spec having subscription failed
> in silent mode is expected behaviour.
>
> You could find a similar discussion on [1]. Based on [1] what they've
> done is hacked the client and the server to accept error codes for 3.1
> specification. This will not be clean and will not interop with other
> clients (even if we could hack the server to send error codes, the clients
> which has implemented according to 3.1 specification will not accept the
> error message).
>
> Another option is to initiate a disconnection from the broker to avoid
> stale connections. But then again as mentioned in the beginning if 
> there're
> list of subscriptions for a connection, even the authorised subscriptions
> would not be able to consume.
>
>   # The MQTT 3.1.1 specification there's an error code introduced 0x80
> for forbidden subscriptions. So that should be the way we should ideally
> use for indication of an error IMHO. But it'll be available in 3.1.1.
>
>
> [1] https://issues.jboss.org/browse/ENTMQ-990
>
>
>
>
> On Sat, Oct 3, 2015 at 7:06 AM, Hasitha Hiranya 
> wrote:
>
>> Hi,
>>
>> Yes, Connection Refused, not authorized is the best we can do.
>>
>> @Pamod, any batter alternative?
>>
>> Thanks!
>>
>> On Fri, Oct 2, 2015 at 10:55 PM, Yasassri Ratnayake <
>> yasas...@wso2.com> wrote:
>>
>>> Hi Pumudu,
>>>
>>> MQTT spec doesn't talk about a permission model, So IMO the closest
>>> error we can propagate to the client is "0x05 Connection Refused, not
>>> authorized".
>>>
>>>
>>> With Regards,
>>>
>>> On Fri, Oct 2, 2015 at 6:17 PM, Pumudu Ruhunage 
>>> wrote:
>>>
 Hi All,

 If 

Re: [Dev] [DEV][MB][MQTT] How to handle permission denied to subscribe a topic due to tenancy

[Pamod Sylvester]

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"

Also we have a test case for this in the Paho interop test suite for this
[1]. I couldn't run this recently but you should be able to verify against
it on the functional behavior.

Also ideally we need to port the test cases to our integration tests if
something is missing WDYT ?

@Pumudu/Ramith i am +1 for the approach and prioritizing 3.1.1
specification.

[1] https://wiki.eclipse.org/File:Mqtt-test.zip

Thanks,
Pamod

On Sat, Oct 3, 2015 at 4:25 PM, Yasassri Ratnayake 
wrote:

> 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,
>>
>> @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 client.
>>
>> Thanks,
>> Pumudu
>>
>> On Sat, Oct 3, 2015 at 3:44 PM, Ramith Jayasinghe 
>> wrote:
>>
>>> 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 can be several topic subscriptions in one connection.
 So disconnection might not be the ideal solution IMO. WDYT ?


 On Saturday, October 3, 2015, Pumudu Ruhunage  wrote:

> 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 given topic.
>
> So can we agree on following implementation?
> MQTT 3.1- No error code send to client. Disconnect client
> from broker.
> MQTT 3.1.1 - Send error code 0x80 to client. (Is error code enough ?
> should we disconnect client from broker ?)
>
> WDYT ?
>
> Thanks,
> Pumudu
>
>
>
> On Sat, Oct 3, 2015 at 10:18 AM, Pamod Sylvester 
> wrote:
>
>> The CONNECT and SUBSCRIBE are two different command messages. The
>> subscription phase comes after the connection.
>>
>> Also the other fact is a single connection could involve multiple
>> topic subscriptions. So lets say if a given tenant sends a list of topic
>> subscriptions there could be subscriptions which the tenant could be
>> authorised among that list. So closing/refusing the entire connection 
>> might
>> not be appropriate in this case.
>>
>> - 0x05 (Connection Refused: not authorized) is sent as an
>> acknowledgement for CONNECT message (CONNACK).  i.e a given client has
>> provided unauthorised credentials etc.
>>
>> During this phase the subscription will not occur, we only could
>> validate whether a given tenants credentials are correct or not.
>>
>> - When the subscription happens based on my understanding of the spec
>> it has passed the CONNACK stage. The only way we could indicate an error
>> related to subscription is through SUBACK.
>>
>>   # The MQTT 3.1 specification has a limitation where error codes
>> cannot be sent with SUBACK. Hence for 3.1 spec having subscription failed
>> in silent mode is expected behaviour.
>>
>> You could find a similar discussion on [1]. Based on [1] what they've
>> done is hacked the client and the server to accept error codes for 3.1
>> specification. This will not be clean and will not interop with other
>> clients (even if we could hack the server to send error codes, the 
>> clients
>> which has implemented according to 3.1 specification will not accept the
>> error message).
>>
>> Another option is to initiate a disconnection from the broker to
>> avoid stale connections. But then again as mentioned in the beginning if
>> there're list of subscriptions for a connection, even the authorised
>> subscriptions would not be able to consume.
>>
>>   # The MQTT 3.1.1 specification there's an error code introduced
>> 0x80 for forbidden subscriptions. So that should be the way we 

Re: [Dev] [DEV][MB][MQTT] How to handle permission denied to subscribe a topic due to tenancy

[Yasassri Ratnayake]

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 {org.wso2.andes.kernel.disruptor.LogExceptionHandler} -  [ Sequence:
10463 ] Exception occurred while processing inbound events.
org.wso2.andes.store.AndesDataIntegrityViolationException: Error occurred
while storing queue information  queue name:carbon:subscriberid0129951
at
org.wso2.andes.store.rdbms.RDBMSStoreUtils.convertBySQLException(RDBMSStoreUtils.java:149)
at
org.wso2.andes.store.rdbms.RDBMSStoreUtils.convertSQLException(RDBMSStoreUtils.java:118)
at
org.wso2.andes.store.rdbms.RDBMSAndesContextStoreImpl.storeQueueInformation(RDBMSAndesContextStoreImpl.java:783)
at
org.wso2.andes.store.FailureObservingAndesContextStore.storeQueueInformation(FailureObservingAndesContextStore.java:326)
at
org.wso2.andes.kernel.AMQPConstructStore.addQueue(AMQPConstructStore.java:114)
at
org.wso2.andes.kernel.AndesContextInformationManager.createQueue(AndesContextInformationManager.java:148)
at
org.wso2.andes.kernel.disruptor.inbound.InboundQueueEvent.updateState(InboundQueueEvent.java:134)
at
org.wso2.andes.kernel.disruptor.inbound.InboundEventContainer.updateState(InboundEventContainer.java:167)
at
org.wso2.andes.kernel.disruptor.inbound.StateEventHandler.onEvent(StateEventHandler.java:77)
at
org.wso2.andes.kernel.disruptor.inbound.StateEventHandler.onEvent(StateEventHandler.java:42)
at com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by:
com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException:
Duplicate entry 'carbon:subscriberid0129951' for key 'PRIMARY'
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
at com.mysql.jdbc.Util.handleNewInstance(Util.java:408)
at com.mysql.jdbc.Util.getInstance(Util.java:383)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1049)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4226)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4158)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2615)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2776)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2840)
at
com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2082)
at
com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2334)
at
com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2262)
at
com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2246)
at
org.wso2.andes.store.rdbms.RDBMSAndesContextStoreImpl.storeQueueInformation(RDBMSAndesContextStoreImpl.java:777)
... 11 more
[2015-10-03 17:07:08,605] ERROR
{org.wso2.andes.mqtt.connectors.PersistenceStoreConnector} -  Error
occurred while opening subscription
org.wso2.andes.kernel.AndesException: Error occurred while checking if
queue: carbon:subscriberid0129951 is added
at
org.wso2.andes.kernel.disruptor.inbound.InboundQueueEvent.waitForCompletion(InboundQueueEvent.java:278)
at org.wso2.andes.kernel.Andes.createQueue(Andes.java:357)
at
org.wso2.andes.mqtt.connectors.PersistenceStoreConnector.addSubscriber(PersistenceStoreConnector.java:164)
at
org.wso2.andes.mqtt.MQTTopicManager.registerTopicSubscriptionInCluster(MQTTopicManager.java:409)
at
org.wso2.andes.mqtt.MQTTopicManager.addTopicSubscription(MQTTopicManager.java:177)
at
org.dna.mqtt.wso2.AndesMQTTBridge.onTopicSubscription(AndesMQTTBridge.java:168)
at
org.dna.mqtt.moquette.messaging.spi.impl.ProtocolProcessor.processSubscribe(ProtocolProcessor.java:800)
at
org.dna.mqtt.moquette.messaging.spi.impl.SimpleMessaging.onEvent(SimpleMessaging.java:186)
at
org.dna.mqtt.moquette.messaging.spi.impl.SimpleMessaging.onEvent(SimpleMessaging.java:47)
at com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:128)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.util.concurrent.TimeoutException: Timeout waiting for task.
at
com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:269)
at
com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:96)
at

Re: [Dev] WSO2 Committers += Vijitha Ekanayake

[Chanaka Fernando]

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, Kasun Indrasiri  wrote:
>>
>>> Hi devs,
>>>
>>> Its my pleasure to welcome Vijitha Ekanayake as a WSO2 Committer.
>>> Vijitha, welcome aboard and keep up the good work!
>>>
>>> Thanks.
>>>
>>> --
>>> Kasun Indrasiri
>>> Software Architect
>>> WSO2, Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> cell: +94 77 556 5206
>>> Blog : http://kasunpanorama.blogspot.com/
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> Best Regards
>> Isuru Ranawaka
>> M: +94714629880
>> Blog : http://isurur.blogspot.com/
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
>
> *Prabath Ariyarathna*
>
> *Associate Technical Lead*
>
> *WSO2, Inc. *
>
> *lean . enterprise . middleware *
>
>
> *Email: prabat...@wso2.com *
>
> *Blog: http://prabu-lk.blogspot.com *
>
> *Flicker : https://www.flickr.com/photos/47759189@N08
> *
>
> *Mobile: +94 77 699 4730 *
>
>
>
>
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
--
Chanaka Fernando
Senior Technical Lead
WSO2, Inc.; http://wso2.com
lean.enterprise.middleware

mobile: +94 773337238
Blog : http://soatutorials.blogspot.com
LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0
Twitter:https://twitter.com/chanakaudaya
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Error in wso2 greg - Artifact list does not appear

[Akila Nimantha [IT/EKO/LOITS]]

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 this, service list does not display in wso2 G-Reg and following 
error message appeared.

[cid:image006.png@01D0FDE8.D51EF440]


Is there any solution or workarounds for solve this issue.


Best Regards,

Akila Rathnayake
Software Engineer


This message (including any attachments) is intended only for
the use of the individual or entity to which it is addressed and
may contain information that is non-public, proprietary,
privileged, confidential, and exempt from disclosure under
applicable law or may constitute as attorney work product.
If you are not the intended recipient, you are hereby notified
that any use, dissemination, distribution, or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify us immediately by telephone and
(i) destroy this message if a facsimile or (ii) delete this message
immediately if this is an electronic communication.

Thank you.
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] WSO2 Committers += Vijitha Ekanayake

[Prabath Ariyarathna]

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, welcome aboard and keep up the good work!
>>
>> Thanks.
>>
>> --
>> Kasun Indrasiri
>> Software Architect
>> WSO2, Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> cell: +94 77 556 5206
>> Blog : http://kasunpanorama.blogspot.com/
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Best Regards
> Isuru Ranawaka
> M: +94714629880
> Blog : http://isurur.blogspot.com/
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 

*Prabath Ariyarathna*

*Associate Technical Lead*

*WSO2, Inc. *

*lean . enterprise . middleware *


*Email: prabat...@wso2.com *

*Blog: http://prabu-lk.blogspot.com *

*Flicker : https://www.flickr.com/photos/47759189@N08
*

*Mobile: +94 77 699 4730 *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Registry] Registry java.sql.SQLException: Lock wait timeout exceeded

[Isuruwan Herath]

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 operation in app
cloud which is taking a long time to execute, then try increasing the
innodb lock wait time out.

HTH,
Isuruwan

On Thu, Oct 1, 2015 at 11:17 AM, Malith Munasinghe  wrote:

> Hi All,
>
> Recently on app cloud we faced an locked timeout exceeded issue on
> registry. This kept application creation down for a while. Is there any
> suggestions on how to keep these kind of issues from occurring.
>
> Attached is the error log that was observed.
>
> Regards,
> Malith.
>
> --
> Malith Munasinghe | Software Engineer
> M: +94 (071) 9401122
> E: mali...@wso2.com
> W: http://wso2.com
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Isuruwan Herath
Technical Lead

Contact: +94 776 273 296
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [DEV][MB][MQTT] How to handle permission denied to subscribe a topic due to tenancy

[Ramith Jayasinghe]

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 can be several topic subscriptions in one connection.
> So disconnection might not be the ideal solution IMO. WDYT ?
>
>
> On Saturday, October 3, 2015, Pumudu Ruhunage  wrote:
>
>> 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 given topic.
>>
>> So can we agree on following implementation?
>> MQTT 3.1- No error code send to client. Disconnect client from broker.
>> MQTT 3.1.1 - Send error code 0x80 to client. (Is error code enough ?
>> should we disconnect client from broker ?)
>>
>> WDYT ?
>>
>> Thanks,
>> Pumudu
>>
>>
>>
>> On Sat, Oct 3, 2015 at 10:18 AM, Pamod Sylvester  wrote:
>>
>>> The CONNECT and SUBSCRIBE are two different command messages. The
>>> subscription phase comes after the connection.
>>>
>>> Also the other fact is a single connection could involve multiple topic
>>> subscriptions. So lets say if a given tenant sends a list of topic
>>> subscriptions there could be subscriptions which the tenant could be
>>> authorised among that list. So closing/refusing the entire connection might
>>> not be appropriate in this case.
>>>
>>> - 0x05 (Connection Refused: not authorized) is sent as an
>>> acknowledgement for CONNECT message (CONNACK).  i.e a given client has
>>> provided unauthorised credentials etc.
>>>
>>> During this phase the subscription will not occur, we only could
>>> validate whether a given tenants credentials are correct or not.
>>>
>>> - When the subscription happens based on my understanding of the spec it
>>> has passed the CONNACK stage. The only way we could indicate an error
>>> related to subscription is through SUBACK.
>>>
>>>   # The MQTT 3.1 specification has a limitation where error codes cannot
>>> be sent with SUBACK. Hence for 3.1 spec having subscription failed in
>>> silent mode is expected behaviour.
>>>
>>> You could find a similar discussion on [1]. Based on [1] what they've
>>> done is hacked the client and the server to accept error codes for 3.1
>>> specification. This will not be clean and will not interop with other
>>> clients (even if we could hack the server to send error codes, the clients
>>> which has implemented according to 3.1 specification will not accept the
>>> error message).
>>>
>>> Another option is to initiate a disconnection from the broker to avoid
>>> stale connections. But then again as mentioned in the beginning if there're
>>> list of subscriptions for a connection, even the authorised subscriptions
>>> would not be able to consume.
>>>
>>>   # The MQTT 3.1.1 specification there's an error code introduced 0x80
>>> for forbidden subscriptions. So that should be the way we should ideally
>>> use for indication of an error IMHO. But it'll be available in 3.1.1.
>>>
>>>
>>> [1] https://issues.jboss.org/browse/ENTMQ-990
>>>
>>>
>>>
>>>
>>> On Sat, Oct 3, 2015 at 7:06 AM, Hasitha Hiranya 
>>> wrote:
>>>
 Hi,

 Yes, Connection Refused, not authorized is the best we can do.

 @Pamod, any batter alternative?

 Thanks!

 On Fri, Oct 2, 2015 at 10:55 PM, Yasassri Ratnayake 
 wrote:

> Hi Pumudu,
>
> MQTT spec doesn't talk about a permission model, So IMO the closest
> error we can propagate to the client is "0x05 Connection Refused, not
> authorized".
>
>
> With Regards,
>
> On Fri, Oct 2, 2015 at 6:17 PM, Pumudu Ruhunage 
> wrote:
>
>> Hi All,
>>
>> If a tenant don't have permission to subscribe to a given topic
>> (tenant 'a.com' try to subscribe to tenant 'b.com') currently it
>> will keep connected even though it's not subscribed, because user
>> authentication was successful. This is misleading to subscriber as no
>> return code sent and it's actively connected to broker.
>> AFAIK mqtt don't define how to handle tenancy scenarios in it's spec.
>> Couldn't find a definition in MQTT spec 3.1.0/3.1.1 on how to reject if
>> permission denied to subscribe to a given topic(due to tenancy).
>>
>> One option to handle this scenario is to send return code 5 (Connection
>> Refused, not authorized) to client if it doesn't have permission to
>> subscribe to given topic. This way client will disconnect if it don't 
>> have
>> permission to subscribe. Is this acceptable or are there any alternatives
>> to handle this scenario?
>>
>> jira 

Re: [Dev] [DEV][MB][MQTT] How to handle permission denied to subscribe a topic due to tenancy

[Pumudu Ruhunage]

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 client.

Thanks,
Pumudu

On Sat, Oct 3, 2015 at 3:44 PM, Ramith Jayasinghe  wrote:

> 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 can be several topic subscriptions in one connection.
>> So disconnection might not be the ideal solution IMO. WDYT ?
>>
>>
>> On Saturday, October 3, 2015, Pumudu Ruhunage  wrote:
>>
>>> 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 given topic.
>>>
>>> So can we agree on following implementation?
>>> MQTT 3.1- No error code send to client. Disconnect client
>>> from broker.
>>> MQTT 3.1.1 - Send error code 0x80 to client. (Is error code enough ?
>>> should we disconnect client from broker ?)
>>>
>>> WDYT ?
>>>
>>> Thanks,
>>> Pumudu
>>>
>>>
>>>
>>> On Sat, Oct 3, 2015 at 10:18 AM, Pamod Sylvester  wrote:
>>>
 The CONNECT and SUBSCRIBE are two different command messages. The
 subscription phase comes after the connection.

 Also the other fact is a single connection could involve multiple topic
 subscriptions. So lets say if a given tenant sends a list of topic
 subscriptions there could be subscriptions which the tenant could be
 authorised among that list. So closing/refusing the entire connection might
 not be appropriate in this case.

 - 0x05 (Connection Refused: not authorized) is sent as an
 acknowledgement for CONNECT message (CONNACK).  i.e a given client has
 provided unauthorised credentials etc.

 During this phase the subscription will not occur, we only could
 validate whether a given tenants credentials are correct or not.

 - When the subscription happens based on my understanding of the spec
 it has passed the CONNACK stage. The only way we could indicate an error
 related to subscription is through SUBACK.

   # The MQTT 3.1 specification has a limitation where error codes
 cannot be sent with SUBACK. Hence for 3.1 spec having subscription failed
 in silent mode is expected behaviour.

 You could find a similar discussion on [1]. Based on [1] what they've
 done is hacked the client and the server to accept error codes for 3.1
 specification. This will not be clean and will not interop with other
 clients (even if we could hack the server to send error codes, the clients
 which has implemented according to 3.1 specification will not accept the
 error message).

 Another option is to initiate a disconnection from the broker to avoid
 stale connections. But then again as mentioned in the beginning if there're
 list of subscriptions for a connection, even the authorised subscriptions
 would not be able to consume.

   # The MQTT 3.1.1 specification there's an error code introduced 0x80
 for forbidden subscriptions. So that should be the way we should ideally
 use for indication of an error IMHO. But it'll be available in 3.1.1.


 [1] https://issues.jboss.org/browse/ENTMQ-990




 On Sat, Oct 3, 2015 at 7:06 AM, Hasitha Hiranya 
 wrote:

> Hi,
>
> Yes, Connection Refused, not authorized is the best we can do.
>
> @Pamod, any batter alternative?
>
> Thanks!
>
> On Fri, Oct 2, 2015 at 10:55 PM, Yasassri Ratnayake  > wrote:
>
>> Hi Pumudu,
>>
>> MQTT spec doesn't talk about a permission model, So IMO the closest
>> error we can propagate to the client is "0x05 Connection Refused, not
>> authorized".
>>
>>
>> With Regards,
>>
>> On Fri, Oct 2, 2015 at 6:17 PM, Pumudu Ruhunage 
>> wrote:
>>
>>> Hi All,
>>>
>>> If a tenant don't have permission to subscribe to a given topic
>>> (tenant 'a.com' try to subscribe to tenant 'b.com') currently it
>>> will keep connected even though it's not subscribed, because user
>>> authentication was successful. This is misleading to subscriber as no
>>> return code sent and it's actively connected to broker.
>>> AFAIK mqtt don't define how to handle tenancy scenarios in it's
>>> spec. Couldn't 

Re: [Dev] Please merge the PR

[Manuranga Perera]

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:
>
>> Please review and merge https://github.com/wso2/carbon-dashboards/pull/53
>>  for https://wso2.org/jira/browse/UES-585
>>
>> For this we need to have rpc.js as a library. When I was testing it I
> directly included it to the index.xml as  * src="http://sandbox.ig.gmodules.com/gadgets/js/rpc.js
> <http://sandbox.ig.gmodules.com/gadgets/js/rpc.js>">.* But when
> you were trying, we didn't include that rpc library. That was the reason
> for the conflict.
> Now I have changed the designer.js to loads the rpc library along with UI
> initialization(This is the time set_pref get registered) and I added rcp.js
> to the portal/js/ folder.
> Please let me know If you have any concerns.
>
> *Sajith Abeywardhana* | Software Engineer
> WSO2, Inc | lean. enterprise. middleware.
> #20, Palm Grove, Colombo 03, Sri Lanka.
> Mobile: +94772260485
> Email: saji...@wso2.com | Web: www.wso2.com
>
>
>
>
>>
>> *Sajith Abeywardhana* | Software Engineer
>> WSO2, Inc | lean. enterprise. middleware.
>> #20, Palm Grove, Colombo 03, Sri Lanka.
>> Mobile: +94772260485
>> Email: saji...@wso2.com | Web: www.wso2.com
>>
>
>


-- 
With regards,
*Manu*ranga Perera.

phone : 071 7 70 20 50
mail : m...@wso2.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Registry] Registry java.sql.SQLException: Lock wait timeout exceeded

[Malith Munasinghe]

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 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 operation in app
> cloud which is taking a long time to execute, then try increasing the
> innodb lock wait time out.
>
> HTH,
> Isuruwan
>
> On Thu, Oct 1, 2015 at 11:17 AM, Malith Munasinghe 
> wrote:
>
>> Hi All,
>>
>> Recently on app cloud we faced an locked timeout exceeded issue on
>> registry. This kept application creation down for a while. Is there any
>> suggestions on how to keep these kind of issues from occurring.
>>
>> Attached is the error log that was observed.
>>
>> Regards,
>> Malith.
>>
>> --
>> Malith Munasinghe | Software Engineer
>> M: +94 (071) 9401122
>> E: mali...@wso2.com
>> W: http://wso2.com
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Isuruwan Herath
> Technical Lead
>
> Contact: +94 776 273 296
>



-- 
Malith Munasinghe | Software Engineer
M: +94 (071) 9401122
E: mali...@wso2.com
W: http://wso2.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [DEV][MB][MQTT] How to handle permission denied to subscribe a topic due to tenancy

[Pamod Sylvester]

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, 2015, Pumudu Ruhunage  wrote:

> 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 given topic.
>
> So can we agree on following implementation?
> MQTT 3.1- No error code send to client. Disconnect client from broker.
> MQTT 3.1.1 - Send error code 0x80 to client. (Is error code enough ?
> should we disconnect client from broker ?)
>
> WDYT ?
>
> Thanks,
> Pumudu
>
>
>
> On Sat, Oct 3, 2015 at 10:18 AM, Pamod Sylvester  > wrote:
>
>> The CONNECT and SUBSCRIBE are two different command messages. The
>> subscription phase comes after the connection.
>>
>> Also the other fact is a single connection could involve multiple topic
>> subscriptions. So lets say if a given tenant sends a list of topic
>> subscriptions there could be subscriptions which the tenant could be
>> authorised among that list. So closing/refusing the entire connection might
>> not be appropriate in this case.
>>
>> - 0x05 (Connection Refused: not authorized) is sent as an acknowledgement
>> for CONNECT message (CONNACK).  i.e a given client has provided
>> unauthorised credentials etc.
>>
>> During this phase the subscription will not occur, we only could validate
>> whether a given tenants credentials are correct or not.
>>
>> - When the subscription happens based on my understanding of the spec it
>> has passed the CONNACK stage. The only way we could indicate an error
>> related to subscription is through SUBACK.
>>
>>   # The MQTT 3.1 specification has a limitation where error codes cannot
>> be sent with SUBACK. Hence for 3.1 spec having subscription failed in
>> silent mode is expected behaviour.
>>
>> You could find a similar discussion on [1]. Based on [1] what they've
>> done is hacked the client and the server to accept error codes for 3.1
>> specification. This will not be clean and will not interop with other
>> clients (even if we could hack the server to send error codes, the clients
>> which has implemented according to 3.1 specification will not accept the
>> error message).
>>
>> Another option is to initiate a disconnection from the broker to avoid
>> stale connections. But then again as mentioned in the beginning if there're
>> list of subscriptions for a connection, even the authorised subscriptions
>> would not be able to consume.
>>
>>   # The MQTT 3.1.1 specification there's an error code introduced 0x80
>> for forbidden subscriptions. So that should be the way we should ideally
>> use for indication of an error IMHO. But it'll be available in 3.1.1.
>>
>>
>> [1] https://issues.jboss.org/browse/ENTMQ-990
>>
>>
>>
>>
>> On Sat, Oct 3, 2015 at 7:06 AM, Hasitha Hiranya > > wrote:
>>
>>> Hi,
>>>
>>> Yes, Connection Refused, not authorized is the best we can do.
>>>
>>> @Pamod, any batter alternative?
>>>
>>> Thanks!
>>>
>>> On Fri, Oct 2, 2015 at 10:55 PM, Yasassri Ratnayake >> > wrote:
>>>
 Hi Pumudu,

 MQTT spec doesn't talk about a permission model, So IMO the closest
 error we can propagate to the client is "0x05 Connection Refused, not
 authorized".


 With Regards,

 On Fri, Oct 2, 2015 at 6:17 PM, Pumudu Ruhunage > wrote:

> Hi All,
>
> If a tenant don't have permission to subscribe to a given topic
> (tenant 'a.com' try to subscribe to tenant 'b.com') currently it will
> keep connected even though it's not subscribed, because user 
> authentication
> was successful. This is misleading to subscriber as no return code sent 
> and
> it's actively connected to broker.
> AFAIK mqtt don't define how to handle tenancy scenarios in it's spec.
> Couldn't find a definition in MQTT spec 3.1.0/3.1.1 on how to reject if
> permission denied to subscribe to a given topic(due to tenancy).
>
> One option to handle this scenario is to send return code 5 (Connection
> Refused, not authorized) to client if it doesn't have permission to
> subscribe to given topic. This way client will disconnect if it don't have
> permission to subscribe. Is this acceptable or are there any alternatives
> to handle this scenario?
>
> jira https://wso2.org/jira/browse/MB-1409
>
> 

Re: [Dev] [DEV][MB][MQTT] How to handle permission denied to subscribe a topic due to tenancy

[Pumudu Ruhunage]

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 given topic.

So can we agree on following implementation?
MQTT 3.1- No error code send to client. Disconnect client from broker.
MQTT 3.1.1 - Send error code 0x80 to client. (Is error code enough ? should
we disconnect client from broker ?)

WDYT ?

Thanks,
Pumudu



On Sat, Oct 3, 2015 at 10:18 AM, Pamod Sylvester  wrote:

> The CONNECT and SUBSCRIBE are two different command messages. The
> subscription phase comes after the connection.
>
> Also the other fact is a single connection could involve multiple topic
> subscriptions. So lets say if a given tenant sends a list of topic
> subscriptions there could be subscriptions which the tenant could be
> authorised among that list. So closing/refusing the entire connection might
> not be appropriate in this case.
>
> - 0x05 (Connection Refused: not authorized) is sent as an acknowledgement
> for CONNECT message (CONNACK).  i.e a given client has provided
> unauthorised credentials etc.
>
> During this phase the subscription will not occur, we only could validate
> whether a given tenants credentials are correct or not.
>
> - When the subscription happens based on my understanding of the spec it
> has passed the CONNACK stage. The only way we could indicate an error
> related to subscription is through SUBACK.
>
>   # The MQTT 3.1 specification has a limitation where error codes cannot
> be sent with SUBACK. Hence for 3.1 spec having subscription failed in
> silent mode is expected behaviour.
>
> You could find a similar discussion on [1]. Based on [1] what they've done
> is hacked the client and the server to accept error codes for 3.1
> specification. This will not be clean and will not interop with other
> clients (even if we could hack the server to send error codes, the clients
> which has implemented according to 3.1 specification will not accept the
> error message).
>
> Another option is to initiate a disconnection from the broker to avoid
> stale connections. But then again as mentioned in the beginning if there're
> list of subscriptions for a connection, even the authorised subscriptions
> would not be able to consume.
>
>   # The MQTT 3.1.1 specification there's an error code introduced 0x80 for
> forbidden subscriptions. So that should be the way we should ideally use
> for indication of an error IMHO. But it'll be available in 3.1.1.
>
>
> [1] https://issues.jboss.org/browse/ENTMQ-990
>
>
>
>
> On Sat, Oct 3, 2015 at 7:06 AM, Hasitha Hiranya  wrote:
>
>> Hi,
>>
>> Yes, Connection Refused, not authorized is the best we can do.
>>
>> @Pamod, any batter alternative?
>>
>> Thanks!
>>
>> On Fri, Oct 2, 2015 at 10:55 PM, Yasassri Ratnayake 
>> wrote:
>>
>>> Hi Pumudu,
>>>
>>> MQTT spec doesn't talk about a permission model, So IMO the closest
>>> error we can propagate to the client is "0x05 Connection Refused, not
>>> authorized".
>>>
>>>
>>> With Regards,
>>>
>>> On Fri, Oct 2, 2015 at 6:17 PM, Pumudu Ruhunage  wrote:
>>>
 Hi All,

 If a tenant don't have permission to subscribe to a given topic (tenant
 'a.com' try to subscribe to tenant 'b.com') currently it will keep
 connected even though it's not subscribed, because user authentication was
 successful. This is misleading to subscriber as no return code sent and
 it's actively connected to broker.
 AFAIK mqtt don't define how to handle tenancy scenarios in it's spec.
 Couldn't find a definition in MQTT spec 3.1.0/3.1.1 on how to reject if
 permission denied to subscribe to a given topic(due to tenancy).

 One option to handle this scenario is to send return code 5 (Connection
 Refused, not authorized) to client if it doesn't have permission to
 subscribe to given topic. This way client will disconnect if it don't have
 permission to subscribe. Is this acceptable or are there any alternatives
 to handle this scenario?

 jira https://wso2.org/jira/browse/MB-1409

 Thanks,
 Pumudu
 --
 Pumudu Ruhunage
 Associate Software Engineer | WSO2 Inc
 M: +94 779 664493  | http://wso2.com

 ___
 Dev mailing list
 Dev@wso2.org
 http://wso2.org/cgi-bin/mailman/listinfo/dev


>>>
>>>
>>> --
>>> Yasassri Ratnayake
>>> Software Engineer - QA
>>> WSO2 Inc ; http://wso2.com
>>> lean.enterprise.middleware
>>> *Mobile : +94715933168 <%2B94715933168>*
>>> *Blogs : http://yasassriratnayake.blogspot.com
>>> *
>>> *http://wso2logs.blogspot.com *
>>>
>>> ___
>>>