Here's what I believe is going on:
The OI configurator in the GF installer does the following:
productError = javaExecuteCommand.getErrors();
This causes OI to read the error output from the process that it
The process that it spawns (the UC bootstrapper) spawns a second,
long running process - the notifier. The UC bootstrapper does not
wait for the notifier to exit, nor does it attempt to capture the
output stream from that process. The bootstrapper just launches
the notifier then finishes its work and exits. It doesn't care
whether the notifier was sucessfully started or not.
On Windows it appears that when the bootstrapper process exits the
OI process inherits the notifier's output stream. Instead of
only reading the output from the bootstrapper OI configurator is also
is waiting on any output from the notifier (python).
This does not occur on Solaris. It seems to be Windows specific.
I suspect that on Windows if the OI configurator did not attempt to
collect the error output from the UC bootstrapper this problem would
go away. It would also go away if the bootstrapper did not attempt
to start the notifier.
This explains why some folks do not see this problem. If the notifier
is already running when they install GF or they choose not to enable
UC notifications the notifier will not be started or it will exit
immediately when it sees that one is already running - thus no issue.
It is only when the bootstrapper starts the notifier and an instance
is not already running will this problem occur.
One option might be to not use the ExecuteCommand in the OI configurator
but rather use Runtime.exec directly and manage the input/out stream
directly. Use InputStream.available() to test whether there is any
error output to read from the bootstrapper.