You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@river.apache.org by Andrew Meng <ml...@hotmail.com> on 2009/10/13 20:36:26 UTC
Multicase problem.
Hello,
I am trying to test the Tiling ComputeFarm implementation. The multicast worker works fine on a local machine and does not work on a remote machine. Disabling Selinux/Firewall and enabling multicast on both master and worker machines does not help at all. It seems that worker could not find the registrar using multicast machinism.
Can anyone shed any light on how to debug multicast issue?
Thanks a lot,
Andrew
_________________________________________________________________
New! Faster Messenger access on the new MSN homepage
http://go.microsoft.com/?linkid=9677406
Re: Multicase problem.
Posted by Gregg Wonderly <ge...@cox.net>.
Sorry I could not respond sooner. Andrew, I believe that the problem is at the
server. I believe that when it asks for the IP address associated with it's
name, it gets 127.0.0.1. Can you check the /etc/hosts on the server to see what
it has in it?
Gregg Wonderly
Andrew Meng wrote:
> Hello,
>
> Can any Jini developer who monitors this queue helps me out?
>
> My code(attached below) is very simple, why does it try to lookup Javaspace service at local host? If there is indeed some network misconfiguration, can any one give me any advice about how to troubleshoot it?
>
> connection refused or timed out to BasicObjectEndpoint[bfad5326-91ff-4cde-bc78-d03238dfdfbe,TcpEndpoint[127.0.0.1:38220]]; nested exception is:
> java.net.ConnectException: Connection refused
>
>
> public class SpaceAccessor {
> public static JavaSpace getSpace(String name) {
> try {
> if (System.getSecurityManager() == null) {
> System.setSecurityManager(new RMISecurityManager());
> }
> if (System.getProperty("com.sun.jini.use.registry")
> == null)
> {
> //Create a template to lookup the JavaSpaces service.
> Class [] types = new Class[]{JavaSpace.class};
> ServiceTemplate tmpl = new ServiceTemplate(null,types,null );
>
> // Locate the JavaSpaces service and create a JavaSpace proxy attached to it.
> LookupLocator locator = new LookupLocator("jini://s04");
> ServiceRegistrar sr = locator.getRegistrar();
> JavaSpace space = (JavaSpace)sr.lookup(tmpl); //got exception here.
>
> return space;
>
> }
> } catch (Exception e) {
> System.err.println(e.getMessage());
> }
> return null;
> }
>
> Thanks a lot in advance!
> Andrew
>
> From: mlq1@hotmail.com
> To: river-user@incubator.apache.org
> Subject: RE: Multicase problem.
> Date: Wed, 14 Oct 2009 20:06:31 +0000
>
>
>
>
>
>
>
>
> Greg,
>
> Here is what I got on server(s04) where LUS is running:
>
> [root@s04 ~]# netstat -an | grep LISTEN
> tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN
> tcp 0 0 0.0.0.0:47754 0.0.0.0:* LISTEN
> tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
> tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
> tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN
> tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
> tcp 0 0 :::4160 :::* LISTEN
>
> my /etc/hosts on the worker machine(s03)look like this:
>
> 192.168.0.4 s04.meng.com s04
> 127.0.0.1 localhost.localdomain localhost
> 192.168.0.3 s03 s03
>
> My question is, if s03 can successfully get registrar back from s04, why does the registrar.lookup() bind to localhost instead of s04?
>
> Thanks,
> Andrew
>
>> Date: Wed, 14 Oct 2009 14:09:22 -0500
>> From: gergg@cox.net
>> To: river-user@incubator.apache.org
>> Subject: Re: Multicase problem.
>>
>> This points at a common linux misconfiguration where the /etc/hosts file ends up
>> having bad values in it that map the hostname to 127.0.0.1 and vice-versa.
>>
>> The end result is that the LUS binds to localhost instead of the interface
>> address for a network interface, and then tells you this is where it is bound,
>> which of course you can not connect to.
>>
>> If you will do a "netstat -an |grep LISTEN" on the server that the LUS is
>> running on, you should see that there is no external LISTEN on 4160, only a
>> localhost binding.
>>
>> You are finding the service via multicast, but then getting back an address that
>> you can't connect to it with I am guessing.
>>
>> Gregg Wonderly
>>
>> Patrick Wright wrote:
>>> This reminds me of a situation where some of our BasicObjectEndpoints
>>> were ending up with the loopback address. When a remote server would
>>> try to contact on that endpoint, it of course wouldn't find us.
>>>
>>> HTH
>>> Patrick
>>>
>
> Click less, mail more: Hotmail on the new MSN homepage!
> _________________________________________________________________
> New! Faster Messenger access on the new MSN homepage
> http://go.microsoft.com/?linkid=9677406
Re: Multicase problem.
Posted by Patrick Wright <pd...@gmail.com>.
Hi Andrew
Yeah, that's usually the cause. We've found that it's safer to
explicitly provide the IP address for each endpoint that will be sent
across the wire and not worry about the hosts file. That's esp. true
in the case of development, as developers may do funny things with
their hosts file, and on some production boxes that no one wants to
"fix" for fear of breakage.
Glad to heard you worked it out.
Patrick
On Fri, Oct 16, 2009 at 5:10 PM, Andrew Meng <ml...@hotmail.com> wrote:
>
> Patrick,
>
> With your great help, I finally figure it out that it has bad entry in /etc/hosts files on the server. It was like "127.0.0.1 localhost s04" and it is working now after remove "s04" from the end.
>
> Thanks a lot!
> Andrew
>
>> Date: Fri, 16 Oct 2009 16:02:05 +0200
>> Subject: Re: Multicase problem.
>> From: pdoubleya@gmail.com
>> To: river-user@incubator.apache.org
>>
>> Hi Andrew
>>
>> Here's a stab in the dark. I suspect that the launch-all is using the
>> config file at installverify/support/reggie.config.
>>
>> Back that file up, then edit it and add
>> serverExporter = new
>> BasicJeriExporter(TcpServerEndpoint.getInstance("REGGIE HOST ADDRESS",
>> 0),
>> invocationLayerFactory,
>> false,
>> true);
>>
>> where REGGIE HOST ADDRESS is the IP address of the server where you
>> are running the LUS. Note the 0 parameter means "assign a port
>> randomly".
>>
>> After saving that change, restart your services and see what happens.
>> If you turn logging up (level FINE) for net.jini.jeri you should see
>> something like
>> 157 Oct 16, 2009 3:58:54 PM net.jini.jeri.BasicJeriExporter export
>> 158 FINE: export of
>> com.sun.jini.reggie.TransientRegistrarImpl@398825b3 via
>> BasicJeriExporter[TcpServerEndpoint[0],1a57e3ff-63bc-45d1-b64a-785be02b4596]
>> returns proxy Proxy[ 158
>> Registrar,BasicInvocationHandler[BasicObjectEndpoint[1a57e3ff-63bc-45d1-b64a-785be02b4596,TcpEndpoint[127.0.1.1:37977]]]]
>>
>> where the TcpEndpoint has the correct server IP.
>>
>> Hope this works :)
>> Patrick
>
> _________________________________________________________________
> New! Get to Messenger faster: Sign-in here now!
> http://go.microsoft.com/?linkid=9677407
RE: Multicase problem.
Posted by Andrew Meng <ml...@hotmail.com>.
Patrick,
With your great help, I finally figure it out that it has bad entry in /etc/hosts files on the server. It was like "127.0.0.1 localhost s04" and it is working now after remove "s04" from the end.
Thanks a lot!
Andrew
> Date: Fri, 16 Oct 2009 16:02:05 +0200
> Subject: Re: Multicase problem.
> From: pdoubleya@gmail.com
> To: river-user@incubator.apache.org
>
> Hi Andrew
>
> Here's a stab in the dark. I suspect that the launch-all is using the
> config file at installverify/support/reggie.config.
>
> Back that file up, then edit it and add
> serverExporter = new
> BasicJeriExporter(TcpServerEndpoint.getInstance("REGGIE HOST ADDRESS",
> 0),
> invocationLayerFactory,
> false,
> true);
>
> where REGGIE HOST ADDRESS is the IP address of the server where you
> are running the LUS. Note the 0 parameter means "assign a port
> randomly".
>
> After saving that change, restart your services and see what happens.
> If you turn logging up (level FINE) for net.jini.jeri you should see
> something like
> 157 Oct 16, 2009 3:58:54 PM net.jini.jeri.BasicJeriExporter export
> 158 FINE: export of
> com.sun.jini.reggie.TransientRegistrarImpl@398825b3 via
> BasicJeriExporter[TcpServerEndpoint[0],1a57e3ff-63bc-45d1-b64a-785be02b4596]
> returns proxy Proxy[ 158
> Registrar,BasicInvocationHandler[BasicObjectEndpoint[1a57e3ff-63bc-45d1-b64a-785be02b4596,TcpEndpoint[127.0.1.1:37977]]]]
>
> where the TcpEndpoint has the correct server IP.
>
> Hope this works :)
> Patrick
_________________________________________________________________
New! Get to Messenger faster: Sign-in here now!
http://go.microsoft.com/?linkid=9677407
Re: Multicase problem.
Posted by Patrick Wright <pd...@gmail.com>.
Hi Andrew
Here's a stab in the dark. I suspect that the launch-all is using the
config file at installverify/support/reggie.config.
Back that file up, then edit it and add
serverExporter = new
BasicJeriExporter(TcpServerEndpoint.getInstance("REGGIE HOST ADDRESS",
0),
invocationLayerFactory,
false,
true);
where REGGIE HOST ADDRESS is the IP address of the server where you
are running the LUS. Note the 0 parameter means "assign a port
randomly".
After saving that change, restart your services and see what happens.
If you turn logging up (level FINE) for net.jini.jeri you should see
something like
157 Oct 16, 2009 3:58:54 PM net.jini.jeri.BasicJeriExporter export
158 FINE: export of
com.sun.jini.reggie.TransientRegistrarImpl@398825b3 via
BasicJeriExporter[TcpServerEndpoint[0],1a57e3ff-63bc-45d1-b64a-785be02b4596]
returns proxy Proxy[ 158
Registrar,BasicInvocationHandler[BasicObjectEndpoint[1a57e3ff-63bc-45d1-b64a-785be02b4596,TcpEndpoint[127.0.1.1:37977]]]]
where the TcpEndpoint has the correct server IP.
Hope this works :)
Patrick
RE: Multicase problem.
Posted by Andrew Meng <ml...@hotmail.com>.
Patrick,
On the server machine, I just run LaunchAll in jini/installverify directory after install Jini 2.0. Is that not enough?
On the remote worker machine, where are the configuration files? Many Jini tutorials mention to "get the Brain Murphy's 2.0 configuration". Is that what I need to put on the worker machine or something else? But I could not find it anywhere. Can you please send me a standard config file ?
Thanks a lot,
Andrew
> Date: Fri, 16 Oct 2009 10:53:31 +0200
> Subject: Re: Multicase problem.
> From: pdoubleya@gmail.com
> To: river-user@incubator.apache.org
>
> Hi Andrew
>
> How are you starting your reggie? What's the config?
>
> If I understand it correctly, Reggie needs a couple of configuration
> settings that end up requiring an IP address--serverExporter is one.
> What I think you want to avoid in your situation, given your hosts
> configuration, is something like the default
>
> serverExporter = new BasicJeriExporter(TcpServerEndpoint.getInstance(0),
> invocationLayerFactory,
> false,
> true);
>
> If you use TcpServerEndpoint without a host parameter, it will
> delegate to InetAddress.getLocalHost(), which you don't want.
> Basically, the way I read it, you can lookup the registrar because you
> are doing a unicast lookup--you are specifying the host where the LUS
> is running. However, the registrar exports an endpoint which is part
> of what you receive in the call to getRegistrar(). It's how the
> registrar proxy (on the client side) instance knows how to call home.
> If it's exported with an endpoint bound to 127.0.0.1, you're stuck.
>
> I believe in our case we always specify the host IP parameter for our
> endpoints explicitly via the two-arg constructor to
> TcpServerEndpoint--host, port.
>
> HTH
> Patrick
_________________________________________________________________
Click less, chat more: Messenger on MSN.ca
http://go.microsoft.com/?linkid=9677404
Re: Multicase problem.
Posted by Patrick Wright <pd...@gmail.com>.
Hi Andrew
How are you starting your reggie? What's the config?
If I understand it correctly, Reggie needs a couple of configuration
settings that end up requiring an IP address--serverExporter is one.
What I think you want to avoid in your situation, given your hosts
configuration, is something like the default
serverExporter = new BasicJeriExporter(TcpServerEndpoint.getInstance(0),
invocationLayerFactory,
false,
true);
If you use TcpServerEndpoint without a host parameter, it will
delegate to InetAddress.getLocalHost(), which you don't want.
Basically, the way I read it, you can lookup the registrar because you
are doing a unicast lookup--you are specifying the host where the LUS
is running. However, the registrar exports an endpoint which is part
of what you receive in the call to getRegistrar(). It's how the
registrar proxy (on the client side) instance knows how to call home.
If it's exported with an endpoint bound to 127.0.0.1, you're stuck.
I believe in our case we always specify the host IP parameter for our
endpoints explicitly via the two-arg constructor to
TcpServerEndpoint--host, port.
HTH
Patrick
RE: Multicase problem.
Posted by Andrew Meng <ml...@hotmail.com>.
Hello,
Can any Jini developer who monitors this queue helps me out?
My code(attached below) is very simple, why does it try to lookup Javaspace service at local host? If there is indeed some network misconfiguration, can any one give me any advice about how to troubleshoot it?
connection refused or timed out to BasicObjectEndpoint[bfad5326-91ff-4cde-bc78-d03238dfdfbe,TcpEndpoint[127.0.0.1:38220]]; nested exception is:
java.net.ConnectException: Connection refused
public class SpaceAccessor {
public static JavaSpace getSpace(String name) {
try {
if (System.getSecurityManager() == null) {
System.setSecurityManager(new RMISecurityManager());
}
if (System.getProperty("com.sun.jini.use.registry")
== null)
{
//Create a template to lookup the JavaSpaces service.
Class [] types = new Class[]{JavaSpace.class};
ServiceTemplate tmpl = new ServiceTemplate(null,types,null );
// Locate the JavaSpaces service and create a JavaSpace proxy attached to it.
LookupLocator locator = new LookupLocator("jini://s04");
ServiceRegistrar sr = locator.getRegistrar();
JavaSpace space = (JavaSpace)sr.lookup(tmpl); //got exception here.
return space;
}
} catch (Exception e) {
System.err.println(e.getMessage());
}
return null;
}
Thanks a lot in advance!
Andrew
From: mlq1@hotmail.com
To: river-user@incubator.apache.org
Subject: RE: Multicase problem.
Date: Wed, 14 Oct 2009 20:06:31 +0000
Greg,
Here is what I got on server(s04) where LUS is running:
[root@s04 ~]# netstat -an | grep LISTEN
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:47754 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
tcp 0 0 :::4160 :::* LISTEN
my /etc/hosts on the worker machine(s03)look like this:
192.168.0.4 s04.meng.com s04
127.0.0.1 localhost.localdomain localhost
192.168.0.3 s03 s03
My question is, if s03 can successfully get registrar back from s04, why does the registrar.lookup() bind to localhost instead of s04?
Thanks,
Andrew
> Date: Wed, 14 Oct 2009 14:09:22 -0500
> From: gergg@cox.net
> To: river-user@incubator.apache.org
> Subject: Re: Multicase problem.
>
> This points at a common linux misconfiguration where the /etc/hosts file ends up
> having bad values in it that map the hostname to 127.0.0.1 and vice-versa.
>
> The end result is that the LUS binds to localhost instead of the interface
> address for a network interface, and then tells you this is where it is bound,
> which of course you can not connect to.
>
> If you will do a "netstat -an |grep LISTEN" on the server that the LUS is
> running on, you should see that there is no external LISTEN on 4160, only a
> localhost binding.
>
> You are finding the service via multicast, but then getting back an address that
> you can't connect to it with I am guessing.
>
> Gregg Wonderly
>
> Patrick Wright wrote:
> > This reminds me of a situation where some of our BasicObjectEndpoints
> > were ending up with the loopback address. When a remote server would
> > try to contact on that endpoint, it of course wouldn't find us.
> >
> > HTH
> > Patrick
> >
>
Click less, mail more: Hotmail on the new MSN homepage!
_________________________________________________________________
New! Faster Messenger access on the new MSN homepage
http://go.microsoft.com/?linkid=9677406
RE: Multicase problem.
Posted by Andrew Meng <ml...@hotmail.com>.
Greg,
Here is what I got on server(s04) where LUS is running:
[root@s04 ~]# netstat -an | grep LISTEN
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:47754 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN
tcp 0 0 :::4160 :::* LISTEN
my /etc/hosts on the worker machine(s03)look like this:
192.168.0.4 s04.meng.com s04
127.0.0.1 localhost.localdomain localhost
192.168.0.3 s03 s03
My question is, if s03 can successfully get registrar back from s04, why does the registrar.lookup() bind to localhost instead of s04?
Thanks,
Andrew
> Date: Wed, 14 Oct 2009 14:09:22 -0500
> From: gergg@cox.net
> To: river-user@incubator.apache.org
> Subject: Re: Multicase problem.
>
> This points at a common linux misconfiguration where the /etc/hosts file ends up
> having bad values in it that map the hostname to 127.0.0.1 and vice-versa.
>
> The end result is that the LUS binds to localhost instead of the interface
> address for a network interface, and then tells you this is where it is bound,
> which of course you can not connect to.
>
> If you will do a "netstat -an |grep LISTEN" on the server that the LUS is
> running on, you should see that there is no external LISTEN on 4160, only a
> localhost binding.
>
> You are finding the service via multicast, but then getting back an address that
> you can't connect to it with I am guessing.
>
> Gregg Wonderly
>
> Patrick Wright wrote:
> > This reminds me of a situation where some of our BasicObjectEndpoints
> > were ending up with the loopback address. When a remote server would
> > try to contact on that endpoint, it of course wouldn't find us.
> >
> > HTH
> > Patrick
> >
>
_________________________________________________________________
New! Get to Messenger faster: Sign-in here now!
http://go.microsoft.com/?linkid=9677407
Re: Multicase problem.
Posted by Gregg Wonderly <ge...@cox.net>.
This points at a common linux misconfiguration where the /etc/hosts file ends up
having bad values in it that map the hostname to 127.0.0.1 and vice-versa.
The end result is that the LUS binds to localhost instead of the interface
address for a network interface, and then tells you this is where it is bound,
which of course you can not connect to.
If you will do a "netstat -an |grep LISTEN" on the server that the LUS is
running on, you should see that there is no external LISTEN on 4160, only a
localhost binding.
You are finding the service via multicast, but then getting back an address that
you can't connect to it with I am guessing.
Gregg Wonderly
Patrick Wright wrote:
> This reminds me of a situation where some of our BasicObjectEndpoints
> were ending up with the loopback address. When a remote server would
> try to contact on that endpoint, it of course wouldn't find us.
>
> HTH
> Patrick
>
Re: Multicase problem.
Posted by Patrick Wright <pd...@gmail.com>.
This reminds me of a situation where some of our BasicObjectEndpoints
were ending up with the loopback address. When a remote server would
try to contact on that endpoint, it of course wouldn't find us.
HTH
Patrick
RE: Multicase problem.
Posted by Andrew Meng <ml...@hotmail.com>.
Jonahthan,
Thanks for the tip! I just figured out that firewall provented accessing port 4160 and 8081 on the master machine. After getting registrar object back, however it has lookup problem now. see the attached exceptions. The jini services(includeing JavaSpace) are on host "s04", but worker machine(s03) tries to lookup javaspace object at localhost instead of from s04. Here is my /etc/hosts file:
192.168.0.4 s04.meng.com s04
127.0.0.1 localhost
192.168.0.3 s03
what did I miss?
Thanks a lot,
Andrew
INE: main: name = "com.sun.jini.reggie.RegistrarProxy", codebase = "http://s04.meng.com:8081/reggie-dl.jar http://s04.meng.com:8081/jsk-dl.jar", defaultLoader = sun.misc.Launcher$AppClassLoader@7d772e
Oct 14, 2009 12:38:57 PM sun.rmi.server.LoaderHandler loadClass
FINER: main: (thread context class loader: sun.misc.Launcher$AppClassLoader@7d772e)
Oct 14, 2009 12:38:57 PM sun.rmi.server.LoaderHandler loadClass
FINER: main: class "com.sun.jini.reggie.RegistrarProxy" found via codebase, defined by sun.rmi.server.LoaderHandler$Loader@119cca4["http://s04.meng.com:8081/reggie-dl.jar http://s04.meng.com:8081/jsk-dl.jar"]
Oct 14, 2009 12:38:57 PM sun.rmi.server.LoaderHandler loadProxyClass
FINE: main: interfaces = [com.sun.jini.reggie.Registrar, net.jini.core.constraint.RemoteMethodControl, net.jini.security.proxytrust.TrustEquivalence], codebase = "http://s04.meng.com:8081/reggie-dl.jar http://s04.meng.com:8081/jsk-dl.jar", defaultLoader = sun.rmi.server.LoaderHandler$Loader@119cca4["http://s04.meng.com:8081/reggie-dl.jar http://s04.meng.com:8081/jsk-dl.jar"]
Oct 14, 2009 12:38:57 PM sun.rmi.server.LoaderHandler loadProxyClass
FINER: main: (thread context class loader: sun.misc.Launcher$AppClassLoader@7d772e)
Oct 14, 2009 12:38:57 PM sun.rmi.server.LoaderHandler loadProxyInterfaces
FINER: main: non-public interface "com.sun.jini.reggie.Registrar" defined by sun.rmi.server.LoaderHandler$Loader@119cca4["http://s04.meng.com:8081/reggie-dl.jar http://s04.meng.com:8081/jsk-dl.jar"]
Oct 14, 2009 12:38:57 PM sun.rmi.server.LoaderHandler loadProxyClass
FINER: main: proxy interfaces found via defaultLoader, defined by [sun.rmi.server.LoaderHandler$Loader@119cca4["http://s04.meng.com:8081/reggie-dl.jar http://s04.meng.com:8081/jsk-dl.jar"], sun.misc.Launcher$AppClassLoader@7d772e, sun.misc.Launcher$AppClassLoader@7d772e]
Oct 14, 2009 12:38:57 PM sun.rmi.server.LoaderHandler loadProxyClass
FINER: main: proxy class defined by sun.rmi.server.LoaderHandler$Loader@119cca4["http://s04.meng.com:8081/reggie-dl.jar http://s04.meng.com:8081/jsk-dl.jar"]
Oct 14, 2009 12:38:57 PM sun.rmi.server.LoaderHandler loadClass
FINE: main: name = "java.lang.reflect.Proxy", codebase = "", defaultLoader = sun.rmi.server.LoaderHandler$Loader@119cca4["http://s04.meng.com:8081/reggie-dl.jar http://s04.meng.com:8081/jsk-dl.jar"]
Oct 14, 2009 12:38:57 PM sun.rmi.server.LoaderHandler loadClass
FINER: main: class "java.lang.reflect.Proxy" found via defaultLoader, defined by null
Oct 14, 2009 12:38:57 PM sun.rmi.server.LoaderHandler loadClass
FINE: main: name = "net.jini.jeri.BasicInvocationHandler", codebase = "", defaultLoader = sun.rmi.server.LoaderHandler$Loader@119cca4["http://s04.meng.com:8081/reggie-dl.jar http://s04.meng.com:8081/jsk-dl.jar"]
Oct 14, 2009 12:38:57 PM sun.rmi.server.LoaderHandler loadClass
FINER: main: class "net.jini.jeri.BasicInvocationHandler" found via defaultLoader, defined by sun.misc.Launcher$AppClassLoader@7d772e
Oct 14, 2009 12:38:57 PM sun.rmi.server.LoaderHandler loadClass
FINE: main: name = "net.jini.jeri.BasicObjectEndpoint", codebase = "", defaultLoader = sun.misc.Launcher$AppClassLoader@7d772e
Oct 14, 2009 12:38:57 PM sun.rmi.server.LoaderHandler loadClass
FINER: main: class "net.jini.jeri.BasicObjectEndpoint" found via defaultLoader, defined by sun.misc.Launcher$AppClassLoader@7d772e
Oct 14, 2009 12:38:57 PM sun.rmi.server.LoaderHandler loadClass
FINE: main: name = "net.jini.jeri.tcp.TcpEndpoint", codebase = "", defaultLoader = sun.misc.Launcher$AppClassLoader@7d772e
Oct 14, 2009 12:38:57 PM sun.rmi.server.LoaderHandler loadClass
FINER: main: class "net.jini.jeri.tcp.TcpEndpoint" found via defaultLoader, defined by sun.misc.Launcher$AppClassLoader@7d772e
Oct 14, 2009 12:38:57 PM sun.rmi.server.LoaderHandler loadClass
FINE: main: name = "net.jini.id.UuidFactory$Impl", codebase = "", defaultLoader = sun.misc.Launcher$AppClassLoader@7d772e
Oct 14, 2009 12:38:57 PM sun.rmi.server.LoaderHandler loadClass
FINER: main: class "net.jini.id.UuidFactory$Impl" found via defaultLoader, defined by sun.misc.Launcher$AppClassLoader@7d772e
Oct 14, 2009 12:38:57 PM sun.rmi.server.LoaderHandler loadClass
FINE: main: name = "net.jini.id.Uuid", codebase = "", defaultLoader = sun.misc.Launcher$AppClassLoader@7d772e
Oct 14, 2009 12:38:57 PM sun.rmi.server.LoaderHandler loadClass
FINER: main: class "net.jini.id.Uuid" found via defaultLoader, defined by sun.misc.Launcher$AppClassLoader@7d772e
Oct 14, 2009 12:38:57 PM net.jini.jeri.BasicInvocationHandler invoke
FINE: outbound call com.sun.jini.reggie.Registrar.lookup to BasicObjectEndpoint[d3002af8-560b-4ec7-9fab-5b9701ee8359,TcpEndpoint[127.0.0.1:43540]]
args [com.sun.jini.reggie.Template@422ede]
InvocationConstraints[reqs: {}, prefs: {}]
Oct 14, 2009 12:38:57 PM net.jini.jeri.tcp.TcpEndpoint$ConnectionEndpointImpl newSocket
FINE: created socket Socket[unconnected]
Oct 14, 2009 12:38:57 PM net.jini.jeri.tcp.TcpEndpoint$ConnectionEndpointImpl connectToHost
HANDLED: exception connecting to /127.0.0.1:43540
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:519)
at net.jini.jeri.tcp.TcpEndpoint$ConnectionEndpointImpl.connectToSocketAddress(TcpEndpoint.java:678)
at net.jini.jeri.tcp.TcpEndpoint$ConnectionEndpointImpl.connectToHost(TcpEndpoint.java:608)
at net.jini.jeri.tcp.TcpEndpoint$ConnectionEndpointImpl.connect(TcpEndpoint.java:543)
at net.jini.jeri.connection.ConnectionManager.connect(ConnectionManager.java:228)
at net.jini.jeri.connection.ConnectionManager$ReqIterator.next(ConnectionManager.java:629)
at net.jini.jeri.BasicObjectEndpoint$1.next(BasicObjectEndpoint.java:371)
at net.jini.jeri.BasicInvocationHandler.invokeRemoteMethodOnce(BasicInvocationHandler.java:708)
at net.jini.jeri.BasicInvocationHandler.invokeRemoteMethod(BasicInvocationHandler.java:659)
at net.jini.jeri.BasicInvocationHandler.invoke(BasicInvocationHandler.java:528)
at com.sun.jini.reggie.$Proxy0.lookup(Unknown Source)
at com.sun.jini.reggie.RegistrarProxy.lookup(RegistrarProxy.java:112)
at org.tiling.computefarm.impl.javaspaces.util.ServiceFinder.findService(ServiceFinder.java:16)
at org.tiling.computefarm.impl.javaspaces.worker.UnicastWorker.run(UnicastWorker.java:42)
at org.tiling.computefarm.impl.javaspaces.worker.UnicastWorker.main(UnicastWorker.java:104)
Oct 14, 2009 12:38:57 PM net.jini.jeri.tcp.TcpEndpoint$ConnectionEndpointImpl connectToHost
FAILED: exception connecting to 127.0.0.1:43540
> Subject: Re: Multicase problem.
> From: jonathan.costers@googlemail.com
> To: river-user@incubator.apache.org
> Date: Wed, 14 Oct 2009 19:31:37 +0200
>
> Hi Andrew
>
> You could try using the following JDK logging settings:
>
> # For debugging discovery
> com.sun.jini.discovery.level = INFO
> com.sun.jini.discovery.DiscoveryV1.level = INFO
> com.sun.jini.discovery.DiscoveryV2.level = INFO
> com.sun.jini.discovery.x500.level = INFO
>
> # For debugging the helper utilities
> net.jini.discovery.LookupDiscovery.level = INFO
> net.jini.discovery.LookupLocatorDiscovery.level = INFO
> net.jini.lookup.JoinManager.level = INFO
> net.jini.lookup.ServiceDiscoveryManager.level = INFO
> net.jini.lease.LeaseRenewalManager.level = INFO
>
> Of course, set the logging level to something higher than INFO ...
>
> Add these lines in your logging.properties file and tell the JVM to use
> it by passing something like
> "-Djava.util.logging.config.file=config/logging.properties" to yr JVM.
>
> Hope this helps.
>
> Op dinsdag 13-10-2009 om 18:36 uur [tijdzone +0000], schreef Andrew
> Meng:
> > Hello,
> >
> > I am trying to test the Tiling ComputeFarm implementation. The multicast worker works fine on a local machine and does not work on a remote machine. Disabling Selinux/Firewall and enabling multicast on both master and worker machines does not help at all. It seems that worker could not find the registrar using multicast machinism.
> >
> > Can anyone shed any light on how to debug multicast issue?
> >
> > Thanks a lot,
> > Andrew
> >
> > _________________________________________________________________
> > New! Faster Messenger access on the new MSN homepage
> > http://go.microsoft.com/?linkid=9677406
>
_________________________________________________________________
New! Faster Messenger access on the new MSN homepage
http://go.microsoft.com/?linkid=9677406
Re: Multicase problem.
Posted by Jonathan Costers <jo...@googlemail.com>.
Hi Andrew
You could try using the following JDK logging settings:
# For debugging discovery
com.sun.jini.discovery.level = INFO
com.sun.jini.discovery.DiscoveryV1.level = INFO
com.sun.jini.discovery.DiscoveryV2.level = INFO
com.sun.jini.discovery.x500.level = INFO
# For debugging the helper utilities
net.jini.discovery.LookupDiscovery.level = INFO
net.jini.discovery.LookupLocatorDiscovery.level = INFO
net.jini.lookup.JoinManager.level = INFO
net.jini.lookup.ServiceDiscoveryManager.level = INFO
net.jini.lease.LeaseRenewalManager.level = INFO
Of course, set the logging level to something higher than INFO ...
Add these lines in your logging.properties file and tell the JVM to use
it by passing something like
"-Djava.util.logging.config.file=config/logging.properties" to yr JVM.
Hope this helps.
Op dinsdag 13-10-2009 om 18:36 uur [tijdzone +0000], schreef Andrew
Meng:
> Hello,
>
> I am trying to test the Tiling ComputeFarm implementation. The multicast worker works fine on a local machine and does not work on a remote machine. Disabling Selinux/Firewall and enabling multicast on both master and worker machines does not help at all. It seems that worker could not find the registrar using multicast machinism.
>
> Can anyone shed any light on how to debug multicast issue?
>
> Thanks a lot,
> Andrew
>
> _________________________________________________________________
> New! Faster Messenger access on the new MSN homepage
> http://go.microsoft.com/?linkid=9677406