More possible problems with connection pools

[Christofer Dutz <ch...@c-ware.de>]

Hi all,

as I'm currently working on the go connection-pool and here especially for the KNX protocol, I have come across a problem I am unsure how we should proceed in general. And I must admit, that I don't even know how the Java version would react @Julian?

So, imagine I have a connection pool, a process gets a connection and executes a read/write operation and as soon as that's finished, it returns the connection after that ... this is trivial.
But what happens with a subscription? Usually, you need to get the connection to subscribe and then you simply have the diver call you instead of calling it.

So instead of having the subscriber having to keep the connection to keep the subscription alive, I would opt for adding subscriptions to the connection and keeping them valid, even after the connection is returned to the pool. Yes, this causes subscriptions from multiple places in your application to get mixed up and potentially one part could interfere with another one (Like unsubscribe a subscription a different part subscribed for). But I think from an API perspective this would probably be the best option for the normal use-cases.

Another problem would be that if we had a pool, that allowed keeping multiple connections to one target, that for unsubscribing, you would need to ensure that you are getting the same instance as for subscribing. But I generally would consider: Multiple parallel connections to one PLC an edge-case that I haven't come across yet.

What do you think?

Chris

RE: More possible problems with connection pools

[Christofer Dutz <ch...@c-ware.de>]

Welll ... 

but multiple connections to different devices :-)

And yes: it will be an option to allow multiple connection in special cases, but the default would be to only have one.
I guess that's why Julian named his new component ConnectionCache, which slightly is closer to what it is in reality.
However, I would assume people to rather look for a ConnectionPool as that's what is being used in other contexts.

I'll open a discuss thread with how the others think we should name the thing.

Chris


-----Original Message-----
From: Niclas Hedhman <ni...@hedhman.org> 
Sent: Freitag, 21. Januar 2022 11:04
To: dev@plc4x.apache.org
Subject: Re: More possible problems with connection pools

On 2022-01-21 10:12, Christofer Dutz wrote:
> I think the very special problem we have here is the limitation of the 
> number of concurrent connections PLCs usually provide ... my S7 1200 
> allows 3 concurrent connections. My KNX gateway (which is one of the 
> better models allowing multiple concurrent connections) only allows 4 
> connections.

Ok, but then it sounds like "Connection Pool" isn't the appropriate general abstraction, since you are basically saying "Only one connection from PLC4X"

Cheers
Niclas

Re: More possible problems with connection pools

[Niclas Hedhman <ni...@hedhman.org>]

On 2022-01-21 10:12, Christofer Dutz wrote:
> I think the very special problem we have here is the limitation of the
> number of concurrent connections PLCs usually provide ... my S7 1200
> allows 3 concurrent connections. My KNX gateway (which is one of the
> better models allowing multiple concurrent connections) only allows 4
> connections.

Ok, but then it sounds like "Connection Pool" isn't the appropriate 
general abstraction, since you are basically saying "Only one connection 
from PLC4X"

Cheers
Niclas

RE: More possible problems with connection pools

[Christofer Dutz <ch...@c-ware.de>]

And as I mentioned: Due to this limitation of connections, the connection pool currently only handles one instance per target, so there isn't any transferring of subscriptions needed. However, I do need to figure out how to re-subscribe in case a connection goes bad.

Chris

-----Original Message-----
From: Christofer Dutz <ch...@c-ware.de> 
Sent: Freitag, 21. Januar 2022 10:13
To: dev@plc4x.apache.org
Subject: RE: More possible problems with connection pools

Hi Niclas,

I think the very special problem we have here is the limitation of the number of concurrent connections PLCs usually provide ... my S7 1200 allows 3 concurrent connections. My KNX gateway (which is one of the better models allowing multiple concurrent connections) only allows 4 connections. 

So, we really need to find a balance between the number of connections and the features we offer. 

In the case of KNX we even have the situation that, as soon as you connect to the gateway, you become part of the KNX network and everything happening on that is automatically forwarded to the clients. So, it's sort of: As soon as you connect, you subscribe to everything. The actual subscriptions I then handle by filtering this stream of incoming events by all subscriptions. But I know this will probably be different for other protocols (like Cesar's S7 Events)

So, in general, I would agree with your assumption, but in this case, I would try to use one connection for as much as possible. Assuming a S7-1200 is used and it has an HMI and the company has some sort of control-system. Then already 2 of the 3 available connections are used. In case of KNX: You usually need to keep one connection free for the engineering software, one for us and usually if you need any form of bridge or converter that also consumes at least one connection.

Chris



-----Original Message-----
From: Niclas Hedhman <ni...@hedhman.org>
Sent: Freitag, 21. Januar 2022 09:43
To: dev@plc4x.apache.org
Subject: Re: More possible problems with connection pools

On 2022-01-21 09:19, Christofer Dutz wrote:
> So instead of having the subscriber having to keep the connection to 
> keep the subscription alive, I would opt for adding subscriptions to 
> the connection and keeping them valid, even after the connection is 
> returned to the pool. Yes, this causes subscriptions from multiple 
> places in your application to get mixed up and potentially one part 
> could interfere with another one (Like unsubscribe a subscription a 
> different part subscribed for). But I think from an API perspective 
> this would probably be the best option for the normal use-cases.

I have had this exact issue (well, not KNX) a long time ago and I would like to provide a recommendation;

   * Don't put subscription on Request/Reply connections.

it will down the line complicate matters, with re-subscriptions when a request/reply fail for small modest reasons, the connection is torn down, and the subscriptions needing to be re-established, and possible clients unsubscribing while that is going on. AND dynamic allocation of connections becomes harder too, as one has to move subscriptions from one connection to another to be able to delete a connection from the pool.

Try to put subscription in separate API/interface.


Cheers
Niclas

RE: More possible problems with connection pools

[Christofer Dutz <ch...@c-ware.de>]

Hi Niclas,

I think the very special problem we have here is the limitation of the number of concurrent connections PLCs usually provide ... my S7 1200 allows 3 concurrent connections. My KNX gateway (which is one of the better models allowing multiple concurrent connections) only allows 4 connections. 

So, we really need to find a balance between the number of connections and the features we offer. 

In the case of KNX we even have the situation that, as soon as you connect to the gateway, you become part of the KNX network and everything happening on that is automatically forwarded to the clients. So, it's sort of: As soon as you connect, you subscribe to everything. The actual subscriptions I then handle by filtering this stream of incoming events by all subscriptions. But I know this will probably be different for other protocols (like Cesar's S7 Events)

So, in general, I would agree with your assumption, but in this case, I would try to use one connection for as much as possible. Assuming a S7-1200 is used and it has an HMI and the company has some sort of control-system. Then already 2 of the 3 available connections are used. In case of KNX: You usually need to keep one connection free for the engineering software, one for us and usually if you need any form of bridge or converter that also consumes at least one connection.

Chris



-----Original Message-----
From: Niclas Hedhman <ni...@hedhman.org> 
Sent: Freitag, 21. Januar 2022 09:43
To: dev@plc4x.apache.org
Subject: Re: More possible problems with connection pools

On 2022-01-21 09:19, Christofer Dutz wrote:
> So instead of having the subscriber having to keep the connection to 
> keep the subscription alive, I would opt for adding subscriptions to 
> the connection and keeping them valid, even after the connection is 
> returned to the pool. Yes, this causes subscriptions from multiple 
> places in your application to get mixed up and potentially one part 
> could interfere with another one (Like unsubscribe a subscription a 
> different part subscribed for). But I think from an API perspective 
> this would probably be the best option for the normal use-cases.

I have had this exact issue (well, not KNX) a long time ago and I would like to provide a recommendation;

   * Don't put subscription on Request/Reply connections.

it will down the line complicate matters, with re-subscriptions when a request/reply fail for small modest reasons, the connection is torn down, and the subscriptions needing to be re-established, and possible clients unsubscribing while that is going on. AND dynamic allocation of connections becomes harder too, as one has to move subscriptions from one connection to another to be able to delete a connection from the pool.

Try to put subscription in separate API/interface.


Cheers
Niclas

Re: More possible problems with connection pools

[Niclas Hedhman <ni...@hedhman.org>]

On 2022-01-21 09:19, Christofer Dutz wrote:
> So instead of having the subscriber having to keep the connection to
> keep the subscription alive, I would opt for adding subscriptions to
> the connection and keeping them valid, even after the connection is
> returned to the pool. Yes, this causes subscriptions from multiple
> places in your application to get mixed up and potentially one part
> could interfere with another one (Like unsubscribe a subscription a
> different part subscribed for). But I think from an API perspective
> this would probably be the best option for the normal use-cases.

I have had this exact issue (well, not KNX) a long time ago and I would 
like to provide a recommendation;

   * Don't put subscription on Request/Reply connections.

it will down the line complicate matters, with re-subscriptions when a 
request/reply fail for small modest reasons, the connection is torn 
down, and the subscriptions needing to be re-established, and possible 
clients unsubscribing while that is going on. AND dynamic allocation of 
connections becomes harder too, as one has to move subscriptions from 
one connection to another to be able to delete a connection from the 
pool.

Try to put subscription in separate API/interface.


Cheers
Niclas