May be the word Service for this context is misleading. I referred to a java interface + implementation and I didn’t mean a new process with its own container.
For example: Interface name could be
TenantPlanValidator and default implementation that will be shipped with Hono could be
DefaultTenantPlanValidator.
Best Regards,
Karthees
From: hono-dev-bounces@xxxxxxxxxxx <hono-dev-bounces@xxxxxxxxxxx>
On Behalf Of Hudalla Kai (INST/ECS4)
Sent: Freitag, 1. Februar 2019 16:26
To: hono developer discussions <hono-dev@xxxxxxxxxxx>
Subject: Re: [hono-dev] [Hono #927 & #929] Limit number of connections and messages based on data volume for a tenant
I am not sure I understand what you mean with the "new Java service". Are you talking about a new process which would run in its own container?
Hi Dejan, Jens and Kai,
Already I came across the caching of the tenant information and I thought that the
TenantService can instruct not to cache the information in case of any configured limits, so that the protocol adapters get more recent updates. I like the approach to directly invoke a new Java service without any amqp communication and get the configured
limits from the TenantObject.
Tenant connection and message plans can be based on any number of factors. For example to allow further messages or not, can be based on limits on number of messages over a period
of time, data volume or it can also be based on number of successful transactions made on any external system. In that case, IMHO it is better that the new Java Service makes decisions based on the various configured plans instead of the adapters. Adapters
can invoke this new Service (ex. using methods “allowConnections(tenantObject)”
/ ”allowMessages(tenantObject)” ) to check if further connections or messages are allowed. In this way, a Hono user can easily bring their own plan validation implementation and plug it in to the adapters.
Hono can be shipped with a default implementation of the above service to validate the number of connections and data volume. I like the concept of caching like gps data. The
new Java service can cache the metrics backend and I don’t see any other useful data that can be cached. If you have more specific idea on that, please throw some light on it. Does it mean, if the metrics backend is not reachable, then make use of the cached
metrics data to make decisions?
Best Regards
Karthees
Mit freundlichen Grüßen / Best regards
Kartheeswaran Kalidass
Engineering Cloud Services 4 Bosch IoT Hub (INST/ECS4)
Bosch Software Innovations GmbH | Stuttgarter Straße 130 | 71332 Waiblingen |
GERMANY | www.bosch-si.com
Kartheeswaran.Kalidass@xxxxxxxxxxxx
Sitz: Berlin, Registergericht: Amtsgericht Charlottenburg; HRB 148411 B
Aufsichtsratsvorsitzender: Dr.-Ing. Thorsten Lücke; Geschäftsführung: Dr. Stefan Ferber, Michael Hahn, Dr. Aleksandar Mitrovic
I’m also inclined to do make decisions locally (on the adapter level). Of course, plan data should be stored in the TenantObject.
So storing the tenant plan information in the tenant service is absolutely fine. Let's not have another persistent storage. But I think the decision should be made in the protocol adapter, and not inside the tenant service.
I hope this is what you meant.
Hi Jens & Karthees,
first I was a little concerned regarding the direct dependency on the metrics back end that your proposal would introduce to the protocol adapters. But in fact, we already have that anyway, so abstracting
that dependency using a strategy interface seems like a good idea.
I also like the idea of using a combination of (potentially cached) information from the metrics back end and local (more recent) information. This reminds me of car that has GPS but uses local sensors
when inside of a tunnel ...
I would still propose to manage the limits for a tenant in the Tenant service and transfer them as part of the get Tenant operation's response to the protocol adapters. The adapters can then make
a local decision based on all of that information. If the limits are adapted for a tenant then IMHO it should not be too much of a problem for the change to take effect only after all cached values have timed out. In the end we already have that problem for
the "enabled" flag as well.
Cheers,
Kai
I am not sure this works implementing this in the Tenant Service itself. I dug a little bit deeper after our conversation yesterday: The protocol adapter does ask the tenant service for more information, but then it locally caches the tenant
information in the protocol adapter. So if the Tenant Service would implement the functionality of rejecting a new connection, then this wouldn't really work as this information would be cached as well inside the protocol adapter.
I mentioned yesterday in the call that it might not be necessary to create a new AMQP service for that. But simply a Java service (interface + impl) to check for that. So no additional AMQP communication would be required. This adapter
could look up the information from the Prometheus endpoint, and make a decision locally. It could also cache the information from prometheus, but still keep a record of local changes and make a local decision.
That way you could drop in implementations based on other metrics backends, you don't need to rewrite the device registry, and you don't add new AMQP traffic.
Hi all,
In my last mail, I sent a proposal regarding limiting the number of device connections [#927] and messages based on
data volume [#929] per tenant. As part of that, two new methods are to be introduced to the
TenantObject, which can be used by the protocol adapters before accepting any new connections or messages. And the implementation to verify those limitations was proposed be part of the
TenantService implementation. Hono file system based device registry (FileBasedTenantService) will contain a reference implementation using metrics data to verify against the configured limits .
Today in the Hono community meeting, we had a chance to discuss about this topic.
@Jens Thanks for the suggestion. Which is instead of implementing this as a part of the TenantService to bring this
as part of a new Service (ex. TenatLimitationService or TenatPlanService). I like this separation of concern approach.
Also Hono users would bring their own Device Registry (so the
TenantService implementation). If the metrics based reference implementation is part of the new Service, then it is easy for them to reuse.
I gave a thought about this approach. Currently protocol adapters before accepting any new connections or messages,
make a request to the TenantService to get the TenantObject. In addition to that, to verify the limitations, the adapters must also make a request to the new Service.
It seems to me, that it brings more amqp traffic. Considering this, IMHO it seems good to have these 2 methods (if
to allow connections and messages) as part of the TenantService. WDYT?
To make the method names more intuitive, I would suggest to rename “boolean checkWithConnectionPlan()” to “boolean
allowConnections()” and “boolean checkWithMessagePlan()” to “boolean allowMessages()”.
Best Regards,
Karthees
Hi all,
I would like to talk about the below two issues, share an implementation proposal and hear your views on it.
#927 - Limit the number of simultaneously connected devices. (Example: Tenant A can has a connection plan of 10000
simultaneously connected devices).
#929 - The data volume over a period should not exceed the configured value per tenant. (Example: Tenant A has a data
usage plan of 2 GB per month).
In the above cases, protocol adapters must ensure that the number of simultaneously connected devices and the data
volume (used over a period) for a tenant don't exceed the configured limits. In a real world scenario, apart from the number of connections and the data volume, more plans based on other factors are also possible such as limiting the number of messages per
tenant for a time period. FMPOV it is basically connection and message plans for a tenant.
I can imagine very well the below two methods, which can be used by the Protocol adapters to check the plans before
accepting a connection or a message. I think device registry (TenantObject) might be a suitable central place to hold these two methods.
Users with their own implementation of device registry can have their own implementation of these methods. I would
like to start with #927 by providing a reference implementation with the default device registry shipped with Hono. As part of this, I would like to make the limits configurable by adding a parameter “connections-limit" to the tenant configuration. Inside
method “checkWithConnectionPlan(tenanId)”, connections related metrics data from Prometheus Backend will be used to validate the connections limit and the result is returned. Followed by changes in Protocol adapters to use this method to check the connections
limit before accepting a connection.
/**
* Checks with the connection plan before accepting a new connection for a given tenantId
* @param tenantId The tenant for which the object is constructed.
* @returns if a new device connection is allowed or not.
*/
public static boolean checkWithConnectionPlan(final String tenantId);
/**
* Checks with the message plan before accepting a message for a given tenantId
* @param tenantId The tenant for which the object is constructed.
* @returns if a message can be accepted or not.
*/
public static boolean checkWithMessagePlan(final String tenantId);
WDYT?
Best Regards
Karthees
_______________________________________________
hono-dev mailing list
hono-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/hono-dev
--
Jens Reimann
Principal Software Engineer / EMEA ENG Middleware
Werner-von-Siemens-Ring 14
85630 Grasbrunn
Germany
phone: +49 89 2050 71286
_____________________________________________________________________________
Red Hat GmbH, www.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill
_______________________________________________
hono-dev mailing list
hono-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/hono-dev
--
Jens Reimann
Principal Software Engineer / EMEA ENG Middleware
Werner-von-Siemens-Ring 14
85630 Grasbrunn
Germany
phone: +49 89 2050 71286
_____________________________________________________________________________
Red Hat GmbH, www.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill
_______________________________________________
hono-dev mailing list
hono-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/hono-dev
--
|
