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
