Hi Nathan,
Like Marc, I feel that such functionality is better to be implemented
outside of JaCoCo.
If you don't like the approach of a special WAR suggested by Marc in
https://groups.google.com/g/jacoco/c/QsyvL7bUDng/m/EUglIletAgAJ
and prefer agent, then you can implement your own agent that will be
talking with JaCoCo agent.
For example
after compilation
javac -cp jacoco-0.8.6/lib/jacocoagent.jar -d . Agent.java
of the following Agent.java
package example;
class Agent {
public static void premain(String agentArgs,
java.lang.instrument.Instrumentation inst) {
System.out.println("JaCoCo version: " +
org.jacoco.agent.rt.RT.getAgent().getVersion());
}
}
and creation of jar
jar cfm agent.jar manifest.txt example
using the following manifest.txt
Premain-Class: example.Agent
execution of
java -javaagent:jacoco-0.8.6/lib/jacocoagent.jar -javaagent:agent.jar -help
will print version of JaCoCo.
Similarly your agent can request dumps and send them out.
Regards,
Evgeny
On Tuesday, October 20, 2020 at 5:51:48 PM UTC+2 Nathan Wray wrote:
> Marc, I went ahead and implemented what I had in mind for reconnect. If
> you have time please review, I'd appreciate any feedback. We're intending
> to use this internally in the meantime.
>
> https://github.com/jacoco/jacoco/pull/1111
>
> Thank you
> Nathan
>
> On Thursday, October 15, 2020 at 3:49:54 PM UTC-4 Marc R. Hoffmann wrote:
>
>> Correct!
>>
>> That could be a separate WAR that you deploy on the test Tomcats.
>>
>>
>> On 15. Oct 2020, at 21:41, Nathan Wray <nw...@detroitsci.com> wrote:
>>
>> If I understand you correctly, this would be a small bit of code I'd
>> create and package into my apps along with the JaCoCo jars.
>>
>> I thought about a similar pattern but the drawback I see is that build
>> dependency change and the introduction of JaCoCo-specific code and jars
>> into production. The javaagent approach lets me instrument only test
>> without any prerequisites that I need to enforce out to the different
>> development teams, and doesn't impact production. So that's a preferred
>> attribute of a good solution.
>>
>> Thank you
>> Nathan
>>
>>
>>
>> On Thursday, October 15, 2020 at 2:23:15 PM UTC-4 Marc R. Hoffmann wrote:
>>
>>> Hi Nathan,
>>>
>>> thanks for the kind words!
>>>
>>> I see the advantage of the instances connecting to the central service.
>>> That’s why I was suggesting you implement that logic on your own (you can
>>> even do HTTP POST requests).
>>>
>>> By the API I’m not talking about JMX. The API can be directly used from
>>> within Java code deployed with your application. This code could e.g.
>>> periodically receive JaCoCo exec data and post it to the central server:
>>>
>>> IAgent agent = RT.getAgent();
>>> byte[] exec = agent.getExecutionData(true);
>>> // POST exec to your central service
>>>
>>> This does not depend a established connection.
>>>
>>> Regards,
>>> -marc
>>>
>>>
>>>
>>> On 15. Oct 2020, at 20:16, Nathan Wray <nw...@detroitsci.com> wrote:
>>>
>>> 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 <nw...@detroitsci.com> 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, il2s...@gmail.com 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 jacoco+un...@googlegroups.com.
>>>>> 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 jacoco+un...@googlegroups.com.
>>>>
>>>> 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 jacoco+un...@googlegroups.com.
>>>
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jacoco/a4f489c7-8950-4ca8-b060-c25791ae513en%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/jacoco/a4f489c7-8950-4ca8-b060-c25791ae513en%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 jacoco+un...@googlegroups.com.
>>
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jacoco/8ee14fc4-31cd-427d-bc4f-5e12eb1a0c33n%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/jacoco/8ee14fc4-31cd-427d-bc4f-5e12eb1a0c33n%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 jacoco+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jacoco/18953785-70b9-4977-92e3-918b1321ca68n%40googlegroups.com.
