[6745] does not connect to default agent

Setup: RHEL3, TC6745, mysql 5
Installed into fresh directories and the only files copied over from a previous install
(6692) were the project config files, database.properties, license.keys and version.dat. Also, created a new database.

Installed the new build and cannot get the server to successfully show the
default agent as connected, even though pings are successful, and a message
showing that an upgrade of the agent will occur. When XMLRPC debug is on
I can see the exchange of messages, but still no successful connection.

Also, I can see messages for the server trying to ping an agent that it should not
know about (from a previous installation) and I'm stumped - I cannot find out where
the server finds information about this agent (tried config files, the database no dice).

I've also tried to stop the agent, rename it and restart, and the registration is
succssful as a new agent with the new name and port but the agent does not
change status to connected even though it runs locally.

Any clues please? I've upgraded the software as our previous installation started
to exhibit problems (we could not connect to the server although it was running,
there were messages about shutting down the http server, although no one actually
had done it). Anybody knows if I can turn logging to a level more detailed than
DEBUG as there's no information in the log that provides a hint.


Cheers,

Bonny

4 comments
Comment actions Permalink

Hello,

Is it possible that you have an old agent running and using the same port
which is configured for the new agent? Try to change port of the new agent.
If it is not the case please send us logs of the server and agent for deeper
investigation.

--
Pavel Sher
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"



"Bonny Rais" <bonnyr@optushome.com.au> wrote in message
news:19254856.1204605215565.JavaMail.itn@is.intellij.net...

Setup: RHEL3, TC6745, mysql 5
Installed into fresh directories and the only files copied over from a
previous install
(6692) were the project config files, database.properties, license.keys
and version.dat. Also, created a new database.

>

Installed the new build and cannot get the server to successfully show
the
default agent as connected, even though pings are successful, and a
message
showing that an upgrade of the agent will occur. When XMLRPC debug is on
I can see the exchange of messages, but still no successful connection.

>

Also, I can see messages for the server trying to ping an agent that it
should not
know about (from a previous installation) and I'm stumped - I cannot find
out where
the server finds information about this agent (tried config files, the
database no dice).

>

I've also tried to stop the agent, rename it and restart, and the
registration is
succssful as a new agent with the new name and port but the agent does not
change status to connected even though it runs locally.

>

Any clues please? I've upgraded the software as our previous installation
started
to exhibit problems (we could not connect to the server although it was
running,
there were messages about shutting down the http server, although no one
actually
had done it). Anybody knows if I can turn logging to a level more detailed
than
DEBUG as there's no information in the log that provides a hint.

>
>

Cheers,

>

Bonny



0
Comment actions Permalink

Pavel,

There was no old agent still running and the port was definitely not being used.
I had to restart the server to the chagrin of one of my collegues :) The problem
disappeared once the server got restarted so I do not know what happened there.

Also, where, other than the database, is information about agents stored?
is it only in the db and by way of agents actually connecting? As mentioned,
I had the server attempting to ping an agent that is on my machine, which was
definitely turned off, and I could not find out how the server got to find out about
this agent.

Bonny

0
Comment actions Permalink

Hello,

All information about agents stored in database only. When server shuts down
it marks all of the agents as unregistered (disconnected). Then when server
starts agents may become connected only if they initiate communication with
server. This means that server may attempt to ping an agent only if it is up
and running. That is why I asked you to check whether an old agent is
running. So server pings agents in two cases:
- when agent registers on the server (to detect that agent is not covered by
firewall)
- periodically after the registration server pings all of the currently
registered/connected agents to detect which agents became disconnected


--
Pavel Sher
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"



"Bonny Rais" <bonnyr@optushome.com.au> wrote in message
news:28498913.1204635091197.JavaMail.itn@is.intellij.net...

Pavel,

>

There was no old agent still running and the port was definitely not being
used.
I had to restart the server to the chagrin of one of my collegues :) The
problem
disappeared once the server got restarted so I do not know what happened
there.

>

Also, where, other than the database, is information about agents stored?
is it only in the db and by way of agents actually connecting? As
mentioned,
I had the server attempting to ping an agent that is on my machine, which
was
definitely turned off, and I could not find out how the server got to find
out about
this agent.

>

Bonny



0
Comment actions Permalink

Pavel,

Thanks for the reply. Your suggestion was correct after all, and there was an
instance of an agent running on my machine. However, this may point to a bug
in the way the service is implemented, since the service process itself was not
running, but it's child process was (which showed up as java.exe in Task Manager,
and the actual executable representing the service was not running at all).

Also, my agent is configured to report an ownPort of a certain value (23232), and
the server uses a different but adjacent port to try and connect to it? Isn't the
configured port the only one I need to worry about in terms of setting firewall rules?
If not, what are the rules used by the server to try and connect back to the agent?

I am using the ownAddress and ownPort to allow me to connect to the TC server
over an SSH tunnel. In previous builds this worked reasonably well, but not in the
last two builds...

Cheers,

Bonny

0

Please sign in to leave a comment.