RE: [DISCUSS] What should the "Connection Pool" be named?

Well in go that's sort of how I currently do things: The ConnectionPool/Cache hands out PlcConnectionLeases ... these have the same interface as a PlcConnection, but are only a proxy to a real connection ... you can use it as every other connection, as soon as you call close, it's given back

Re: [DISCUSS] What should the "Connection Pool" be named?

Here is how I would create the abstraction; There are "physical connections" from the PLC4X to zero, one or more devices, and a single connection is held to each device. Then we need a solution where different threads can access each such physical connection in an ordered/shared manner. So,

[GitHub] [plc4x] sruehl commented on pull request #305: Remove commons-beanutils

sruehl commented on pull request #305: URL: https://github.com/apache/plc4x/pull/305#issuecomment-1018643462 @todoubaba I removed the dependency in develop. It should no longer use beanutils -- This is an automated message from the Apache Git Service. To respond to the message, please

[GitHub] [plc4x] chrisdutz commented on pull request #305: Remove commons-beanutils

chrisdutz commented on pull request #305: URL: https://github.com/apache/plc4x/pull/305#issuecomment-1018572230 > @todoubaba please have a look on my response on the mailing list But you please also see what others have written ;-) -- This is an automated message from the Apache

[GitHub] [plc4x] sruehl commented on a change in pull request #305: Remove commons-beanutils

sruehl commented on a change in pull request #305: URL: https://github.com/apache/plc4x/pull/305#discussion_r789702016 ## File path: plc4j/spi/pom.xml ## @@ -48,10 +48,6 @@ netty-transport - Review comment: please check if upstream can fix that.

[GitHub] [plc4x] sruehl commented on pull request #305: Remove commons-beanutils

sruehl commented on pull request #305: URL: https://github.com/apache/plc4x/pull/305#issuecomment-1018549163 @todoubaba please have a look on my response on the mailing list -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub

[GitHub] [plc4x] chrisdutz commented on pull request #305: Remove commons-beanutils

chrisdutz commented on pull request #305: URL: https://github.com/apache/plc4x/pull/305#issuecomment-1018539126 Please have a look at the tweaks I did ... but thank you very much for your PR :-) -- This is an automated message from the Apache Git Service. To respond to the message,

RE: [DISCUSS] Remove commons-beanutils dependency

I just had a look and added a review. If you want, I've slight tweaked your version and am currently running the test-suite. As soon as that's done I could propose a little change. Chris -Original Message- From: Christofer Dutz Sent: Freitag, 21. Januar 2022 14:04 To:

RE: [DISCUSS] What should the "Connection Pool" be named?

Hi Stephen, Regarding the name ... we could Name it Cache (which is technically more correct) but we add in the JavaDoc that it's sort of a special ConnectionPool and perhaps add a page to the website which also mentions that, so someone coding with google, can find it. I'm happy with that.

[GitHub] [plc4x] chrisdutz commented on a change in pull request #305: Remove commons-beanutils

chrisdutz commented on a change in pull request #305: URL: https://github.com/apache/plc4x/pull/305#discussion_r789644825 ## File path: plc4j/spi/src/main/java/org/apache/plc4x/java/spi/configuration/ConfigurationFactory.java ## @@ -178,63 +171,78 @@ private static Object

RE: [DISCUSS] Remove commons-beanutils dependency

Hi Yang ... Thanks for that. For some reason I didn't see any notifications about that ... I'll look into it right away. Thank you very much. Chris -Original Message- From: 杨 林 Sent: Freitag, 21. Januar 2022 13:41 To: dev@plc4x.apache.org Subject: 回复: [DISCUSS] Remove

Re: [DISCUSS] What should the "Connection Pool" be named?

Hello, On Fri, 2022-01-21 at 11:35 +, Christofer Dutz wrote: > Hi all, > > in the past we had a "ConnectionPool" ... but in reality, we don't > have a pool of multiple connection to one target, like in databases, > but usually we have only one connection to each source in the "pool". > But

回复: [DISCUSS] Remove commons-beanutils dependency

Hi Chris, The PR is submitted two days ago, https://github.com/apache/plc4x/pull/305. I think it’s better to minimize library dependency, expecially the library is only used in one place. Yang Lin 发件人: Christofer Dutz 发送时间: 2022年1月21日 19:17 收件人:

Re: [DISCUSS] Extend PlcDriver with "supportedTransports"?

Chris by accident sent answer to me (we both love Thunderbird for that). ;-) There is a bit of risk with listing all transports as for modbus as we will effectively end up with tcp, serial and udp (at some point, who knows what else?). ;-) I need to check how optional runtime dependencies

[DISCUSS] What should the "Connection Pool" be named?

Hi all, in the past we had a "ConnectionPool" ... but in reality, we don't have a pool of multiple connection to one target, like in databases, but usually we have only one connection to each source in the "pool". But we can have multiple connections to multiple targets. I guess that's why

RE: More possible problems with connection pools

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

RE: [DISCUSS] Remove commons-beanutils dependency

I fully agree with Lukasz here .. so if we are indeed using beanutils for only this case, we should get rid of it. Less code in the classpath with stuff we actually don't need and which could possibly be a CVE problem. So, I did a quick check, and indeed we only have one usage of something in

Re: [DISCUSS] Remove commons-beanutils dependency

I could argue here as reducing external dependencies for smallish utilities is usually a good thing. If we can get rid of one dependency in favor of our own small targeted reflection helper which doesn't do much this change is good. Bringing 250kb commons for single class isn't something I

RE: [DISCUSS] Remove commons-beanutils dependency

But I agree with Yang, The fix should be trivial and I would really be happy if we got a PR from him :-) Chris -Original Message- From: Sebastian Rühl Sent: Freitag, 21. Januar 2022 11:01 To: dev@plc4x.apache.org Subject: Re: [DISCUSS] Remove commons-beanutils dependency Hi Yang,

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

Re: [DISCUSS] Remove commons-beanutils dependency

Hi Yang, could you please try bring that issue up to the upstream project? We don't want to replicate this logic in PLC4X if this can be solved upstream (at common-beanutils). Maybe there is a alternative implementation for java pojos that I'am currently not aware of. Other than that it's

RE: More possible problems with connection pools

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

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

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

More possible problems with connection pools

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