>> (-DOPENSSL_THREADS). I recompiled Pound-current using the
static[...][...]

I used the complete absolute pathnames to the newly compiled libraries
in the Makefile to make sure ...
[...]

As far as I know, there is no way you could bind to the same port
twice ... And additionally, *both* messages come from the same (and
only) pound process. They could come from alternating threads (I
don't know the internal structure of pound), but pound is only running
once, listening to Port 443 (the other pound instance listening on
port 80 was not running during these tests)
[...]

The DNS setup is very simple, I can't see any problem there. And I
know, that all request are sent with the same IP-Address, since I can
watch the requests with ethereal on both hosts (client and server).
I know, it sounds absolutely weird, but there it is :-/
[...]

Hmm. I am running the setup on two systems: The live System, which is
a virtual server on vserver.de, which will be moved over to a
dedicated server as load increases, and a local test setup using UML
(UserMode Linux). Both are Linux 2.4.* kernels, and as far as I can
see, both use pthreads. How do I find out, if I'm using NPTL?
[...]

Certainly, Stefan.

PS: I'll continue my testing. May be, I can find out some more
informations ...
[...]

> Are you by any chance using NPTL? If yes, please check the list
archives[...]

Hmm, thinking about threading / synchronization problems, i
stress-tested my setup using several hundred almost parallel
wget-requests in an endless loop. This die not produce any failure.

I captured several additional traffic logs but could not find any
indication for a solution. I only found out, that it *has* something
to do with timing: if I set opera to use only one concurrent network
connection, everything works fine. If however I than press the reload
button several times in fast succession, I can force the error.

I really could not find any difference between the wget traffic and
the opera traffic, however I did not dissect the SSL messages and
compared those. I just compared the timing characteristics and SSL
handshaking. 

So, not really any new information, but maybe it helps. Is there
anything else, I could do? At what strategic places in the pound
source could I add debugging messages to further pin down the
Problem. Are there any thread-locks to monitor or things like that?

Thank you, for your patience ...  :-/

Stefan.
[...]

I have been thinking about this problem and think, I have an idea for
the source of the observed behavior.

A quick search in the internet showed me, that SSL has the concept of
resumable sessions designated by a random session id. I would assume,
that the error occurs because of synchronization failures between
several threads when a client requests a specific session id from a
prior connection.

I assume, that Konqueror would not reuse any session id's. Therefore
the Problem does not occur. The other browsers however do reuse the
session id's extensively.

I find the alternating behavior described in one of my previous mails
very suggestive: opera receives a session id and receives an '503
Internal Error' (no backend). This is a HTML failure, not a SSL
failure, so the session id is still valid. On the next request, opera
reuses the session id and this produces a 'session id context
uninitialized' and a premature close of the connection. This error
invalidates the session id to opera and therefore the next request
will request a new session id. This succeeds on the SSL level and
returns '503 Internal Error' and so on.

So this would describe the observed behavior very well. Now the
question is, why I have this problem. If it is threading related
(which I assume because of the time dependent behavior of the
problem), it could be a Problem with the two virtualization engines
used. I will test the pound installation on a dedicated,
non-virtualized system to check.

As in my last mail, I ask, whether there are other possible ways to
find out more about this problem.

Stefan.
[...]

> question is, why I have this problem. If it is threading related[...]

I just did this test. I have the same problem on my standard
workstation (running Debian testing/unstable on a patched grsec 2.4.24
kernel).

Another thing I found is, that the error is *not* timing
dependant. The timing dependent behavior only occurred, because
repeatedly pressing reload will interrupt the previous transfers in
some (random) place, and since the page did still contain references
to css files, a reload would always trigger several
connections. Depending on exactly when the reload was triggered, the
error would occur or not.

I am now certain, that this error does occur alternatingly every
second request. I used ethereal to check the session id's and found
the expected behavior:

  ReqNo  client       server       comment

  1      --           (sess-id-1)  HTTP Response 503
  2      (sess-id-1)  --           session id context uninitialized (connection
closed)
  3      --           (sess-id-2)  HTTP Response 503
  4      (sess-id-2)  --           session id context uninitialized (connection
closed)

  u.s.w.

client is the session id sent to the server or -- if none is
sent. server is the session id sent back by the server or -- if
none. Comment is the outcome of the connection request. During this
test, the timing of the request was irrelevant. Therefore I assume,
the timing related behavior seen was due to the number of requests
having occurred when reload was initiated.

I hope this information will help to pin down the problem. I will now
recompile pound on my workstation and check again.

Stefan.
[...]

On Fri, 2004-04-23 at 01:08, Stefan Bund wrote:[...]

Have a look at pound.c, ~line 240. The l_init() and l_lock() functions
are OpenSSL-specific synchronisation functions.[...]

Robert Segall <roseg(at)apsis.ch> writes:[...]

Thats what i suspected. Presumably the change happened in the 0.9.6 ->
0.9.7 migration? I seem to remember, that openssl is quite known for
breaking compatibility with each release ... I think, FedoreCore 1 has
rpm's for about every openssl version around :-/
[...]

I'll check as soon as I have some Time to spare ... I have to catch up
some other work, the quest for this bug has taken rather long :-)

Stefan