OnBase Client Scheduler (freezing)?

[Sheila_Shaver]

(OnBase 12.0.2.173)   I don't know if "freezing" is what is happening, but it isn't "started" and it isn't "stopped."

My issue starts out with my app/web server losing connection to the database.  I get a "System.Data.Odbc.OdbcException" Error in my Event Viewer - OnBase Log.  I then get 2 errors in the Event Viewer - Application Log.  They are "The connection to the database was lost - Database Error encountered:...".  The first one says that "An existing connection was forcibly closed by the remote host". The second one says "Communication lin failure".  I'm working on the reason for being disconnected from the database - I think it has to do with a new server backup procedure from our Networking/OPS dept.  My problem is with the way my Service is behaving...

When I check my "OnBase Client Scheduler" Service, it looks like it is running.  So, I tell the Service to <Stop>.  It takes 2 minutes and basically times-out.  I get "Could not stop the OnBase Client Scheduler service on Local Computer.  Error 1053:  The service did not respond to the start or control request in a timely fashion."  BUT - it now looks like the Service is Stopped.  Now I can "Start" the Service.  At this point everything will start getting caught up.  My sweeping, OCR, and barcoding.

In OnBase, my Service Configuration is "Automatic" with all of my additional switches.  My logon settings use a Service Account and I have the Service Dependencies:  "DCOM Server Process Launcher", "Event Log", "Remote Procedure Call (RPC), "Security Accounts Manager" and "Windows Management Instrumentation".  In Services, I have the "Recovery" set to "Restart the Service" for every failure after 1 minute.  My Service runs great and perfectly EXCEPT when I lose the database connection this way.  It's like the service just locks up.  If I lose the database connection (for less than a minute), should my Service even be affected?  If it is affected, shouldn't it know to stop - and then follow my rules for recovery?  Where is some more detailed documentation (or documentation I'm overlooking) on the -SERVICE switch?  I'm also running the -DUMP switch, but where is this log saved and what would it be called?  And would losing connection to the database be considered "unexpected termination"?

Would greatly appreciate any ideas / help.

Thank you!

[William_Howell]

I've seen the same thing. My understanding is that ODBC connections are not "self-healing" which means that once the db connection is interrupted even briefly, the ODBC connection is lost and cannot automatically be re-established until the service is restarted. The service isn't aware that the ODBC connection has been lost as that happens at a low layer of the protocol stack so the automatic restart settings won't help. In speaking with Hyland about this issue a year or so ago, they said they were investigating options but this is basically a Microsoft issue. If anyone can confirm this or has found a workaround, please pass it on By the way, we found some HP server based monitoring tools can cause this type of brief connection drop so you might experiment with turning off monitoring for a few days or make sure you have the latest version of those tools and NIC card drivers.

[quote user="Sheila Shaver"]

(OnBase 12.0.2.173)   I don't know if "freezing" is what is happening, but it isn't "started" and it isn't "stopped."

My issue starts out with my app/web server losing connection to the database.  I get a "System.Data.Odbc.OdbcException" Error in my Event Viewer - OnBase Log.  I then get 2 errors in the Event Viewer - Application Log.  They are "The connection to the database was lost - Database Error encountered:...".  The first one says that "An existing connection was forcibly closed by the remote host". The second one says "Communication lin failure".  I'm working on the reason for being disconnected from the database - I think it has to do with a new server backup procedure from our Networking/OPS dept.  My problem is with the way my Service is behaving...

When I check my "OnBase Client Scheduler" Service, it looks like it is running.  So, I tell the Service to <Stop>.  It takes 2 minutes and basically times-out.  I get "Could not stop the OnBase Client Scheduler service on Local Computer.  Error 1053:  The service did not respond to the start or control request in a timely fashion."  BUT - it now looks like the Service is Stopped.  Now I can "Start" the Service.  At this point everything will start getting caught up.  My sweeping, OCR, and barcoding.

In OnBase, my Service Configuration is "Automatic" with all of my additional switches.  My logon settings use a Service Account and I have the Service Dependencies:  "DCOM Server Process Launcher", "Event Log", "Remote Procedure Call (RPC), "Security Accounts Manager" and "Windows Management Instrumentation".  In Services, I have the "Recovery" set to "Restart the Service" for every failure after 1 minute.  My Service runs great and perfectly EXCEPT when I lose the database connection this way.  It's like the service just locks up.  If I lose the database connection (for less than a minute), should my Service even be affected?  If it is affected, shouldn't it know to stop - and then follow my rules for recovery?  Where is some more detailed documentation (or documentation I'm overlooking) on the -SERVICE switch?  I'm also running the -DUMP switch, but where is this log saved and what would it be called?  And would losing connection to the database be considered "unexpected termination"?

Would greatly appreciate any ideas / help.

Thank you!

[Eric_Hyde]

I used to see the same thing, when running OnBase v11, but since upgrading to v13, the Scheduler service stops with errors written to Windows System and Application logs. I typically see this type of problem when running maintenance on our SQL server, so I've set the Windows Scheduler service to restart after 30 minutes, and to continue to retry, indefinitely. The Scheduler service now stops during SQL maintenance, but successfully starts once the maintenance is complete.

Of course, you might not want to wait 30 minutes between service restart attempts, but that's what works in our environment.