Mailing-List: contact jcs-users-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "JCS Users List" <jcs-users@jakarta.apache.org>
Received-SPF: pass (athena.apache.org: domain of lists@nabble.com designates
 216.139.236.158 as permitted sender)
Message-ID: <19100276.post@talk.nabble.com>
Date: Thu, 21 Aug 2008 19:17:18 -0700 (PDT)
From: rasuyom <rasuyom@yahoo.com>
To: jcs-users@jakarta.apache.org
Subject: Re: Lateral UDP Discovery Issue with JBoss
In-Reply-To: <1219348836.7044.118.camel@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <19095240.post@talk.nabble.com>
 <1219348836.7044.118.camel@localhost>


Hi Niall,

JCS resides on both JBoss Server, the objective is to have cache replicated
on both servers. So when server1 got updated (puts), server2 should get
updated. We are using Centos 5 64bit running on xeon servers. 

I will look at the link that you have provided and thanks for replying to my
post.

Best regards,

Ronald


Niall Gallagher wrote:
> 
> Hi Rasuyom,
> 
> It's not clear what JCS is trying to do there - if you could provide
> some of the stack trace it would help. Your environment is very similar
> to ours though - Centos (which version?), Java 6, JBoss 4.2.2. Although
> we are running slightly older JCS 1.2.7.9. Also we are running the JCS
> remote server not the lateral configuration but we had issues similar to
> what you mention.
> 
> It looks like the server might be trying to either:
> 
> 1) open a socket so other servers can connect to it over the network
> ---however it's trying to open the socket on its own loopback interface
> (127.0.0.1) instead of its LAN interface
> 
> or 
> 
> 2) connect to a remote server
> ---however it's trying to communicate with the other server using IP
> address 127.0.0.1
> 
> 
> Issue (1) can be caused by JCS' use of InetAddress.getLocalHost(). This
> causes JCS to confuse the server's loopback interface with the server's
> actual network card, so JCS tries to bind to the loopback interface
> instead of the network card at startup. I've logged a bug report for JCS
> on this here: http://issues.apache.org/jira/browse/JCS-40
> 
> Issue (2) can be caused by a remote server connecting to the local
> server, but telling the local server to use IP address 127.0.0.1 for
> callbacks. This can cause the local server to try to call back to the
> remote server via 127.0.0.1 which obviously fails.
> 
> I posted my solutions to both these problems in the bug report above. My
> solution was basically to fix the root cause of the issue which is
> InetAddress.getLocalHost() in JCS source code by replacing all uses of
> that method with the method I included in the bug report. 
> 
> If you want a quick fix and your servers have static IP addresses, you
> could alter the /etc/hosts file to make InetAddress.getLocalHost()
> return the LAN IP address of the server instead of the loopback IP.
> There are disadvantages to this per my bug report.
> 
> Basically if you see any errors mentioning 127.0.0.1 it's due to the
> InetAddress.getLocalHost() bug. We've successfully sorted the issue in
> our in house build and everything works now. 
> 
> Niall
> 
> On Thu, 2008-08-21 at 12:25 -0700, rasuyom wrote:
> 
>> Hi,
>> 
>> I'm pretty new with JCS Lateral UDP Discovery and I followed the samples
>> but
>> i can't seem to make it work. This is how I configured my cache.ccf
>> 
>> Server 1:
>> jcs.auxiliary.LTCP=org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory
>> jcs.auxiliary.LTCP.attributes=org.apache.jcs.auxiliary.lateral.socket.tcp.TCPLateralCacheAttributes
>> jcs.auxiliary.LTCP.attributes.TcpListenerPort=11110
>> jcs.auxiliary.LTCP.attributes.AllowGet=true
>> #jcs.auxiliary.LTCP.attributes.PutOnlyMode=false
>> jcs.auxiliary.LTCP.attributes.UdpDiscoveryAddr=228.5.6.9
>> jcs.auxiliary.LTCP.attributes.UdpDiscoveryPort=6780
>> jcs.auxiliary.LTCP.attributes.UdpDiscoveryEnabled=true
>> 
>> Server 2:
>> jcs.auxiliary.LTCP=org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory
>> jcs.auxiliary.LTCP.attributes=org.apache.jcs.auxiliary.lateral.socket.tcp.TCPLateralCacheAttributes
>> jcs.auxiliary.LTCP.attributes.TcpListenerPort=11111
>> #jcs.auxiliary.LTCP.attributes.PutOnlyMode=false
>> jcs.auxiliary.LTCP.attributes.AllowGet=true
>> jcs.auxiliary.LTCP.attributes.UdpDiscoveryAddr=228.5.6.9
>> jcs.auxiliary.LTCP.attributes.UdpDiscoveryPort=6780
>> jcs.auxiliary.LTCP.attributes.UdpDiscoveryEnabled=true
>> 
>> 
>> I have been searching the mail archives and follow some trails but still
>> couldn't fix my errors below:
>> 
>> Server 1:
>> 06:20:44,921 ERROR [LateralCacheRestore] Can't fix Can't fix Socket is
>> null,
>> cannot connect to 127.0.0.1:11111
>> 
>> Server 2:
>> 06:21:00,764 ERROR [LateralCacheRestore] Can't fix Can't fix Socket is
>> null,
>> cannot connect to 127.0.0.1:11110
>> 
>> 
>> As I saw some people saw this problem with Linux/*nix systems and I am
>> wondering is someone can shed some light on how to resolve this problem.
>> 
>> Please bear with me.
>> 
>> Thanks!
>> 
>> 
>> Environment:
>> JCS 1.3 Lateral UDP Discovery, JBoss 4.2.2, Centos, JDK 1.6.0_07
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Lateral-UDP-Discovery-Issue-with-JBoss-tp19095240p19100276.html
Sent from the JCS - Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org