Double streams

[Carsten H. Pedersen]

Hello.

Having an issue with double streams... for a lack of a better name. :)

I have the following two streams:
- FooInputStream, fis, extending InputStream
- FooOutputStream, fos, extending OutputStream

These each have a piped stream as a local variable, so:
- fos has a PipedOutputStream, pos
- fis has a PipedInputStream, pis

So pis and pos are initalized and connected, and are passed to fis and
fos, respectively.

What i wanted to do was write to fos, which would then delegate the
call to pos, and then i could read from fis, which would read from
pis. So the writes are fine, and the read in pis returns fine, but
then it just seems to hang. If i close any of the ouputstreams, it
returns, and everything is fine. But then i can't use the
outputstreams, and i need to do that.

Can any explain what's going on? Maybe a push in the right direction
as to how to solve it?

Regards,
Carsten H. Pedersen

[Oliver Wong]

"Carsten H. Pedersen" <[e-mail]> wrote in message
news:43***********************@dreader1.cybercity. dk...

Hello.

Having an issue with double streams... for a lack of a better name. :)

I have the following two streams:
- FooInputStream, fis, extending InputStream
- FooOutputStream, fos, extending OutputStream

These each have a piped stream as a local variable, so:
- fos has a PipedOutputStream, pos
- fis has a PipedInputStream, pis

So pis and pos are initalized and connected, and are passed to fis and
fos, respectively.

What i wanted to do was write to fos, which would then delegate the call
to pos, and then i could read from fis, which would read from pis. So the
writes are fine, and the read in pis returns fine, but then it just seems
to hang. If i close any of the ouputstreams, it returns, and everything is
fine. But then i can't use the outputstreams, and i need to do that.

Can any explain what's going on? Maybe a push in the right direction as to
how to solve it?

Do you flush the streams?

Is the reading and writing done in seperate threads?

- Oliver

[Carsten H. Pedersen]

Oliver Wong wrote:

Do you flush the streams?

Is the reading and writing done in seperate threads?

- Oliver

Well, i tried flushing. It doesn't work. Since the "outer" inputstream
gets what it needs, there shouldn't be a reason to flush the
outputstreams... or should there?

Reading and writing are in seperate threads, yeah. Each of the four
streams are in their own thread.

As i wrote, the "inner" inputstream returns to the "outer" inputstream
with the bytes written, but then it just stops, as if it is waiting
for the outputstreams to close. And if i close any of the
outputstreams, everything is fine.

/Carsten

[Oliver Wong]

"Carsten H. Pedersen" <[e-mail]> wrote in message
news:43***********************@dreader2.cybercity. dk...

Oliver Wong wrote:

Do you flush the streams?

Is the reading and writing done in seperate threads?

- Oliver
Well, i tried flushing. It doesn't work.

When you say "It doesn't work", it's not clear to me what the problem
is. Exceptions being thrown? Application deadlocks? Characters arrive in
random order? etc.
Since the "outer" inputstream gets what it needs, there shouldn't be a
reason to flush the outputstreams... or should there?
Closing an output stream in itself should not "unblock" the input
stream, but usually when an output stream closes, it first flushes itself.
That is why I ask if you tried flushing.

Reading and writing are in seperate threads, yeah. Each of the four
streams are in their own thread.

This is strange to me. I expected for there to be two threads, not four.
One thread is producing data which is pushes into the FooOutputStream, which
then forwards the data to the PipedOutputStream (all within the same
thread). Then, a second thread, reads from the FooInputStream, which then
requests data from the PipedInputStream, and then consumes the data.

- Oliver

[Carsten H. Pedersen]

Oliver Wong wrote:

Well, i tried flushing. It doesn't work.

When you say "It doesn't work", it's not clear to me what the problem
is. Exceptions being thrown? Application deadlocks? Characters arrive in
random order? etc.

Well, it does not change anything in what's going on. So a deadlock of
some sort i would guess. The characters arrive in the order they
should to the inner.

Reading and writing are in seperate threads, yeah. Each of the four
streams are in their own thread.

This is strange to me. I expected for there to be two threads, not
four. One thread is producing data which is pushes into the
FooOutputStream, which then forwards the data to the PipedOutputStream
(all within the same thread). Then, a second thread, reads from the
FooInputStream, which then requests data from the PipedInputStream, and
then consumes the data.

Yeah... i tried to replicate my problem on a smaller scale. I'm
fiddling with RMI. So two clients, each of whom has the Foo* Streams,
and inside these there is a Remote interface, which can call read()
and write(), respectively, on an object on the server. This object
being a stream, which extends PipedOutputStream (or PipedInputStream),
and the two clients communicate with eachother with the server (and
the pipes) as a proxy.

So i just made it all local, and put them all in their seperate
threads to test it... but i still get the deadlock.

Same thing happens in the RMI scenario, though:

client1 -> client1outputstream.write -> serveroutputstream.write ->
serverinputstream.read -> client2inputstream.read -> deadlock (->
client2)

I would be happy to try another solution to exchange this data between
the clients, though. It's not a must to do it this way, it's just the
way that i just sorta stumbled upon. And since this error arose, and i
don't understand, i thought i'd at least attempt to solve it before
possibly moving on to another solution.

/Carsten

[Oliver Wong]

"Carsten H. Pedersen" <[e-mail]> wrote in message
news:43***********************@dreader1.cybercity. dk...

Oliver Wong wrote:

This is strange to me. I expected for there to be two threads, not
four. One thread is producing data which is pushes into the
FooOutputStream, which then forwards the data to the PipedOutputStream
(all within the same thread). Then, a second thread, reads from the
FooInputStream, which then requests data from the PipedInputStream, and
then consumes the data.

Yeah... i tried to replicate my problem on a smaller scale. I'm fiddling
with RMI. So two clients, each of whom has the Foo* Streams, and inside
these there is a Remote interface, which can call read() and write(),
respectively, on an object on the server. This object being a stream,
which extends PipedOutputStream (or PipedInputStream), and the two clients
communicate with eachother with the server (and the pipes) as a proxy.

How many threads does each client have, and what does each thread do?

- Oliver

[Carsten H. Pedersen]

Oliver Wong wrote:

Yeah... i tried to replicate my problem on a smaller scale. I'm
fiddling with RMI. So two clients, each of whom has the Foo* Streams,
and inside these there is a Remote interface, which can call read()
and write(), respectively, on an object on the server. This object
being a stream, which extends PipedOutputStream (or PipedInputStream),
and the two clients communicate with eachother with the server (and
the pipes) as a proxy.

How many threads does each client have, and what does each thread do?

- Oliver

Each client only has one thread. Client A writes data to its
FooOutputStream, which writes to its associated PipedOutputStream on
the server. Client B reads data from its FooInputStream, which reads
from its associated PipedInputStream (which is connected to the
PipiedOutputStream associated with client A) on the server. It then
blocks before data is returned from FooInputStream to client B.

If i close the output stream it returns - which means that it's
closing the output stream on the server, since calling close on the
FooOutputStream just sends to the call to the PipedOutputStream on the
server.

/Carsten

[Oliver Wong]

"Carsten H. Pedersen" <[e-mail]> wrote in message
news:43***********************@dreader1.cybercity. dk...

Oliver Wong wrote:

How many threads does each client have, and what does each thread do?

- Oliver

Each client only has one thread. Client A writes data to its
FooOutputStream, which writes to its associated PipedOutputStream on the
server. Client B reads data from its FooInputStream, which reads from its
associated PipedInputStream (which is connected to the PipiedOutputStream
associated with client A) on the server. It then blocks before data is
returned from FooInputStream to client B.

If i close the output stream it returns - which means that it's closing
the output stream on the server, since calling close on the
FooOutputStream just sends to the call to the PipedOutputStream on the
server.

Okay, sorry, but I'm stumped then. =)

- Oliver

[Carsten H. Pedersen]

>

Okay, sorry, but I'm stumped then. =)

- Oliver

Thanks for trying, though. :) I think i'm missing something about how
streams behave. Since closing the outputstream seems to flush it, it's
gotta be close to working... maybe.

/Carsten

[Godspeed]

More code please.

"Carsten H. Pedersen" <[e-mail]> wrote in message
news:43***********************@dreader1.cybercity. dk...

Okay, sorry, but I'm stumped then. =)

- Oliver

Thanks for trying, though. :) I think i'm missing something about how
streams behave. Since closing the outputstream seems to flush it, it's
gotta be close to working... maybe.

/Carsten