We have a daemon that restarts witango when it crashes. Very efficient.
Since the crashes aren't associated with transactions, we don't end up with
database corruption from them. We do, however, lose user sessions. When
witango restarts after a crash, the first thing it does is expire all the
user sessions. On average, there are 10-20 active shopping carts with
$30-2000 in them. So management views a crash as that much lost sales if the
customers don't try again, or annoying that many loyal customers when they
do re-create their shopping carts.


On 3/3/05 11:56 AM, "Bill Conlon" <[EMAIL PROTECTED]> wrote:

> Roland,
> 
> While it's not ready for a public release, you might be able to use my
> witango_watch daemon to help out.
> 
> I built this to overcome the bug in startupurl (witango can't issue a
> url to itself, so you can't use startup url to initialize your apps).
> 
> But you can use this for anything that's in the witangoevents.log, like
> DSN expirations, or custom log messages that you write.
> 
> bill
> On Thursday, March 3, 2005, at 11:20  AM, Roland Dumas wrote:
> 
>> Ok, not yet figured out why one machine clone crashes while the other
>> doesn't, but am trying to patch each part of ODBC without taking
>> production
>> machine out of service. (It's a very productive ecommerce site)
>> 
>> What we've figured out:
>> 
>> When witango gets a hit that requires a connection to mysql, it looks
>> for an
>> available connection using that DSN. If it's available, it uses it.
>> 
>> If there are current connections, but they're busy, it spawns another
>> 
>> A pile of hits at the same moment creates a small stack of data
>> connections.
>> Up to 8.
>> 
>> Subsequently, when traffic is slower, witango picks one of the data
>> connections and lets the others age. Don't know how it picks one vs
>> another,
>> but that's what it does. That leaves the others aging out and should
>> expire
>> when they hit the datasourcelife setting.
>> 
>> That's where the trouble comes. Rather than die, the connections get
>> hung
>> up, cause CPU usage to jack up, eventually cause new hits to get hung
>> and
>> the witango server crashes. When they're tied up, they aren't
>> available to
>> be used, but are technically alive, I guess, because if witango has
>> selected
>> one of those, visitors get hung up.
>> 
>> So, after updating this piece and that piece of ODBC, it still does
>> the same
>> thing and JDBC has its own profile of random crashes.
>> 
>> So, while we sift though the finger-pointing and terse instructions,
>> we've
>> jury rigged a way to prevent crashes.
>> 
>> On another witango server, we've created a cron to hit the sick server
>> every
>> hour with 8 <@URL>s that each hit a database. That makes sure that the
>> 8
>> connection requests are simultaneous and generate 8 connections. The
>> connections are alive, but aging, these 8 refresh them all. The
>> counter goes
>> back to 1.
>> 
>> Then, we set the datasource life to 24 hours. That gives the cron 24
>> opportunities to restart the timer on every datasource.
>> 
>> Seems to be working.
>> 
>> Net net: if datasource expiry is causing crashes, don't ever let one
>> expire.
>> 
>> 
>> 
>> 
>> 
>> 
>> -----------------------------------------
>> Roland Dumas
>> Roberts Information Services
>> 310 W. Bellevue Avenue
>> San Mateo CA 94402
>> 650-347-1373
>> 415-412-9300 (cell)
>> [EMAIL PROTECTED]
>> SMS: http://new.servqual.com/html/sms.tml
>> 
>> 
>> _______________________________________________________________________
>> _
>> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
>> 
> 
> ________________________________________________________________________
> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
> 


-----------------------------------------
Roland Dumas
Roberts Information Services
310 W. Bellevue Avenue
San Mateo CA 94402
650-347-1373
415-412-9300 (cell)
[EMAIL PROTECTED]
SMS: http://new.servqual.com/html/sms.tml


________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf

Reply via email to