Marc, thank you for your reply. And let me say I've been a long time fan of EclEmma. So thank you for your work.
Regarding your suggestion: * "In you case running the agents in TCP client mode and pool them periodically with temporary connections looks like the more robust setup.* I think you're suggesting the Tomcat app servers be run in TcpServer mode, and then polled periodically from a central Client collector. This would definitely work and solves the long-term connection issue. What appealed to me about running the many app servers as TcpClient is that I don't need prior knowledge of which servers exist at the central server. From that point of view, a new Tomcat application (using TcpClient) could be created and would connect to the collection server without any configurations needing to be updated. Likewise polling the mbean interface would require a list of which addresses to visit. Not to mention our corporate policy has JMX locked down in our farm. I'll think about this further and see which makes the most sense. Thanks again for your help. Nathan On Thursday, October 15, 2020 at 2:00:03 PM UTC-4 Marc R. Hoffmann wrote: > Hi Nathan, > > thanks for the detailed description of you use case! > > I’m still not convinced it is a good idea to add distributed/resilient to > the coverage agent. There are simply too many failure scenarios to test and > get right. Especially in the case of JVM shutdown you don’t want to have > wait/retry loops. > > In you case running the agents in TCP client mode and pool them > periodically with temporary connections looks like the more robust setup. > > Alternatively JaCoCo also offers a runtime API: > https://www.jacoco.org/jacoco/trunk/doc/api/org/jacoco/agent/rt/package-summary.html > > Using this API you can create your own distributed upload logic and > package that with your application. > > Regards, > -marc > > > > > > On 15. Oct 2020, at 19:20, Nathan Wray <[email protected]> wrote: > > Funnily enough this is exactly the question I was researching so fortunate > to see it asked and answered so recently. > > Our use case (proposed use case) is to stand up a central server (coverage > collection server) to request/receive JaCoCo data periodically and store > it, probably on a rolling window basis. > > We would deploy the agents against Tomcat apps in tcpclient mode, with > sessionIDs identifying which application is being instrumented. These > tomcat servers (tcpclient) would be used for automated and manual test > cases, sometimes over the course of days, and the servers would be expected > to be "up" without restarts for long periods of time. > > Presumably the collection server could at some point be bounced or fail, > at which point all of the tcpclients would be hung and need to be > restarted. The idea I'd been considering as I look though the code was to > add an optional "retry" setting specific to tcpclient that would cause > TcpOutputClient to create a new TcpConnection on failure (possibly after > some delay, which conceptually could be configurable). It seems relatively > clear to me how to retrofit this. For my use case at least, I would ignore > any data that happened to be in transit during a failure. I have not looked > at what would happen to the visitor if the server were killed during data > transmission. > > Mark, if I were to do this work, add the test cases, update the > documentation, would this be a pull request that would be considered? Or is > this functionality that you do not consider a fit for the project? > What is the right process to surface this for consideration? > > Thank you > Nathan > > > On Tuesday, September 29, 2020 at 12:23:24 AM UTC-4 Marc R. Hoffmann wrote: > >> Hi, >> >> there is no reconnect mode. And I doubt it’s a good idea to add one. As >> the event “TCP Server down” can happen at any point in time there are >> arbitrary error conditions in the client incl. data loss . >> >> Regards, >> -marc >> >> >> On 29. Sep 2020, at 03:33, [email protected] wrote: >> >> >> I couldn't find >> >> retry tcp connection in "tcpclient" mode when it lost it's connection. >> >> >> For Example, >> >> TCP Server <------- jacocoagent(tcpclient mode) >> >> 1. Conneciton established >> 2. TCP Server down >> 3. Connection lost >> 4. TCP Server restart >> 5. No retry >> >> Have any idea for this ? >> >> Thank you. >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "JaCoCo and EclEmma Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jacoco/d7ef4354-1fef-4ee0-b7dc-18782e81e6c1o%40googlegroups.com >> >> <https://groups.google.com/d/msgid/jacoco/d7ef4354-1fef-4ee0-b7dc-18782e81e6c1o%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> >> > -- > You received this message because you are subscribed to the Google Groups > "JaCoCo and EclEmma Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/jacoco/fd81ebeb-fefc-412f-953c-c12d0d4e8d56n%40googlegroups.com > > <https://groups.google.com/d/msgid/jacoco/fd81ebeb-fefc-412f-953c-c12d0d4e8d56n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > > -- You received this message because you are subscribed to the Google Groups "JaCoCo and EclEmma Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jacoco/a4f489c7-8950-4ca8-b060-c25791ae513en%40googlegroups.com.
