RMI in java

[david]

hello ppl,
I am a newbie. I need some help. I have been going through forums to
find some details. But could not find what exactly i am looking for.
anyways, my question is.

I have a server and a set of clients connected to the server to
perform a certain task, using RMI. when a client performs an
operation, the server needs to update other clients (actually all
clients) about the operation, so that all the clients would have the
latest information about the task. now my question is..
i)how will the server update all the clients when actually the
operation is invoked(through the RMI object in the server) by one
client.
Should the server 'act' like a client and try to update every client
using an RMI objects exported in the clients' side?

another question related to the serialization when passing the object
over the RMI call,

if i have a class which is something like 'public class
MySerialObject implements Serializable'
ii)ok.lets say I pass one of the object (instance of )of
MySerialObject as the response for the RMI call from the client. Do I
have to do anything on the client side to deserialize the object???
(in socket I would need to explicitly marshalling and unmarshalling.)

I have just started reading about RMI since 3-4days ago. and I am not
very good at Java programming either, as i am a C/C++ developer.
just curious, since i have done a lot of socket programming, I feel
that RMI looks easy to implement, especially in this kind of
requirement,for which multiple clients connected to a single server to
do a collective task.(correct me if m wrong, pls)

hope i have not repeated the same question someone has already asked
or asked in a different way.

as i read different materials, i get many other doubts to be clarified
in RMI also. but will ask one by one.

thanks for any kind of help or response

--david

 

[John B. Matthews]

I am a newbie. I need some help. I have been going through forums to
find some details. But could not find what exactly i am looking for.
anyways, my question is.

As you are new to Java in general, and RMI in particular, you might look
through the corresponding tutorials:

<http://java.sun.com/docs/books/tutorial/index.html>
<http://java.sun.com/docs/books/tutorial/rmi/index.html>

 

[Tom Anderson]

I have a server and a set of clients connected to the server to perform
a certain task, using RMI. when a client performs an operation, the
server needs to update other clients (actually all clients) about the
operation, so that all the clients would have the latest information
about the task. now my question is..

i)how will the server update all the clients when actually the operation
is invoked(through the RMI object in the server) by one client.

Should the server 'act' like a client and try to update every client
using an RMI objects exported in the clients' side?

This would be the most straightforward way to do it, yes.

another question related to the serialization when passing the object
over the RMI call,

if i have a class which is something like 'public class MySerialObject
implements Serializable' ii)ok.lets say I pass one of the object
(instance of )of MySerialObject as the response for the RMI call from
the client. Do I have to do anything on the client side to deserialize
the object??? (in socket I would need to explicitly marshalling and
unmarshalling.)

No, RMI will take care of this for you.

I have just started reading about RMI since 3-4days ago. and I am not
very good at Java programming either, as i am a C/C++ developer. just
curious, since i have done a lot of socket programming, I feel that RMI
looks easy to implement, especially in this kind of requirement,for
which multiple clients connected to a single server to do a collective
task.(correct me if m wrong, pls)

You're not wrong, RMI makes this quite easy.

I put together a little demo, just to make sure that my memory was right:

http://urchin.earth.li/~twic/Code/RMIDemo/

Just put all that in a directory somewhere, run the build script, then run
the server script, and as many copies of the client script as you like,
passing each a name. If you're not on unix, read the scripts to see what
you need to do.

tom

--
The other big thing is the method by which these new discoveries had
been made. They had not been made in studies. They were not made by
the ransacking of ancient texts. Nobody deduced the existence of Nova
Scotia. These things were discovered by the very simple process of
driving a ship into them. A ship is a form of scientific instrument. --
Allan Chapman

 

[Roedy Green]

Should the server 'act' like a client and try to update every client
using an RMI objects exported in the clients' side?

There would have to be a thread at the clients listening for these
probes. It may be simpler to do it the Borland Paradox way.

Have your clients to a quick probe every N seconds to you RMI server
to see if anything has happened recently.

A harder way to do it would be to get the server to send out a UDP
broadcast to each client on a different socket. The client dedicates a
thread just to listening for that incoming packet that means
"something happened -- for details probe the server."
--
Roedy Green Canadian Mind Products
http://mindprod.com

"People think of security as a noun, something you go buy. In reality, it’s an abstract concept like happiness. Openness is unbelievably helpful to security."
~ James Gosling (born: 1955-05-18 age: 54), inventor of Java.

 

[Roedy Green]

I feel
that RMI looks easy to implement, especially in this kind of
requirement,for which multiple clients connected to a single server to
do a collective task.(correct me if m wrong, pls)

IIRC the hardest thing about it was getting the firewalls to let the
traffic through. That was a decade ago. I don't know how it has
changed.
--
Roedy Green Canadian Mind Products
http://mindprod.com

"People think of security as a noun, something you go buy. In reality, it’s an abstract concept like happiness. Openness is unbelievably helpful to security."
~ James Gosling (born: 1955-05-18 age: 54), inventor of Java.

 

[Lew]

There would have to be a thread at the clients listening for these
probes. It may be simpler to do it the Borland Paradox way.

Have your clients to a quick probe every N seconds to you RMI server
to see if anything has happened recently.

A harder way to do it would be to get the server to send out a UDP
broadcast to each client on a different socket. The client dedicates a
thread just to listening for that incoming packet that means
"something happened -- for details probe the server."

Another pattern is to have clients register with the server as interested in
given events or results. They do this by making a call to the server that is
not returned immediately, but only after something becomes available.

This puts thread pressure on the server but is a simple model to implement.
Clients will usually be multi-threaded also, so that registration with the
server doesn't halt other action.

I learned this model in days of yore with operating systems that used
send-receive-reply semantics for inter-process communication. The receiving
task, the RMI server in our scenario, was called a "resource manager" and was
the gateway for all clients to whatever service it provided. Clients would
send to the resource manager and block on a reply that was contingent on
server-side availability. The resource manager would "send" to interested
clients by replying to their messages.

 

[david]

As you are new to Java in general, and RMI in particular, you might look
through the corresponding tutorials:

<http://java.sun.com/docs/books/tutorial/index.html>
<http://java.sun.com/docs/books/tutorial/rmi/index.html>

Yes, I have been going through different materials about RMI and
techniques. In the mean while, I thought of getting some experts'
advice on this as to check whether I am on the right track to complete
my task.

I am working on a simple distributed-gaming assignment. So basically I
need to choose better techniques in terms of communication and
performance, and implement those, and justify why I have chosen those.
I have considered this as the design phase of the assignment and going
through different ways to accomplish the work.

 

[david]

I put together a little demo, just to make sure that my memory was right:

http://urchin.earth.li/~twic/Code/RMIDemo/

@tom,
Thanks for the demo.
Before working on the actual assignment, I was trying to achieve this
idea, in which the server will get the client details and then invoke
the clients' objects for any events.

Just put all that in a directory somewhere, run the build script, then run
the server script, and as many copies of the client script as you like,
passing each a name. If you're not on unix, read the scripts to see what
you need to do.

Yeah, I am fairly good in Unix scripting. So dint face any trouble in
make it work.
Thanks again for the efforts. Now I have some basic understanding on
how I should go work on my assignment.

 

[david]

Should the server 'act' like a client and try to update every client

There would have to be a thread at the clients listening for these
probes.  

RMI itself acts like a thread, right? so I export the client RMI
object to handle the 'notification' on the event from the server, it
would serve the purpose, right?
Or a separate thread at the client side, to listen at any port for
events from Server?
pls correct me, if my interpretation is wrong.

Have your clients to a quick probe every N seconds to you RMI server
to see if anything has happened recently.

OK. I count this idea.
actually I considered server 'pushing' the event to the clients would
be slightly better for the communication perfromance rather than the
client 'pulling'(asking for) the details.

A harder way to do it would be to get the server to send out a UDP
broadcast to each client on a different socket. The client dedicates a
thread just to listening for that incoming packet that means
"something happened -- for details probe the server."

Yeah. I will definitely consider this option.Thanks man.

 

[david]

That's one option. Look athttp://www.jini.org/wiki/Jini_Distributed_Events_Specification

for possible architecture.

There are better choices like JMS or JavaSpaces than pure RMI for this
though.

Thanks for the different suggestions, Michal.
I will spend time on these. I will see and consider, which one would
be easier to implement and at the same time have a good performance.

 

[markspace]

Another pattern is to have clients register with the server as
interested in given events or results. They do this by making a call to
the server that is not returned immediately, but only after something
becomes available.

I learned this model in days of yore

All that is old, is new again:

<http://en.wikipedia.org/wiki/Comet_(programming)>

<http://www.ibm.com/developerworks/web/library/wa-cometjava/>

 

[kalakkal]

i have one more doubt regarding the synchronization of the objects.

assume that I have a two dimensional array of objects(resource)
available in the server and clients can access those objects using the
RMI interface. and right now, there are two clients (a and b) are
using one particular object(resource) each. And if at any time, client
'a' or 'b' wants to access another object(resource), the server needs
to check whether it's been held by some other client or not.

(tried to put that in a picture.. )

--------------------
| | | | | |
--------------------
| | a | * | | |
--------------------
| | | b | | |
--------------------
| | | | | |
--------------------

I thought of having a set of two dimensional mutex locks (from C++)
kind of lock to represent the two dimensional array of objects(the
resources). And whenever a client tries to access a particular
resource object,
i) check whether the object is available/free to be
taken
ii) lock the corresponding mutex
iii) check again for availability of the object,
if yes..then mark it as in use with the
corresponding client's details
iv) then release the mutex lock.

But, java does not have the mutex thing.
Conditional 'Synchronized' block around a two dimensional array
element threw an
(like "synchronized (myArray[j])")
'java.lang.NullPointerException'

(though i noticed that conditional Synchronized blocked worked for the
second-level array condition.like this "synchronized (myArray)" )

a two dimensional binary semaphore to achieve this scenario (to get
the mutex effect, work around) would be very expensive, if the matrix
dimension is larger.

m going through some e-books for various Java concurrency techniques
to get some better idea.

pls..give me some suggestion or pointers to get some clear idea.
thanks in advance.

--david

 

[david]

i have one more doubt regarding the synchronization of the objects.

assume that I have a two dimensional array of objects(resource)
available in the server and clients can access those objects using the
RMI interface. and right now, there are two clients (a and b) are
using one particular object(resource) each. And if at any time, client
'a' or 'b' wants to access another object(resource), the server needs
to check whether it's been held by some other client or not.

(tried to put that in a picture.. )

--------------------
| | | | | |
--------------------
| | a | * | | |
--------------------
| | | b | | |
--------------------
| | | | | |
--------------------

I thought of having a set of two dimensional mutex locks (from C++)
kind of lock to represent the two dimensional array of objects(the
resources). And whenever a client tries to access a particular
resource object,
i) check whether the object is available/free to be
taken
ii) lock the corresponding mutex
iii) check again for availability of the object,
if yes..then mark it as in use with the
corresponding client's details
iv) then release the mutex lock.

But, java does not have the mutex thing.
Conditional 'Synchronized' block around a two dimensional array
element threw an
(like "synchronized (myArray[j])")
'java.lang.NullPointerException'

(though i noticed that conditional Synchronized blocked worked for the
second-level array condition.like this "synchronized (myArray)" )

a two dimensional binary semaphore to achieve this scenario (to get
the mutex effect, work around) would be very expensive, if the matrix
dimension is larger.

m going through some e-books for various Java concurrency techniques
to get some better idea.

pls..give me some suggestion or pointers to get some clear idea.
thanks in advance.

--david

 

[Lew]

i have one more doubt regarding the synchronization of the objects.

I personally remain ever confused by this use of the word "doubt". I know, my
problem.

assume that I have a two dimensional array of objects(resource)
available in the server and clients can access those objects using the
RMI interface. and right now, there are two clients (a and b) are
using one particular object(resource) each. And if at any time, client
'a' or 'b' wants to access another object(resource), the server needs
to check whether it's been held by some other client or not.

(tried to put that in a picture.. )

--------------------
| | | | | |
--------------------
| | a | * | | |
--------------------
| | | b | | |
--------------------
| | | | | |
--------------------

I thought of having a set of two dimensional mutex locks (from C++)
kind of lock to represent the two dimensional array of objects(the
resources). And whenever a client tries to access a particular
resource object,
i) check whether the object is available/free to be
taken
ii) lock the corresponding mutex
iii) check again for availability of the object,
if yes..then mark it as in use with the
corresponding client's details
iv) then release the mutex lock.

But, java does not have the mutex thing.

No? I do not know what you mean by "mutex" or how it differs from what the
inbuilt Hoare monitors or the Lock class or semaphores deliver, but I can't
imagine how they fail you in a way that what you call a "mutex" wouldn't.

Conditional 'Synchronized' block around a two dimensional array

What is "Synchronized"? I know the keyword 'synchronized', but not this other
thing.

element threw an
(like "synchronized (myArray[j])")
'java.lang.NullPointerException'

The NPE has nothing to do with synchronization, therefore mutexes will not fix
it. The problem is that either myArray or myArray or myArray[j] are null.

(though i noticed that conditional Synchronized blocked worked for the
second-level array condition.like this "synchronized (myArray)" )

a two dimensional binary semaphore to achieve this scenario (to get
the mutex effect, work around) would be very expensive, if the matrix
dimension is larger.

m going through some e-books for various Java concurrency techniques
to get some better idea.

pls..give me some suggestion or pointers to get some clear idea.
thanks in advance.

Off your main question but relevant to your posts:
- Post once per message. Repeating your post won't increase the quality or
number of answers.
- "Java" is spelled with a capital "J".
- The English first-person singular pronoun "I" is spelled with a capital "I".
- "Pls" is not a word.
- "m" is not a word.

On your main question: don't try to synchronize on a 'null' variable.

 

[david]

No?  I do not know what you mean by "mutex" or how it differs from what the
inbuilt Hoare monitors or the Lock class or semaphores deliver, but I can't
imagine how they fail you in a way that what you call a "mutex" wouldn't.

As I have worked heavily in C/C++ development, I am quite familiar
with the concurrency techniques in those programming languages. And I
am relatively new to Java. After reading through some materials, I
came to know that the synchronization techniques are some what
different, due to the memory model and performance optimization. And
then, I tried what I thought would work. But failed to achieve it
exactly.

The NPE has nothing to do with synchronization, therefore mutexes will not fix
it.  The problem is that either myArray or myArray or myArray[j] are null.

Spot on. I failed to notice in the code that I created those objects
but dint initialize that particular instance.Once I made the changes,
it worked.
But I am still looking for a better option for the synchronization, if
there is any. I am sure there would be. I will figure it out.

Off your main question but relevant to your posts:
- Post once per message.  Repeating your post won't increase the quality or
number of answers.

I realized it very late. Thanks.

- "Java" is spelled with a capital "J".
- The English first-person singular pronoun "I" is spelled with a capital "I".
- "Pls" is not a word.
- "m" is not a word.

I was in a hurry to move on to another task. Those are my regular
email instincts and not an intentional one. I did not realize those
mistakes. I should not have used those in the public forum posting.
Anyways, I will apologize for that. Thanks for the kind reminder, Lew.
I really appreciate it. I am new to forum participation too. (That is
not an excuse, I know)

On your main question: don't try to synchronize on a 'null' variable.

Thanks again.

--david

 

[Lew]

As I have worked heavily in C/C++ development, I am quite familiar
with the concurrency techniques in those programming languages. And I
am relatively new to Java. After reading through some materials, I
came to know that the synchronization techniques are some what
different, due to the memory model and performance optimization. And
then, I tried what I thought would work. But failed to achieve it
exactly.

Every object has a monitor (i.e., built-in mutex). When you use
'synchronize(reference)', you lock a critical section with the monitor built
in to the referent. There are other techniques - 'volatile' variables provide
some simple, fast synchronization. The java.util.concurrent and related
packages provide all sorts of concurrency structures.

The Java tutorials on java.sun.com scratch the surface of concurrency
education for Java. Articles on the IBM DeveloperWorks/Java site go into
depth. One of the more authoritative writers there, a co-developer of Java's
concurrency libraries, Brian Goetz, is the principal author of /Java
Concurrency in Practice/, a seminal text on the matter. Doug Lea's writing is
also significant.