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

Ask Your Question
0

Replication with unicast only

Hi, I'm very new to Gigaspaces.. I need to start 2 spaces that will be sync replicated and should use only unicast (multicast wont work) I understand that for using unicast i need to run GSM/LUS on at least one server (and not more than 2) and then start the sync replicated spaces.

my question is: 1) how do i start the GSM/LUS service?? 2) when starting the spaces (i use gsInstance.sh),. i need to add the locators=host:port directive?

Thanks.

{quote}This thread was imported from the previous forum. For your reference, the original is [available here|http://forum.openspaces.org/thread.jspa?threadID=2429]{quote}

asked 2008-07-01 09:59:39 -0500

maimonoded gravatar image

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

jaissefsfex gravatar image
edit retag flag offensive close merge delete

8 Answers

Sort by ยป oldest newest most voted
0

You can use more than one GSM/LUS even when using unicast to discover the GSM/LUS.

All you need to do is to declare the machines(s) running the GSM/LUS.
U need to do this from the server side and client side.
- server side : see the LOOKUPLOCATRS variable at the gigaspaces root/bin/setenv
- client side use the locators space URL parameter.

These 2 should have the host name (s) of the machine(s) running GSM/LUS.
For multiple machine just have the names with comma separated.

Once you have this set you can deploy the replicated space using the UI / CLI / API as usual.

Shay

answered 2008-07-01 10:45:19 -0500

shay hassidim gravatar image
edit flag offensive delete link more
0

yes, i'm using 6.5 rc1.

it was my mistake, i meant 4162 not 4160. i understand that 4162 is the port for this unicast right?

so i've server1 runing GSM/LUS that is listening to this port. and on the same server i've create a space, by defining the LOOKUPLOCATORS=server1 env variable and running the gsInstance.sh like this: ./gsInstance.sh "/./myspace?cluster_schema=sync_replicated&total_members=2&id=1" this one works fine.. and i can see it in the gs-ui.

on server2 i've defining the LOOKUPLOCATORS=server1 env variable and running the gsInstance.sh like this: ./gsInstance.sh "/./myspace?cluster_schema=sync_replicated&total_members=2&id=2"

but in server2 i get the errors i mentioned in my previous post.

thanks.

answered 2008-07-02 05:28:48 -0500

maimonoded gravatar image
edit flag offensive delete link more

Comments

Hi, First, regardless your issue, I would recommend you moving to the 6.5 GA.

You should be aware of that when running a gsInstance you have an embedded LUS running within the same java process with the space. So if you start 2 gsInstances you have total 2 LUS running, one on each box/space. The GSM is useless in this scenario since you have not deployed spaces into the ServiceGrid GSCs.

Please specify the locators space url attribute e.g.: ./gsInstance.sh "/./myspace?cluster_schema=sync_replicated&total_members=2&id=1&locators=server1" and ./gsInstance.sh "/./myspace?cluster_schema=sync_replicated&total_members=2&id=2&locators=server1"

Also, please send the full log of the spaces console.

Gershon

gershond gravatar imagegershond ( 2008-07-02 05:39:01 -0500 )edit
0

Oded,

Thank you for taking the time to explain your problem and the resolution. I tried that and sure enough, it solved my problem, too. The GSM indicated that the services (such as Lookup) were starting on the +machine's+ IP address (not 127.0.0.1, as before), and voila! Remote servers (such as GSC) were able to find and register with the GSM.

Funny, but this is covered only in the GigaSpaces documentation topic on configuring +multicast+ on Linux; nowhere (that I could find) does it mention that it's a requirement, for both multicast +and+ unicast lookup.

Anyway, that gets me off the dime on this problem. Once again, thanks for monitoring this thread and sharing the benefit of your experience with this!

John

answered 2008-07-26 22:00:10 -0500

edit flag offensive delete link more

Comments

Hi, we get a similar error for one of our servers (it hosts a backup node): WARNING [net.jini.discovery.LookupLocatorDiscovery]: Exception occured during unicast discovery to 192.XXX.XXX.XXX:4162 with constraints InvocationConstraints[reqs: {}, prefs: {}]. Please verify the unicast locators hostname and port are set properly.

we are using XAP.NET 6.6.1 not sure if that's an indication of an issue or not but if i try and telnet to the server ip and port i can't connect.

any suggestions?

Sean

sfarmar gravatar imagesfarmar ( 2009-07-02 08:18:54 -0500 )edit

I would first test XAP 6.6.4 and see if you can reproduce it.
If it is still happing - I would try XAP 7.0.
With both of the above - some issues been resolved with the communication protocol layer that might be related to the problem you observe.

If you still get this problem - please submit a support case.

Shay

shay hassidim gravatar imageshay hassidim ( 2009-07-02 16:11:27 -0500 )edit

Shay, thanks a lot for your replay

Edited by: Sean Farmar on Jul 28, 2009 4:36 AM

sfarmar gravatar imagesfarmar ( 2009-07-28 04:33:29 -0500 )edit
0

Hi, Well, now i've started the GSM/LUS and it is listening to 4160. and when i start a space on the same server with the LOOKUPLOCATORS defined, it works, but when i try to create a replicated space from other server with the LOOKUPLOCATORS defined it is not working and i'm getting:

INFO [net.jini.lookup.JoinManager]: JoinManager - failure Caused by: java.rmi.ConnectException: Connect Failed; nested exception is: java.net.ConnectException: Connection refusedWARNING [net.jini.discovery.LookupLocatorDiscovery]: Exception in ... ... ... InternalDiscoverylListener.discovered() going to discard the discoveryEvent: net.jini.discovery.DiscoveryEvent[source=net.jini.discovery.LookupLocatorDiscovery@f2da21] Caused by: java.rmi.ConnectException: Connect Failed; nested exception is: java.net.ConnectException: Connection refused

There is no FW between the servers, and no local FW on the servers. any ideas?

Thanks.

answered 2008-07-02 04:49:38 -0500

maimonoded gravatar image
edit flag offensive delete link more

Comments

Hi Oded,
I understand you are using a clean 6.5 GA installation, am I right? If so, can you just use port 4162 everywhere, in setenv etc.? Why do you need to use 4160? Do you have any other GigaSpaces installations running on same subnet?

Gershon

gershond gravatar imagegershond ( 2008-07-02 05:22:45 -0500 )edit
0

Was there ever a resolution to this problem? The thread just seems to end with no confirmation of a resolution (the suggested solution seemed to be to upgrade to 6.5, but is that really necessary to solve this problem?)

I'm seeing the exact same problem with GigaSpaces 6.0 (Build 2150). I'm wanting to use uni-cast, so following the instructions for configuring for uni-cast, I'm updating setenv.sh on both machines (one runs the GSM, the other a GSC) as follows:

 if [ "${LOOKUPLOCATORS}" = "" ] ; then
 LOOKUPLOCATORS=*"gsm-host-name:4160"*; export LOOKUPLOCATORS
 fi
 LOOKUP_LOCATORS_PROP="-Dcom.gs.jini_lus.locators=${LOOKUPLOCATORS}"; export LOOKUP_LOCATORS_PROP

When I do this, the GSM starts up, but I note that he indicates

 INFO [com.gigaspaces.grid.lookup]: Lookup discovered at [127.0.0.1:4160], Groups [gigaspaces-6.0XAP], total [1]

When I start a GSC on the other machine with the same configuration change to setenv.sh, I get repeated error messages:

 Jul 25, 2008 2:48:10 PM
 WARNING [net.jini.discovery.LookupLocatorDiscovery]: Exception in InternalDiscoverylListener.discovered() going to discard the discoveryEvent:           net.jini.discovery.DiscoveryEvent[source=net.jini.discovery.LookupLocatorDiscovery@105eb6f]
 Caused by: java.rmi.ConnectException: Connect Failed; nested exception is: 
         java.net.ConnectException: Connection refused

This suggests to me that the GSC cannot connect to what he believes to be the Lookup Service. If I try to start the GS utility (gs.sh), I get the same repetitive connection failure messages.

This should work as described, right? I checked both machines. They're on the same subnet, no firewalls between them, and no firewalls blocking access on the machines. What am I overlooking? Thanks!

answered 2008-07-25 14:11:27 -0500

edit flag offensive delete link more

Comments

Would this solves the problem:
ulimit -u unlimited
?
Shay

shay hassidim gravatar imageshay hassidim ( 2008-07-25 15:36:00 -0500 )edit
0

Thanks. the step that i don't understand how to do is the very first one: start a GSM/LUS service that will listen to the unicast port. after setting the LOOKUPLOCATORS env, when i start the gsm.sh i get this message:

WARNING [net.jini.discovery.LookupLocatorDiscovery]: Exception occured during unicast discovery to server1:4162 with constraints InvocationConstraints[reqs: {}, prefs: {}]. Please verify the unicast locators hostname and port are set properly.

server1 is the current server, this server should be the server that will listen to the unicast port.

regards,

answered 2008-07-02 02:45:14 -0500

maimonoded gravatar image
edit flag offensive delete link more
0

Hi, The problem I had was because the servers hosts file was configured in a way that gigaspaces can't understand, for example, I had 2 machines, one machine hostname is gg1 and the other is gg2. the /etc/hosts file of gg1 looked like this: 127.0.0.1 localhost localhost.localdomain gg1

and the /etc/hosts file of gg2 looked like this: 127.0.0.1 localhost localhost.localdomain gg2

after starting the GSM I could see that gigaspaces is listening to the LUS port on my LAN IP (and not 127.0.0.1). but none of the spaces/LUS's/GSC's could find the other, to make it work I changed both server /etc/hosts file to include the hostname on the LAN ip, for example, gg1 /etc/hosts file look like this:

127.0.0.1 localhost localhost.localdomain 192.168.0.1 gg1

and /etc/hosts of gg2 look like this: 127.0.0.1 localhost localhost.localdomain 192.168.0.2 gg2

this fixed the problem.

I don't know if this is a bug in gigaspaces or not, but the unusual thing in gigaspaces was that it was listening on the LAN ip but was identified as 127.0.0.1 to other LUS's that tried to access it, and when they got 127.0.0.1 as the LUS IP they tried to access it and got nothing :)

Regards, Oded

answered 2008-07-26 05:40:50 -0500

maimonoded 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

Stats

Asked: 2008-07-01 09:59:39 -0500

Seen: 4,571 times

Last updated: Jul 26 '08