RMI Concurrent Requests Handled by Different Threads?

Discussion in 'Java' started by Reza, Jun 10, 2005.

  1. Reza

    Reza Guest

    Hi:

    I was wondering if anyone knows the final word on concurrent requests'
    thread assignment behaviour for Sun's implementation of the J2SE 1.4+
    spec?

    In other words, for the Sun implementation, do cuncurrent RMI method
    call requests get handled by different thread instances or the same
    one?

    Does it matter if there is a thread pool or not?

    The RMI spec is very vague in this area, so I want to know what the
    predominant implementation does. It does not make sense that the same
    thread instance will be running concurently, but I just want to make
    sure

    Also, is RMI thread pooling enabled by deafult in 1.4+?

    Thanks in advance.

    Reza
     
    Reza, Jun 10, 2005
    #1
    1. Advertising

  2. Reza

    Esmond Pitt Guest

    Reza wrote:
    > Hi:
    >
    > I was wondering if anyone knows the final word on concurrent requests'
    > thread assignment behaviour for Sun's implementation of the J2SE 1.4+
    > spec?
    >
    > In other words, for the Sun implementation, do cuncurrent RMI method
    > call requests get handled by different thread instances or the same
    > one?
    >
    > Does it matter if there is a thread pool or not?
    >
    > The RMI spec is very vague in this area, so I want to know what the
    > predominant implementation does. It does not make sense that the same
    > thread instance will be running concurently, but I just want to make
    > sure


    The RMI Spec is worded in such a way that you *cannot* assume that there
    is only one thread in the server, or even that two successive RMI calls
    from the same client thread are despatched in the same server thread
    (although in fact in Sun's implementation the latter is often the case).
    So, don't assume *anything* involving single threads. In any case any
    single-threaded implementation of RMI would be entirely useless for
    practical purposes, and I have never seen or heard of one.

    > Also, is RMI thread pooling enabled by deafult in 1.4+?


    Not in Sun's implementation. There is some thread pool code in
    java.rmi.runtime but nothing uses it. Same in 1.5. I have heard that
    other implementations do use thread pooling but have no information. If
    Sun Java RMI ever does use thread pooling I would hope that it would use
    java.util.concurrent, not the java.rmi.runtime stuff which doesn't even
    seem complete.
     
    Esmond Pitt, Jun 11, 2005
    #2
    1. Advertising

  3. Reza

    Reza Guest

    Esmond:

    Thank you so much for replying. It's easy to lose faith in usenet, but
    it's good to see there are people out there not too consumed to help
    out...

    Just to recapitulate, concurrent requests (not ones in sequence) are
    handled by two separate threads, or they are serialized not to become
    concurrent and are handled by the same thread, right? I know this is
    common sense given Java threading behaviour, but I am trying to help
    someone else out myself and would hate to give out bad information.

    Thank you again for replying, I appreciate it.

    Reza

    Esmond Pitt wrote:
    > Reza wrote:
    > > Hi:
    > >
    > > I was wondering if anyone knows the final word on concurrent requests'
    > > thread assignment behaviour for Sun's implementation of the J2SE 1.4+
    > > spec?
    > >
    > > In other words, for the Sun implementation, do cuncurrent RMI method
    > > call requests get handled by different thread instances or the same
    > > one?
    > >
    > > Does it matter if there is a thread pool or not?
    > >
    > > The RMI spec is very vague in this area, so I want to know what the
    > > predominant implementation does. It does not make sense that the same
    > > thread instance will be running concurently, but I just want to make
    > > sure

    >
    > The RMI Spec is worded in such a way that you *cannot* assume that there
    > is only one thread in the server, or even that two successive RMI calls
    > from the same client thread are despatched in the same server thread
    > (although in fact in Sun's implementation the latter is often the case).
    > So, don't assume *anything* involving single threads. In any case any
    > single-threaded implementation of RMI would be entirely useless for
    > practical purposes, and I have never seen or heard of one.
    >
    > > Also, is RMI thread pooling enabled by deafult in 1.4+?

    >
    > Not in Sun's implementation. There is some thread pool code in
    > java.rmi.runtime but nothing uses it. Same in 1.5. I have heard that
    > other implementations do use thread pooling but have no information. If
    > Sun Java RMI ever does use thread pooling I would hope that it would use
    > java.util.concurrent, not the java.rmi.runtime stuff which doesn't even
    > seem complete.
     
    Reza, Jun 12, 2005
    #3
  4. Reza

    Esmond Pitt Guest

    Reza wrote:
    >
    > Just to recapitulate, concurrent requests (not ones in sequence) are
    > handled by two separate threads, or they are serialized not to become
    > concurrent and are handled by the same thread, right?


    Nothing in the RMI Specification entitles you to assume that they are
    handled by a single thread; I am not aware of any implementation which
    does so; and if one appeared it would be laughed out of existence.
     
    Esmond Pitt, Jun 12, 2005
    #4
  5. Reza

    Reza Guest

    Esmond:

    I am not sure if we are disagreeing...that is exactly what I am saying
    as well...if there is any chance of two concurrent RMI method calls
    executing (on a given JVM) at the same time (from the same client or
    more than one client), then they have to be running under two seprate
    threads...I don't even think it is possible to program something
    otherwise...

    Just for absolute painful clarity, do you agree?

    Thanks,
    Reza
     
    Reza, Jun 12, 2005
    #5
  6. Reza

    Esmond Pitt Guest

    Reza wrote:
    > Esmond:
    >
    > I am not sure if we are disagreeing...that is exactly what I am saying
    > as well...if there is any chance of two concurrent RMI method calls
    > executing (on a given JVM) at the same time (from the same client or
    > more than one client), then they have to be running under two seprate
    > threads...I don't even think it is possible to program something
    > otherwise...


    Yes, that is how all implementations I am aware of operate. It is
    possible to implement RMI single-threaded and the spec does not prohibit
    it but if it has ever been done commercially I am an unkey's muncle.

    The reason for the convoluted wording in the RMI Spec is to make
    implementors of remote objects aware that they must take multithreading
    into account and cannot assume a single-thread model.
     
    Esmond Pitt, Jun 13, 2005
    #6
  7. Reza

    Reza Guest

    Esmond:

    Thanks again for taking the time to reply. I thought as much, but
    figured I would bounce off the idea with at least one more person.

    Best,
    Reza

    Esmond Pitt wrote:
    > Reza wrote:
    > > Esmond:
    > >
    > > I am not sure if we are disagreeing...that is exactly what I am saying
    > > as well...if there is any chance of two concurrent RMI method calls
    > > executing (on a given JVM) at the same time (from the same client or
    > > more than one client), then they have to be running under two seprate
    > > threads...I don't even think it is possible to program something
    > > otherwise...

    >
    > Yes, that is how all implementations I am aware of operate. It is
    > possible to implement RMI single-threaded and the spec does not prohibit
    > it but if it has ever been done commercially I am an unkey's muncle.
    >
    > The reason for the convoluted wording in the RMI Spec is to make
    > implementors of remote objects aware that they must take multithreading
    > into account and cannot assume a single-thread model.
     
    Reza, Jun 13, 2005
    #7
    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. PJ
    Replies:
    4
    Views:
    526
  2. Replies:
    2
    Views:
    440
  3. Pep
    Replies:
    6
    Views:
    875
  4. Alex
    Replies:
    2
    Views:
    348
  5. TroutyJoe
    Replies:
    1
    Views:
    1,026
    =?Utf-8?B?Y2xpY2tvbg==?=
    Aug 9, 2006
Loading...

Share This Page