![]() 07:19 - SEVERE - Failed to initialize server object 'EEA/AirQualitySos': 0x80004005: Failure to access the DBMS server - Server Failure to access the DBMS server." - EEA/AirQualitySos.MapServer ![]() The base table definition string ""Airquality_"" is invalid. 07:18 - WARNING - "The Layer:'Airquality_' in Map:'Layers' is invalid. The base table definition string ""Airquality_E2a.DBO.%Network"" is invalid. 07:18 - WARNING - "The StandaloneTable:'Airquality_E2a.DBO.%Network' in Map:'Layers' is invalid. The base table definition string ""Airquality_E2a.DBO.%Observation"" is invalid. 07:18 - WARNING - "The StandaloneTable:'Airquality_E2a.DBO.%Observation' in Map:'Layers' is invalid. Check that the usage timeout is appropriately configured for such requests. 07:17 - SEVERE - Processing request took longer than the usage timeout for service 'EEA/AirQualitySos.MapServer'. I was able to react and keep the SOE up a little longer. In addition, the FutureTask pattern provided some additional insights. I could not connect via the SQL Server Management Studio. By chance I catched the right moment when the SOE got stuck and had the possibility to check the DB server. I am using MS SQL Server 2008 in our testing environment. It seems like that the database server hangs for unkown reason. It cannot be reproduced 100% - it happens from time to time at different queries.Īfter some testing (regular cache updates every 20 minutes / 10-15 parallel service requests every 15 minutes) I got some results. This might be a deadlock bug inside the COM object or related. No shutdown hook is executed, it is just killed. My conclusion is that AGS is shutting down the SOE instance the hard way (similar to "kill -9 " on UNIX). I never receive any more logs for this SOE instance - and a new one is created subsequently. The thread is "stuck" (even it is in RUNNABLE state) at that method for 1-3 minutes and than happens the magic (!!): All logs suddenly stop. M圜allingClass.pullData( M圜allingClass.java:142)Ĭom.evaluate(Unknown Source) The results are of one of the two following kinds:Ĭom.nativeVtblInvokeNative(Native Method)Ĭom.a(Unknown Source)Ĭom.vtblInvoke(Unknown Source)Ĭom.nextRow(Unknown Source) So I created an additional observer thread, that logs the thread's state and dumps its StackTrace to a file once it exceeds the 10 minute mark. That lead me to the consumption that there is probably something going wrong within the ArcObjects interaction. Not a single execution of this simulated workers crashed in the way described above. I did some additional testing, debugging and logging on this issue.įirst of all, I simulated some long running task with simple Thread.sleep() calls, making a scheduled thread work for more than 10 minutes three times per hour. Does someone have an idea of what could be done? May it be that ArcObjects or COM gets in the way somehow here? ![]() I ran out of ideas after the migration from ScheduledExecutorService to Quartz did not change anything. Though, the original scheduler thread (managed by Quartz) is in waiting mode, looking like the execution has finished successfully. I am catching RuntimeException and Throwable (logging, then re-throwing) already but nothing comes up in the AGS log files. The most dubious thing about this that not a single exceptions is being logged. ![]() It seems that from time to time the update job does not run until the end (file does not get updated, last logging statement is not executed). I now did some stress testing of this cache updates, making it run every 20 minutes and observing the timestamp of the files. These queries are scheduled once a day and dump the results into a file on the HDD, creating a fast-access cache of the results. My Java SOE (AGS 10.2) does a set of database queries (via IQueryDef) running in a scheduler thread (invoked via Quartz 2.2.1) that take a few minutes.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |