Re: [Architecture] tenant specific MQTT receivers in DAS , not listening to topics once tenant get unloaded

[Chathura Ekanayake]

On Wed, Mar 22, 2017 at 10:51 AM, Jasintha Dasanayake 
wrote:

> Hi Sinthuja
>
> On Tue, Mar 21, 2017 at 4:23 PM, Sinthuja Ragendran 
> wrote:
>
>> Hi Jasintha,
>>
>> I have a concern on how are we going to handle already created tenants if
>> we are going to go with different receiver configurations per tenant? It
>> works for the case if this component is attached for the server runtime
>> from the initial stages, but if it is to be incorporated into an already
>> running system then how that the tenanted receiver artefact is going to be
>> connected? Are you planning to add some component into analytics server
>> side, to create the receiver configurations for all tenants? I would prefer
>> this logic to be handled within the custom new receiver implementation,
>> hence if such receiver configuration is there, automatically the required
>> logic will be executed, and we can handle all those necessary checks and
>> validation in the receiver implementation.
>>
>> In this scenario , all the existing tenants also need to login to the
> device cloud and activate androidsens for their devices at that time we
> create the receiver, (it won't be by default activate for all tenants)
>

We can use this as a quick solution to get the things working without
introducing changes to DAS. I think in the long run we have to do a custom
receiver implementation, which runs in super tenant mode and subscribes to
topics on behalf of tenants. We may also have to change DAS deployers to
pick receiver configurations and inform the custom receiver implementation
to subscribe to relevant topics. In that way, we can avoid invoking admin
services to create receivers whenever a tenant has to be loaded.

- Chathura


>
>> On Tue, Mar 21, 2017 at 4:03 PM, Jasintha Dasanayake 
>> wrote:
>>
>>> HI
>>>
>>> Thanks for all feedback , So I am going to implement this by creating
>>> event receiver configuration dynamically for each tenant and deploying into
>>> DAS using the event receiver admin service. As Mohan mentioned , IMO
>>> keeping a per tenant receiver will be a better option because an existing
>>> subscriptions will not be effected when adding/removing another tenant's
>>> artifacts.
>>>
>>
>> IMHO if you have one receiver configuration/or seperate receiver
>> configuration doesn't make a difference here, in both cases any tenanted
>> behaviour will not interfere with other.
>>
>> Additionally, if you are going with seperate receiver configurations per
>> tenant, then you need to make sure, that you don't create multiple receiver
>> configurations for same tenant.
>>
>
> By design in the IOT users won't be able to activate it more than one time.
>
> Thanks and Regards
> /Jasintha
>
>>
>> Thanks,
>> Sinthuja.
>>
>>
>>>
>>> Thanks
>>> /Jasintha
>>>
>>> On Tue, Mar 21, 2017 at 11:27 AM, Anjana Fernando 
>>> wrote:
>>>
 Hi,

 On Mon, Mar 20, 2017 at 11:02 AM, Sinthuja Ragendran >>> > wrote:

> Hi,
>
> As the receiver configurations are deployable artefacts, those will be
> active when the tenant is loaded. One approach is to have all tenants
> loaded indefinitely. I think this will have high memory. And therefore we
> internally discussed below approach to handling this problem.
>
> Instead of having multiple MQTT receiver configurations per tenant to
> handle this, implement a specialised/privileged MQTT event receiver which
> could handle multiple subscriptions on behalf of tenants, and it's only
> deployable in the super tenant mode. In that case, this event receiver 
> will
> have the topic URI with {tenantDomain} placeholder and it is used to
> subscribe to the specific tenanted topic. And then, based on which topic
> the event has arrived the tenant flow will be started and an event will be
> inserted into specific tenant space. By this way, only the tenants which
> are actively used/sending events will be loaded, and not all tenants are
> required to be loaded.
>
> Please share your thoughts on this. Also, AFAIR we had the similar
> requirement for Task execution. @Anjana, how are we handling that?
>

 Yes, the tasks and their definitions are stored in the super tenant
 space. So they get triggered appropriately, and as required, any tenant
 specific resources would be loaded by the task implementation.

 Cheers,
 Anjana.


>
> Thanks,
> Sinthuja.
>
> On Mon, Mar 20, 2017 at 10:50 AM, Jasintha Dasanayake <
> jasin...@wso2.com> wrote:
>
>> HI All
>>
>> When DAS working in tenant mode and a particular tenant has MQTT
>> receivers, those cannot be activated once tenants get unloaded. For an
>> example , if I restart the DAS then those tenants specific MQTT receivers
>> are not loaded unless we explicitly load that particular tenant. IMO,
>> expected behavior would be, those receivers should be loaded and 
>> subscribed
>> to a 

Re: [Architecture] tenant specific MQTT receivers in DAS , not listening to topics once tenant get unloaded

[Jasintha Dasanayake]

Hi Sinthuja

On Tue, Mar 21, 2017 at 4:23 PM, Sinthuja Ragendran 
wrote:

> Hi Jasintha,
>
> I have a concern on how are we going to handle already created tenants if
> we are going to go with different receiver configurations per tenant? It
> works for the case if this component is attached for the server runtime
> from the initial stages, but if it is to be incorporated into an already
> running system then how that the tenanted receiver artefact is going to be
> connected? Are you planning to add some component into analytics server
> side, to create the receiver configurations for all tenants? I would prefer
> this logic to be handled within the custom new receiver implementation,
> hence if such receiver configuration is there, automatically the required
> logic will be executed, and we can handle all those necessary checks and
> validation in the receiver implementation.
>
> In this scenario , all the existing tenants also need to login to the
device cloud and activate androidsens for their devices at that time we
create the receiver, (it won't be by default activate for all tenants)


>
> On Tue, Mar 21, 2017 at 4:03 PM, Jasintha Dasanayake 
> wrote:
>
>> HI
>>
>> Thanks for all feedback , So I am going to implement this by creating
>> event receiver configuration dynamically for each tenant and deploying into
>> DAS using the event receiver admin service. As Mohan mentioned , IMO
>> keeping a per tenant receiver will be a better option because an existing
>> subscriptions will not be effected when adding/removing another tenant's
>> artifacts.
>>
>
> IMHO if you have one receiver configuration/or seperate receiver
> configuration doesn't make a difference here, in both cases any tenanted
> behaviour will not interfere with other.
>
> Additionally, if you are going with seperate receiver configurations per
> tenant, then you need to make sure, that you don't create multiple receiver
> configurations for same tenant.
>

By design in the IOT users won't be able to activate it more than one time.

Thanks and Regards
/Jasintha

>
> Thanks,
> Sinthuja.
>
>
>>
>> Thanks
>> /Jasintha
>>
>> On Tue, Mar 21, 2017 at 11:27 AM, Anjana Fernando 
>> wrote:
>>
>>> Hi,
>>>
>>> On Mon, Mar 20, 2017 at 11:02 AM, Sinthuja Ragendran 
>>> wrote:
>>>
 Hi,

 As the receiver configurations are deployable artefacts, those will be
 active when the tenant is loaded. One approach is to have all tenants
 loaded indefinitely. I think this will have high memory. And therefore we
 internally discussed below approach to handling this problem.

 Instead of having multiple MQTT receiver configurations per tenant to
 handle this, implement a specialised/privileged MQTT event receiver which
 could handle multiple subscriptions on behalf of tenants, and it's only
 deployable in the super tenant mode. In that case, this event receiver will
 have the topic URI with {tenantDomain} placeholder and it is used to
 subscribe to the specific tenanted topic. And then, based on which topic
 the event has arrived the tenant flow will be started and an event will be
 inserted into specific tenant space. By this way, only the tenants which
 are actively used/sending events will be loaded, and not all tenants are
 required to be loaded.

 Please share your thoughts on this. Also, AFAIR we had the similar
 requirement for Task execution. @Anjana, how are we handling that?

>>>
>>> Yes, the tasks and their definitions are stored in the super tenant
>>> space. So they get triggered appropriately, and as required, any tenant
>>> specific resources would be loaded by the task implementation.
>>>
>>> Cheers,
>>> Anjana.
>>>
>>>

 Thanks,
 Sinthuja.

 On Mon, Mar 20, 2017 at 10:50 AM, Jasintha Dasanayake <
 jasin...@wso2.com> wrote:

> HI All
>
> When DAS working in tenant mode and a particular tenant has MQTT
> receivers, those cannot be activated once tenants get unloaded. For an
> example , if I restart the DAS then those tenants specific MQTT receivers
> are not loaded unless we explicitly load that particular tenant. IMO,
> expected behavior would be, those receivers should be loaded and 
> subscribed
> to a particular topic without loading the tenants explicitly.
>
> Are there any known mechanism to address this particular problem ?
>
> Thanks and Regards
> /jasintha
>
> --
>
> *Jasintha Dasanayake**Associate Technical Lead*
>
> *WSO2 Inc. | http://wso2.com lean . enterprise .
> middleware*
>
>
> *mobile :- 0711-368-118 <071%20136%208118>*
>



 --
 *Sinthuja Rajendran*
 Technical Lead
 WSO2, Inc.:http://wso2.com

 Blog: http://sinthu-rajan.blogspot.com/
 Mobile: +94774273955 <077%20427%203955>



>>>
>>>
>>> --
>>> *Anjana Fernando*
>>> Associate Director / Architect
>>> WS

Re: [Architecture] tenant specific MQTT receivers in DAS , not listening to topics once tenant get unloaded

[Sinthuja Ragendran]

Hi Jasintha,

I have a concern on how are we going to handle already created tenants if
we are going to go with different receiver configurations per tenant? It
works for the case if this component is attached for the server runtime
from the initial stages, but if it is to be incorporated into an already
running system then how that the tenanted receiver artefact is going to be
connected? Are you planning to add some component into analytics server
side, to create the receiver configurations for all tenants? I would prefer
this logic to be handled within the custom new receiver implementation,
hence if such receiver configuration is there, automatically the required
logic will be executed, and we can handle all those necessary checks and
validation in the receiver implementation.


On Tue, Mar 21, 2017 at 4:03 PM, Jasintha Dasanayake 
wrote:

> HI
>
> Thanks for all feedback , So I am going to implement this by creating
> event receiver configuration dynamically for each tenant and deploying into
> DAS using the event receiver admin service. As Mohan mentioned , IMO
> keeping a per tenant receiver will be a better option because an existing
> subscriptions will not be effected when adding/removing another tenant's
> artifacts.
>

IMHO if you have one receiver configuration/or seperate receiver
configuration doesn't make a difference here, in both cases any tenanted
behaviour will not interfere with other.

Additionally, if you are going with seperate receiver configurations per
tenant, then you need to make sure, that you don't create multiple receiver
configurations for same tenant.

Thanks,
Sinthuja.


>
> Thanks
> /Jasintha
>
> On Tue, Mar 21, 2017 at 11:27 AM, Anjana Fernando  wrote:
>
>> Hi,
>>
>> On Mon, Mar 20, 2017 at 11:02 AM, Sinthuja Ragendran 
>> wrote:
>>
>>> Hi,
>>>
>>> As the receiver configurations are deployable artefacts, those will be
>>> active when the tenant is loaded. One approach is to have all tenants
>>> loaded indefinitely. I think this will have high memory. And therefore we
>>> internally discussed below approach to handling this problem.
>>>
>>> Instead of having multiple MQTT receiver configurations per tenant to
>>> handle this, implement a specialised/privileged MQTT event receiver which
>>> could handle multiple subscriptions on behalf of tenants, and it's only
>>> deployable in the super tenant mode. In that case, this event receiver will
>>> have the topic URI with {tenantDomain} placeholder and it is used to
>>> subscribe to the specific tenanted topic. And then, based on which topic
>>> the event has arrived the tenant flow will be started and an event will be
>>> inserted into specific tenant space. By this way, only the tenants which
>>> are actively used/sending events will be loaded, and not all tenants are
>>> required to be loaded.
>>>
>>> Please share your thoughts on this. Also, AFAIR we had the similar
>>> requirement for Task execution. @Anjana, how are we handling that?
>>>
>>
>> Yes, the tasks and their definitions are stored in the super tenant
>> space. So they get triggered appropriately, and as required, any tenant
>> specific resources would be loaded by the task implementation.
>>
>> Cheers,
>> Anjana.
>>
>>
>>>
>>> Thanks,
>>> Sinthuja.
>>>
>>> On Mon, Mar 20, 2017 at 10:50 AM, Jasintha Dasanayake >> > wrote:
>>>
 HI All

 When DAS working in tenant mode and a particular tenant has MQTT
 receivers, those cannot be activated once tenants get unloaded. For an
 example , if I restart the DAS then those tenants specific MQTT receivers
 are not loaded unless we explicitly load that particular tenant. IMO,
 expected behavior would be, those receivers should be loaded and subscribed
 to a particular topic without loading the tenants explicitly.

 Are there any known mechanism to address this particular problem ?

 Thanks and Regards
 /jasintha

 --

 *Jasintha Dasanayake**Associate Technical Lead*

 *WSO2 Inc. | http://wso2.com lean . enterprise .
 middleware*


 *mobile :- 0711-368-118 <071%20136%208118>*

>>>
>>>
>>>
>>> --
>>> *Sinthuja Rajendran*
>>> Technical Lead
>>> WSO2, Inc.:http://wso2.com
>>>
>>> Blog: http://sinthu-rajan.blogspot.com/
>>> Mobile: +94774273955 <077%20427%203955>
>>>
>>>
>>>
>>
>>
>> --
>> *Anjana Fernando*
>> Associate Director / Architect
>> WSO2 Inc. | http://wso2.com
>> lean . enterprise . middleware
>>
>
>
>
> --
>
> *Jasintha Dasanayake**Associate Technical Lead*
>
> *WSO2 Inc. | http://wso2.com lean . enterprise .
> middleware*
>
>
> *mobile :- 0711-368-118 <071%20136%208118>*
>



-- 
*Sinthuja Rajendran*
Technical Lead
WSO2, Inc.:http://wso2.com

Blog: http://sinthu-rajan.blogspot.com/
Mobile: +94774273955
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] tenant specific MQTT receivers in DAS , not listening to topics once tenant get unloaded

[Jasintha Dasanayake]

HI

Thanks for all feedback , So I am going to implement this by creating event
receiver configuration dynamically for each tenant and deploying into DAS
using the event receiver admin service. As Mohan mentioned , IMO keeping a
per tenant receiver will be a better option because an existing
subscriptions will not be effected when adding/removing another tenant's
artifacts.

Thanks
/Jasintha

On Tue, Mar 21, 2017 at 11:27 AM, Anjana Fernando  wrote:

> Hi,
>
> On Mon, Mar 20, 2017 at 11:02 AM, Sinthuja Ragendran 
> wrote:
>
>> Hi,
>>
>> As the receiver configurations are deployable artefacts, those will be
>> active when the tenant is loaded. One approach is to have all tenants
>> loaded indefinitely. I think this will have high memory. And therefore we
>> internally discussed below approach to handling this problem.
>>
>> Instead of having multiple MQTT receiver configurations per tenant to
>> handle this, implement a specialised/privileged MQTT event receiver which
>> could handle multiple subscriptions on behalf of tenants, and it's only
>> deployable in the super tenant mode. In that case, this event receiver will
>> have the topic URI with {tenantDomain} placeholder and it is used to
>> subscribe to the specific tenanted topic. And then, based on which topic
>> the event has arrived the tenant flow will be started and an event will be
>> inserted into specific tenant space. By this way, only the tenants which
>> are actively used/sending events will be loaded, and not all tenants are
>> required to be loaded.
>>
>> Please share your thoughts on this. Also, AFAIR we had the similar
>> requirement for Task execution. @Anjana, how are we handling that?
>>
>
> Yes, the tasks and their definitions are stored in the super tenant space.
> So they get triggered appropriately, and as required, any tenant specific
> resources would be loaded by the task implementation.
>
> Cheers,
> Anjana.
>
>
>>
>> Thanks,
>> Sinthuja.
>>
>> On Mon, Mar 20, 2017 at 10:50 AM, Jasintha Dasanayake 
>> wrote:
>>
>>> HI All
>>>
>>> When DAS working in tenant mode and a particular tenant has MQTT
>>> receivers, those cannot be activated once tenants get unloaded. For an
>>> example , if I restart the DAS then those tenants specific MQTT receivers
>>> are not loaded unless we explicitly load that particular tenant. IMO,
>>> expected behavior would be, those receivers should be loaded and subscribed
>>> to a particular topic without loading the tenants explicitly.
>>>
>>> Are there any known mechanism to address this particular problem ?
>>>
>>> Thanks and Regards
>>> /jasintha
>>>
>>> --
>>>
>>> *Jasintha Dasanayake**Associate Technical Lead*
>>>
>>> *WSO2 Inc. | http://wso2.com lean . enterprise .
>>> middleware*
>>>
>>>
>>> *mobile :- 0711-368-118 <071%20136%208118>*
>>>
>>
>>
>>
>> --
>> *Sinthuja Rajendran*
>> Technical Lead
>> WSO2, Inc.:http://wso2.com
>>
>> Blog: http://sinthu-rajan.blogspot.com/
>> Mobile: +94774273955 <077%20427%203955>
>>
>>
>>
>
>
> --
> *Anjana Fernando*
> Associate Director / Architect
> WSO2 Inc. | http://wso2.com
> lean . enterprise . middleware
>



-- 

*Jasintha Dasanayake**Associate Technical Lead*

*WSO2 Inc. | http://wso2.com lean . enterprise .
middleware*


*mobile :- 0711-368-118*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] tenant specific MQTT receivers in DAS , not listening to topics once tenant get unloaded

[Anjana Fernando]

Hi,

On Mon, Mar 20, 2017 at 11:02 AM, Sinthuja Ragendran 
wrote:

> Hi,
>
> As the receiver configurations are deployable artefacts, those will be
> active when the tenant is loaded. One approach is to have all tenants
> loaded indefinitely. I think this will have high memory. And therefore we
> internally discussed below approach to handling this problem.
>
> Instead of having multiple MQTT receiver configurations per tenant to
> handle this, implement a specialised/privileged MQTT event receiver which
> could handle multiple subscriptions on behalf of tenants, and it's only
> deployable in the super tenant mode. In that case, this event receiver will
> have the topic URI with {tenantDomain} placeholder and it is used to
> subscribe to the specific tenanted topic. And then, based on which topic
> the event has arrived the tenant flow will be started and an event will be
> inserted into specific tenant space. By this way, only the tenants which
> are actively used/sending events will be loaded, and not all tenants are
> required to be loaded.
>
> Please share your thoughts on this. Also, AFAIR we had the similar
> requirement for Task execution. @Anjana, how are we handling that?
>

Yes, the tasks and their definitions are stored in the super tenant space.
So they get triggered appropriately, and as required, any tenant specific
resources would be loaded by the task implementation.

Cheers,
Anjana.


>
> Thanks,
> Sinthuja.
>
> On Mon, Mar 20, 2017 at 10:50 AM, Jasintha Dasanayake 
> wrote:
>
>> HI All
>>
>> When DAS working in tenant mode and a particular tenant has MQTT
>> receivers, those cannot be activated once tenants get unloaded. For an
>> example , if I restart the DAS then those tenants specific MQTT receivers
>> are not loaded unless we explicitly load that particular tenant. IMO,
>> expected behavior would be, those receivers should be loaded and subscribed
>> to a particular topic without loading the tenants explicitly.
>>
>> Are there any known mechanism to address this particular problem ?
>>
>> Thanks and Regards
>> /jasintha
>>
>> --
>>
>> *Jasintha Dasanayake**Associate Technical Lead*
>>
>> *WSO2 Inc. | http://wso2.com lean . enterprise .
>> middleware*
>>
>>
>> *mobile :- 0711-368-118 <071%20136%208118>*
>>
>
>
>
> --
> *Sinthuja Rajendran*
> Technical Lead
> WSO2, Inc.:http://wso2.com
>
> Blog: http://sinthu-rajan.blogspot.com/
> Mobile: +94774273955 <077%20427%203955>
>
>
>


-- 
*Anjana Fernando*
Associate Director / Architect
WSO2 Inc. | http://wso2.com
lean . enterprise . middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] tenant specific MQTT receivers in DAS , not listening to topics once tenant get unloaded

[Mohanadarshan Vivekanandalingam]

Yes, I had a chat with Jasintha on this as well.

In this case, we have a topic for each tenant since there are some
permission and authorizations involved with each tenant. Then we need to
connect to multiple topics to consume events from multiple tenants. This
means we need to maintain multiple subscriptions from DAS (1 subscription
for 1 topic).

Now the question is how to maintain tenant specific subscriptions in DAS.
Since we are using MQTT here, eager loading is the option that we suggest
to deploy tenant specific artifacts in server startup but since this is
cloud scenario, loading all the tenants in the startup is not an option as
suggested by Sinthuja. Then good option is maintaining the subscriptions of
tenants in super tenant level and push events by starting the tenant flow
based on the topic that we received the message. Here I believe, it is good
to have 1 receiver artifact for each tenant then if need to remove a
subscription of tenant then we can simply delete relevant artifact.

Thanks,
Mohan


On Mon, Mar 20, 2017 at 2:05 PM, Sinthuja Ragendran 
wrote:

> Hi Ayyoob,
>
> On Mon, Mar 20, 2017 at 1:54 PM, Ayyoob Hamza  wrote:
>
>> Agree that it's better to handle this in super tenant layer due to its
>> complexity, but I wonder whether this needs to be specific for
>> MQTT scenarios. Because we need the same requirement for HTTP and thrift
>> receivers. So for HTTP and Thrift can we have it through super tenant space
>> or do we have to think of a generic solution on how to deploy the artifacts
>> for the tenants.
>>
>
> Thrift case is different, because there is only one listener for all
> tenants and we don't start different endpoints/listeners per tenant. And
> the tenent flow is started, once the tenant is authenticated and sending
> the events. In the case of HTTP, we do have the same problem as MQTT. In
> HTTP case, there is seperate HTTP endpoints registered for different
> tenants, and AFAIR those will be removed once the tenant is unloaded. So
> far, we didn't have problems in the deployments as HTTP or other receivers
> than thrift is used in the multi tenant case.
>
>>
>> In addition to recievers, we are using publishers and
>> tenant-specific summarisation scripts, does these gets undeployed when the
>> tenant is unloaded ?.
>>
>
> Summarization scripts will work, AFAIR the tasks registered for the
> tenants will be still active though the tenant is unloaded, and once the
> trigger has been received for the task, it will be loading the tenant and
> executing the script. For the event publishers, the same issue exists, but
> before the publisher gets tiggered the event should be arrived into the
> core, and by that time the tenant is already loaded and hence I believe the
> publishers will not be having this problem.
>
> Thanks,
> Sinthuja.
>
>
>>
>> Thanks,
>> *Ayyoob Hamza*
>> *Software Engineer*
>> WSO2 Inc.; http://wso2.com
>> email: ayy...@wso2.com cell: +94 77 1681010 <%2B94%2077%207779495>
>>
>
>
>
> --
> *Sinthuja Rajendran*
> Technical Lead
> WSO2, Inc.:http://wso2.com
>
> Blog: http://sinthu-rajan.blogspot.com/
> Mobile: +94774273955 <+94%2077%20427%203955>
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*V. Mohanadarshan*
*Associate Tech Lead,*
*Data Technologies Team,*
*WSO2, Inc. http://wso2.com  *
*lean.enterprise.middleware.*

email: mo...@wso2.com
phone:(+94) 771117673 <+94%2077%20111%207673>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] tenant specific MQTT receivers in DAS , not listening to topics once tenant get unloaded

[Sinthuja Ragendran]

Hi Ayyoob,

On Mon, Mar 20, 2017 at 1:54 PM, Ayyoob Hamza  wrote:

> Agree that it's better to handle this in super tenant layer due to its
> complexity, but I wonder whether this needs to be specific for
> MQTT scenarios. Because we need the same requirement for HTTP and thrift
> receivers. So for HTTP and Thrift can we have it through super tenant space
> or do we have to think of a generic solution on how to deploy the artifacts
> for the tenants.
>

Thrift case is different, because there is only one listener for all
tenants and we don't start different endpoints/listeners per tenant. And
the tenent flow is started, once the tenant is authenticated and sending
the events. In the case of HTTP, we do have the same problem as MQTT. In
HTTP case, there is seperate HTTP endpoints registered for different
tenants, and AFAIR those will be removed once the tenant is unloaded. So
far, we didn't have problems in the deployments as HTTP or other receivers
than thrift is used in the multi tenant case.

>
> In addition to recievers, we are using publishers and
> tenant-specific summarisation scripts, does these gets undeployed when the
> tenant is unloaded ?.
>

Summarization scripts will work, AFAIR the tasks registered for the tenants
will be still active though the tenant is unloaded, and once the trigger
has been received for the task, it will be loading the tenant and executing
the script. For the event publishers, the same issue exists, but before the
publisher gets tiggered the event should be arrived into the core, and by
that time the tenant is already loaded and hence I believe the publishers
will not be having this problem.

Thanks,
Sinthuja.


>
> Thanks,
> *Ayyoob Hamza*
> *Software Engineer*
> WSO2 Inc.; http://wso2.com
> email: ayy...@wso2.com cell: +94 77 1681010 <%2B94%2077%207779495>
>



-- 
*Sinthuja Rajendran*
Technical Lead
WSO2, Inc.:http://wso2.com

Blog: http://sinthu-rajan.blogspot.com/
Mobile: +94774273955
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] tenant specific MQTT receivers in DAS , not listening to topics once tenant get unloaded

[Ayyoob Hamza]

Agree that it's better to handle this in super tenant layer due to its
complexity, but I wonder whether this needs to be specific for
MQTT scenarios. Because we need the same requirement for HTTP and thrift
receivers. So for HTTP and Thrift can we have it through super tenant space
or do we have to think of a generic solution on how to deploy the artifacts
for the tenants.

In addition to recievers, we are using publishers and
tenant-specific summarisation scripts, does these gets undeployed when the
tenant is unloaded ?.

Thanks,
*Ayyoob Hamza*
*Software Engineer*
WSO2 Inc.; http://wso2.com
email: ayy...@wso2.com cell: +94 77 1681010 <%2B94%2077%207779495>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] tenant specific MQTT receivers in DAS , not listening to topics once tenant get unloaded

[Srinath Perera]

I agree with Sinthuja. Having a receiver per tenant will be too heavy and
complicated and having a super tenant receiver that receives and handle
data will simplify the design.

--Srinath

On Mon, Mar 20, 2017 at 11:02 AM, Sinthuja Ragendran 
wrote:

> Hi,
>
> As the receiver configurations are deployable artefacts, those will be
> active when the tenant is loaded. One approach is to have all tenants
> loaded indefinitely. I think this will have high memory. And therefore we
> internally discussed below approach to handling this problem.
>
> Instead of having multiple MQTT receiver configurations per tenant to
> handle this, implement a specialised/privileged MQTT event receiver which
> could handle multiple subscriptions on behalf of tenants, and it's only
> deployable in the super tenant mode. In that case, this event receiver will
> have the topic URI with {tenantDomain} placeholder and it is used to
> subscribe to the specific tenanted topic. And then, based on which topic
> the event has arrived the tenant flow will be started and an event will be
> inserted into specific tenant space. By this way, only the tenants which
> are actively used/sending events will be loaded, and not all tenants are
> required to be loaded.
>
> Please share your thoughts on this. Also, AFAIR we had the similar
> requirement for Task execution. @Anjana, how are we handling that?
>
> Thanks,
> Sinthuja.
>
> On Mon, Mar 20, 2017 at 10:50 AM, Jasintha Dasanayake 
> wrote:
>
>> HI All
>>
>> When DAS working in tenant mode and a particular tenant has MQTT
>> receivers, those cannot be activated once tenants get unloaded. For an
>> example , if I restart the DAS then those tenants specific MQTT receivers
>> are not loaded unless we explicitly load that particular tenant. IMO,
>> expected behavior would be, those receivers should be loaded and subscribed
>> to a particular topic without loading the tenants explicitly.
>>
>> Are there any known mechanism to address this particular problem ?
>>
>> Thanks and Regards
>> /jasintha
>>
>> --
>>
>> *Jasintha Dasanayake**Associate Technical Lead*
>>
>> *WSO2 Inc. | http://wso2.com lean . enterprise .
>> middleware*
>>
>>
>> *mobile :- 0711-368-118 <071%20136%208118>*
>>
>
>
>
> --
> *Sinthuja Rajendran*
> Technical Lead
> WSO2, Inc.:http://wso2.com
>
> Blog: http://sinthu-rajan.blogspot.com/
> Mobile: +94774273955 <+94%2077%20427%203955>
>
>
>


-- 

Srinath Perera, Ph.D.
   http://people.apache.org/~hemapani/
   http://srinathsview.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] tenant specific MQTT receivers in DAS , not listening to topics once tenant get unloaded

[Sinthuja Ragendran]

Hi,

As the receiver configurations are deployable artefacts, those will be
active when the tenant is loaded. One approach is to have all tenants
loaded indefinitely. I think this will have high memory. And therefore we
internally discussed below approach to handling this problem.

Instead of having multiple MQTT receiver configurations per tenant to
handle this, implement a specialised/privileged MQTT event receiver which
could handle multiple subscriptions on behalf of tenants, and it's only
deployable in the super tenant mode. In that case, this event receiver will
have the topic URI with {tenantDomain} placeholder and it is used to
subscribe to the specific tenanted topic. And then, based on which topic
the event has arrived the tenant flow will be started and an event will be
inserted into specific tenant space. By this way, only the tenants which
are actively used/sending events will be loaded, and not all tenants are
required to be loaded.

Please share your thoughts on this. Also, AFAIR we had the similar
requirement for Task execution. @Anjana, how are we handling that?

Thanks,
Sinthuja.

On Mon, Mar 20, 2017 at 10:50 AM, Jasintha Dasanayake 
wrote:

> HI All
>
> When DAS working in tenant mode and a particular tenant has MQTT
> receivers, those cannot be activated once tenants get unloaded. For an
> example , if I restart the DAS then those tenants specific MQTT receivers
> are not loaded unless we explicitly load that particular tenant. IMO,
> expected behavior would be, those receivers should be loaded and subscribed
> to a particular topic without loading the tenants explicitly.
>
> Are there any known mechanism to address this particular problem ?
>
> Thanks and Regards
> /jasintha
>
> --
>
> *Jasintha Dasanayake**Associate Technical Lead*
>
> *WSO2 Inc. | http://wso2.com lean . enterprise .
> middleware*
>
>
> *mobile :- 0711-368-118 <071%20136%208118>*
>



-- 
*Sinthuja Rajendran*
Technical Lead
WSO2, Inc.:http://wso2.com

Blog: http://sinthu-rajan.blogspot.com/
Mobile: +94774273955
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture