I m trying to integrate Jacoco with Websphere to get the code coverage by Manual Testing.
I have set JVM arguments as below
![-javaagent:C:\Shankara\Software\jacoco-0.7.2.201409121644\lib\jacocoagent.jar=destfile=C:\Shankara\Software\jacoco.exec,append=true,includes=com.*][1]
i m able to get exec file successfully however the coverage is still red colour. Please assists me on this urgently
Did you stop the target JVM instance.
Until you do that, you won't get the code coverage data (of source main code) via running your non-unit tests.
Try this:
1. Attach jacocoagent.jar and pass params (like you have done) then
2. Run your tests (manual / automated which will exercise / cover the main source code), then
3. Stop the target JVM instance/session (which is WebSphere), then
4. You'll notice jacoco file size will be a little more than what you're getting before.
Use this jacoco exec (which you get after stopping the target JVM instance) for running jacocoTestReport to get the final code coverage %.
Note: If you don't want to stop the target JVM session/instance where your application/webservice is running then read Jacoco documentation as there's a way to do that too.
See here: http://www.eclemma.org/jacoco/trunk/doc/agent.html
Specially the parameters:
dumponexit If set to true coverage data will be written on VM shutdown. The dump can only be written if either file is specified or the output is tcpserver/tcpclient and a connection is open at the time when the VM terminates. true
output Output method to use for writing coverage data. Valid options are:
file: At VM termination execution data is written to the file specified in the destfile attribute.
tcpserver: The agent listens for incoming connections on the TCP port specified by the address and port attribute. Execution data is written to this TCP connection.
tcpclient: At startup the agent connects to the TCP port specified by the address and port attribute. Execution data is written to this TCP connection.
none: Do not produce any output.
Please see the security considerations below.
address IP address or hostname to bind to when the output method is tcpserver or connect to when the output method is tcpclient. In tcpserver mode the value "*" causes the agent to accept connections on any local address. loopback interface
port Port to bind to when the output method is tcpserver or connect to when the output method is tcpclient. In tcpserver mode the port must be available, which means that if multiple JaCoCo agents should run on the same machine, different ports have to be specified.
Related
Have a Windows environment where the "Ports" tab is empty on all network printers, but only on some win7 clients. All other printing functionality from these clients works to printers on those print servers. Due to the way the environment is set up I cannot easily attach a kernel debugger to these vSphere virtual machines.
Server 2008 R2 machines - OK
Clean Win7 machine - OK
Win7 machine + much 3rd party software, including 3rd party device drivers, multiple API hooking software, etc - BROKEN
All machines are joined to same domain, and logged in as same user.
Using Rohitab API Monitor on Explorer.exe I identified the winspool EnumPorts is succeeding, but returning 0 ports on the failing machine, but under same user account/same network and same parameters it returns 600+ ports on both working machines..
I wrote a test C++ program to test EnumPorts on its own. The Visual Studio 2015 project + binary is here
The key part of this program is:
pPortInfo = (PORT_INFO_2 *)malloc(cbNeeded);
bResult = EnumPorts(argv[1],
2,
(LPBYTE)pPortInfo,
cbNeeded,
&cbNeeded,
&cbReturned);
On a working machine output from pPortInfo is :
CALL: EnumPorts("\\PRINTSERVER01",(LPBYTE)pPortInfo,4096,&cbNeeded,&cbReturned)
RETURNED: false ERROR CODE: 122 ERROR MSG: The data area passed to a system call is too small.
CALL: EnumPorts("\\PRINTSERVER01",(LPBYTE)pPortInfo,121800,&cbNeeded,&cbReturned)
RETURNED: true ERROR CODE: 0 ERROR MSG: The operation completed successfully.
cbReturned = 629
PORT #0
Port Name: TS005
Monitor Name: Dynamic Print Monitor
Description: Inactive TS Port
Port Type: WRITE READ
PORT #1
Port Name: TS004
Monitor Name: Dynamic Print Monitor
Description: Inactive TS Port
Port Type: WRITE READ
etc...
On the broken machine:
CALL: EnumPorts("\\PRINTSERVER01",(LPBYTE)pPortInfo,4096,&cbNeeded,&cbReturned)
RETURNED: true ERROR CODE: 0 ERROR MSG: The operation completed successfully.
cbReturned = 0
What I have identified/tried so far
Using SysInternals AutoRuns to compare machines there are hundreds of differences between Windows Services Configuration/Drivers/Hooking DLLs on both machines. I want to find a technique to narrow this down to potential culprit without having to remove/disable all these items
I've tried disabling all hooking DLLs by renaming AppInit_DLLs key and confirming these DLLs no longer load in the process, but it remains broken
Captured WireShark trace - On the working machine network traffic is sent/received to the print server when EnumPorts is called. On the broken machine there is no network traffic sent to the print server at all. However on the broken machine you can still run commands like net view /all \ and map to printers/drives on the remote print server.
Used Microsoft Message Analyzer RPC trace, this logs the RPC calls but not sure how to interpret this data. None of the calls appear to be failing.
Looking deeper into winspool!EnumPorts it uses NdrClientCall2 to communicate with print server but these calls are not failing.
Tried disabling local firewall
Tried netsh winsock reset and restarting
Tested with antivirus disabled
Created a filter in Windows Event viewer to look at ALL windows event log entries during the time test is run and can't find any seemingly related errors
Running my test tool via WinDbg there are no first chance exceptions or other errors
Tried setting a breakpoint at the completion of EnumPort function then created a complete memory dmp with NotMyFault but couldn't find anything, and didn't really know what I was looking for in the first place
Used Process Monitor to look for missing registry keys/files and couldn't find any
I am using the Python Cassandra driver offered by Datastax to connect to a single node Cassandra instance. My Python code spawns multiple processes (using the multiprocessing module), each of which opens a connection to this node, and shuts it down during exit.
Here's the behavior I observe: when the number of processes spawned is less (say ~ 30) my code runs flawlessly. But with a higher number I see errors like these (probably not surprising):
File "/usr/local/lib/python2.7/dist-packages/cassandra/cluster.py", line 755, in connect
self.control_connection.connect()
File "/usr/local/lib/python2.7/dist-packages/cassandra/cluster.py", line 1868, in connect
self._set_new_connection(self._reconnect_internal())
File "/usr/local/lib/python2.7/dist-packages/cassandra/cluster.py", line 1903, in _reconnect_internal
raise NoHostAvailable("Unable to connect to any servers", errors)
NoHostAvailable: ('Unable to connect to any servers', {'127.0.0.1': error(99, "Tried connecting to [('127.0.0.1', 9042)]. Last error: Cannot assign requested address")})
Apparently, the host is unable to accept new connections. This is something that looks like should be taken care of by the driver or Cassandra - by having new connection requests queue up and grant them when it frees up.
How do I impose this behavior?
"Cannot assign requested address" can indicate that you're running out of local ports. This is not up to the driver -- it is a system configuration issue. Here is a good article about the problem (it refers to MySQL, but the issue is the same). Note that connections in TIME_WAIT state occupy local ports, and can linger beyond individual program runs.
The article discusses multiple solutions, including expanded port ranges, listening on multiple IP addresses, or changing application connection behavior. I would consider application behavior, and recommend running fewer processes. Depending on what you're trying to overcome with multiprocessing, you'd probably be best served using (process count) <= (machine cores) (this is the default behavior of multiprocessing.Pool).
I'm using jacocoagent.jar having placed in my app code. But when I restarts the app service not getting the jacoco.exec. Not getting the file even after executing test case using the box where app code is deployed. (provided path of the file in one .conf file).Serv is Geronim used for
Whether jacoco.exec should get created for the first time? once the app service is restarted or once any test case is executed?
By default, JaCoCo generates the .exec file after the server is shut down. If you want to change that behavior, you need to listen to the port where JaCoCo is generating the output and pipe it to another file. This change can be done in the configuration and by running a listener to collect the data generated by JaCoCo.
I'm using MATLAB to connect to a database hosted in AWS (using the database toolbox). In order to do that, I supply the URL of the database as a local port and create a SSH tunnel to the AWS host.
The issue is that this tunnel needs to be created in order for the code to run. If it is not, no error message is generated but MATLAB gets hung and needs to be killed. I would like to deploy this code to users who will not be able to troubleshoot if this tunnel is missing.
My question is: is there a way to check for a local port opening in MATLAB? How would I check if the tunnel is setup?
Since you are using the Database Toolbox, you might want to use the logintimeout function. As the documentation says:
Note If you do not specify a value for logintimeout and the MATLAB session cannot establish a database connection, your MATLAB
session may freeze.
And you would wrap your code inside a try/catch block
I am not familiar with Matlab's TCP objects, but there is a system command that executes a program, returning its exit code (see its documentation). So what would probably do the job is a small program or script (as portable as needed), that tries to connect to the local port.
Alternatively, the small program/script could actually open (or re-open) the tunnel and return 0 on success. (This possibly adds the problem of how Matlab handles forking processes, I don't know how it handles that.)
There probably is some way to do the check if open and re-open if not-housekeeping via Matlab, but I have no clue.
We occasionaly have a problem where we attempt to start the Jrun service and it fails with the following two errors:
error JRun Naming Service unable to start on port 2902
java.net.BindException: Port in use by another service or process: 2902
info No JDBC data sources have been configured for this server (see jrun-resources.xml)
error java.net.BindException: Port in use by another service or process: 8300
We then have to reboot the machine and Jrun comes up with no problem. This is very intermittent - happens perhaps one out of every 10 times we restart Jrun services.
I saw another reference on StackOverflow that if Windows Services take longer than 30 seconds to restart Windows shuts down the startup proccess. Perhaps that is the issue here? The logs indeed indicate that these errors are thrown about 37+ seconds after the restart command is issued.
We are on a 64bit platform on WinServer 2008.
Thanks!
We've been experiencing a similar problem on some of our servers. Unfortunately, netstat never indicated any sort of actual port conflict for us. My suspicion is that it's related to our recent deployment of a ColdFusion "cumulative hotfix" to our servers. We use the multi-server edition of CF 8.0.1 enterprise with a large number of instances on each machine -- each with its own JVM and its own distinct set of ports. Each CF instance is attached to its own IIS website and runs as its own Windows Service.
Within the past few weeks, we started getting similar "port in use" exceptions on startup, on our 32-bit machines as well as our 64-bit machines, all of which are running Windows Server 2003. I found several possible culprits and tried the following:
In jrun-jms.xml for each CF instance, there's an entry for the RMI transport layer that reads <port>0</port> -- which, according to the JRun documentation, means "choose a random port." I made that non-random and distinct per instance (in the 2600-2650 range) and restarted each instance. Things improved temporarily, perhaps coincidentally.
In the same file, under the entry for the TCPIP transport later, every instance defaulted to <port>2522</port> -- so I changed those to distinct ports per instance in the 2500-2550 range and restarted each instance. That didn't seem to help at all.
I tried researching whether ports in the 2500-3000 range might be used for any other purpose, and I couldn't find anything obvious, and besides, netstat wasn't telling me that any of my choices were in use.
I found something online about Windows designating ports from 1024 to 5000 as the "dynamic port" range, so I added 10000 to the port numbers I had set in jrun-jms.xml and restarted each instance again. Still didn't help.
I tried changing the port in jndi.properties, also by adding 10000 to the port numbers. Unfortunately this meant wiping out all my wsconfig connections to IIS and creating them again from scratch. I had to edit wsconfig_jvm.config as well, adding -DWSConfig.PortScanStartPort=12900 to java.args, so it could detect my CF instances. (By default it only scans ports 2900-3000. See bpurcell.org for details. It's an old post but still relevant.) So far so good!
My best guess is that Adobe (or MS Windows) changed the way some of its code grabs "random" ports. But all I know for sure so far is that the steps outlined above appear to have fixed the problem.
Have you verified that the services are in fact stopping? Task manager should show no instances of jrun.exe. You can also check to see what is bound to that port by opening a command window and running
netstat -a -b
This will list all your open ports, plus what program is using them. You can also use
netstat -a -o
Which does the same thing as the above, but will list the process id instead of the program name. You can then cross-reference those with task manager. You'll need to enable showing the PIDs in task manager by going to View->Select Columns and making sure PID is checked. My guess would be that the jrun processes are not shutting down in a timely fashion.