search

coherence-community / oracle-bedrock

Oracle Bedrock
Other
55 stars 31 forks source link

ApplicationConsoles should not be sharable between Applications #271

Closed brianoliver closed 8 years ago

brianoliver commented 9 years ago

Imagine two or more Applications that are started using the same ApplicationConsole.

Now lets imagine that we send (using StdIn) some input using the ApplicationConsole. Which of the Applications receive the StdIn? Do they receive the same input? Do they receive part of the input? Does only one receive the input?

Currently the semantics are undefined (as witnessed by multiple Redirector threads attempting to read from the same shared BufferedInputStream).

For example, below we can see that two redirector threads are attempting to read from the same BufferedInputStream (0x00000000c0051a00).

In reality we should not allow ApplicationConsoles to be shared between Applications, instead new ones should be created (especially for input-purposes). Fortunately we now support using ApplicationConsoleBuilders, which should do the trick!

Fundamentally we need to change the SystemApplicationConsole so that it doesn't read from StdIn, but instead reads from a provided BufferedInputStream (which should not be Stdin). If it is we should warn about it.

Stack Trace:

"Application-1 StdIn Thread" #33 daemon prio=5 os_prio=0 tid=0x0000000056d27800 nid=0x14f0 runnable [0x000000005a95e000]
java.lang.Thread.State: RUNNABLE
at java.io.FileInputStream.readBytes(Native Method)
at java.io.FileInputStream.read(FileInputStream.java:255)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
- locked <0x00000000c0051a00> (a java.io.BufferedInputStream)
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
- locked <0x00000000eff33da8> (a java.io.InputStreamReader)
at java.io.InputStreamReader.read(InputStreamReader.java:184)
at java.io.BufferedReader.fill(BufferedReader.java:161)
at java.io.BufferedReader.readLine(BufferedReader.java:324)
- locked <0x00000000eff33da8> (a java.io.InputStreamReader)
at java.io.BufferedReader.readLine(BufferedReader.java:389)
at com.oracle.tools.runtime.AbstractApplication$InputRedirector.run(AbstractApplication.java:437)
at java.lang.Thread.run(Thread.java:745)

"Application-2 StdIn Thread" #67 daemon prio=5 os_prio=0 tid=0x0000000058ab7800 nid=0x1674 waiting for monitor entry [0x000000005d18e000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.io.BufferedInputStream.read(BufferedInputStream.java:336)
- waiting to lock <0x00000000c0051a00> (a java.io.BufferedInputStream)
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
- locked <0x00000000f00bb720> (a java.io.InputStreamReader)
at java.io.InputStreamReader.read(InputStreamReader.java:184)
at java.io.BufferedReader.fill(BufferedReader.java:161)
at java.io.BufferedReader.readLine(BufferedReader.java:324)
- locked <0x00000000f00bb720> (a java.io.InputStreamReader)
at java.io.BufferedReader.readLine(BufferedReader.java:389)
at com.oracle.tools.runtime.AbstractApplication$InputRedirector.run(AbstractApplication.java:437)
at java.lang.Thread.run(Thread.java:745)
brianoliver commented 8 years ago

@brianoliver said: With the refactoring to use Options for specifying parameters, this is now much harder to achieve as every launch request uses a new builder instance.

There's still the possibility that a static reference to an individual builder may be used, but this is probably ok as it would be "by design" when someone does this.

brianoliver commented 8 years ago

This issue was imported from JIRA ORACLETOOLS-271

brianoliver commented 9 years ago

Reported by @brianoliver

brianoliver commented 8 years ago

Marked as works as designed by @brianoliver on Monday, May 9th 2016, 7:41:57 am