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

Ask Your Question
0

setting up / connecting to space behind a firewall

His everyone,

The goal is to connect to the space from outside of LAN where it is running. I followed instructions at http://www.gigaspaces.com/wiki/displa... and set the following properties in gs.sh, gs-ui.sh as appropriate:

-Dcom.gs.multicast.enabled=false -Dcom.gs.multicast.discoveryPort=7102 -Dcom.gigaspaces.system.registryPort=7103 -Dcom.gigaspaces.start.httpPort=7104

and in services.config:

bindPort = System.getProperty("com.gs.transport_protocol.lrmi.bind-port", "1700-1800");

However, 1) there are then several warnings being thrown by gsm/gsc/gs-ui, 2) and I cannot connect to the space from a remote computer (outside LAN).

Could anyone please suggest what the likely reasons should be?

  • The ports 7102, 7103, 7104 are activated,
  • LOOKUPLOCATORS is set to "testing.ip.address:7102" and NIC_ADDR to "testing.ip.address",
  • using space url "jini:/testing.ip.address/*/stockSpace?locators=testing.ip.address:7102" to connect from a remote computer

gsm: 21.10.2008 22:47:18 WARNING [org.jini.rio.tools.webster]: Getting Request Caused by: java.net.SocketException: Connection reset 21.10.2008 22:47:18 WARNING [org.jini.rio.tools.webster]: Failed to send 500 response Caused by: java.net.SocketException: Connection reset

gsc: WARNING [org.jini.rio.tools.webster]: Bind Address Failure on port [7104] Caused by: java.net.BindException: Address already in use

gs-ui: (why is unicast discovery is not being made to "testing.ip.address"?) 21.10.2008 22:14:46 WARNING [net.jini.discovery.LookupLocatorDiscovery]: Exception occured during unicast discovery to 7102:4162 with constraints InvocationConstraints[reqs: {}, prefs: {}]. Please verify the unicast locators hostname and port are set properly. Caused by: java.net.SocketException: Invalid argument or cannot assign requested address 21.10.2008 22:14:49 WARNING [net.jini.discovery.LookupLocatorDiscovery]: Exception occured during unicast discovery to 192.168.0.95:4162 with constraints InvocationConstraints[reqs: {}, prefs: {}]. Please verify the unicast locators hostname and port are set properly. Caused by: java.net.NoRouteToHostException: No route to host 21.10.2008 22:14:49 WARNING [net.jini.discovery.LookupLocatorDiscovery]: Exception occured during unicast discovery to quadron:4162 with constraints InvocationConstraints[reqs: {}, prefs: {}]. Please verify the unicast locators hostname and port are set properly. Caused by: java.net.ConnectException: Connection refused

Caused by: com.j_spaces.core.client.FinderException: LookupFinder failed to find service using the following service attributes:

Service attributes: [net.jini.lookup.entry.Name(name=stockSpace)] Service attributes: [com.j_spaces.lookup.entry.State(state=started,electable=null,replicable=null)] Lookup timeout: [5000] Classes: [interface com.j_spaces.core.service.Service] Jini Lookup Groups: [gigaspaces-testing] Jini Lookup Locators: testing.ip.address:7102,testing.ip.address Number of Lookup Services: 0

Many thanks, Denis

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

asked 2008-10-21 17:14:13 -0500

asdfasdf gravatar image

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

jaissefsfex gravatar image
edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

For the sake of the test - Can you run the gs-all instead of separate gsc and gsm and see if this works?

The gsc and gsm might be using same config. That's why you get "Address already in use" when starting the GSC.

Shay

answered 2008-10-22 10:46:14 -0500

shay hassidim gravatar image
edit flag offensive delete link more

Comments

Thanks for the hint. Have started gs-all, and not getting the "Address already in use" exception. Could you clarify this point. Must GSC and GSM use different configuration when under firewall settings (always)? And should the gs-ui exceptions be ignored?

I am still not being able to access the server from outside the LAN (probably because of the complicated network configuration with multiple NICs).

However, when starting GigaSpaces on server A (without a firewall) with default configuration and connecting to it remotely from another server B (under firewall), I noticed that the Local View is not being updated anymore (as opposed to running it within the LAN). Could you please suggest what the likely reason could be: is it to do with that the client with Local View is under a firewall? (I understand that the server is trying to initialize connection for notifications which is blocked by the client's firewall). What would be a recommended way to ensure that clients behind firewall and not located within the LAN or VPN can utilize local view/cache functionality?

Thanks

Edited by: Denis Ergash on Oct 26, 2008 7:50 PM

Edited by: Denis Ergash on Oct 27, 2008 6:51 AM

asdfasdf gravatar imageasdfasdf ( 2008-10-26 19:48:43 -0500 )edit

"Have started gs-all, and not getting the "Address already in use" exception. Could you clarify this point. Must GSC and GSM use different configuration when under firewall settings (always)? "

In general you should be able to set different config for the GSC and GSM in order these will not use the same ports. These are sharing the same config out of the box and there is a fix that allows you to have different config. Check this with support.

"However, when starting GigaSpaces on server A (without a firewall) with default configuration and connecting to it remotely from another server B (under firewall), I noticed that the Local View is not being updated anymore (as opposed to running it within the LAN)."

Does the client machine have multiple network cards? I guess so. With machines connecting over the WAN you must bind the JVM process to a specific IP. Since the space process invoking a remote method at the client (when sending notifications) the RMI layer should "know" to which IP it should send the call. You do that by setting java.rmi.server.hostname system property at the client side to have the client IP.

Shay

shay hassidim gravatar imageshay hassidim ( 2008-10-27 08:51:38 -0500 )edit

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-10-21 17:14:13 -0500

Seen: 260 times

Last updated: Oct 22 '08