Re: Issue implementing Runtime.exec() with StreamGobbler
- From: "Matt Humphrey" <matth@xxxxxxxx>
- Date: Mon, 9 Mar 2009 19:49:30 -0400
"Vic" <vikrantp@xxxxxxxxx> wrote in message
news:9dbde3a1-605a-4816-9d2a-77c48a2de197@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
To give you guys an idea about the way we run automation is
we do jloader -v <version> >&! out/<log file>
So jloader basically calls LoaderAutomationRun.java (starts the loop)
and calls LoaderTestcase.java in the loop for each test case and
inside LoaderTestcase.java it runs the commands using
NewCommandExecuter.
I just looked a thte out/<log file> and it just shows something like
this ->
TESTCASE Transaction836
Start generation all loader files
DEBUG: validating(transaction/*
DEBUG: NEW load order transaction/1,
DEBUG: FINAL NEW load order transaction/1,
Executing generateLoaderFile(transaction/1, 0)
dTrans: null
Executing generateLoaderFile, adding Transaction836.0.lrd
LOADER FILES CREATED 1
DEBUG: Created 1 loader files
New Command Executer: EXECUTING
COMMAND: /home/qauser/620currentLOADER/
bin/loader -u genevaman -w qa -f Transaction836.0.lrd
As you can see the last line, the New Command Executer never returned.
Sorry to bother you guys but I really want to get this solved soon so
any help on this would be appreciated. Thanks in advance
Ok, so what you're observing is that diagnostic line "ExitValue for Command"
does not appear in the output, but you still haven't shown the loop code or
said what you mean by "never returned" Now that we understand the previous
problem, we know that if the test returns null the loop will exit and your
main program will still stop without any messages. This new case, however,
looks like the test process itself never finishes and the test driver does
not stop. Is that the case? You need to say more about what that loop is
and does.
If your test driver is hanging, I'd guess that the test process itself is
faulty. Perhaps it's requesting input or just plain stuck. If your test
driver is halting, the answer will be in how it halts. It may fail if New
Command Executer throws an exception prior to waitFor. It's not clear that
stderr exceptions are appearing in your output and we know that the null
will cause your main to halt with no messages.
Lew also mentioned one possible case by which the StreamGobbler's assignment
of the result field in its own thread is not visible to the driver thread
because of the lack of synchronization. Put the keyword "volatile" on the
String result declaration in StreamGobbler to fix this.
Matt Humphrey http://www.iviz.com/
.
- Follow-Ups:
- References:
- Issue implementing Runtime.exec() with StreamGobbler
- From: Vic
- Re: Issue implementing Runtime.exec() with StreamGobbler
- From: Robert Klemme
- Re: Issue implementing Runtime.exec() with StreamGobbler
- From: Vic
- Issue implementing Runtime.exec() with StreamGobbler
- Prev by Date: Re: Why doesn't ArrayDeque implement the List interface?
- Next by Date: Re: ConcurrentHashMap - concurrency between clear() and iterator on map.entrySet()
- Previous by thread: Re: Issue implementing Runtime.exec() with StreamGobbler
- Next by thread: Re: Issue implementing Runtime.exec() with StreamGobbler
- Index(es):
Relevant Pages
|
