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 PipedOutputStre am, pos
- fis has a PipedInputStrea m, 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]

Re: Double streams


"Carsten H. Pedersen" <no@nono.no> wrote in message
news:43f0f261$0 $78284$157c6196 @dreader1.cyber city.dk...[color=blue]
> 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 PipedOutputStre am, pos
> - fis has a PipedInputStrea m, 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?[/color]

Do you flush the streams?

Is the reading and writing done in seperate threads?

- Oliver

[Carsten H. Pedersen]

Re: Double streams

Oliver Wong wrote:[color=blue]
> Do you flush the streams?
>
> Is the reading and writing done in seperate threads?
>
> - Oliver[/color]

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]

Re: Double streams


"Carsten H. Pedersen" <no@nono.no> wrote in message
news:43f23a33$0 $67262$157c6196 @dreader2.cyber city.dk...[color=blue]
> Oliver Wong wrote:[color=green]
>> Do you flush the streams?
>>
>> Is the reading and writing done in seperate threads?
>>
>> - Oliver[/color]
>
> Well, i tried flushing. It doesn't work.[/color]

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.
[color=blue]
> Since the "outer" inputstream gets what it needs, there shouldn't be a
> reason to flush the outputstreams.. . or should there?[/color]

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.
[color=blue]
>
> Reading and writing are in seperate threads, yeah. Each of the four
> streams are in their own thread.[/color]

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 PipedOutputStre am (all within the same
thread). Then, a second thread, reads from the FooInputStream, which then
requests data from the PipedInputStrea m, and then consumes the data.

- Oliver

[Carsten H. Pedersen]

Re: Double streams

Oliver Wong wrote:[color=blue][color=green]
>> Well, i tried flushing. It doesn't work.[/color]
>
>
> 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.[/color]

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.
[color=blue][color=green]
>> Reading and writing are in seperate threads, yeah. Each of the four
>> streams are in their own thread.[/color]
>
>
> 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 PipedOutputStre am
> (all within the same thread). Then, a second thread, reads from the
> FooInputStream, which then requests data from the PipedInputStrea m, and
> then consumes the data.[/color]

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 PipedOutputStre am (or PipedInputStrea m),
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 -> client1outputst ream.write -> serveroutputstr eam.write ->
serverinputstre am.read -> client2inputstr eam.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]

Re: Double streams


"Carsten H. Pedersen" <no@nono.no> wrote in message
news:43f26362$0 $78286$157c6196 @dreader1.cyber city.dk...[color=blue]
> Oliver Wong wrote:[color=green]
>> 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 PipedOutputStre am
>> (all within the same thread). Then, a second thread, reads from the
>> FooInputStream, which then requests data from the PipedInputStrea m, and
>> then consumes the data.[/color]
>
> 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 PipedOutputStre am (or PipedInputStrea m), and the two clients
> communicate with eachother with the server (and the pipes) as a proxy.
>[/color]

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

- Oliver

[Carsten H. Pedersen]

Re: Double streams

Oliver Wong wrote:[color=blue][color=green]
>> 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 PipedOutputStre am (or PipedInputStrea m),
>> and the two clients communicate with eachother with the server (and
>> the pipes) as a proxy.
>>[/color]
>
> How many threads does each client have, and what does each thread do?
>
> - Oliver[/color]

Each client only has one thread. Client A writes data to its
FooOutputStream , which writes to its associated PipedOutputStre am on
the server. Client B reads data from its FooInputStream, which reads
from its associated PipedInputStrea m (which is connected to the
PipiedOutputStr eam 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 PipedOutputStre am on the
server.

/Carsten

[Oliver Wong]

Re: Double streams


"Carsten H. Pedersen" <no@nono.no> wrote in message
news:43f34d21$0 $78279$157c6196 @dreader1.cyber city.dk...[color=blue]
> Oliver Wong wrote:[color=green]
>>
>> How many threads does each client have, and what does each thread do?
>>
>> - Oliver[/color]
>
> Each client only has one thread. Client A writes data to its
> FooOutputStream , which writes to its associated PipedOutputStre am on the
> server. Client B reads data from its FooInputStream, which reads from its
> associated PipedInputStrea m (which is connected to the PipiedOutputStr eam
> 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 PipedOutputStre am on the
> server.[/color]

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

- Oliver

[Carsten H. Pedersen]

Re: Double streams

>[color=blue]
>
> Okay, sorry, but I'm stumped then. =)
>
> - Oliver[/color]

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]

Re: Double streams

More code please.

"Carsten H. Pedersen" <no@nono.no> wrote in message
news:43f59f9a$0 $78283$157c6196 @dreader1.cyber city.dk...[color=blue][color=green]
>>
>>
>> Okay, sorry, but I'm stumped then. =)
>>
>> - Oliver[/color]
>
> 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[/color]