In java, Relay starts but nothing happens

[jurandy007]

In java Relay starts but nothing happens.
I have installed on my windows 10 the JRE 8 281 x86 and x64. This only happens with gnirehtet java.

👇

PS C:\Android\Gnirehtet\Java> .\gnirehtet-run.cmd
2021-03-08 19:54:24.855 I Gnirehtet: Starting relay server on port 31416...
2021-03-08 19:54:24.855 I Gnirehtet: Checking gnirehtet client...
2021-03-08 19:54:25.015 I Relay: Relay server started

[rom1v]

Your device should open a popup. Some devices system have bugs with the popup if the screen is off (or in other conditions), gnirehtet just request the system to open a VPN.

[rom1v]

This only happens with gnirehtet java.

You mean, with the Rust version, it works?

[jurandy007]

yes, in the rust version it works

[rom1v]

Sorry, I could not reproduce. On Windows, if I run gnirehtet-run.cmd, it works as expected.

It is very suspicious that the Rust version works but the Java version fails to "start", since they execute exactly the same command.

[mythsman]

Sorry, I could not reproduce. On Windows, if I run gnirehtet-run.cmd, it works as expected.

It is very suspicious that the Rust version works but the Java version fails to "start", since they execute exactly the same command.

I encouter this problem too .

The progress stucks at process.waitFor() , because its output buffer is full ,so it is waiting for its output to be read by another progress . However the scanner cannot read the output because process.waitFor() is a blocking method.

This problem only occurs when the output of the progress is larger than the default write buffer... so it works well usually..

The solution is that we can redirect the output to another file, and then read from that file...

#370

[rom1v]

The progress stucks at process.waitFor(), because its output buffer is full

Oh, yes! 👍

The solution is that we can redirect the output to another file, and then read from that file...

Instead we could parse the output stream before waitFor().

[mythsman]

The progress stucks at process.waitFor(), because its output buffer is full

Oh, yes! 👍

The solution is that we can redirect the output to another file, and then read from that file...

Instead we could parse the output stream before waitFor().

Yes, but I think it is not the best practice. If the output is slow , you may read a fake 'eof' before the progress is actually finished :)

[rom1v]

If the output is slow , you may read a fake 'eof' before the progress is actually finished

Hmm, no, you may not read a fake EOF. You may get partial reads, but not fake EOF.

Writing a file to the filesystem for that is not necessary.

[mythsman]

If the output is slow , you may read a fake 'eof' before the progress is actually finished

Hmm, no, you may not read a fake EOF. You may get partial reads, but not fake EOF.

Writing a file to the filesystem for that is not necessary.

Well , I just cannot come up with another solution to avoid partial reads except for creating another thread to read it ...

[rom1v]

Fixed on dev. See #370 (comment)