Mantis - Resin
Viewing Issue Advanced Details
4708 major random 08-11-11 05:00 02-27-13 16:15
georgbuschbeck  
alex  
normal  
closed 4.0.20  
fixed  
none    
none 4.0.36  
0004708: sticky session
Hi,

we are using mod_caucho on debian lenny (amd64) with apache2.2 latetly we have recognized that our sessions appear to not be sticky to one of our resin instances anymore, we tested first with 4.0.18, and now with 4.0.20, but the behaviour didn't change, still from time to time the session is switched to the other resin instance. with no obvious reason.

how do i get more debugging info here?

Notes
(0005449)
uweschaefer_   
08-18-11 13:37   
Is there else anything we can provide? As a long-time paying customer, we are quite frustrated with our production system being extremely fragile.# due to random server switches.
session replication as a workaround is impractical due to different physical locations.

we're desperate.
(0005450)
ferg   
08-18-11 16:14   
When filing a bug as a paying customer, please also send a mail to the support address so we can increase the priority. Otherwise the bug report looks like an open-source report.

The mod_caucho should only failover if it cannot connect to the backend Resin instance. (The mod_caucho code hasn't changed in a long while.)

Can you send the server and load-balance timeout parameters? mod_caucho reads those from the backend server to see what values to use for a timeout.
(0005451)
ferg   
08-18-11 16:36   
Checking the code, the key parameters are

load-balance-connect-timeout
load-balance-socket-timeout
load-balance-idle-time

keepalive-timeout
socket-timeout

(also keepalive-max).

mod_caucho's view of the values should be displayed in /caucho-status
(0005452)
ferg   
08-18-11 17:25   
Also, the /resin-admin graphs (in the "meters" tab of the summary) might show unusual netstat behavior or other glitches like a memory spike.
(0005453)
ferg   
08-18-11 18:37   
As a test, you might try lowering load-balance-idle-time to 30s instead of the default 60s. (And check the netstat history). That would test the possibility of a timing issue without affecting performance much.
(0005454)
uweschaefer_   
08-19-11 04:39   
thanks for the hints, scott.

config everywhere is

connect timeout : 5
idle time: 60
recover : 15
socket timeout : 600

frontend apache2 has

KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15

no keepalives defined in resin.

we can reproduce the behavior internally, so it does not look like being connected to high load.
(0005455)
ferg   
08-19-11 09:04   
If you can reproduce it in the lab, can you set the logging to "fine" or "finer" on both backend Resin instances, and mail the jvm-default logs?
 
BTW, it's the Resin keepalive that matters (because this is the mod_caucho to Resin link). The Apache one doesn't matter.

The http://caucho.com/resin-4.0/admin/clustering-overview.xtp [^] page has a diagram showing the load balancing timings.

Also, the JMX for the resin:type=Port,name=XXX-6800 will show the SocketTimeout and KeepaliveTimeout.

Our load testing wasn't able to show any problems, though.
(0006204)
alex   
02-27-13 16:15   
can't reproduce