Re: donating to update WOLips

I think there was a discussion but nothing was set up. I would be willing to donate as well. Michael > On Jun 29, 2020, at 8:27 PM, Theodore Petrosky via Webobjects-dev > wrote: > > is there a gofundme or other crowd source set up so I can donated to update > WOLips? > > It’s been talked

donating to update WOLips

is there a gofundme or other crowd source set up so I can donated to update WOLips? It’s been talked about, but I haven’t seen anything. I would donate!!! Ted ___ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing lis

Re: Creating a EOModel in code

Don, > On 29 Jun 2020, at 17:16, Don Lindsay wrote: > Thanks for the information. This may be the path I will need to go down for > this specific project. Good luck! I have checked our sources and actually there were two small gotcha's we did bump into: (i) programmatically added attribut

Re: Is it normal that ulimit hangs a thread instead of raising an exception or something like that?

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

Re: Creating a EOModel in code

Thanks for the information. This may be the path I will need to go down for this specific project. Thanks Don > On Jun 29, 2020, at 07:14, OCsite wrote: > > Don, > > we do something remotely similar all the time (not creating a complete model, > but adding attributes dynamically at laun

Re: Looks like an OSC must be disposed manually?!? (was: background tasks locked, workers run all right)

If other things depend on that OSC, then disposing it would be bad. If it is an OSC you made to do work in a long running task and then disposed at the end of that task, it would be good to dispose it… or… to keep it in an OSC pool and check it back into that pool. They aren’t cheap. AARON ROSE

Is it normal that ulimit hangs a thread instead of raising an exception or something like that?

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. Nev

Re: Looks like an OSC must be disposed manually?!? (was: background tasks locked, workers run all right)

Aaron, thanks, this I hope I sort of understand. Still, in the garbage-collected environment, any object, far as I can say, should (a) be automatically disposed when there's no explicit reference to it, regardless of whether it is cheap or big; (b) if there's some internal means to keep unrefe

Re: Looks like an OSC must be disposed manually?!? (was: background tasks locked, workers run all right)

OSC is a cursor to the DB. They aren’t particularly cheap to acquire. As far as I know, they live until you dispose of them. They don’t automatically dispose. They are not cheap like an editingContext. One OSC can service a plethora of editingContexts. Simple WOApps have two OSC for the life of

Looks like an OSC must be disposed manually?!? (was: background tasks locked, workers run all right)

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 th

Re: Creating a EOModel in code

Don, we do something remotely similar all the time (not creating a complete model, but adding attributes dynamically at launch to entities). Works without a glitch, I cannot recall any problem at all with this. Should work for you as well, I would be rather surprised if you encounter any probl