Re: [SPAM: 3.000] Connection refused to host

Happy Manocha <[email protected]>
Newsgroups gmane.comp.java.sun.rmi
Message-ID <[email protected]> 
Hello all/carl,
my rmi registry port is 5098 and activation port is 5099.

Do i need to open these ports on SUSE Linux ?
if yes how ?

Regds
Happy Manocha



-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Tuesday, November 01, 2005 6:49 AM
To: Happy Manocha
Subject: Re: [SPAM: 3.000] Connection refused to host


Hi,

That should have worked.  The iptables command only stays valid, however,
until the computer is restarted.

This really sounds like a firewalling system.  Make sure that all security
has been turned off, which might be hard to do under SUSE Linux.

~Carl.


On 10/31/05, Happy Manocha < [email protected] <mailto:[email protected]>
> wrote:

Hi carl ,
I followed both of the steps  but getting the same error ?

there could be any other reason ? or after running the command "iptables -F"
do i need to relogin ?

Regds

Happy Manocha


-----Original Message-----
From: [email protected]  <mailto:[email protected]> [mailto:
[email protected] <mailto:[email protected]> ]
Sent: Monday, October 31, 2005 12:43 AM
To: Happy Manocha
Cc: [email protected] <mailto:[email protected]>
Subject: Re: [SPAM: 3.000] Connection refused to host


Hi,

On 10/31/05, Happy Manocha < [email protected] <mailto:[email protected]>
> wrote:


i am trying to run an application , which is register ing object with
rmiregistry. This application is running fine  on linux/windows.
Now i am trying to make it up for SUSE Linux (SLES-9) . I am getting the
following error :


RMI traffic is probably being firewalled.  The default firewall rules will
block all non-standard inbound connections.

I posted a solution to this in March 2005 (
<http://archives.java.sun.com/cgi-bin/wa?A2=ind0503&L=rmi-users&P=R399&I=-3&
X=0F1C0F71BC3F7581B4&[email protected]> 018912). You might want
to see if this fixes your problem.

Regards,
~Carl.



java.rmi.ConnectException: Connection refused to host: 10.10.50.211
<http://10.10.50.211> ; nested
exception is:
       java.net.ConnectException: Connection refused <@>
java.rmi.activation.ActivationException <@>
java.rmi.activation.ActivationException: unable to obtain ActivationSystem;
nested exception is:
       java.rmi.ConnectException: Connection refused to host: 10.10.50.211
<http://10.10.50.211> ;
nested exception is:
       java.net.ConnectException: Connection refused
       at
java.rmi.activation.ActivationGroup.getSystem (ActivationGroup.java:490)

Do i need to do set something for SUSE linux version ?

Regds
Happy Manocha


-----Original Message-----
From: Peter Jones - JavaSoft East [mailto:
<mailto:[email protected]> [email protected]]
Sent: Friday, September 30, 2005 12:14 PM
To: [email protected] <mailto:[email protected]>
Subject: Re: java.rmi.NoSuchObjectException: no such object in table


> If I have a server stub and I bind that stub to a local Registry, is
> that enough to keep it from being cleaned up by DGC?

It should be.  One case in which it currently isn't is when the
registry invocation is made on a registry remote object directly
instead of a stub for a registry (i.e. what's returned from
LocateRegistry.createRegistry instead of LocateRegsitry.getRegistry)
and the remote object's stub passed to the registry was returned from
RemoteObject.toStub or UnicastRemoteObject.exportObject; in this
situation, the following old bug thwarts reachability:

       http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4114579
<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4114579>

But invoking a registry stub (like LocateRegistry.getRegistry returns)
should avoid that problem, because the remote object's stub will get
marshalled and unmarshalled and thus properly registered with DGC.

> I seem to be getting the above exception from a client (on a heavily
> loaded and scaled system) and I'm not quite sure why. My server
> simply extends AbstractRemoteObject then in the ctor does something
> basically like this:
>
>         LocateRegistry.getRegistry( getLocalServicePort() ).rebind(
>             UnicastRemoteObject.toStub( this ) );

Bug 4114579 could come into play here too if the surrounding code is
such that the local garbage collector can determine that the variable
"this" is not used after the above code and the object it refers to is
eligible for garbage collection after the UnicastRemoteObject.toStub
invocation has completed, but before the Registry.rebind has
completed.  That might seem far-fetched, but we've seen that sort of
GC behavior with the Hotspot Server VM, since JDK 5.0, on
multiprocessor machines-- in particular, there is also this bug:

       http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6181943
<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6181943>

which could also affect the above code (regardless of 4114579).  We
haven't yet seen that bug occur with pre-5.0 JDK VMs, however.  Are
you using the Server VM?

But this would only "explain" garbage collection of the remote object
at the time of registry bind-- if it the collected remote object has
previously been looked up and invoked successfully, then the problem
must be something else; I'm not sure if that's what you meant by this:

> With ~1,000 servers, the client can get this stub and invoke methods
> on it with no problem. Looking at the server (i.e. agent) logs, all
> have been initialized and idle for at least an hour. Every once in a
> while we will see something like this:
>
>  Caused by: java.rmi.NoSuchObjectException: no such object in table

If so, then this shouldn't happen without removal or replacement of
the registry binding or DGC communication failure, which seems
unlikely.  Are these remote objects exported with custom client socket
factories?  Any other unexpected failures logged?

-- Peter

===========================================================================
To unsubscribe, send email to [email protected]
<mailto:[email protected]>  and include in the body
of the message "signoff RMI-USERS".  For general help, send email to
[email protected] <mailto:[email protected]>  and include in the
body of the message "help".

For a list of frequently asked RMI questions please refer to:
http://java.sun.com/j2se/1.3/docs/guide/rmi/faq.html
<http://java.sun.com/j2se/1.3/docs/guide/rmi/faq.html>

To view past RMI-USERS postings, please see:
http://archives.java.sun.com/archives/rmi-users.html
<http://archives.java.sun.com/archives/rmi-users.html>

===========================================================================
To unsubscribe, send email to [email protected]
<mailto:[email protected]>  and include in the body
of the message "signoff RMI-USERS".  For general help, send email to
[email protected]  <mailto:[email protected]> and include in the
body of the message "help".

For a list of frequently asked RMI questions please refer to:
http://java.sun.com/j2se/1.3/docs/guide/rmi/faq.html
<http://java.sun.com/j2se/1.3/docs/guide/rmi/faq.html>

To view past RMI-USERS postings, please see:
http://archives.java.sun.com/archives/rmi-users.html
<http://archives.java.sun.com/archives/rmi-users.html>





===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff RMI-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

For a list of frequently asked RMI questions please refer to:
http://java.sun.com/j2se/1.3/docs/guide/rmi/faq.html

To view past RMI-USERS postings, please see:
http://archives.java.sun.com/archives/rmi-users.html
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.