[Spread-users] Sess_recv_client_auth: BUG! Session is alreadyauthorized (status 0x1)

[Dave Parker]

Jonathan Stanton wrote:
> 
> Can you give me a basic idea of how you are doing "connections really fast"
> as this is the first report I've seen of this. The 'Bug!' is because this
> is sanity checking code that should never trigger.

Sure.

I've set up an agent that's listening for messages.  The messages
contain shell commands.  When the agent receives the message it forks a
process which obtains a new connection, executes the shell command, and
sends a message back to the original sender (of the command message) via
the new connection, then the child disconnects/exits.

I wrote a client program that lets me send commands to said agent.  I
give it a shell command to execute, and it does this:

1) Gets a connection
2) sends a message to the group the agent is listening to
3) waits for a response
4) loop to 2)

I run about five or so of these clients simultaneously (or try to).

So the jist is that the agent ends up forking of a ton of children that
in turn make connections and send messages.

I'm using two physical machines (one for the agent, one for the multiple
clients).

Now, you'll recall that in my first message I mentioned "some other
thing" that I'm seeing.  The "some other thing" *looks* like at some
point the client is not receiving a reply from the agent (and is thus
hanging).  The spread server on the box on which the agent is running
continues to run OK.  In attempting to figure out what was going on with
that, I restarted the client programs several times.  After some
repetition of all that I got the "already authorized" message.


There's an aspect to the way the agent operates that's a bit vague to me
and may shed some light: I've written a Perl class that wraps a lot of
the stuff in the Perl library, and I use instances of that class as my
program's interface to the Spread connection.  The class in question has
a destructor that shuts down the connection.

Now, when the agent parent process forks, it's forking instances of the
parent's connection object as well.  I'm not *using* that object, but
it's in the forked process, and when the child dies the destructor gets
called.  Could I potentially be getting into trouble with this?

> I assume you are not using any of the special authentication modules, just
> the default allow all behaivor?