 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / March 2006Double streams
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 > Hello. > [quoted text clipped - 19 lines] > 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 > 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 >> Do you flush the streams? >> [quoted text clipped - 3 lines] > > 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 >> 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. [quoted text clipped - 5 lines] > 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 >> 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 [quoted text clipped - 9 lines] > 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 >> 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, [quoted text clipped - 7 lines] > > - 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 >> How many threads does each client have, and what does each thread do? >> [quoted text clipped - 11 lines] > FooOutputStream just sends to the call to the PipedOutputStream on the > server. Okay, sorry, but I'm stumped then. =) - Oliver > 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 More code please. >> Okay, sorry, but I'm stumped then. =) >> [quoted text clipped - 5 lines] > > /Carsten Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.