Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Networking between a Java application and an executable launched with Runtime.exec()

 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

I've got a situation where a Java application needs to launch an .exe file (by calling Runtime.exec) and then listen on a TCP socket for messages from the .exe process. The problem is that the Java process doesn't receive anything from the .exe process.

Now here's the interesting part:
If I start the Java process and then start the .exe manually, Java receives all communication from the .exe perfectly.

In other words, it seems like the .exe wouldn't have privileges to open network connections or something if launched with Runtime.exec. I'd appreciate any knowledge, educated guesses, even stabs in the dark with regard to what could be the issue here.

Thanks.
 
Henry Wong
author
Marshal
Pie
Posts: 21214
81
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In other words, it seems like the .exe wouldn't have privileges to open network connections or something if launched with Runtime.exec. I'd appreciate any knowledge, educated guesses, even stabs in the dark with regard to what could be the issue here.


Purely as an educated guess... Maybe the .exe is trying to connect before the java program is listening on the port. I would would considering listening to the port (in another thread) first.

Henry
 
Simon Brown
sharp shooter, and author
Ranch Hand
Posts: 1913
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've had problems doing this once before and reading the contents of the output stream returned from the Process seemed to kickstart things (the process was just blocked, I think). Perhaps worth a try...
[ May 22, 2005: Message edited by: Simon Brown ]
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Henry Wong:
Purely as an educated guess... Maybe the .exe is trying to connect before the java program is listening on the port. I would would considering listening to the port (in another thread) first.

Thanks, Henry, for the educated guess
Unfortunately that wasn't the problem. The Java program starts listening on the port already several seconds before the .exe is being launched.
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Simon Brown:
I've had problems doing this once before and reading the contents of the output stream returned from the Process seemed to kickstart things (the process was just blocked, I think). Perhaps worth a try...

Hmm. I'll try and let you know whether it helped. Thanks.

...

Nope. It didn't help. I started two instances of the following "StreamGobbler" class/thread to consume whatever the .exe would print into stderr or stdout but both threads print "Read 0 bytes" after the .exe application is shut down.
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24211
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This isn't running on an old version of Windows, is it? There used to be a problem where if you used the Runtime.exec() that passed environment variables, you'd have to add a special variable or the TCP stack would be loaded for the child process. This was true as late as NT4, I think -- unless it was NT 3.51.
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ernest Friedman-Hill:
This isn't running on an old version of Windows, is it? There used to be a problem where if you used the Runtime.exec() that passed environment variables, you'd have to add a special variable or the TCP stack would be loaded for the child process. This was true as late as NT4, I think -- unless it was NT 3.51.

Nope. I've got Windows XP. Although the software I'm talking about needs to work on Windows 2000 as well.
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok. Problem solved. For some odd reason, the executable is not able to send stuff over the network if some environment variable isn't set. And when you launch the executable with Runtime.exec(), that environment variable isn't there.

For those coming after me, I solved the problem by passing the environment variables as the third argument to Runtime.exec(String, String[], File). I also noticed that getting the environment variables in the first place is surprisingly difficult in Java 1.4 (where System.getenv(String) throws an exception saying it's deprecated and System.getProperties() doesn't return environment variables unless they were passed in to the JVM with the -D option):
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24211
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Lasse Koskela:
Ok. Problem solved. For some odd reason, the executable is not able to send stuff over the network if some environment variable isn't set. And when you launch the executable with Runtime.exec(), that environment variable isn't there.


Huh -- so I was right, or half-right, anyway. I thought this was fixed long ago! The original origin of this issue was that WINSOCK.DLL was a bolt-on to Windows -- Windows didn't natively offer TCP/IP support. Without the environment variable, this DLL couldn't load properly. I assumed -- wrongly, apparently! -- that in later years this simply went away, but apparently, it did not. This is good to know -- thanks, Lasse!
 
Gregg Bolinger
GenRocket Founder
Ranch Hand
Posts: 15302
6
Chrome IntelliJ IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ernest Friedman-Hill:


Huh -- so I was right, or half-right, anyway. I thought this was fixed long ago! The original origin of this issue was that WINSOCK.DLL was a bolt-on to Windows -- Windows didn't natively offer TCP/IP support. Without the environment variable, this DLL couldn't load properly. I assumed -- wrongly, apparently! -- that in later years this simply went away, but apparently, it did not. This is good to know -- thanks, Lasse!


I fear you expect too much from The Gates.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic