JDK exec 1.3 vs 1.4

[André Hurschler]

Hello

I start a Linux bash script for Oracle import, with the exec command.
With JDK 1.3 is everything correct but JDK 1.4 breaks
the process after 20000 imported rows.
Has someone an idea ?

Runtime rtime = Runtime.getRuntime();
Process child = rtime.exec("/bin/bash");
BufferedWriter outCommand = new BufferedWriter(new
OutputStreamWriter(child.getOutputStream()));
// execute the command
outCommand.write(command);
outCommand.newLine();
outCommand.flush();
// exit bash shell
outCommand.write("exit");
outCommand.newLine();
outCommand.flush();
// wait for the shellscript to complete
try
{
int retCode = child.waitFor();
return retCode;
}
catch (InterruptedException iex)
{
// interrupted by another thread
return -1;
}


thanks

André Hurschler

(e-mail address removed)

 

[Paul Lutus]

Hello

I start a Linux bash script for Oracle import, with the exec command.
With JDK 1.3 is everything correct but JDK 1.4 breaks
the process after 20000 imported rows.

Maybe this has nothing to do with Java. All your routine is doing is waiting
for the process to finish. You may want to look into resource issues at the
system level, to see if the problem lies elsewhere.

 

[André Hurschler]

Maybe this has nothing to do with Java. All your routine is doing is
waiting

for the process to finish. You may want to look into resource issues at the
system level, to see if the problem lies elsewhere.

Paul Lutus

Hello Paul

hmmm Maybe, but I had tested under 1.3 and 1.4 and it was reproducibly.

 

[Paul Lutus]

Hello Paul

hmmm Maybe, but I had tested under 1.3 and 1.4 and it was reproducibly.

Then perhaps look at system memory usage under both conditions. Maybe 1.4 is
using more system memory, sufficiently so to produce this outcome. I don't
think this has anything to do with the Process.waitFor() issue, at least
directly.

 

[John B. Matthews]

Maybe this has nothing to do with Java. All your routine is doing is waiting
for the process to finish. You may want to look into resource issues at the
system level, to see if the problem lies elsewhere.

Paul Lutus

Hello Paul

hmmm Maybe, but I had tested under 1.3 and 1.4 and it was reproducibly.[/QUOTE]

Does the (import?) command you send execute correcly from an
interactive shell? Same user? Same quotas? Same ulimits?

John

 

[André Hurschler]

Does the (import?) command you send execute correcly from an

interactive shell? Same user? Same quotas? Same ulimits?

John

Hello John

Yes the import is from a interactive shell correct.
And all users have unlimited access.

ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) unlimited
cpu time (seconds, -t) unlimited
max user processes (-u) 7168
virtual memory (kbytes, -v) unlimited

Disk quotas for user xyz (uid 504): none

 

[John B. Matthews]

Does the (import?) command you send execute correcly from an
interactive shell? Same user? Same quotas? Same ulimits?

John

Hello John

Yes the import is from a interactive shell correct.
And all users have unlimited access.

ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) unlimited
cpu time (seconds, -t) unlimited
max user processes (-u) 7168
virtual memory (kbytes, -v) unlimited

Disk quotas for user xyz (uid 504): none[/QUOTE]

More specifically: user1 runs the import via Runtime.exec();
user2 runs the same command in an interactive shell. Are user1
and user2 the same user? Do they have the same database resource
quotas (e.g. tablespace, rollback, etc.)?

It might also be instructive to examine Process.getErrorStream()
and Process.getInputStream() for diagnostic output.

John

 

[Babu Kalakrishnan]

It might also be instructive to examine Process.getErrorStream()
and Process.getInputStream() for diagnostic output.

Now that you brought up getInputStream / getErrorStream, I remember seeing a
problem discussed on one of the c.l.j newsgroups where a Process would stop
midway because it had no way to write to its stdout / stderr handles. The
OP may find that his error has vanished once he starts reading from these two
streams !!

From the API docs of java.lang.Process :

The parent process uses these streams to feed input to and get output from the
subprocess. Because some native platforms only provide limited buffer size for
standard input and output streams, failure to promptly write the input stream or
read the output stream of the subprocess may cause the subprocess to block, and
even deadlock.

BK

 

[John B. Matthews]

Now that you brought up getInputStream / getErrorStream, I
remember seeing a problem discussed on one of the c.l.j
newsgroups where a Process would stop midway because it had
no way to write to its stdout / stderr handles. The OP may
find that his error has vanished once he starts reading from
these two streams !!

From the API docs of java.lang.Process :

The parent process uses these streams to feed input to and
get output from the subprocess. Because some native platforms
only provide limited buffer size for standard input and
output streams, failure to promptly write the input stream or
read the output stream of the subprocess may cause the
subprocess to block, and even deadlock.

BK

I had overlooked this! Typically, database import tools produce
copious standard output, which would explain the oddly
consistent delay before blocking. One may hope the OP's
integrity constraints are in working order

John