Re: API Module

[Christofer Dutz]

I commented them out as I thought we moved classes and probably move the tests 
to follow them.

Outlook for Android herunterladen


From: Andrey Skorikov 
Sent: Friday, October 26, 2018 4:49:05 PM
To: dev@plc4x.apache.org
Subject: API Module

Hello all,

currently there are some issues with the PLC4J API module:
  - the interface model.PlcField is never used in the API module
  - most of the tests are commented out; the rest of the tests does not
test anything sensible

I propose to remove the commented out code and useless tests from the
module; in fact this implies deleting all of the "tests" in the API
module. Since the API module provides only the interface for protocol
implementations, there is nothing to test anyway.

Furthermore I propose to move the types that are not used in the API
module to modules where they are actually used, if any. The idea is to
keep the API module as clean as possible, for both clients and protocol
implementors.

What do you think?

Best regards,
Andrey

AW: Plc-opm

[Julian Feinauer]

Thank you so much sebastian, for your warm and motivating words and even more 
for cleaning up the mess from the github-gitbox desync combined with some merge 
related problems with the branch.


Julian


Von: Sebastian Rühl 
Gesendet: Freitag, 26. Oktober 2018 19:21:54
An: dev@plc4x.apache.org
Betreff: Re: Plc-opm

Hi all,

I was able to fix the the remaining issues from the merges (GitHub-gitbox 
desync)  in the commit (9bb69d9 

 
https://github.com/apache/incubator-plc4x/commit/4ad765e3d7328526a8bbfe7b5918645be74ca603).
Again, thanks to Julian for the great work on plc4j-opm, this looks really 
promising and my first impressions are really good :).  Keep up the good work.

Sebastian

> Am 26.10.2018 um 18:58 schrieb Sebastian Rühl 
> :
>
> Hi,
>
> We still have issues with the build of plc-ops which I currently fix in 
> master.
> (Still using 0.1.0-SNAPSHOT driver bases)
> @chris: time for the enforcer plugin sanity checks ;)
>
> Sebastian

Re: Plc-opm

[Sebastian Rühl]

Hi all,

I was able to fix the the remaining issues from the merges (GitHub-gitbox 
desync)  in the commit (9bb69d9 

 
https://github.com/apache/incubator-plc4x/commit/4ad765e3d7328526a8bbfe7b5918645be74ca603).
Again, thanks to Julian for the great work on plc4j-opm, this looks really 
promising and my first impressions are really good :).  Keep up the good work.

Sebastian

> Am 26.10.2018 um 18:58 schrieb Sebastian Rühl 
> :
> 
> Hi,
> 
> We still have issues with the build of plc-ops which I currently fix in 
> master.
> (Still using 0.1.0-SNAPSHOT driver bases)
> @chris: time for the enforcer plugin sanity checks ;)
> 
> Sebastian

Plc-opm

[Sebastian Rühl]

Hi,

We still have issues with the build of plc-ops which I currently fix in master.
(Still using 0.1.0-SNAPSHOT driver bases)
@chris: time for the enforcer plugin sanity checks ;)

Sebastian

Re: OPM / Connection Pool

[Sebastian Rühl]

Thinks so...

> Am 26.10.2018 um 16:33 schrieb Julian Feinauer :
> 
> Hey,
> 
> 
> is this regarding the feature to return a Future of the send to fail if netty 
> is not able to send something, or?
> 
> 
> Julian
> 
> 
> Von: Sebastian Rühl 
> Gesendet: Freitag, 26. Oktober 2018 16:24:28
> An: dev@plc4x.apache.org
> Betreff: Re: OPM / Connection Pool
> 
> And btw:
> 
> Regarding timeouts:
> https://netty.io/4.1/api/io/netty/handler/timeout/ReadTimeoutHandler.html 
> 
> 
> https://netty.io/4.1/api/io/netty/handler/timeout/WriteTimeoutHandler.html 
> 
> 
> As simple as inserting one line of code in the pipelines :)
> `channel.pipeline().addLast("readTimeoutHandler", new ReadTimeoutHandler 
> (30);`
> 
>> Am 26.10.2018 um 16:17 schrieb Sebastian Rühl 
>> :
>> 
>> Hi Both,
>> 
>> What we would need then is something like this:
>> https://netty.io/4.1/api/io/netty/handler/traffic/ChannelTrafficShapingHandler.html
>>  
>> 
>> 
>> …only message based (e.g. 100 requests).
>> This could then be implemented in driver-bases (like the 
>> SingleItemToSingleRequestProtocol)  and could be used for protocol that 
>> don’t have sophisticated traffic control implementation like S7
>> 
>> Sebastian
>> 
>>> Am 26.10.2018 um 16:04 schrieb Julian Feinauer 
>>> mailto:j.feina...@pragmaticminds.de>>:
>>> 
>>> Hey Chris,
>>> 
>>> 
>>> yes, indeed, sorry for the confusion.
>>> 
>>> I agree with this "low level" limiting, as this is simply necessary to 
>>> ensure connection.
>>> 
>>> What I mean is that we could decide in an application to not send more than 
>>> 100 requests / s (for whatever reason) and handle that before forwarding 
>>> the requests to the pool.
>>> 
>>> 
>>> Julian
>>> 
>>> 
>>> Von: Christofer Dutz >> >
>>> Gesendet: Freitag, 26. Oktober 2018 16:01:37
>>> An: dev@plc4x.apache.org 
>>> Betreff: Re: OPM / Connection Pool
>>> 
>>> Hi Julian,
>>> 
>>> I think we might be thinking of different things when referring to 
>>> "limiting".
>>> In my case I know that a Siemens S7 device is able to process a maximum 
>>> number of concurrent requests. If more are sent, they are simply discarded 
>>> and an error response is sent.
>>> This maximum number of concurrent requests is agreed upon during the 
>>> connection phase in the maxAmqCaller and maxAmqCallee parameters. The S7 
>>> driver now automatically limits the number of requests sent out to respect 
>>> these boundaries. And I don't see an option to handle this generically 
>>> except to limit it to 1 globally.
>>> 
>>> I think you are referring to something else. Could you please explain to us 
>>> what you mean with "request limiting".
>>> 
>>> Chris
>>> 
>>> Am 26.10.18, 15:55 schrieb "Julian Feinauer" >> >:
>>> 
>>>   Hey Sebastian,
>>> 
>>> 
>>>   the only problem witht he reuse i had is possible internal state during 
>>> in-flight messages or problems with multi threading (I'm not sure if all 
>>> drivers are thread safe and stateless during in-flight messages), but I 
>>> agree that this is minor currently, just wanted to add the todo to keep it 
>>> in view : )
>>> 
>>>   Request Limiting is, as I think, no concern of the driver itself, I 
>>> think, so I would add request limiting probably in an layer above thus I'm 
>>> totally fine.
>>> 
>>> 
>>>   With regards to Marcels branch I thought it would be ideal to move over 
>>> its ProxyConnection as this is everything thats needed to fix the todo (all 
>>> methods delegate untill close() is called then all throw an unsupported 
>>> operation exception. This is similar to what common jdbc pools do, I 
>>> checked dbcp and some other one).
>>> 
>>> 
>>>   Yes, we can directly add the validation hook from commons pool, but I 
>>> think we need a plc specific ping method in the api to call as we have no 
>>> "common" field or "query" we can issue.
>>> 
>>> 
>>>   Best
>>> 
>>>   Julian
>>> 
>>>   
>>>   Von: Sebastian Rühl >> >
>>>   Gesendet: Freitag, 26. Oktober 2018 13:23:55
>>>   An: dev@plc4x.apache.org 
>>>   Betreff: Re: OPM / Connection Pool
>>> 
>>>   Hi Julian,
>>> 
>>>   Regarding the reuse of Connections:
>>>   I was aware of that issue but forgot to add a TODO for that (sorry for 
>>> that). But in general a pool is not a request limiter rater a connection 
>>> limiter. Therefore the continue use shouldn’t be that big of an issue for 
>>> the time being (Till we resolve that issue).
>>> 
>>>   Request Limiting:
>>>   

AW: OPM / Connection Pool

[Julian Feinauer]

Hey,


is this regarding the feature to return a Future of the send to fail if netty 
is not able to send something, or?


Julian


Von: Sebastian Rühl 
Gesendet: Freitag, 26. Oktober 2018 16:24:28
An: dev@plc4x.apache.org
Betreff: Re: OPM / Connection Pool

And btw:

Regarding timeouts:
https://netty.io/4.1/api/io/netty/handler/timeout/ReadTimeoutHandler.html 


https://netty.io/4.1/api/io/netty/handler/timeout/WriteTimeoutHandler.html 


As simple as inserting one line of code in the pipelines :)
`channel.pipeline().addLast("readTimeoutHandler", new ReadTimeoutHandler 
(30);`

> Am 26.10.2018 um 16:17 schrieb Sebastian Rühl 
> :
>
> Hi Both,
>
> What we would need then is something like this:
> https://netty.io/4.1/api/io/netty/handler/traffic/ChannelTrafficShapingHandler.html
>  
> 
>
> …only message based (e.g. 100 requests).
> This could then be implemented in driver-bases (like the 
> SingleItemToSingleRequestProtocol)  and could be used for protocol that don’t 
> have sophisticated traffic control implementation like S7
>
> Sebastian
>
>> Am 26.10.2018 um 16:04 schrieb Julian Feinauer > >:
>>
>> Hey Chris,
>>
>>
>> yes, indeed, sorry for the confusion.
>>
>> I agree with this "low level" limiting, as this is simply necessary to 
>> ensure connection.
>>
>> What I mean is that we could decide in an application to not send more than 
>> 100 requests / s (for whatever reason) and handle that before forwarding the 
>> requests to the pool.
>>
>>
>> Julian
>>
>> 
>> Von: Christofer Dutz > >
>> Gesendet: Freitag, 26. Oktober 2018 16:01:37
>> An: dev@plc4x.apache.org 
>> Betreff: Re: OPM / Connection Pool
>>
>> Hi Julian,
>>
>> I think we might be thinking of different things when referring to 
>> "limiting".
>> In my case I know that a Siemens S7 device is able to process a maximum 
>> number of concurrent requests. If more are sent, they are simply discarded 
>> and an error response is sent.
>> This maximum number of concurrent requests is agreed upon during the 
>> connection phase in the maxAmqCaller and maxAmqCallee parameters. The S7 
>> driver now automatically limits the number of requests sent out to respect 
>> these boundaries. And I don't see an option to handle this generically 
>> except to limit it to 1 globally.
>>
>> I think you are referring to something else. Could you please explain to us 
>> what you mean with "request limiting".
>>
>> Chris
>>
>> Am 26.10.18, 15:55 schrieb "Julian Feinauer" > >:
>>
>>Hey Sebastian,
>>
>>
>>the only problem witht he reuse i had is possible internal state during 
>> in-flight messages or problems with multi threading (I'm not sure if all 
>> drivers are thread safe and stateless during in-flight messages), but I 
>> agree that this is minor currently, just wanted to add the todo to keep it 
>> in view : )
>>
>>Request Limiting is, as I think, no concern of the driver itself, I 
>> think, so I would add request limiting probably in an layer above thus I'm 
>> totally fine.
>>
>>
>>With regards to Marcels branch I thought it would be ideal to move over 
>> its ProxyConnection as this is everything thats needed to fix the todo (all 
>> methods delegate untill close() is called then all throw an unsupported 
>> operation exception. This is similar to what common jdbc pools do, I checked 
>> dbcp and some other one).
>>
>>
>>Yes, we can directly add the validation hook from commons pool, but I 
>> think we need a plc specific ping method in the api to call as we have no 
>> "common" field or "query" we can issue.
>>
>>
>>Best
>>
>>Julian
>>
>>
>>Von: Sebastian Rühl > >
>>Gesendet: Freitag, 26. Oktober 2018 13:23:55
>>An: dev@plc4x.apache.org 
>>Betreff: Re: OPM / Connection Pool
>>
>>Hi Julian,
>>
>>Regarding the reuse of Connections:
>>I was aware of that issue but forgot to add a TODO for that (sorry for 
>> that). But in general a pool is not a request limiter rater a connection 
>> limiter. Therefore the continue use shouldn’t be that big of an issue for 
>> the time being (Till we resolve that issue).
>>
>>Request Limiting:
>>A separate generic request limiter feature would be nice but is 
>> out-of-scope of the pool. In case of S7 this is builtin 
>> (maxAmqCaller/maxAmqCallee).
>>
>>Regarding the branch of Marcel (And thanks for the great contribution 
>> Marcel :):

Re: OPM / Connection Pool

[Sebastian Rühl]

And btw:

Regarding timeouts:
https://netty.io/4.1/api/io/netty/handler/timeout/ReadTimeoutHandler.html 


https://netty.io/4.1/api/io/netty/handler/timeout/WriteTimeoutHandler.html 


As simple as inserting one line of code in the pipelines :)
`channel.pipeline().addLast("readTimeoutHandler", new ReadTimeoutHandler 
(30);`

> Am 26.10.2018 um 16:17 schrieb Sebastian Rühl 
> :
> 
> Hi Both,
> 
> What we would need then is something like this:
> https://netty.io/4.1/api/io/netty/handler/traffic/ChannelTrafficShapingHandler.html
>  
> 
> 
> …only message based (e.g. 100 requests).
> This could then be implemented in driver-bases (like the 
> SingleItemToSingleRequestProtocol)  and could be used for protocol that don’t 
> have sophisticated traffic control implementation like S7
> 
> Sebastian
> 
>> Am 26.10.2018 um 16:04 schrieb Julian Feinauer > >:
>> 
>> Hey Chris,
>> 
>> 
>> yes, indeed, sorry for the confusion.
>> 
>> I agree with this "low level" limiting, as this is simply necessary to 
>> ensure connection.
>> 
>> What I mean is that we could decide in an application to not send more than 
>> 100 requests / s (for whatever reason) and handle that before forwarding the 
>> requests to the pool.
>> 
>> 
>> Julian
>> 
>> 
>> Von: Christofer Dutz > >
>> Gesendet: Freitag, 26. Oktober 2018 16:01:37
>> An: dev@plc4x.apache.org 
>> Betreff: Re: OPM / Connection Pool
>> 
>> Hi Julian,
>> 
>> I think we might be thinking of different things when referring to 
>> "limiting".
>> In my case I know that a Siemens S7 device is able to process a maximum 
>> number of concurrent requests. If more are sent, they are simply discarded 
>> and an error response is sent.
>> This maximum number of concurrent requests is agreed upon during the 
>> connection phase in the maxAmqCaller and maxAmqCallee parameters. The S7 
>> driver now automatically limits the number of requests sent out to respect 
>> these boundaries. And I don't see an option to handle this generically 
>> except to limit it to 1 globally.
>> 
>> I think you are referring to something else. Could you please explain to us 
>> what you mean with "request limiting".
>> 
>> Chris
>> 
>> Am 26.10.18, 15:55 schrieb "Julian Feinauer" > >:
>> 
>>Hey Sebastian,
>> 
>> 
>>the only problem witht he reuse i had is possible internal state during 
>> in-flight messages or problems with multi threading (I'm not sure if all 
>> drivers are thread safe and stateless during in-flight messages), but I 
>> agree that this is minor currently, just wanted to add the todo to keep it 
>> in view : )
>> 
>>Request Limiting is, as I think, no concern of the driver itself, I 
>> think, so I would add request limiting probably in an layer above thus I'm 
>> totally fine.
>> 
>> 
>>With regards to Marcels branch I thought it would be ideal to move over 
>> its ProxyConnection as this is everything thats needed to fix the todo (all 
>> methods delegate untill close() is called then all throw an unsupported 
>> operation exception. This is similar to what common jdbc pools do, I checked 
>> dbcp and some other one).
>> 
>> 
>>Yes, we can directly add the validation hook from commons pool, but I 
>> think we need a plc specific ping method in the api to call as we have no 
>> "common" field or "query" we can issue.
>> 
>> 
>>Best
>> 
>>Julian
>> 
>>
>>Von: Sebastian Rühl > >
>>Gesendet: Freitag, 26. Oktober 2018 13:23:55
>>An: dev@plc4x.apache.org 
>>Betreff: Re: OPM / Connection Pool
>> 
>>Hi Julian,
>> 
>>Regarding the reuse of Connections:
>>I was aware of that issue but forgot to add a TODO for that (sorry for 
>> that). But in general a pool is not a request limiter rater a connection 
>> limiter. Therefore the continue use shouldn’t be that big of an issue for 
>> the time being (Till we resolve that issue).
>> 
>>Request Limiting:
>>A separate generic request limiter feature would be nice but is 
>> out-of-scope of the pool. In case of S7 this is builtin 
>> (maxAmqCaller/maxAmqCallee).
>> 
>>Regarding the branch of Marcel (And thanks for the great contribution 
>> Marcel :):
>>He did some good work but at the end the implementation was initially too 
>> different from the commons-pool one as I would have reverted/changed almost 
>> every line. So the idea was it to write it upfront in the separate module to 
>> have the 

Re: Happy birthday Toddy!

[Sebastian Rühl]

All the best Toddy ;D

> Am 16.10.2018 um 18:40 schrieb Christofer Dutz :
> 
> Happy birthday Toddy!
> 
> Today, one year ago, I did the first commit and look at us now! Wow ... Going 
> strong and stronger every day.
> 
> So happy the days are over, where I was talking to myself on this list. So 
> happy to have all you others on board :-)
> 
> Big goal for the next year: TLP :-)
> 
> Party on,
> Chris
> 
> 
> Outlook for Android herunterladen
> 

Re: OPM / Connection Pool

[Sebastian Rühl]

Hi Both,

What we would need then is something like this:
https://netty.io/4.1/api/io/netty/handler/traffic/ChannelTrafficShapingHandler.html
 


…only message based (e.g. 100 requests).
This could then be implemented in driver-bases (like the 
SingleItemToSingleRequestProtocol)  and could be used for protocol that don’t 
have sophisticated traffic control implementation like S7

Sebastian

> Am 26.10.2018 um 16:04 schrieb Julian Feinauer :
> 
> Hey Chris,
> 
> 
> yes, indeed, sorry for the confusion.
> 
> I agree with this "low level" limiting, as this is simply necessary to ensure 
> connection.
> 
> What I mean is that we could decide in an application to not send more than 
> 100 requests / s (for whatever reason) and handle that before forwarding the 
> requests to the pool.
> 
> 
> Julian
> 
> 
> Von: Christofer Dutz 
> Gesendet: Freitag, 26. Oktober 2018 16:01:37
> An: dev@plc4x.apache.org
> Betreff: Re: OPM / Connection Pool
> 
> Hi Julian,
> 
> I think we might be thinking of different things when referring to "limiting".
> In my case I know that a Siemens S7 device is able to process a maximum 
> number of concurrent requests. If more are sent, they are simply discarded 
> and an error response is sent.
> This maximum number of concurrent requests is agreed upon during the 
> connection phase in the maxAmqCaller and maxAmqCallee parameters. The S7 
> driver now automatically limits the number of requests sent out to respect 
> these boundaries. And I don't see an option to handle this generically except 
> to limit it to 1 globally.
> 
> I think you are referring to something else. Could you please explain to us 
> what you mean with "request limiting".
> 
> Chris
> 
> Am 26.10.18, 15:55 schrieb "Julian Feinauer" :
> 
>Hey Sebastian,
> 
> 
>the only problem witht he reuse i had is possible internal state during 
> in-flight messages or problems with multi threading (I'm not sure if all 
> drivers are thread safe and stateless during in-flight messages), but I agree 
> that this is minor currently, just wanted to add the todo to keep it in view 
> : )
> 
>Request Limiting is, as I think, no concern of the driver itself, I think, 
> so I would add request limiting probably in an layer above thus I'm totally 
> fine.
> 
> 
>With regards to Marcels branch I thought it would be ideal to move over 
> its ProxyConnection as this is everything thats needed to fix the todo (all 
> methods delegate untill close() is called then all throw an unsupported 
> operation exception. This is similar to what common jdbc pools do, I checked 
> dbcp and some other one).
> 
> 
>Yes, we can directly add the validation hook from commons pool, but I 
> think we need a plc specific ping method in the api to call as we have no 
> "common" field or "query" we can issue.
> 
> 
>Best
> 
>Julian
> 
>
>Von: Sebastian Rühl 
>Gesendet: Freitag, 26. Oktober 2018 13:23:55
>An: dev@plc4x.apache.org
>Betreff: Re: OPM / Connection Pool
> 
>Hi Julian,
> 
>Regarding the reuse of Connections:
>I was aware of that issue but forgot to add a TODO for that (sorry for 
> that). But in general a pool is not a request limiter rater a connection 
> limiter. Therefore the continue use shouldn’t be that big of an issue for the 
> time being (Till we resolve that issue).
> 
>Request Limiting:
>A separate generic request limiter feature would be nice but is 
> out-of-scope of the pool. In case of S7 this is builtin 
> (maxAmqCaller/maxAmqCallee).
> 
>Regarding the branch of Marcel (And thanks for the great contribution 
> Marcel :):
>He did some good work but at the end the implementation was initially too 
> different from the commons-pool one as I would have reverted/changed almost 
> every line. So the idea was it to write it upfront in the separate module to 
> have the possibility to compare it side by side and pick the goodies.
> 
>Regarding validation:
>The commons-pool validation calls isConnected() on return. So we could 
> implement the „ping“ in the isConnected() as well or implement a ping() as 
> you described.
> 
>Sebastian
> 
>> Am 25.10.2018 um 23:13 schrieb Julian Feinauer 
>> :
>> 
>> Hey all,
>> 
>> just wanted to keep you up to date with some things Sebastian and I 
>> discussed off-list.
>> Thanks to Sebastians support the Object Plc Mapping (opm) is now mergend 
>> into master and I would love to get some feedback.
>> I hope that I can soon add some documentation on the side about that and I 
>> would be happy if someone likes to implement writing (currently only reading 
>> is supported), see PLC4X-70.
>> 
>> Sebastian also added an implementation for the Connection Pool. This can 
>> become one of the most important features to make it usable in enterprise 
>> applications (pooling, keep 

Re: OPM / Connection Pool

[Sebastian Rühl]

Hi Julian,

When designing protocol adapters they shall be designed with thread safety in 
mind. So if we get issues here we should take care of if. Nevertheless 
regarding you comment (and you are quite right with that): Keep using a 
returned (or closed) connection from a pool is not what the designer had in 
mind. Therefore I implemented connection invalidation with „08dd73e 
“
 and added a test-case. This should prevent reuse of the connection. As far as 
I know using the proxy this way (using anonym inner class with final parameters 
opposed to using a dedicated class) one can’t access the contained connection 
via reflection and therefore can’t circumvent the invalidation.

Regarding that request limiting is see it similar to you (above, or below 
[shall be default message based and per protocol on other metrics if possible])…

Regarding the ProxyConnection I state above why I prefer the proxy there (could 
be non proxy implementation too).

Yep regarding the hook no objections against that (What we could discuss though 
if the isConnected() should include that or if the semantic of this is a layer 
below).

Sebastian

> Am 26.10.2018 um 15:54 schrieb Julian Feinauer :
> 
> Hey Sebastian,
> 
> 
> the only problem witht he reuse i had is possible internal state during 
> in-flight messages or problems with multi threading (I'm not sure if all 
> drivers are thread safe and stateless during in-flight messages), but I agree 
> that this is minor currently, just wanted to add the todo to keep it in view 
> : )
> 
> Request Limiting is, as I think, no concern of the driver itself, I think, so 
> I would add request limiting probably in an layer above thus I'm totally fine.
> 
> 
> With regards to Marcels branch I thought it would be ideal to move over its 
> ProxyConnection as this is everything thats needed to fix the todo (all 
> methods delegate untill close() is called then all throw an unsupported 
> operation exception. This is similar to what common jdbc pools do, I checked 
> dbcp and some other one).
> 
> 
> Yes, we can directly add the validation hook from commons pool, but I think 
> we need a plc specific ping method in the api to call as we have no "common" 
> field or "query" we can issue.
> 
> 
> Best
> 
> Julian
> 
> 
> Von: Sebastian Rühl 
> Gesendet: Freitag, 26. Oktober 2018 13:23:55
> An: dev@plc4x.apache.org
> Betreff: Re: OPM / Connection Pool
> 
> Hi Julian,
> 
> Regarding the reuse of Connections:
> I was aware of that issue but forgot to add a TODO for that (sorry for that). 
> But in general a pool is not a request limiter rater a connection limiter. 
> Therefore the continue use shouldn’t be that big of an issue for the time 
> being (Till we resolve that issue).
> 
> Request Limiting:
> A separate generic request limiter feature would be nice but is out-of-scope 
> of the pool. In case of S7 this is builtin (maxAmqCaller/maxAmqCallee).
> 
> Regarding the branch of Marcel (And thanks for the great contribution Marcel 
> :):
> He did some good work but at the end the implementation was initially too 
> different from the commons-pool one as I would have reverted/changed almost 
> every line. So the idea was it to write it upfront in the separate module to 
> have the possibility to compare it side by side and pick the goodies.
> 
> Regarding validation:
> The commons-pool validation calls isConnected() on return. So we could 
> implement the „ping“ in the isConnected() as well or implement a ping() as 
> you described.
> 
> Sebastian
> 
>> Am 25.10.2018 um 23:13 schrieb Julian Feinauer 
>> :
>> 
>> Hey all,
>> 
>> just wanted to keep you up to date with some things Sebastian and I 
>> discussed off-list.
>> Thanks to Sebastians support the Object Plc Mapping (opm) is now mergend 
>> into master and I would love to get some feedback.
>> I hope that I can soon add some documentation on the side about that and I 
>> would be happy if someone likes to implement writing (currently only reading 
>> is supported), see PLC4X-70.
>> 
>> Sebastian also added an implementation for the Connection Pool. This can 
>> become one of the most important features to make it usable in enterprise 
>> applications (pooling, keep connections open, …).
>> It is important to note that Marcel opened a PR for the same feature and my 
>> impression is that both implementations are lacking some (different) things 
>> and thus, together, are a pretty good first shot.
>> Thus, I suggest that we keep PR-30 open [1] or at least the branch intact 
>> and move the Proxy Implementations over (added a TODO in the 
>> PooledPlcDriverManager which is dangerous, I think) and also add some 
>> validation (this should be added to the driver interface or the SPI 
>> somewhere, I guess to be able to have a reasonable “ping” for all plc’s, it 
>> is in our case not as easy as a “SELECT 1” in JDBC).
>> 

AW: OPM / Connection Pool

[Julian Feinauer]

Hey Chris,


yes, indeed, sorry for the confusion.

I agree with this "low level" limiting, as this is simply necessary to ensure 
connection.

What I mean is that we could decide in an application to not send more than 100 
requests / s (for whatever reason) and handle that before forwarding the 
requests to the pool.


Julian


Von: Christofer Dutz 
Gesendet: Freitag, 26. Oktober 2018 16:01:37
An: dev@plc4x.apache.org
Betreff: Re: OPM / Connection Pool

Hi Julian,

I think we might be thinking of different things when referring to "limiting".
In my case I know that a Siemens S7 device is able to process a maximum number 
of concurrent requests. If more are sent, they are simply discarded and an 
error response is sent.
This maximum number of concurrent requests is agreed upon during the connection 
phase in the maxAmqCaller and maxAmqCallee parameters. The S7 driver now 
automatically limits the number of requests sent out to respect these 
boundaries. And I don't see an option to handle this generically except to 
limit it to 1 globally.

I think you are referring to something else. Could you please explain to us 
what you mean with "request limiting".

Chris

Am 26.10.18, 15:55 schrieb "Julian Feinauer" :

Hey Sebastian,


the only problem witht he reuse i had is possible internal state during 
in-flight messages or problems with multi threading (I'm not sure if all 
drivers are thread safe and stateless during in-flight messages), but I agree 
that this is minor currently, just wanted to add the todo to keep it in view : )

Request Limiting is, as I think, no concern of the driver itself, I think, 
so I would add request limiting probably in an layer above thus I'm totally 
fine.


With regards to Marcels branch I thought it would be ideal to move over its 
ProxyConnection as this is everything thats needed to fix the todo (all methods 
delegate untill close() is called then all throw an unsupported operation 
exception. This is similar to what common jdbc pools do, I checked dbcp and 
some other one).


Yes, we can directly add the validation hook from commons pool, but I think 
we need a plc specific ping method in the api to call as we have no "common" 
field or "query" we can issue.


Best

Julian


Von: Sebastian Rühl 
Gesendet: Freitag, 26. Oktober 2018 13:23:55
An: dev@plc4x.apache.org
Betreff: Re: OPM / Connection Pool

Hi Julian,

Regarding the reuse of Connections:
I was aware of that issue but forgot to add a TODO for that (sorry for 
that). But in general a pool is not a request limiter rater a connection 
limiter. Therefore the continue use shouldn’t be that big of an issue for the 
time being (Till we resolve that issue).

Request Limiting:
A separate generic request limiter feature would be nice but is 
out-of-scope of the pool. In case of S7 this is builtin 
(maxAmqCaller/maxAmqCallee).

Regarding the branch of Marcel (And thanks for the great contribution 
Marcel :):
He did some good work but at the end the implementation was initially too 
different from the commons-pool one as I would have reverted/changed almost 
every line. So the idea was it to write it upfront in the separate module to 
have the possibility to compare it side by side and pick the goodies.

Regarding validation:
The commons-pool validation calls isConnected() on return. So we could 
implement the „ping“ in the isConnected() as well or implement a ping() as you 
described.

Sebastian

> Am 25.10.2018 um 23:13 schrieb Julian Feinauer 
:
>
> Hey all,
>
> just wanted to keep you up to date with some things Sebastian and I 
discussed off-list.
> Thanks to Sebastians support the Object Plc Mapping (opm) is now mergend 
into master and I would love to get some feedback.
> I hope that I can soon add some documentation on the side about that and 
I would be happy if someone likes to implement writing (currently only reading 
is supported), see PLC4X-70.
>
> Sebastian also added an implementation for the Connection Pool. This can 
become one of the most important features to make it usable in enterprise 
applications (pooling, keep connections open, …).
> It is important to note that Marcel opened a PR for the same feature and 
my impression is that both implementations are lacking some (different) things 
and thus, together, are a pretty good first shot.
> Thus, I suggest that we keep PR-30 open [1] or at least the branch intact 
and move the Proxy Implementations over (added a TODO in the 
PooledPlcDriverManager which is dangerous, I think) and also add some 
validation (this should be added to the driver interface or the SPI somewhere, 
I guess to be able to have a reasonable “ping” for all plc’s, it is in our case 
not as easy as a “SELECT 1” in JDBC).
>
> Thus, we are on a great way, and as soon as we have moved 

Re: OPM / Connection Pool

[Christofer Dutz]

Hi Julian,

I think we might be thinking of different things when referring to "limiting".
In my case I know that a Siemens S7 device is able to process a maximum number 
of concurrent requests. If more are sent, they are simply discarded and an 
error response is sent. 
This maximum number of concurrent requests is agreed upon during the connection 
phase in the maxAmqCaller and maxAmqCallee parameters. The S7 driver now 
automatically limits the number of requests sent out to respect these 
boundaries. And I don't see an option to handle this generically except to 
limit it to 1 globally.

I think you are referring to something else. Could you please explain to us 
what you mean with "request limiting".

Chris

Am 26.10.18, 15:55 schrieb "Julian Feinauer" :

Hey Sebastian,


the only problem witht he reuse i had is possible internal state during 
in-flight messages or problems with multi threading (I'm not sure if all 
drivers are thread safe and stateless during in-flight messages), but I agree 
that this is minor currently, just wanted to add the todo to keep it in view : )

Request Limiting is, as I think, no concern of the driver itself, I think, 
so I would add request limiting probably in an layer above thus I'm totally 
fine.


With regards to Marcels branch I thought it would be ideal to move over its 
ProxyConnection as this is everything thats needed to fix the todo (all methods 
delegate untill close() is called then all throw an unsupported operation 
exception. This is similar to what common jdbc pools do, I checked dbcp and 
some other one).


Yes, we can directly add the validation hook from commons pool, but I think 
we need a plc specific ping method in the api to call as we have no "common" 
field or "query" we can issue.


Best

Julian


Von: Sebastian Rühl 
Gesendet: Freitag, 26. Oktober 2018 13:23:55
An: dev@plc4x.apache.org
Betreff: Re: OPM / Connection Pool

Hi Julian,

Regarding the reuse of Connections:
I was aware of that issue but forgot to add a TODO for that (sorry for 
that). But in general a pool is not a request limiter rater a connection 
limiter. Therefore the continue use shouldn’t be that big of an issue for the 
time being (Till we resolve that issue).

Request Limiting:
A separate generic request limiter feature would be nice but is 
out-of-scope of the pool. In case of S7 this is builtin 
(maxAmqCaller/maxAmqCallee).

Regarding the branch of Marcel (And thanks for the great contribution 
Marcel :):
He did some good work but at the end the implementation was initially too 
different from the commons-pool one as I would have reverted/changed almost 
every line. So the idea was it to write it upfront in the separate module to 
have the possibility to compare it side by side and pick the goodies.

Regarding validation:
The commons-pool validation calls isConnected() on return. So we could 
implement the „ping“ in the isConnected() as well or implement a ping() as you 
described.

Sebastian

> Am 25.10.2018 um 23:13 schrieb Julian Feinauer 
:
>
> Hey all,
>
> just wanted to keep you up to date with some things Sebastian and I 
discussed off-list.
> Thanks to Sebastians support the Object Plc Mapping (opm) is now mergend 
into master and I would love to get some feedback.
> I hope that I can soon add some documentation on the side about that and 
I would be happy if someone likes to implement writing (currently only reading 
is supported), see PLC4X-70.
>
> Sebastian also added an implementation for the Connection Pool. This can 
become one of the most important features to make it usable in enterprise 
applications (pooling, keep connections open, …).
> It is important to note that Marcel opened a PR for the same feature and 
my impression is that both implementations are lacking some (different) things 
and thus, together, are a pretty good first shot.
> Thus, I suggest that we keep PR-30 open [1] or at least the branch intact 
and move the Proxy Implementations over (added a TODO in the 
PooledPlcDriverManager which is dangerous, I think) and also add some 
validation (this should be added to the driver interface or the SPI somewhere, 
I guess to be able to have a reasonable “ping” for all plc’s, it is in our case 
not as easy as a “SELECT 1” in JDBC).
>
> Thus, we are on a great way, and as soon as we have moved over the 
necessary parts from PR-30 and probably also added the validation I would be 
very happy to ship OPM as feature in one of our applications. I’ll then also 
prepare a sample on that because it makes PLC Connections really as easy as 
querying a Database via JPA.
>
> Thanks especially to Marcel and Sebastian!
> Julian
>
> [1] https://github.com/apache/incubator-plc4x/pull/30

AW: OPM / Connection Pool

[Julian Feinauer]

Hey Sebastian,


the only problem witht he reuse i had is possible internal state during 
in-flight messages or problems with multi threading (I'm not sure if all 
drivers are thread safe and stateless during in-flight messages), but I agree 
that this is minor currently, just wanted to add the todo to keep it in view : )

Request Limiting is, as I think, no concern of the driver itself, I think, so I 
would add request limiting probably in an layer above thus I'm totally fine.


With regards to Marcels branch I thought it would be ideal to move over its 
ProxyConnection as this is everything thats needed to fix the todo (all methods 
delegate untill close() is called then all throw an unsupported operation 
exception. This is similar to what common jdbc pools do, I checked dbcp and 
some other one).


Yes, we can directly add the validation hook from commons pool, but I think we 
need a plc specific ping method in the api to call as we have no "common" field 
or "query" we can issue.


Best

Julian


Von: Sebastian Rühl 
Gesendet: Freitag, 26. Oktober 2018 13:23:55
An: dev@plc4x.apache.org
Betreff: Re: OPM / Connection Pool

Hi Julian,

Regarding the reuse of Connections:
I was aware of that issue but forgot to add a TODO for that (sorry for that). 
But in general a pool is not a request limiter rater a connection limiter. 
Therefore the continue use shouldn’t be that big of an issue for the time being 
(Till we resolve that issue).

Request Limiting:
A separate generic request limiter feature would be nice but is out-of-scope of 
the pool. In case of S7 this is builtin (maxAmqCaller/maxAmqCallee).

Regarding the branch of Marcel (And thanks for the great contribution Marcel :):
He did some good work but at the end the implementation was initially too 
different from the commons-pool one as I would have reverted/changed almost 
every line. So the idea was it to write it upfront in the separate module to 
have the possibility to compare it side by side and pick the goodies.

Regarding validation:
The commons-pool validation calls isConnected() on return. So we could 
implement the „ping“ in the isConnected() as well or implement a ping() as you 
described.

Sebastian

> Am 25.10.2018 um 23:13 schrieb Julian Feinauer :
>
> Hey all,
>
> just wanted to keep you up to date with some things Sebastian and I discussed 
> off-list.
> Thanks to Sebastians support the Object Plc Mapping (opm) is now mergend into 
> master and I would love to get some feedback.
> I hope that I can soon add some documentation on the side about that and I 
> would be happy if someone likes to implement writing (currently only reading 
> is supported), see PLC4X-70.
>
> Sebastian also added an implementation for the Connection Pool. This can 
> become one of the most important features to make it usable in enterprise 
> applications (pooling, keep connections open, …).
> It is important to note that Marcel opened a PR for the same feature and my 
> impression is that both implementations are lacking some (different) things 
> and thus, together, are a pretty good first shot.
> Thus, I suggest that we keep PR-30 open [1] or at least the branch intact and 
> move the Proxy Implementations over (added a TODO in the 
> PooledPlcDriverManager which is dangerous, I think) and also add some 
> validation (this should be added to the driver interface or the SPI 
> somewhere, I guess to be able to have a reasonable “ping” for all plc’s, it 
> is in our case not as easy as a “SELECT 1” in JDBC).
>
> Thus, we are on a great way, and as soon as we have moved over the necessary 
> parts from PR-30 and probably also added the validation I would be very happy 
> to ship OPM as feature in one of our applications. I’ll then also prepare a 
> sample on that because it makes PLC Connections really as easy as querying a 
> Database via JPA.
>
> Thanks especially to Marcel and Sebastian!
> Julian
>
> [1] https://github.com/apache/incubator-plc4x/pull/30

[GitHub] asfgit closed pull request #32: Provide connection metadata

[GitBox]

asfgit closed pull request #32: Provide connection metadata
URL: https://github.com/apache/incubator-plc4x/pull/32
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] skorikov opened a new pull request #32: Provide connection metadata

[GitBox]

skorikov opened a new pull request #32: Provide connection metadata
URL: https://github.com/apache/incubator-plc4x/pull/32
 
 
   As discussed in the mailing list, connection capabilities should be obtained 
via metadata and remove `Optional`s from the `PlcConnection`.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Resining behind reverting some of the changes

[Christofer Dutz]

Hi,

I just pushed some changes, that seem to revert part of the changes done to 
GitHub.

This is not an expression of them being unwanted, but more a necessary thing in 
order to re-sync both repos without having to force anything.

Hopefully I can now re enable the sync mechanism and we’ll be able to continue 
from there on.

Chris

[GitHub] sruehl commented on issue #30: connection manager for connection pool initial version

[GitBox]

sruehl commented on issue #30: connection manager for connection pool initial 
version
URL: https://github.com/apache/incubator-plc4x/pull/30#issuecomment-433380970
 
 
   I haven't closed this... What the...???


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] sruehl closed pull request #30: connection manager for connection pool initial version

[GitBox]

sruehl closed pull request #30: connection manager for connection pool initial 
version
URL: https://github.com/apache/incubator-plc4x/pull/30
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: OPM / Connection Pool

[Sebastian Rühl]

Hi Julian,

Regarding the reuse of Connections:
I was aware of that issue but forgot to add a TODO for that (sorry for that). 
But in general a pool is not a request limiter rater a connection limiter. 
Therefore the continue use shouldn’t be that big of an issue for the time being 
(Till we resolve that issue). 

Request Limiting:
A separate generic request limiter feature would be nice but is out-of-scope of 
the pool. In case of S7 this is builtin (maxAmqCaller/maxAmqCallee).

Regarding the branch of Marcel (And thanks for the great contribution Marcel :):
He did some good work but at the end the implementation was initially too 
different from the commons-pool one as I would have reverted/changed almost 
every line. So the idea was it to write it upfront in the separate module to 
have the possibility to compare it side by side and pick the goodies.

Regarding validation:
The commons-pool validation calls isConnected() on return. So we could 
implement the „ping“ in the isConnected() as well or implement a ping() as you 
described.

Sebastian

> Am 25.10.2018 um 23:13 schrieb Julian Feinauer :
> 
> Hey all,
> 
> just wanted to keep you up to date with some things Sebastian and I discussed 
> off-list.
> Thanks to Sebastians support the Object Plc Mapping (opm) is now mergend into 
> master and I would love to get some feedback.
> I hope that I can soon add some documentation on the side about that and I 
> would be happy if someone likes to implement writing (currently only reading 
> is supported), see PLC4X-70.
> 
> Sebastian also added an implementation for the Connection Pool. This can 
> become one of the most important features to make it usable in enterprise 
> applications (pooling, keep connections open, …).
> It is important to note that Marcel opened a PR for the same feature and my 
> impression is that both implementations are lacking some (different) things 
> and thus, together, are a pretty good first shot.
> Thus, I suggest that we keep PR-30 open [1] or at least the branch intact and 
> move the Proxy Implementations over (added a TODO in the 
> PooledPlcDriverManager which is dangerous, I think) and also add some 
> validation (this should be added to the driver interface or the SPI 
> somewhere, I guess to be able to have a reasonable “ping” for all plc’s, it 
> is in our case not as easy as a “SELECT 1” in JDBC).
> 
> Thus, we are on a great way, and as soon as we have moved over the necessary 
> parts from PR-30 and probably also added the validation I would be very happy 
> to ship OPM as feature in one of our applications. I’ll then also prepare a 
> sample on that because it makes PLC Connections really as easy as querying a 
> Database via JPA.
> 
> Thanks especially to Marcel and Sebastian!
> Julian
> 
> [1] https://github.com/apache/incubator-plc4x/pull/30

[GitHub] skorikov closed pull request #31: Fix master build

[GitBox]

skorikov closed pull request #31: Fix master build
URL: https://github.com/apache/incubator-plc4x/pull/31
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/plc4j/core/src/main/java/org/apache/plc4x/java/PlcDriverManagerInterface.java 
b/plc4j/core/src/main/java/org/apache/plc4x/java/PlcDriverManagerInterface.java
index c9b8ef261..47e077b95 100644
--- 
a/plc4j/core/src/main/java/org/apache/plc4x/java/PlcDriverManagerInterface.java
+++ 
b/plc4j/core/src/main/java/org/apache/plc4x/java/PlcDriverManagerInterface.java
@@ -18,8 +18,8 @@ Licensed to the Apache Software Foundation (ASF) under one
 */
 package org.apache.plc4x.java;
 
+import org.apache.plc4x.java.api.PlcConnection;
 import org.apache.plc4x.java.api.authentication.PlcAuthentication;
-import org.apache.plc4x.java.api.connection.PlcConnection;
 import org.apache.plc4x.java.api.exceptions.PlcConnectionException;
 
 public interface PlcDriverManagerInterface {
diff --git 
a/plc4j/core/src/main/java/org/apache/plc4x/java/connectionpool/ConnectionProxy.java
 
b/plc4j/core/src/main/java/org/apache/plc4x/java/connectionpool/ConnectionProxy.java
index b1188d5c9..926674ee8 100644
--- 
a/plc4j/core/src/main/java/org/apache/plc4x/java/connectionpool/ConnectionProxy.java
+++ 
b/plc4j/core/src/main/java/org/apache/plc4x/java/connectionpool/ConnectionProxy.java
@@ -18,7 +18,7 @@ Licensed to the Apache Software Foundation (ASF) under one
 */
 package org.apache.plc4x.java.connectionpool;
 
-import org.apache.plc4x.java.api.connection.PlcConnection;
+import org.apache.plc4x.java.api.PlcConnection;
 
 public interface ConnectionProxy extends PlcConnection {
 }
\ No newline at end of file
diff --git 
a/plc4j/core/src/main/java/org/apache/plc4x/java/connectionpool/PlcConnectionManager.java
 
b/plc4j/core/src/main/java/org/apache/plc4x/java/connectionpool/PlcConnectionManager.java
index fc3ff0114..8e6f8c0fd 100644
--- 
a/plc4j/core/src/main/java/org/apache/plc4x/java/connectionpool/PlcConnectionManager.java
+++ 
b/plc4j/core/src/main/java/org/apache/plc4x/java/connectionpool/PlcConnectionManager.java
@@ -20,8 +20,8 @@ Licensed to the Apache Software Foundation (ASF) under one
 
 import org.apache.plc4x.java.PlcDriverManager;
 import org.apache.plc4x.java.PlcDriverManagerInterface;
+import org.apache.plc4x.java.api.PlcConnection;
 import org.apache.plc4x.java.api.authentication.PlcAuthentication;
-import org.apache.plc4x.java.api.connection.PlcConnection;
 import org.apache.plc4x.java.api.exceptions.PlcConnectionException;
 import org.apache.plc4x.java.exceptions.NoConnectionAvailableException;
 import org.apache.plc4x.java.exceptions.NotConnectedException;
diff --git 
a/plc4j/core/src/main/java/org/apache/plc4x/java/connectionpool/PlcConnectionProxy.java
 
b/plc4j/core/src/main/java/org/apache/plc4x/java/connectionpool/PlcConnectionProxy.java
index ea9884f06..333075ee9 100644
--- 
a/plc4j/core/src/main/java/org/apache/plc4x/java/connectionpool/PlcConnectionProxy.java
+++ 
b/plc4j/core/src/main/java/org/apache/plc4x/java/connectionpool/PlcConnectionProxy.java
@@ -18,11 +18,11 @@ Licensed to the Apache Software Foundation (ASF) under one
 */
 package org.apache.plc4x.java.connectionpool;
 
-
-import org.apache.plc4x.java.api.connection.PlcConnection;
-import org.apache.plc4x.java.api.connection.PlcReader;
-import org.apache.plc4x.java.api.connection.PlcSubscriber;
-import org.apache.plc4x.java.api.connection.PlcWriter;
+import org.apache.plc4x.java.api.PlcConnection;
+import org.apache.plc4x.java.api.messages.PlcReadRequest;
+import org.apache.plc4x.java.api.messages.PlcSubscriptionRequest;
+import org.apache.plc4x.java.api.messages.PlcUnsubscriptionRequest;
+import org.apache.plc4x.java.api.messages.PlcWriteRequest;
 
 import java.util.Optional;
 
@@ -71,31 +71,39 @@ public void close() {
 }
 
 @Override
-public Optional getReader() {
+public Optional readRequestBuilder() {
 if(closed){
 return Optional.empty();
 }else {
-return plcConnection.getReader();
+return plcConnection.readRequestBuilder();
 }
 }
 
 @Override
-public Optional getWriter() {
+public Optional writeRequestBuilder() {
 if(closed) {
 return Optional.empty();
 }else{
-return plcConnection.getWriter();
+return plcConnection.writeRequestBuilder();
 }
 }
 
 @Override
-public Optional getSubscriber() {
+public Optional 
subscriptionRequestBuilder() {
 if(closed){
 return Optional.empty();
 }else {
-return plcConnection.getSubscriber();
+return plcConnection.subscriptionRequestBuilder();
 }
 }
 
+@Override
+public Optional 

Please stop pushing to the Github repo ... at least for now ...

[Christofer Dutz]

Hi all,

we have had problems with syncing our Git repos multiple times now. As soon as 
changes are pushed to Github the whole Sync seems to blow up.
So please don’t push stuff to the apache github repo or use the convenient 
“Merge” button on Github.

We are currently trying to fix things again, but “origin” should be set to: 
https://gitbox.apache.org/repos/asf/incubator-plc4x.git

Hopefully we’ll find out what the problem is and allow pushing to github, but 
for now it just requires us to do a lot of manual work after every push to 
Github.

Chris

[GitHub] skorikov opened a new pull request #31: Fix master build

[GitBox]

skorikov opened a new pull request #31: Fix master build
URL: https://github.com/apache/incubator-plc4x/pull/31
 
 
   This "fixes" the broken master build. Please note that four tests are set to 
"ignored" and remain to be fixed.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services