why does ObjectInputStream constructor block reading a header

Discussion in 'Java' started by kartik, Oct 30, 2004.

  1. kartik

    kartik Guest

    The ObjectInputStream constructor blocks till it reads a header from
    the underlying input stream. This can cause deadlocks when you have a
    pair of object streams communicating over sockets (it has happened to
    me). Does anybody know why it may have been coded this way instead of
    reading the header on the first call to readObject()?

    -kartik
     
    kartik, Oct 30, 2004
    #1
    1. Advertising

  2. kartik

    Esmond Pitt Guest

    kartik wrote:
    > The ObjectInputStream constructor blocks till it reads a header from
    > the underlying input stream. This can cause deadlocks when you have a
    > pair of object streams communicating over sockets (it has happened to
    > me). Does anybody know why it may have been coded this way instead of
    > reading the header on the first call to readObject()?


    No but you can avoid the deadlock by creating the ObjectOutputStream
    first and flushing it, then creating the ObjectInputStream.
     
    Esmond Pitt, Oct 30, 2004
    #2
    1. Advertising

  3. kartik

    Tony Morris Guest

    "kartik" <> wrote in message
    news:...
    > The ObjectInputStream constructor blocks till it reads a header from
    > the underlying input stream. This can cause deadlocks when you have a
    > pair of object streams communicating over sockets (it has happened to
    > me). Does anybody know why it may have been coded this way instead of
    > reading the header on the first call to readObject()?
    >
    > -kartik


    Yes - they have been written in accordance with specification and the
    specification is the correct way of solving the problem.

    The problem you have is attempting asynchronous I/O in the same thread.
    This is just not possible.

    --
    Tony Morris
    http://xdweb.net/~dibblego/
     
    Tony Morris, Oct 30, 2004
    #3
  4. kartik

    Esmond Pitt Guest

    Tony Morris wrote:
    > In that case, you want to look at the java.nio package.
    >

    Why?
     
    Esmond Pitt, Nov 2, 2004
    #4
  5. kartik

    Tony Morris Guest

    Tony Morris, Nov 3, 2004
    #5
  6. kartik

    Esmond Pitt Guest

    Esmond Pitt, Nov 4, 2004
    #6
  7. kartik

    kartik Guest

    "Tony Morris" <> wrote in message news:<jo0id.9050$>...
    > "Esmond Pitt" <> wrote in message
    > news:FlUhd.8063$...
    > > Tony Morris wrote:
    > > > In that case, you want to look at the java.nio package.
    > > >

    > > Why?
    > >

    >
    > Because it includes non-blocking I/O.


    But I do *not* want non-blocking I/O (and its associated complexity).
    My only problem is that the ObjectInputStream constructor reads the
    stream header before it really has to, and that's causing deadlock.
     
    kartik, Nov 4, 2004
    #7
  8. kartik

    Tony Morris Guest

    > But I do *not* want non-blocking I/O (and its associated complexity).
    > My only problem is that the ObjectInputStream constructor reads the
    > stream header before it really has to, and that's causing deadlock.


    It doesn't cause deadlock.
    Perhaps you meant a blocked I/O operation?
    I'm not sure if that particular constructor does block, but it's no secret
    that J2SE I/O has flaws, and that this is one of them (the inability to
    cleanly break out of a blocked I/O state).
    In most cases, even an interrupt fails.

    There are texts on the topic.
    I suggest "Taming Java Threads", Allen Holub.
    There's another good one my Doug Lea (forget the title).

    --
    Tony Morris
    http://xdweb.net/~dibblego/
     
    Tony Morris, Nov 4, 2004
    #8
  9. kartik

    Esmond Pitt Guest

    Tony Morris wrote:
    >>But I do *not* want non-blocking I/O (and its associated complexity).
    >>My only problem is that the ObjectInputStream constructor reads the
    >>stream header before it really has to, and that's causing deadlock.

    >
    >
    > It doesn't cause deadlock.


    It does cause deadlock, between the peers, unless one of them constructs
    the ObjectOutputStream first. Try it yourself.

    > Perhaps you meant a blocked I/O operation?


    No he doesn't.

    > I'm not sure if that particular constructor does block


    I am sure that that particular constructor does block until it receives
    the stream header from the corresponding ObjectOutputStream()
    constructor at the peer.

    >, but it's no secret
    > that J2SE I/O has flaws, and that this is one of them (the inability to
    > cleanly break out of a blocked I/O state).


    'This' is not what the OP is talking about.

    > In most cases, even an interrupt fails.
    >
    > There are texts on the topic.
    > I suggest "Taming Java Threads", Allen Holub.
    > There's another good one my Doug Lea (forget the title).


    Tony, this is all irrelevant.
     
    Esmond Pitt, Nov 5, 2004
    #9
  10. kartik

    kartik Guest

    "Tony Morris" <> wrote in message news:<qwmid.11074$>...
    > > But I do *not* want non-blocking I/O (and its associated complexity).
    > > My only problem is that the ObjectInputStream constructor reads the
    > > stream header before it really has to, and that's causing deadlock.

    >
    > It doesn't cause deadlock.
    > Perhaps you meant a blocked I/O operation?

    I meant a deadlock. I have two machines that communicate using object
    streams over sockets. Each tries to create the ObjectInputStream
    before the ObjectOutputStream, but since the other side hasn't written
    the stream header (because it hasn't constructed its output stream),
    they deadlock.

    > I'm not sure if that particular constructor does block

    It does. See http://java.sun.com/j2se/1.5.0/docs...am.html#ObjectInputStream(java.io.InputStream)

    > There are texts on the topic.
    > I suggest "Taming Java Threads", Allen Holub.
    > There's another good one my Doug Lea (forget the title).

    Concurrent Programming in Java?
     
    kartik, Nov 6, 2004
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Serial # 19781010
    Replies:
    1
    Views:
    736
    Roedy Green
    Jul 15, 2003
  2. OtisUsenet
    Replies:
    7
    Views:
    4,261
  3. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,217
    Smokey Grindel
    Dec 2, 2006
  4. morrell
    Replies:
    1
    Views:
    999
    roy axenov
    Oct 10, 2006
  5. Knute Johnson
    Replies:
    2
    Views:
    2,151
    Knute Johnson
    Apr 15, 2007
Loading...

Share This Page