Re: Disabling Multicast to run multiple JavaSpace
Dan Creswell <[email protected]>
| Newsgroups | gmane.comp.java.sun.javaspaces |
|---|---|
| Message-ID | <[email protected]> |
Okay, so ignoring (1) for the moment you need to segment your JavaSpaces.
I can't quite tell exactly what your architecture is but the basic
condition seems to be that you want just one unique JavaSpace registered
with each lookup service. Can you explain exactly why you need this
arrangement - why does a client need binding to one specific JavaSpace?
There are many ways this can be potentially be achieved without having
to go to this much pain with lookup services.
That said, here are some ideas you could try/consider:
You could do this by amending Outrigger's config setting
initialLookupGroups to LookupDiscovery.NO_GROUPS which prevents
multicast join. Then you'd need to specify initialLookupLocators to be
an array of LookupLocator initialized to contain one LookupLocator which
would be the appropriate lookup service URL for that JavaSpace to
register with.
That would ensure you could have just one JavaSpace associated with just
one LUS such that a client connecting to just one LUS will find only one
JavaSpace.
A possibly better alternative would be to have several LUS in a group,
say "a", and configure Outrigger's initialLookupGroups to be new
String[] {"a"}.
You could then do the same for a group, say "b" etc. This would allow
you to use multicast discovery/lookup/join but still ensure you had just
one JavaSpace per lookup service. The advantage of this is that loss of
one lookup service no longer prevents lookup at least under some
circumstances.
Hope that helps,
Dan.
timur mehrvarz wrote:
> Hi Jools,
>
> these are the reasons:
>
> 1st, our operational guys don't like the multicast announcements. (This
> one must not be counted if you can help me fix the other two.)
>
> 2nd, I would like to run multiple services, side by side, each with
> their own local Javaspace. I would like to be sure that each service is
> accessing it's own, local Javaspace. Our services use a unicast URL to
> contact their local lookup server. But with multiple spaces up and
> running in the same network, you never know which space you are really
> provided with. (At least I don't.)
>
> 3nd, there is a problem running multiple spaces, if there are firewalls
> that blocks everything except multicast packages (so Jini announcements
> slip through). In such an environment, my local lookup-server may
> provide my local service with the address of a Javaspace instance
> running behind a firewall. In this case, there is no way for my service
> to access that Javaspace instance (and my service throws exceptions -
> even though there is a local JS running fine).
>
> A local JavaSpace is really all we need at the current time.
>
> BR, Timur
>
>
> On 22 11:57:16 AM, at 11:57 AM, Jools Enticknap wrote:
>
>> Hi Timur,
>>
>> What makes you think that you need to disable multicast so you can
>> have two or more JavaSpaces ?
>>
>> Although you maybe having a problem disabling multicast, you might be
>> doing it for the wrong reason.
>>
>> Jini is designed to allow you to have as many, or few services
>> (JavaSpaces are just services) as you like.
>>
>> Perhaps you could give us a little more insight ?
>>
>> --Jools
>>
>>
>>> we're trying to disable multicast traffic, so that we can run two (or
>>> more) JavaSpaces in parallel in the same LAN.
>>>
>>> Despite the fact that we have disabled multicast usage (zero length
>>> array for multicastInterfaces), JINI discovers all configured
>>> interfaces:
>>>
>>> CONFIG: LookupDiscovery - multicast network interface(s): [name:qfe3
>>> (qfe3) index: 4 addresses:
>>> /10.215.203.68;
>>> , name:qfe2 (qfe2) index: 3 addresses:
>>> /10.215.203.66;
>>> /10.215.203.67;
>>> , name:hme0 (hme0) index: 2 addresses:
>>> /10.215.52.192;
>>> , name:lo0 (lo0) index: 1 addresses:
>>> /127.0.0.1;
>>> ]
>>>
>>> [.....]
>>> Mar 22, 2005 11:23:16 AM com.sun.jini.reggie.RegistrarImpl init
>>> CONFIG: multicast disabled
>>> Mar 22, 2005 11:23:16 AM net.jini.config.AbstractConfiguration
>>> getEntryInternal
>>> FAILED: ConfigurationFile@120cc56{transient-reggie.config}, component
>>> com.sun.jini.reggie, name multicastRequestSubjectChecker: entry not
>>> found
>>> [.....]
>>>
>>> Obviously, multicast is disabled.
>>>
>>> Nevertheless:
>>>
>>> root@wherever#snoop -d qfe3 net 224.0.1.84 or net 224.0.1.85
>>> Using device /dev/qfe (promiscuous mode)
>>> wherever-qfe3 -> JINI-ANNOUNCEMENT.MCAST.NET IP D=224.0.1.84
>>> S=10.215.203.68 LEN=28, ID=9325
>>> app1 -> JINI-ANNOUNCEMENT.MCAST.NET IP D=224.0.1.84
>>> S=10.215.203.66 LEN=28, ID=40772
>>> app1 -> JINI-ANNOUNCEMENT.MCAST.NET IP D=224.0.1.84
>>> S=10.215.203.66 LEN=28, ID=40773
>>>
>>> Multicast announcements are being sent out.
>>>
>>> Is there any way to totally disable the multicast traffic?
>>>
>>> Cheers,
>>> Timur
>>>
>>>
>>> Startup: ===
>>>
>>> #!/bin/sh
>>> /apps/java/j2sdk/current/bin/java
>>> -Djava.util.logging.config.file=reggie.log.properties
>>> -Djava.security.policy=services.all.policy
>>> -Djsk.lib=/apps/jini/jini2_0_002/lib -jar
>>> /apps/jini/jini2_0_002/lib/start.jar t1.config
>>>
>>> ===
>>>
>>> t1.config: ===
>>> import com.sun.jini.start.NonActivatableServiceDescriptor;
>>> import com.sun.jini.start.ServiceDescriptor;
>>> import com.sun.jini.config.ConfigUtil;
>>>
>>> com.sun.jini.start {
>>> private static reggieconf = "transient-reggie.config";
>>>
>>> // Discovery Group to use
>>> private static group = "${user.name}";
>>>
>>> private static httpdPort = "8090";
>>> private static codebaseBase = ConfigUtil.concat(new Object[] {
>>> "http://", ConfigUtil.getHostName(), ":", httpdPort, "/"});
>>>
>>> private static policy = "services.all.policy";
>>> private static classpathBase = ConfigUtil.concat(new Object[] {
>>> "${jsk.lib}","${/}"});
>>>
>>> static serviceDescriptors = new ServiceDescriptor[] {
>>>
>>> // httpd
>>> new NonActivatableServiceDescriptor(
>>> "",
>>> policy,
>>> ConfigUtil.concat(new Object[] {classpathBase,
>>> "tools.jar"}),
>>> "com.sun.jini.tool.ClassServer",
>>> new String[]{"-port", httpdPort, "-dir", "${jsk.lib}",
>>> "-verbose"}),
>>> // Reggie (lookup service)
>>> new NonActivatableServiceDescriptor(
>>> ConfigUtil.concat(new Object[] {codebaseBase,
>>> "reggie-dl.jar"}),
>>> policy,
>>> ConfigUtil.concat(new Object[] {classpathBase,
>>> "reggie.jar"}),
>>> "com.sun.jini.reggie.TransientRegistrarImpl",
>>> new String[] { reggieconf })
>>> };
>>> }
>>> ===
>>>
>>> transient-reggie.config: ===
>>> import net.jini.jeri.BasicILFactory;
>>> import net.jini.jeri.BasicJeriExporter;
>>> import net.jini.jeri.tcp.TcpServerEndpoint;
>>>
>>> com.sun.jini.reggie {
>>>
>>> multicastInterfaces = new java.net.NetworkInterface[]{};
>>> initialMemberGroups = new String[] { "cb-member-group" };
>>> }
>>> ===
>>>
>>> ======================================================================
>>> =====
>>> To unsubscribe, send email to [email protected] and include in
>>> the body
>>> of the message "signoff JAVASPACES-USERS". For general help, send
>>> email to
>>> [email protected] and include in the body of the message "help".
>>>
>>> To view past JAVASPACES-USERS postings, please see:
>>> http://archives.java.sun.com/archives/javaspaces-users.html
>>>
>>> JDC members can download the JavaSpaces(tm) Technology from:
>>> http://developer.java.sun.com/developer/products/jini/
>>
>>
>> =======================================================================
>> ====
>> To unsubscribe, send email to [email protected] and include in the
>> body
>> of the message "signoff JAVASPACES-USERS". For general help, send
>> email to
>> [email protected] and include in the body of the message "help".
>>
>> To view past JAVASPACES-USERS postings, please see:
>> http://archives.java.sun.com/archives/javaspaces-users.html
>>
>> JDC members can download the JavaSpaces(tm) Technology from:
>> http://developer.java.sun.com/developer/products/jini/
>
>
> ===========================================================================
> To unsubscribe, send email to [email protected] and include in the body
> of the message "signoff JAVASPACES-USERS". For general help, send email to
> [email protected] and include in the body of the message "help".
>
> To view past JAVASPACES-USERS postings, please see:
> http://archives.java.sun.com/archives/javaspaces-users.html
>
> JDC members can download the JavaSpaces(tm) Technology from:
> http://developer.java.sun.com/developer/products/jini/
>
===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff JAVASPACES-USERS". For general help, send email to
[email protected] and include in the body of the message "help".
To view past JAVASPACES-USERS postings, please see:
http://archives.java.sun.com/archives/javaspaces-users.html
JDC members can download the JavaSpaces(tm) Technology from:
http://developer.java.sun.com/developer/products/jini/