Increasing the datasourcelife= will cause Witango to drop/create
datasource connections less. I've found on windows that the server runs
slightly better when it has to do less management of datasources (longer
life). But I still prefer to keep this number as low as possible since I
believe that refreshing the connections regularly is a good thing. Your
platform/software might have very different outcomes.

Robert

-----Original Message-----
From: Roland Dumas [mailto:[EMAIL PROTECTED] 
Sent: Friday, March 05, 2004 5:54 PM
To: [EMAIL PROTECTED]
Subject: Re: Witango-Talk: Crashes on OS X

My second urgent problem is increase in frequency of witango crashes.  
It is crashing now 4-6 times a day. Needless to say, all the variables  
are dumped as it restarts, losing user sessions, etc.

The crash log is very consistent. Always an IODBC thing going on. I  
look and there is absolutely no correlation with what was going on just

prior to the crash. Neither the web log nor the witango log shows  
anything like a pattern that could lead to an application, a database,  
a record, etc., and a mirror of the site runs as a test server and has  
not seen a single crash of this kind.

My current theory is that it's related to these kinds of events:

05/03/2004      01:23:59                                0
[Expired] ODBC datasource ridgerw

Expiry of datasources. Is it possible that something in that event  
could be tripping up witango? How does one change the expiry anyway? Is

that a value set somewhere?


On Feb 9, 2004, at 8:34 AM, Roland Dumas wrote:

> Can anyone tell me if this is evidence of RAM problems? The crashed  
> thread records tend to be rather consistent in what they're writing  
> and where they are writing it, as far as my uneducated eyes can tell.
>
>> On Feb 6, 2004, at 10:05 AM, Ben Johansen wrote:
>>
>>> Disclaimer: Not a Mac Guy ;-)
>>>
>>> This sounds a lot like a RAM module going bad.
>>>
>>> This can be intermittent for several reasons
>>> -the ram chip is fail intermittently
>>> -the failed location on the ram chip is in a high mem address and  
>>> only
>>> is reached under higher loads.
>>>
>>> One thing you can do when looking at those funny number is to see if

>>> you
>>> see a consistent funny number :)
>>
>> OK: you can tell me if this constitutes a consistent funny number. I

>> grabbed the crash log, clipped out the crashed thread and here are a

>> few. Definitely recurring numbers in the "in" (is that a memory  
>> location or something?)
>>
>> Thread 10 Crashed:
>>  #0   0x94f92e68 in _iodbcdm_driverload
>>  #1   0x94f94f64 in SQLDriverConnect
>>  #2   0x0016b8e0 in 0x16b8e0
>>  #3   0x00047570 in 0x47570
>>  #4   0x000685b8 in 0x685b8
>>  #5   0x00024ec0 in 0x24ec0
>>  #6   0x00025278 in 0x25278
>>  #7   0x0001949c in 0x1949c
>>  #8   0x00019e24 in 0x19e24
>>  #9   0x00017ac8 in 0x17ac8
>>  #10  0x0001a910 in 0x1a910
>>  #11  0x0014e09c in 0x14e09c
>>  #12  0x90020c28 in _pthread_body
>>
>>  Thread 2 Crashed:
>>  #0   0x94f92e68 in _iodbcdm_driverload
>>  #1   0x94f94f64 in SQLDriverConnect
>>  #2   0x0016b8e0 in 0x16b8e0
>>  #3   0x00047570 in 0x47570
>>  #4   0x000685b8 in 0x685b8
>>  #5   0x00024ec0 in 0x24ec0
>>  #6   0x00025278 in 0x25278
>>  #7   0x0001949c in 0x1949c
>>  #8   0x00019e24 in 0x19e24
>>  #9   0x0001830c in 0x1830c
>>  #10  0x0007cba0 in 0x7cba0
>>  #11  0x0009dd18 in 0x9dd18
>>  #12  0x0009d780 in 0x9d780
>>  #13  0x00019750 in 0x19750
>>  #14  0x00019e54 in 0x19e54
>>  #15  0x00017ac8 in 0x17ac8
>>  #16  0x0001a910 in 0x1a910
>>  #17  0x0014e09c in 0x14e09c
>>  #18  0x90020c28 in _pthread_body
>>
>>  Thread 14 Crashed:
>>  #0   0x94f92e68 in _iodbcdm_driverload
>>  #1   0x94f94f64 in SQLDriverConnect
>>  #2   0x0016b8e0 in 0x16b8e0
>>  #3   0x00047570 in 0x47570
>>  #4   0x000685b8 in 0x685b8
>>  #5   0x00024ec0 in 0x24ec0
>>  #6   0x00025278 in 0x25278
>>  #7   0x0001949c in 0x1949c
>>  #8   0x00019e24 in 0x19e24
>>  #9   0x00017ac8 in 0x17ac8
>>  #10  0x0001a910 in 0x1a910
>>  #11  0x0014e09c in 0x14e09c
>>  #12  0x90020c28 in _pthread_body
>>
>>  Thread 20 Crashed:
>>  #0   0x94f92e68 in _iodbcdm_driverload
>>  #1   0x94f94f64 in SQLDriverConnect
>>  #2   0x0016b8e0 in 0x16b8e0
>>  #3   0x00047570 in 0x47570
>>  #4   0x000685b8 in 0x685b8
>>  #5   0x00024ec0 in 0x24ec0
>>  #6   0x00025278 in 0x25278
>>  #7   0x0001949c in 0x1949c
>>  #8   0x00019e24 in 0x19e24
>>  #9   0x00017ac8 in 0x17ac8
>>  #10  0x0001a910 in 0x1a910
>>  #11  0x0014e09c in 0x14e09c
>>  #12  0x90020c28 in _pthread_body
>>
>>
______________________________________________________________________ 
>> __
>> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
>>
>
>
_______________________________________________________________________ 
> _
> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
>

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

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

Reply via email to