Cluster server

rjshelq · Post by **rjshelq** » Tue Dec 05, 2006 5:49 pm

So, it seems that the "extra" monitors need to be killed.

Is there any easy way that you can imagine to have the monitor, or some other new process, automatically kill the monitor, kill texis, and remove the shared memory if there has not been any search activity for a few minutes?

Post by **mark** » Wed Dec 06, 2006 10:34 am

Perhaps by watching the modify time of the shared mem.

Or, since the database monitor goes away automatically when there's no activity for a period of time, which is settable in texis.cnf, you could look for the database monitor (a monitor with a -z option on the command line). If it's not present there are no recent searches.

rjshelq · Post by **rjshelq** » Fri Dec 08, 2006 1:18 pm

Great, this approach is looking very promising.

Is there a reliable way to recognize which shared memory segments were created by Webinator? So, far I always see segment keys that begin with 0xdbac, then 0x17e4, and finally 0xb28a. Will the segment keys always begin with those same characters?

Is there any convenient signal from the initial startup of texis to start my daemon (which will evenutally kill the texis and monitor processes)?

Post by **mark** » Fri Dec 08, 2006 1:36 pm

Only the one key is predicatable. All others are random.
There's nothing to tell you when texis or monitor starts unless you write your own wrappers around them.

I don't see how any of this can help the situation you described. If monitor on machine starts at second 0 and stays running for 60 seconds and monitor on another machine starts at second 10 and stays running for 60 seconds there's a 50 second window where corruption can/will occur. Also remember that users are standing in line taking turns, you could have several or more users hitting the system at the same time. Each would be directed to a different machine by the load balancer. So you'd have a number of texis and monitor processes from multiple machines running at the same time and stepping on each others' disk data.

rjshelq · Post by **rjshelq** » Fri Dec 08, 2006 2:32 pm

From your earlier comments, it seemed that as long as the database operations are read only (which is what I thought searches would be), then there would not be any harmful interaction due to multiple monitors briefly "overlapping".

I have turned off the saving of queries, and plan to do only manual walks (during which time all cgi access to texis will be avoided by temporarily renaming the texis link in the cgi-bin so that no one can search until the walk is finished).

So, could you clarify your comment about "stepping on each others' disk data"? Can that happen during a search? Are there times other than query saving and site walks that the data can be corrupted?

Post by **mark** » Fri Dec 08, 2006 5:32 pm

You have to use <sqlcp singleuser on> (see the vortex manual) to make the search fully single-user. But there's still the issue of the global license, due to the shared install dir, which is always read-write. It *may* work to get a good license.key file then make it read-only. I'm not sure and haven't delved into the innards to find out.