Seems “normal” in the sense that it is trying to connect but it cannot. Creating an OSC makes a cursor to the DB which usually ends up being a file on disk and can run into ulimits. At some point, maybe, resources will be relinquished so it keeps waiting.
You can: 1) Find out if your cursors are real and needed. If they are not, you need to be closing your OSC with an explicit dispose so they don’t linger. 2) Raise your ulimit if you have a healthy number of cursors open that is not a leak and you need more than defaults allow. The ulimit is a stop gap to stop you from having a system that falls apart. It’s a check of sorts.. AARON ROSENZWEIG / Chat 'n Bike <http://www.chatnbike.com/> e: aa...@chatnbike.com <mailto:aa...@chatnbike.com> t: (301) 956-2319 > On Jun 29, 2020, at 10:32 AM, ocs--- via Webobjects-dev > <webobjects-dev@lists.apple.com> wrote: > > Oh, and there's one related question. > > It seems to me particularly weird that if sockets caused by the stale OSCs > exceed the ulimit, the threads which use these sockets hang. Is that the > normal and presumed behaviour? I would expect myself an exception thrown > instead, or something like that. Nevertheless, that's not what happens; those > threads are simply stuck in reading from the database forever, like this > (jstack output): > > === > Thread t@37443: (state = IN_NATIVE) > - java.net.SocketInputStream.socketRead0(java.io.FileDescriptor, byte[], > int, int, int) @bci=0 (Compiled frame; information may be imprecise) > - java.net.SocketInputStream.read(byte[], int, int) @bci=84, line=129 > (Compiled frame) > - java.net.SocketInputStream.read() @bci=23, line=182 (Compiled frame) > - java.io.FilterInputStream.read() @bci=4, line=66 (Compiled frame) > - com.frontbase.jdbc.FBJSocket.readInt() @bci=4 (Compiled frame) > - com.frontbase.jdbc.FBJSocket.checkForSecureCommunication() @bci=1 > (Interpreted frame) > - com.frontbase.jdbc.FBJConnection.createConnection() @bci=709 (Interpreted > frame) > - com.frontbase.jdbc.FBJConnection.<init>(com.frontbase.jdbc.FBJURL) > @bci=116 (Interpreted frame) > - com.frontbase.jdbc.FBJDriver.connect(java.lang.String, > java.util.Properties) @bci=22 (Interpreted frame) > - java.sql.DriverManager.getConnection(java.lang.String, > java.util.Properties, java.lang.ClassLoader) @bci=210, line=582 (Interpreted > frame) > - java.sql.DriverManager.getConnection(java.lang.String, > java.util.Properties) @bci=7, line=154 (Interpreted frame) > - com.webobjects.jdbcadaptor.JDBCContext.connect() @bci=251, line=236 > (Interpreted frame) > - er.extensions.jdbc.ERXJDBCAdaptor$Context.connect() @bci=29, line=404 > (Interpreted frame) > - com.webobjects.jdbcadaptor.JDBCContext._tryConnect() @bci=55, line=362 > (Interpreted frame) > - com.webobjects.jdbcadaptor.JDBCContext._channelWillOpen() @bci=8, line=505 > (Interpreted frame) > - com.webobjects.jdbcadaptor.JDBCChannel.openChannel() @bci=17, line=111 > (Interpreted frame) > - > com.webobjects.eoaccess.EODatabaseContext._openChannelWithLoginPanel(com.webobjects.eoaccess.EODatabaseChannel) > @bci=19, line=1907 (Compiled frame) > - com.webobjects.eoaccess.EODatabaseContext._obtainOpenChannel() @bci=62, > line=1966 (Compiled frame) > - > com.webobjects.eoaccess.EODatabaseContext._objectsWithFetchSpecificationEditingContext(com.webobjects.eocontrol.EOFetchSpecification, > com.webobjects.eocontrol.EOEditingContext) @bci=209, line=3054 (Compiled > frame) > - > com.webobjects.eoaccess.EODatabaseContext.objectsWithFetchSpecification(com.webobjects.eocontrol.EOFetchSpecification, > com.webobjects.eocontrol.EOEditingContext) @bci=34, line=3195 (Compiled > frame) > - > com.webobjects.eocontrol.EOObjectStoreCoordinator.objectsWithFetchSpecification(com.webobjects.eocontrol.EOFetchSpecification, > com.webobjects.eocontrol.EOEditingContext) @bci=97, line=488 (Compiled frame) > - > com.webobjects.eocontrol.EOEditingContext.objectsWithFetchSpecification(com.webobjects.eocontrol.EOFetchSpecification, > com.webobjects.eocontrol.EOEditingContext) @bci=79, line=4069 (Interpreted > frame) > - > er.extensions.eof.ERXEC.objectsWithFetchSpecification(com.webobjects.eocontrol.EOFetchSpecification, > com.webobjects.eocontrol.EOEditingContext) @bci=10, line=1308 (Interpreted > frame) > - > com.webobjects.eocontrol.EOEditingContext.objectsWithFetchSpecification(com.webobjects.eocontrol.EOFetchSpecification) > @bci=3, line=4444 (Interpreted frame) > - > er.extensions.eof.ERXEOGlobalIDUtilities.fetchObjectsWithGlobalIDs(com.webobjects.eocontrol.EOEditingContext, > com.webobjects.foundation.NSArray, boolean) @bci=325, line=290 (Interpreted > frame) > - > er.extensions.eof.ERXEOGlobalIDUtilities.fetchObjectsWithGlobalIDs(com.webobjects.eocontrol.EOEditingContext, > com.webobjects.foundation.NSArray) @bci=3, line=229 (Interpreted frame) > - > er.extensions.eof.ERXEOGlobalIDUtilities.fetchObjectWithGlobalID(com.webobjects.eocontrol.EOEditingContext, > com.webobjects.eocontrol.EOGlobalID) @bci=9, line=209 (Interpreted frame) > - > er.extensions.eof.ERXEOGlobalIDUtilities$fetchObjectWithGlobalID.call(java.lang.Object, > java.lang.Object, java.lang.Object) @bci=18 (Interpreted frame) > - others.ImportCSVTask.performAction() @bci=437, line=229 (Interpreted frame) > - er.extensions.concurrency.ERXLongResponseTask$DefaultImplementation.run() > @bci=25, line=166 (Interpreted frame) > - java.lang.Thread.run() @bci=11, line=695 (Interpreted frame) > - er.extensions.concurrency.ERXLongResponseTask$WorkerThread.run() @bci=1, > line=64 (Interpreted frame) > === > > Thanks for any insight, > OC > >> On 29. 6. 2020, at 4:12 PM, ocs--- via Webobjects-dev >> <webobjects-dev@lists.apple.com <mailto:webobjects-dev@lists.apple.com>> >> wrote: >> >> Hi there, >> >> it seems finally I succeeded to find the culprit of the problem described >> below. Far as my testing shows, it seems an ObjectStoreCoordinator is never >> garbage collected (presumed it has been used at least once for a fetch). >> Since the OSC opens a socket to the database, this leads to the problem with >> a number of open sockets for a process. Far as my testing shows, the only >> way to make it to do poof is to call dispose manually, which seems a bit at >> the unexpected side, at least for me. >> >> My current test code looks like this: >> >> === >> class MainPage extends OCSComponent { >> def test { >> def osc=new OCSOSC(),ec=new OCSEC(osc) >> println "created $osc and $ec" >> def >> obj=EOUtilities.objectWithPrimaryKeyValue(ec,'DBAuction',1000001) //[FETCH] >> println "got obj $obj and dying..." >> ec=nil >> osc.dispose() //[WHATTHE] >> osc=nil >> System.gc() >> nil >> } >> } >> class OCSOSC extends EOObjectStoreCoordinator { >> void finalize() { >> println "### $this about to die" >> } >> } >> @InheritConstructors class OCSEC extends ERXEC { >> void finalize() { >> println "### $this about to die" >> } >> } >> === >> >> If both the lines marked [FETCH] and [WHATTHE] above are commented out, >> i.e., if the OSC never fetches, both the osc and ec objects report >> finalizing without a need to dispose. >> >> Nevertheless, once the fetch happens as above, [WHATTHE] must be active too >> — otherwise only ec gets garbage collected; osc never ever does (and >> subsequently also never releases its DB socket). >> >> Well the explicit dispose seems to be the fix for my problem, so far it >> seems to work properly; but since I did not find any mention of calling >> dispose manually nor using a dispose registry in the documentation >> (otherwise than those two registries related to archivation and D2JClient), >> I wonder whether this is the proper approach, or whether I am doing >> something wrong and sooner or later I am in for an ugly surprise? Any >> insight here? >> >> Thanks a lot, >> OC >> >>> On 21. 5. 2020, at 1:13 PM, OCsite <o...@ocs.cz <mailto:o...@ocs.cz>> wrote: >>> >>> Hi there, >>> >>> bumped lately into another weird problem. We import some data into DB in >>> background tasks. Up to yesterday, it worked normally; today six import >>> tasks were launched, and each of them seemingly hang in its first DB >>> operation. Restart did help; alas, the site admins did not try to ask JVM >>> to detect deadlocks when they restarted the application. >>> >>> The background task looks like this: >>> >>> === >>> class ImportCSVTask extends ERXLongResponseTask.DefaultImplementation { >>> def performAction { >>> _thread.priority=Thread.MIN_PRIORITY >>> try { >>> try { >>> editingContext=ERXEC.newEditingContext(objectStore=new >>> EOObjectStoreCoordinator()) >>> editingContext.lock() >>> lognow 1, "=== preparing CSV import in EC $editingContext >>> ===" >>> >>> formPrototype=ERXEOGlobalIDUtilities.fetchObjectWithGlobalID(editingContext,formPrototypeGID) >>> lognow 1, "=== local prototype $formPrototype ===" >>> ... ... >>> === >>> >>> Always the “preparing” log was the last thing those threads presented; none >>> of them ever reported “local prototype”. There's no other related log in >>> there. >>> >>> Meantime the application ran normally and the worker tasks communicated >>> with the database all right (with an occasional report that some select >>> took 70-odd ms from ERXAdaptorChannelDelegate, we have the threshold at >>> 50). We run with ERXObjectStoreCoordinatorPool.maxCoordinators=1. >>> >>> Any idea what could have gone wrong and how to find the culprit and prevent >>> the problem in future? I thought a new EC in a new OSC can't be blocked for >>> long, but self-evidently, I was wrong, they seemed to lock indefinitely >>> (application was restarted ten-odd hours after the first import hanged >>> after its “preparing” report, still no “local prototype”). >>> >>> Thanks and all the best, >>> OC >>> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com >> <mailto:Webobjects-dev@lists.apple.com>) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz >> <https://lists.apple.com/mailman/options/webobjects-dev/ocs%40ocs.cz> >> >> This email sent to o...@ocs.cz > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/aaron%40chatnbike.com > > This email sent to aa...@chatnbike.com
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
