Not able to get coverage info for app server

Abhinav Sahu December 15, 2013

Hi,

I am not able to get coverage info from server which is connected through activemq message queue from client.

My scenario:

1. Creating jar and then rpm packages for client and server application (instrumented)

2. Installing client and server application on same system and started the server.

3. Client and server comunicating through Activemq server (apache product).

4. Testcase executing on client so it send and receive message between client and server through activemq

5. I am able to get code coverge for client because testcase directly accessing client jars. But, not able to get code coverage for server application because client comunicate server through activemq.

I also used distributed_clover option as below but yet I am not able to succeed:

Distributed coverage is enabled with: name=clover.tcp.server;host=localhost;port=1234;timeout=10000;numClients=2;retryPeriod=1000

Note: Initstring are properly defined for both client and server and are same.

Please let me know if my scenario is not clear.

Thanks in advance,

Sahu

1 answer

1 accepted

0 votes
Answer accepted
Marek Parfianowicz
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
December 15, 2013

Hi Sahu,

Do you have any coverage recorded for a server part? I assume that not. In such case, it's rather not a problem of the distributed coverage settings, but rather a problem with:

  • clover.jar - loading coverage recorder classes at runtime or
  • clover.db - reading information from a Clover database by these recorders

Please check logs on your server whether you have any messages related with Clover.

In case when there's a problem with clover.jar you will find messages like those described in following KB articles:

In case when there's a problem with accessing the clover.db databse, a message looks like this:

ERROR: CLOVER: Unable to load the coverage database at "/path/to/the/clover.db"
ERROR: CLOVER: No coverage data will be gathered.

Cheers
Marek

Abhinav Sahu December 15, 2013

Hi Marek,

I didn't find this error anywhere in my server log. Is there any specific location for clover to log.

I have enabled "-Dclover.logging.level=debug" on client, when a testcase is executed. I got below output:

Clover.getRecorder(/home/ta230208/coverage.db, name=clover.tcp.server;host=localhost;port=1234;timeout=10000;numClients=2;retryPeriod=1000, 1386950003546, 0, 101369) called from (first 10 stack elements):
com_cenqua_clover.Clover.getRecorder(Clover.java:122)
com.teradata.datamovement.commandline.standalone.DataMovementCommandLine$__CLR3_1_023962396hp5m7zzt.<clinit>(DataMovementCommandLine.java:211)
com.teradata.datamovement.commandline.standalone.DataMovementCommandLine.main(DataMovementCommandLine.java:6737)

[creating new recorder for /home/ta230208/coverage.db_1386950003546_0]
Failed to newly create the recording-is-live flag file at /home/ta230208/coverage.db.liverec because the file already exists
Added shutdown hook for registry at /home/ta230208/coverage.db
Started recorder for registry at "/home/ta230208/coverage.db": FixedSizeCoverageRecorder[elements.length=106261]
DistributedConfig: data = name=clover.tcp.server;host=localhost;port=1234;timeout=10000;numClients=2;retryPeriod=1000
Distributed coverage is enabled with: name=clover.tcp.server;host=localhost;port=1234;timeout=10000;numClients=2;retryPeriod=1000
Creating listener com.cenqua.clover.remote.CajoTcpRecorderListener  for config: clover.tcp.server
Starting distributed coverage client: name=clover.tcp.server;host=localhost;port=1234;timeout=10000;numClients=2;retryPeriod=1000
Started timer to attempt reconnect every: 1000 ms.Attempting connection to: //localhost:1234/clover.tcp.server
Could not connect to server at //localhost:1234/clover.tcp.server. Connection refused to host: localhost; nested exception is:
        java.net.ConnectException: Connection refusedCould not connect to server at //localhost:1234/clover.tcp.server. Connection refused to host: localhost; nested exception is:
        java.net.ConnectException: Connection refused : Connection refused to host: localhost; nested exception is:
        java.net.ConnectException: Connection refused
java.rmi.ConnectException: Connection refused to host: localhost; nested exception is:
        java.net.ConnectException: Connection refused
        at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:601)
        at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:198)
[...]

Am I missing something for server or client?
Thanks again.
-Sahu
Marek Parfianowicz
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
December 16, 2013

Hi Abhinav,

You wrote that:

4. Testcase is executing on client

It means that JVM which runs the test case must have the -Dclover.server=true property set. The most probably you did not set this, because log contains:

Could not connect to server at //localhost:1234/clover.tcp.server. Connection refused to host: localhost;

It means that the coverage recorder from the "Clover Client" was unable to connect to the "Clover Server".

I suggest a lecture of the following article:

Please note that the terms "Clover Server" and "Clover Client" in the article above have nothing in common with the actual Client/Server archiecture of an application under test.

Simply speaking, the "Clover Server" means a JVM which is running unit tests; and "Clover Client(s)" are JVM(s) running rest of the code.

Cheers
Marek

Abhinav Sahu December 19, 2013

Hi Marek,

Very thanks for your inputs, I have done the same and now I am able to connect the server but still I don't see any coverage info for Server code :(

Below is the snapshot:

Clover.getRecorder(/home/ta230208/coverage.db, name=clover.tcp.server;host=localhost;port=1234;timeout=10000;numClients=2;retryPeriod=1000, 1386950003546, 0, 101369) called from (first 10 stack elements):
com_cenqua_clover.Clover.getRecorder(Clover.java:122)
com.teradata.datamovement.commandline.standalone.DataMovementCommandLine$__CLR3_1_023962396hp5m7zzt.<clinit>(DataMovementCommandLine.java:211)
com.teradata.datamovement.commandline.standalone.DataMovementCommandLine.main(DataMovementCommandLine.java:6737)
[creating new recorder for /home/ta230208/coverage.db_1386950003546_0]
Added shutdown hook for registry at /home/ta230208/coverage.db
Started recorder for registry at "/home/ta230208/coverage.db": FixedSizeCoverageRecorder[elements.length=106261]
DistributedConfig: data = name=clover.tcp.server;host=localhost;port=1234;timeout=10000;numClients=2;retryPeriod=1000
Distributed coverage is enabled with: name=clover.tcp.server;host=localhost;port=1234;timeout=10000;numClients=2;retryPeriod=1000
Starting distributed coverage service.
Creating service com.cenqua.clover.remote.CajoTcpRecorderService for config: clover.tcp.server
About to start service with config: name=clover.tcp.server;host=localhost;port=1234;timeout=10000;numClients=2;retryPeriod=1000
Started coverage service: clover.tcp.server
Clover waiting for 2 remote clients to attach to this remote testing session.
registerListener(). proxies: []
Accepting connection from client: 127.0.0.1
Waiting for 2 remote VMs 1
registerListener(). proxies: [clover.gnu.cajo.utils.extra.ClientProxy@5ff06dc3]
Accepting connection from client: 127.0.0.1
Waiting for 2 remote VMs 2
Recording proceeding now that 2 clients are connected.

Please let me know any other option, I have tried everything.

Thanks again for your help.

Marek Parfianowicz
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
December 19, 2013

Hello Abhinav,

According to log, it looks that coverage recorders have started properly.

Questions:

1) Do you see a global coverage file (named like "clover.db<some_hash_code>") in the directory where clover.db is located (on the server)?

2) If not - do you shutdown your server(s) after tests are finished? Are they being shutted down before you generate Clover report?

3) If not - what flush policy is set in the clover-setup? If it is not set, then by default Clover will write a global coverage file at the JVM termination (it add a listener to the JVM shutdown hook). In case your server(s) runs indefinitely or is being terminated after report generation, this can be the cause of lack of the coverage data.

In such case - please change the flushPolicy to "interval" or "threading" in the clover-setup. Alternatively, shutdown the server after tests.

ad 1) In case you do see a global coverage file (on the server) then maybe you have a problem not with a coverage recording but with a report generation.

Questions:

  • how do you generate a Clover report for your client and server(s)?
  • do you copy all coverage files produced to a single location?
  • do you have a single Clover database for the client module and server modules or each of them has its own database?

I'm asking because coverage recording files could have been not picked by the clover-report task.

Cheers
Marek

Abhinav Sahu December 22, 2013

Hi Marek,

Thanks for your valuable comments.

I am able to see "clover.db<some_hash_code>" in the directory for every tests.

Snapshot:

esxsrv13:/home/ta230208 # ls

build_report3.xml clover.license coverage.db50u0qc_hpfkv2sj coverage.dbbbonxv_hpfkycyb coverage.dbjm9gl9_hpfkv3xf results clover.jar coverage.db coverage.dbbbonxv_hpfkwcwb coverage.dbfogj8o_hpfkye3c coverage.dbjm9gl9_hpfkwdns

My ant task (for report) looks like:

<target name="clover.html">

<delete dir="results" />

<mkdir dir="results" />

<clover-report initString="/home/ta230208/coverage.db">

<current outfile="results" summary="true">

<format type="html" srcLevel="false" showEmpty="true"/>

</current>

</clover-report>

</target>

Yes my server is running indefinitely even after report generation. So do you want it to be shutdown after execution of tests and before report is generated.

Where I can keep flushPolicy in ant task?

Thanks again.

jjaroczynski
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
December 22, 2013

Hello Abhinav,

It looks like coverage files are generated correctly if you can see files like clover.db<some_hash_code>. Can you attach at least partial list of files you can see to this thread? We would like to confirm that they are coverage files.

Can you also let us know what kind of Flush Policy do you use? Please read following article to find out more: https://confluence.atlassian.com/display/CLOVER/Using+a+Flush+Policy
We would like to understand coverage files are being stored if you do not shutdown your server.

Cheers,
Jacek

Abhinav Sahu December 22, 2013

Hi Jacek,

Thanks for your quick response.

I am attaching few coverage.db<some_hash_code> files, please have a look.

(coverage.dbbbonxv_hpjjqrv7.txt) (coverage.dbpicepx_hpjjqt08.txt) (coverage.dbqp3nku_hpjk1rfl.txt) (coverage.dbt19vqc_hpjk3dpw.txt)

I have added .txt at end, please rename them.

And I am not using any flush policy as we don't shutdown the servers any time.

Thanks again.

jjaroczynski
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
December 22, 2013

Hello Abhinav,

The thing is that in client/server usage, one of following things must happen to store coverage files :

  • server shutdown
  • non-default Flush policy (threaded or interval)

If the files are there in your case then you probably shutdown the server some time ago and the files are old or you changed Flush policy. Please read the linked article to get a brief overview of how it works: https://confluence.atlassian.com/display/CLOVER/Using+a+Flush+Policy

Can you also attach a log from your attempt to generate Clover report? It should work fine if the covereage files are there. What do you get when you run the report task? Just an empty report?

Cheers,
Jacek

Abhinav Sahu December 30, 2013

Hi Marek/Jacek,

Thanks for your help, using flush policy made the trick. Now its working fine. :)

Thanks again for all your responses.

Regards,

Abhinav Sahu

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events