Welcome to the new Gigaspaces XAP forum. To recover your account, please follow these instructions.

Ask Your Question

Configure Gigaspaces to work in localhost only

Hi !
Gigaspaces is really good discovering machines. We have some developers working in their machines and the gsc and gsm discover each other.
So the solution I'm using right now is configuring gsm and gsc to work in certain group and changing the urls of space connections to work against that group.
But I figure it's still doing multicast and try to discover gsc's and gsm located in other machines.
I read this page on how to configure unicast: http://www.gigaspaces.com/wiki/display/XAP7/HowtoConfigureUnicastDiscovery
But didn't figure out exactly how to change everything to work only against localhost. So my questions are:
1) how to configure and startup gsm and gsc
2) how to change the space connection url to look only in localhost
Thanks !

This thread was imported from the previous forum.
For your reference, the original is available here

asked 2009-06-10 10:30:06 -0500

pruggia gravatar image

updated 2013-08-08 09:52:00 -0500

jaissefsfex gravatar image
edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

A space (or any other service) publish (or register/export) itself within the lookup service no matter it is embedded or remote to the application.

If it is embedded and not running within a GSC , it will start a lookup service automatically (this is what is going for example when running unit tests). This is why you can access it from the GS-UI.

If it is running within the GSC , it will find the lookup running within the GSM - that's why you need to specify the LOOKUPLOCATORS when you don't have multicast enabled.

So how a client finds a lookup service (and from there accessing the space itself)? - There are 2 main options how to discover a lookup service:

- Via a group - relevant only with multicast enabled networks. This is a tag you assign to the lookup service once started. Clients that would like to register with this lookup or lookup for a service proxy need to use this specific group when discovering the lookup service. Each release got a default group associated with it.
- Via a locator - via specific IP where the lookup is running. This option is used when multicast is disabled on the network.

With cloud deployment (EC2) where multicast is disabled we set the LOOKUPLOCATORS variable automatically to the relevant machine(s) running GSMs. You can get it via a call to the set-cloud-env command.

Some Examples:
The jini://localhost/*/space URL means that the client/space will be looking for the lookup service on the local host together with looking for it on the network via multicast (enabled by default).

If you want to turn off the ability to look for the lookup service on the network via multicast (aka multicast lookup discovery) you should disable multicast via the system property com.gs.multicast.enabled=false on the relevant JVMs (client or GSC JVMs).

jini://localhost/*/space?locators=host,host2 URL means that together with searching for the lookup service on the localhost or the network , we will be looking for it on host1 and host2. We call this unicast lookup discovery.

jini://localhost/*/space?groups=A,B means that together with searching for the lookup service on the localhost we will be doing a multicast call searching for lookup services attached to group A or B.

jini:////space means that searching for the lookup service will be done only via multicast discovery.

/./space?groups=A,B means the started space will register itself with group A and B. To access such a space a remote client will need to use: jini:////space?groups=A or jini:////space?groups=B

I guess you got the idea... I have used the URL properties rather than the spring tags for simplicity.

On top of this mechanism there is also alternative way to "export" the space proxy that is via the regular rmi registry (JNDI) that is started within the JVM in case it is not there yet. By default the port we use here is 10098 and above. That's why we need this port available. It is used also by the JMX. Still - this is an optional mode that is relevant for who ever that can't somehow use the lookup service. Since this is usual rmi registry is suffers from the known problems such as non distributed , non highly available .,etc.

Here are the different options you have to "isolate" your space:
- If you are running unit tests you should Disable the lookup service creation and the space registration with the lookup service. See example below:

<os-core:space id="space" url="/./myspace" >
    <prop key="com.j_spaces.core.container.directory_services.jini_lus.start-embedded-lus">false</prop>
    <prop key="com.j_spaces.core.container.directory_services.jini_lus.enabled">false</prop>
    <prop key="com.j_spaces.core.container.directory_services.jndi.enabled">false</prop>
    <prop key="com.j_spaces.core.container.embedded-services.httpd.enabled">false</prop>

- Deploy the space using a specific lookup group or lookup locator. This means that who ever want to access it need to use the non-default lookup group or a specific locator to access it. Please note that a lookup group is a property attached to the lookup service discovery protocol when having a network that support multicast. If you don't have multicast enabled this property is irrelevant.
- Secure it - you can specify security settings to a space. Only permitted users (with the relevant roles) will be able to access it. It works very similar to database tables grant/deny privileges. See http://www.gigaspaces.com/wiki/display/XAP7/Security
- Provide each environment/deployment different space name.


answered 2009-06-10 11:34:00 -0500

shay hassidim gravatar image
edit flag offensive delete link more


Thank you so much for this info ! If I use the configuration you told me above, I'm getting an exception saying that it cannot connect via RMI , which is ok because I disabled it. I don't know if the Gigaspace bean should be configured in some way not to use RMI. Chaning the property com.j_spaces.core.container.directory_services.jndi.enabled to "true" value makes that exception dissappears.

pruggia gravatar imagepruggia ( 2009-06-11 12:35:34 -0500 )edit

For simplicity I use following parameter when testing in local machine.

Both at client and space. -Dcom.gs.multicast.ttl=0


No matter what I do discovery never goes beyond my local machine...

Thanks Venkat

venkatg gravatar imagevenkatg ( 2009-07-09 10:07:54 -0500 )edit

For simplicity I use following parameter when testing in local machine.

Both at client and space. -Dcom.gs.multicast.ttl=0


No matter what I do discovery never goes beyond my local machine...

Thanks Venkat

venkatg gravatar imagevenkatg ( 2009-07-09 10:08:05 -0500 )edit

If you are using linux machines you can try to change NIC_ADDR value in bin/setenv.sh file to It's about 246 line. In my case it is:

if ; then

in windows machines I would try to use localhost instead but not sure of this.

answered 2009-06-10 10:55:04 -0500

mnemos gravatar image
edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2009-06-10 10:30:06 -0500

Seen: 419 times

Last updated: Jun 10 '09