I have worked through various issue with oracle, not just with
witango. Have you tried making the connection through ODBC to oracle?
I am betting you won't see much of a performance hit, if at all
noticeable.
Setting dstimeout to 0, will force witango to NOT cache connections
at all, and immediately close, which is why it was worse.
If you set the service to restart at midnight, then set the timeout
to 1440 (24 hours) so it will never close a connection, and make sure
you set persistant restart to true, so the service reloads any
variables on restart. I have had to set timeout to 1440, and I think
in your situation, it would be better, cuz you don't want it to EVER
close a connection.
I am guessing you could also set your cron to reset service more than
just at midnight, have it check activeQryThr, and only reset when
zero, and with persistentrestart to true, should be pretty quick and
unnoticable, so you maybe you could pick 2 or 3 times during day,
that you know have less traffic. If you have a startupurl that takes
a while to run, then it would be noticable, cuz your users would see
"server starting up error" for a bit.
--
Robert Garcia
President - BigHead Technology
VP Application Development - eventpix.com
13653 West Park Dr
Magalia, Ca 95954
ph: 530.645.4040 x222 fax: 530.645.4040
[EMAIL PROTECTED] - [EMAIL PROTECTED]
http://bighead.net/ - http://eventpix.com/
On Jul 11, 2005, at 2:41 PM, Erik Gorka wrote:
In taking the time to look at it, it seems to be paying attention
to the data source timeout after all, but fails to close a
connection when the time out should occur. This means that low time
out settings result in a far greater number of open sessions as new
ones are spawned to replace supposedly obsolete ones.
In tests we tried setting the data source time out to 0, which
exploded the number of open sessions. New connections were spawned
as quickly as apps were opened and used. High settings reduce the
rate of proliferation considerably, but doesn't stop it.
As a result, we've taken to setting a one hour data source time
out and using cron to restart the Witango process every night. We
may need to restart more often as usage increases, but we'll have
to see how it goes. I'm at a college and with students away for the
summer its difficult to tell what the needs will be.
Seems like a server bug to me.
Erik Gorka
Reed College
Portland, OR
On Jul 7, 2005, at 3:30 PM, MC Tay wrote:
Yes... we are experiencing the same problem for quite awhile.
Repeatedly reporting the problem to the WiTango support group but
not getting any solution from them. It did the same thing on
previous releases not just 5.5.009. We run it against Oracle 9i on
Windows 2003. Hope we can get a solution to the problem too. It's
quite annoying that we have to keep restarting WiTango service
everyday to prevent it from crashing when it hits a thread level
of about 40-50.
M.C. Tay
At 03:00 PM 7/7/2005, you wrote:
Does anyone have problems with Witango not timing out Oracle
sessions
properly? We're running Witango 5.5.009 under Mac OS X 10.3 using an
Oracle OCI connection (have tried multiple versions, both 8.x and
10.1.03.) going to both Oracle 9 and Oracle 10 databases. Witango
Server seems to be ignoring the data source timeout setting and
never
kills a session. This is causing problem were the database will
disconnect from the server when it hits its maximum number of
connections, requiring a restart of Witango to fix.
We do not know how long this has been going on. We just started
noticing it recently because we just put into production an Oracle
10i database and the connection would keep shutting down. Our
previous database that is still in use is Oracle 9i, but we believe
the problem is there as well but simply went unnoticed because the
connections to that server go through a firewall and the firewall
itself has been timing out inaction connections. For all we know
this
has been an issue with previous versions of Witango as well.
Any thoughts or possible fixes? Is this a bug in the server software
or something else?
Erik Gorka
____________________________________________________________________
____
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
