Meet Invalid execution data file error while dump with tcp client mode

[randal...@gmail.com]

Hi,

Here is my situation:

we have a mico-service architect design product, and now we want to perform the code coverage for all services and don't expected frequency service restart. so we don't use TCPServer and local file mode.

Now we try with TCPClient mode and create a tcp server to collect the dump file, after the agent connect to the tcp server, we can use RemoteControlWriter.visitDumpCommand to collect dump file from each agent. 

we use the sample executiondataclient code to collect dump file as follow. for the first time to trigger dump, the exec file can successful dump out.

final FileOutputStream localFile = new FileOutputStream(DESTFILE);

final ExecutionDataWriter localWriter = new ExecutionDataWriter(

localFile);

// Open a socket to the coverage agent:

final Socket socket = new Socket(InetAddress.getByName(ADDRESS), PORT);

final RemoteControlWriter writer = new RemoteControlWriter(

socket.getOutputStream());

final RemoteControlReader reader = new RemoteControlReader(

socket.getInputStream());

reader.setSessionInfoVisitor(localWriter);

reader.setExecutionDataVisitor(localWriter);

// Send a dump command and read the response:

writer.visitDumpCommand(true, false);

if (!reader.read()) {

throw new IOException("Socket closed unexpectedly.");

}

but if i trigger the dump again, there is a "Invalid execution data file" exception throw from here. the type is not 1 but 16, i don't know why the second time to trigger file dump, there is no Block_Header return? how to resolve?

public boolean read() throws IOException,

IncompatibleExecDataVersionException {

try {

byte type;

do {

type = in.readByte();

if (firstBlock && type != ExecutionDataWriter.BLOCK_HEADER) {

throw new IOException("Invalid execution data file.");

}

firstBlock = false;

} while (readBlock(type));

return true;

} catch (final EOFException e) {

return false;

}

}

Thanks very much.

[Evgeny Mandrikov]

Hi,

There is something strange in your question:

you state that you run agent in "tcpclient" mode and use http://www.jacoco.org/jacoco/trunk/doc/examples/java/ExecutionDataClient.java , while description of last clearly states:

"This example connects to a coverage agent that run in output mode tcpserver"

Should be simply impossible to connect to agent that is in "tcpclient" mode, which is not surprising as it is named "client".

The only guess that first dump is actually incorrectly succeeds resulting in empty data, while should fail - see https://github.com/jacoco/jacoco/pull/538 , which is resolved for the next version of JaCoCo and already available in current snapshot build.

Regards,

Evgeny

[Evgeny Mandrikov]

And example of server for "tcpclient" mode of agent is here - http://www.jacoco.org/jacoco/trunk/doc/examples/java/ExecutionDataServer.java

While this example doesn't show request of dump and shows only acceptance of data that will be written by agent on JVM termination, protocol is the same and dump can be requested ( https://groups.google.com/d/msg/jacoco/V7Bmz5r0P24/PdCC5apIoqgJ ).

Also you might consider usage of MBean - see agent option "jmx=true" and http://www.jacoco.org/jacoco/trunk/doc/examples/java/MBeanClient.java

HTH.

[randal...@gmail.com]

Thanks Evgeny for the quickly reply.

Sorry for the confusing, maybe i have some misunderstanding here. we have hundreds of services started with jacoco agent for test, so it is hard to maintain a list of TCPPort while we using TCPServer mode to dump file. so we use tcp client mode that all jacoco agents need to connect to a central TCPServer.

The sample TCPServer code can only correct the client dump while client stop, I checked the Marc comments that TCPClient model also can use the RemoteControlWriter.visitDumpCommand to pull dump file from TCPServer event when test service is not stop, so i refer to the ExceutionDataClient to check how visitDumpCommand is call and reuse that code, maybe like you said the code cannot use in such way, let me check the code again.

Thanks 

在 2017年8月30日星期三 UTC+8上午5:00:51，Evgeny Mandrikov写道：