Service Virtualization

Hello,

all the time I get many lines of this message in VSE log file:

"2016-08-28 08:00:08,779Z (11:00) [ServerRequestResponder 165] WARN  com.itko.lisa.test.LisaException - LisaException detail Asset not found: config://queue-436AB017EB7E11E5A4A2F01FAF49ED85 exception is n/a"

How can I fix this Exception ?

Thanks

Another DevTest component is calling into the VSE server and causing this exception.  The construction of the exception causes the warning message you see in the VSE server log, but the actual exception gets propagated back to whatever remote process is making the call, where there is presumably a more complete exception log. 

Can you look in your other logs to see if this shows up anywhere else?  Whatever's doing this, it's doing it about once a second.

In another log (Registry) I have just this information :

2016-08-29 07:03:48,804Z (10:03) [Event Sink Thread Pool Thread 4] INFO  com.itko.lisa.coordinator.TestRegistryImpl - Coordinator Servers: 1 Simulator Servers: 1 VSEs: 1 Running vusers: 0 Labs: 1 Memory used 329mb, allocated 510mb, max 510mb (64%) Our cpu usage 0%, system cpu used 0% GC time 0% db ping: 1,006 ms

No more information regarding this issue.

Maybe you have any more idea how to find another component?

What version of DevTest you you have?  Do you have the VSE Console/Portal open?  My only guess is that it's coming from the VSE service status display on the web portal. 

Are you seeing an actual problem with any VSE services, or is this just something that's filling up your log?

Have you used grep or your OS's equivalent to look for the same error in your entire log directory?  Try just grepping/searching for 'queue-436AB017EB7E11E5A4A2F01FAF49ED85'.  If it doesn't show up, then can you try turning the logging level up on your server?

Edit %DEVTEST_HOME%/logging.properties and find the following line:

log4j.rootCategory=INFO,A1

Change it to

log4j.rootCategory=DEBUG,A1

I'm pretty sure you don't have to restart everything; it takes effect automatically.  Wait for the original log message to appear a few times in the VSE log, then revert the change.  Don't leave this set at 'DEBUG' for very long, as it will produce a lot of logs.  After you've done this, try to search for 'queue-436AB017EB7E11E5A4A2F01FAF49ED85' again.

Alternatively, you can search for the actual service(s) related to this error.  You can take the 'queue-XXXX' part of the error and look in your project directory or directories for a file named 'Configs/project.assets/queue-XXXX.xml'. 

There are actually four different 'asset not found' errors in your log.  Three of them are getting logged once every five seconds like clockwork.  Here are the corresponding file names to look for:

queue-30EBBB56EB5911E59B3BF01FAF49ED85.xml

queue-436AB017EB7E11E5A4A2F01FAF49ED85.xml
queue-7FC8BC49023611E6B1C3005056BD4E96.xml

And one is getting logged *twice* every five seconds.  Maybe this queue appears in more than one VSE service?

queue-5F2E6424F4B211E5B1CF005056BD4E96.xml

If you find one of these files in a project then you should be able to open it with a text editor and visually find either the name of the asset (<Name>...</Name>), or the name of the queue (<Queue>...</Queue>).  From there, you should be able to determine which VSE services use that queue asset.

If the VSE service is currently deployed then try re-deploying it to see if that particular error goes away.  You could also just try restarting the entire VSE server to see if the error goes away. 

If the service is not currently deployed, or if restarting the entire VSE server does not make the error go away, then maybe there is a bug where the web portal continues to query the status of VSE services that have been undeployed.  That's my best guess right now as to what's going on without involving official support and hopping onto a Webex.

When I saw this same error last week, it was against a WebLogic JMS virtual service, after the laptop on which WebLogic & VSE was running had been moved between networks, paused, restored, etc. I presumed that the network changes had affected the asset configuration, so I got the virtual service restarted, and it hopped back into life.

In your situation, though, I would be more suspicious of the data driving in the virtual service. Check it with a "raw" (not modified in any way after recording) service model to see whether your Excel data driving is causing the error. Data driving via Excel? Are you sure you want to be doing that, rather than using either sharedModelMap or a conversational virtual service? How do you make sure the spreadsheet can be consistently read by multiple threads when different threads are writing to it?

It's not happening in a VSE service thread.  The thread name is 'ServerRequestResponder', which is an internal thread handling a remote invocation from another DevTest process.  That's what has me puzzled.