Bug 46284 - Add flag to DeltaManager that blocks processing cluster messages until local applicaiton initialization is completed
Summary: Add flag to DeltaManager that blocks processing cluster messages until local ...
Status: RESOLVED WONTFIX
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Cluster (show other bugs)
Version: 6.0.18
Hardware: All All
: P2 enhancement (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-11-24 17:28 UTC by Jason A. Lunn
Modified: 2017-06-01 12:31 UTC (History)
1 user (show)



Attachments
A multi-file patch that includes changes that allow DeltaManager to block processing of cluster messages until local application initialization is complete (11.76 KB, patch)
2008-11-24 17:28 UTC, Jason A. Lunn
Details | Diff
A multi-file patch that includes changes that allow DeltaManager to block processing of cluster messages until local application initialization is complete (12.47 KB, patch)
2008-12-09 06:49 UTC, Jason A. Lunn
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jason A. Lunn 2008-11-24 17:28:21 UTC
Created attachment 22928 [details]
A multi-file patch that includes changes that allow DeltaManager to block processing of cluster messages until local application initialization is complete

Suggested enhancement to DeltaManager that allows a configuration element to control whether incoming cluster messages should be blocked until after local applications are done initializing.

The idea is that there exist some web applications (I know of at least one commercial app [that I happen to support during working hours]) that, when deployed on a cluster with session replication, fails when the cluster is implemented with Tomcat but works fine when using other application containers.

The inspiration for this enhancement is a comment from the vendor's engineering support, who tell me that other application containers (WebSphere and WebLogic, at least) initialize local applications before beginning to process session replication messages from the cluster.

The attached patch gives the Tomcat user the option of continuing to begin processing session replication messages from the cluster immediately (the default), or block processing those messages until local applications have completed initialization.
Comment 1 Filip Hanik 2008-12-08 08:13:30 UTC
Here is some feedback:

1. The formatting gets somewhat messed up, there are tabs in the patch.

2.      public void messageDataReceived(ClusterMessage cmsg) {
+    	// Block processing until local application initialization has
+    	// completed, if a gate has been erected
+    	if(gate != null) {
+    		try {
+    			gate.await();
+    			gate = null;
+    		}
+    		catch(InterruptedException e) {
+    			log.error(e, e);
+    		}
+    	}
+

This will pose a problem since it blocks the messaging threads. Other applications running would suffer since you are now holding on to threads that are supposed to deliver replication messages in other parts of the system.

3. openContainerGates
Does this happen all at once after all the apps are finished. (Am I reading it correct?).
a container gate should be opened immediately after a context has finished initialization. regardless of what other applications/containers are doing.

4. the 'gate' variable would have to be volatile, since the thread that is creating the gate is different from the thread that is reading it, and the non null gate might not have yet become visible.

Comment 2 Jason A. Lunn 2008-12-09 06:49:48 UTC
Created attachment 23005 [details]
A multi-file patch that includes changes that allow DeltaManager to block processing of cluster messages until local application initialization is complete

Revised per Filip's feedback:

1. added volatile keyword to declaration of variable 'gate'
2. synchronized the null check and assignment of 'gate'
3. -- Nothing done here yet, the intention of the current design is to block all incoming session replication messages from being processed until all local applications have been initialized.
4. removed tabs
Comment 3 Mark Thomas 2017-05-31 10:32:01 UTC
I've been looking through the Tomcat code and the essential behaviour appears to be the same all the way back to 6.0.18 (it did change in 6.0.18 in a way that looks to be helpful to the use case).

The session state is transferred when the Manager is started. As of 6.0.18, the ServletContainerInitializers (for 7.0.x onwards) and ServletContextListeners are triggered before the state transfer is started. The only application initialisation that has not been completed at this point is starting the filters and the loadOnStartup Servlets.

While it should be possible to swap the order of the Manager start, Filter initialisation and loadOnStartup Servlet processing, I can't think of a good reason that justifies one order over another. The important order for me is the SCI and SCL vs Manager start and that is already the 'right' way around for the use case described in this bug report.

Therefore, I am resolving this as WONTFIX. If we revisit this, my instinct is to look at simply delaying the request state transfer although that looks much easier for the DeltaManager than the BackupManager.
Comment 4 Jason A. Lunn 2017-06-01 12:31:17 UTC
After over 8 and a half years I have long since stopped being invested in the outcome of this issue.