Bind multiple remote objects to the same RMI registry - rmi

I have a client program that calls remote methods on a server. Now, I want to create 3 different servers based upon the IP address sent by the client.
Question: Should I create 3 different Remote objects and bind them to the same registry. or should I create 3 different Remote objects and bind them to their respective registry ??
What I am doing right now is one Remote object and binding all 3 objects to the same registry.
Remote obj=UnicastRemoteObject.exportObject(this,2026);
Registry r=LocateRegistry.createRegistry(2026);
r.bind("NA", obj);
r.bind("EU", obj);
r.bind("AS", obj);

It has been a long time since I worked with RMI; be that as it may, my advice is to bind all objects in the same registry, which, I guess, you are already doing.

There's no reason to use multiple Registries in the same host, especially if they are all started by the same JVM. Use a single one. Multiple entries in a single hash table inside one Registry are a lot cheaper than multiple Registries.

Related

OPC UA TranslateBrowsePathsToNodeIds: How stable/volatile are resolved NodeIDs

there is a OPC UA service TranslateBrowsePathsToNodeIds.
How volatile or stable are the NodeIDs results returned by the service ---
Is it possible that NodeIDs resolved by the service alter while server runtime?
In our Case we are running our client against a server, which enumerates NodeIDs differently on every server restart. So we decide to resolve IDs by BrowsePath once after each (re)connect to the server. So far so good. But now there is a Problem when the server is restartet and after the first client reconnect no paths can't resolved.. it seems the server is not ready for the job (...).
I am wondering how often I have to update the resolved Node IDs (all or just the onces which was not resolved correctly?).
We are reading data by polling in this case.
I don't know your server, but it seems, you do address an OPC UA Server with a very dynamic behaviour, But I think, it's within the OPC UA spec.
It depends on the OPC UA objects, this server offers and what a client should or wants do with them.
Is it possible that NodeIDs resolved by the service alter while server runtime?
Yes!
Many servers do offer a static node set from the device configuration. In this case, the client will always get the same node ids from TranslateBrowsePathsToNodeIds, the client may use the node ids directly without translation (but has always to resolve the namespace index after connecting to the server). But obviously it's not your kind of server.
Another use case are dynamic objects, with a restricted lifetime, coming and going on any time they want to come an go. Imagine a warehouse in which goods are received and delivered. So a good will be representent with an individual OPC UA object instance, created on receive and removed on delivery. As long the good exists in the warehouse, you may browse to the object, translate its browse pathes to node ids and use them (reading, writing, monitoring). Of course, when the good delivers, the UA object will no longer be needed and could be removed by the server. The node ids removed now could be used later in an other context for another object instance.
Alternatively, the server could offer an interface to create or remove objects with a client.
The question is, how the server deals with the creation or removal of it's objects, how does it announce the changes? There should be a kind of configuration change event you want to monitor with your client. When your client receives an event, it may decide which actions to do, e.g. rebrowse the object and translate the browse pathes. Read the manual!
By the way: TranslateBrowsPathsToNodeIds is widly used to adress subnodes of object instances with a known object type. Once you know the node id for the entire object, you easily get the node ids for the subnodes with their browse pathes.

How does RMI implements the distributed system's single image appearance to end user

We bind Server's name with it's object in rmi registry.And then look up the registry by the server's name or address.How does this keep the distributed System's single image intact as a user must not care about from where the data comes?
I don't know what you mean by 'the distributed system's single image', but the object you lookup in the Registry can be located anywhere, not just in the host containing the Registry. Although putting it somewhere else does take a little more work.

Are there any lightweight OPC servers which can have multiple instances running on the same machine?

I am wanting to run performance testing of an OPC client to 100 servers but I do not want to run 100 machines
Is there any way to set this up for testing purposes?
If they are OPC-DA (or A&E, HDA) servers, and you are really interested in just the performance of the client part, and do not mind actually using a single OPC server that just "looks" like 100 of them, there is a chance that you can use the following trick:
Using REGEDIT, under HKEY_CLASSES_ROOT, find an entry with the ProgID of your server. Its purpose is to point to the server's CLSID.
Make 100 copies of this entry, each time giving it a different ProgID, but pointing still to the same CLSID.
Configure your client to connect to 100 different OPC server, using the ProgIDs you created.
If you client uses just ProgIDs for recognizing the "identity" of the server, it will think it is connecting to 100 different servers, and it will treat them as such, i.e. create 100 separate connections. If the client, however, first converts the ProgID to CLSID, it will see the same CLSID, and it won't work. Obviously, even if this works, the performance test will be skewed as far as the server side is concerned, because there will be just 1 server process, not 100 of them.
Note that CLSID cannot be changed in this way, because it is also hard-coded in the COM class factory inside the server.
Another wild idea that comes to my mind is to use a product such as OPC Tunneler (e.g. MatrikonOPC). In this product you can create any number of "servers", which in fact connect by tunneling to a true OPC server somewhere else. Therefore you might be able to configure 100 tunnels (looking like separate servers), all connecting to 1 target OPC servers.

Creating regions in Memcache using java

I just installed memcache in my machine.Actually,i have to create regions in there.
For eg there should be 3 regions created ,each storing a set of data.Am not sure how can i do that in memcache.Can anyone please help/give eg as it is "urgent".
Thanks in advance
Memcached itself is just a service that runs on your server. It can be connected to and commands sent to it over a text based protocol. Once the service is running, you can use a tool such as telnet or netcat to interact with it.
As for accessing from Java, you'll probably want a library to do most of the work for you. There were a few listed on this question: Java Memcached Client
Now as for your regions: memchached is basically a key/value table. To set a region you'd do something like memcached.set("key", yourData) and to get it back you'd do something like yourData = memcached.get("key")
Note that these functions will vary depending which library you are using.

Perl Is it possible to re-create the Net::Telnet connection if I have its memory location?

Is it possible to re-create the Net::Telnet connection if I have its memory location ?
how can i turn Net::Telnet=GLOB(0x1b50ff0) string to a Net::Telnet object again ?
Thanks.
UPDATE
You can not re-use your object in 2 separate processes as it seems from your comments you are trying to do - one will NOT see the other's memory/address space. You can only do one of 3 things:
Re-create the object from scratch to be the duplicate of the other object in a different program, but only if the object's class supports serialization/de-serialization (usually done via saving object state using Data::Dumper, Storable or other methods). I don't know if Net::Telnet can be handled that way.
Just to be clear, your second program will obtain a COPY of the object once deserialized, which has nothing to do with the original object.
Allow the client to talk to the server and send Telnet commands, which the server passes to Net::telnet object and tells the client the result. Basically, the server acting as a telnet proxy for the client. The client should refer to server's Net::Telnet objects via their IDs, as mentioned in the registry explanation in my original answer.
Use shared memory to store Net::Telnet object if the client and server reside on the same physical server.
ORIGINAL ANSWER
You can try looking at Acme::Ref which un-stringifies a reference... I never used it so can't guarantee it works well or works with specifically Net::telnet.
I agree with the comment posted above that if you need to do this, you most likely are not applying a correct solution to your underlying problem - it would help if you provided more details of what you're trying to achieve high-level.
You should almost never have to deal with stringified reference as opposed to an object reference. If you're within the bounds of your own process, then you can pass the object reference around (or make it global if you really must). If you are using some sort of inter-process communication and an external process needs to refer to one of Net::Telnet objects in your program, you need to create a registry of Net::Telnet objects (could be just an array) and reference them by an index in the registry.