Re: ERXObjectStoreCoordinator can be locked twice?!?

[Chuck Hill]

I'd recommend gradual changes. Let's just move the log line and fix the ec 
creation for now. 

Chuck Hill
Gevity Consulting Inc.

Sent from my mobile device. 

> On Jan 27, 2015, at 4:33 PM, OC  wrote:
> 
> Chuck,
> 
>> On 28. 1. 2015, at 1:23, Chuck Hill  wrote:
>> 
>> This could just be a thread priority thing.  When the first thread does the 
>> unlock, the second locks and proceeds and the println output to the log is 
>> delayed.  Ive definitely see that with NSLog were the order of output from 
>> concurrent threads is sometimes out of sequence in the logs.
> 
> Right you are, as always; probably I should move the log above the unlock.
> 
> Hopefully it was the sole reason.
> 
> Well, now I'm going to create my temporary EC in the locked OSC as you 
> suggested in previous e-mail, and will see what happens...
> 
> (Or do you suggest to change the code completely?)
> 
> Thanks again!
> 
>> On 2015-01-27, 3:04 PM, "OC" wrote:
>> 
>> Hello there,
>> 
>> since I wrote an awk script to check whether my OSCs get unlocked properly, 
>> I've bumped into one very strange thing in the locks.
>> 
>> First, my code is pretty straightforward (assuming we should lock OSC at 
>> all, which is debatable -- based on 
>> http://terminalapp.net/dr-optimistic-locking/; Chuck says well all right, 
>> though it should be sufficient to catch some notifications instead):
>> 
>> ===
>>EOEditingContext ec=auction.editingContext()
>>EOObjectStore osc=ec.rootObjectStore()
>>osc.lock()
>>try {
>>logln "$osc LOCKED FOR CU $sess.currentUser.login"
>>EOEditingContext tempec=ERXEC.newEditingContext()
>>... creating localInstanceIn as needed, updating them as 
>> appropriate ...
>>tempec.saveChanges()
>>println "... saved successfully!"
>>   } catch (exc) {
>>... reporting and logging error -- does not happen ...
>>   } finally {
>>osc.unlock()
>>println "$osc UNLOCKED FOR CU $sess.currentUser.login"
>>   }
>> ===
>> 
>> and in one place in my logs, there is
>> 
>> ===
>> 26.1 14:06:03: 
>> er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] LOCKED 
>> FOR CU CEZProdej
>> ... saved successfully!
>> 26.1 14:06:03: 
>> er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] LOCKED 
>> FOR CU EPETas
>> ... saved successfully!
>> er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] UNLOCKED 
>> FOR CU CEZProdej
>> er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] UNLOCKED 
>> FOR CU EPETas
>> ===
>> 
>> What the darn?!? This should not be possible, or am I completely missing the 
>> point of osc.lock()?!? :-O
>> 
>> In the vicinity, all the other logs looks all right, no exception not other 
>> error reported.
>> 
>> As usual, I'll be pretty grateful for any insight,
>> OC
>> 
>> 
>> ___
>> 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/chill%40gevityinc.com
>> 
>> This email sent to ch...@gevityinc.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

Re: ERXObjectStoreCoordinator can be locked twice?!?

[OC]

Chuck,

On 28. 1. 2015, at 1:23, Chuck Hill  wrote:

> This could just be a thread priority thing.  When the first thread does the 
> unlock, the second locks and proceeds and the println output to the log is 
> delayed.  Ive definitely see that with NSLog were the order of output from 
> concurrent threads is sometimes out of sequence in the logs.

Right you are, as always; probably I should move the log above the unlock.

Hopefully it was the sole reason.

Well, now I'm going to create my temporary EC in the locked OSC as you 
suggested in previous e-mail, and will see what happens...

(Or do you suggest to change the code completely?)

Thanks again!

> On 2015-01-27, 3:04 PM, "OC" wrote:
> 
> Hello there,
> 
> since I wrote an awk script to check whether my OSCs get unlocked properly, 
> I've bumped into one very strange thing in the locks.
> 
> First, my code is pretty straightforward (assuming we should lock OSC at all, 
> which is debatable -- based on http://terminalapp.net/dr-optimistic-locking/; 
> Chuck says well all right, though it should be sufficient to catch some 
> notifications instead):
> 
> ===
> EOEditingContext ec=auction.editingContext()
> EOObjectStore osc=ec.rootObjectStore()
> osc.lock()
> try {
> logln "$osc LOCKED FOR CU $sess.currentUser.login"
> EOEditingContext tempec=ERXEC.newEditingContext()
> ... creating localInstanceIn as needed, updating them as 
> appropriate ...
> tempec.saveChanges()
> println "... saved successfully!"
>} catch (exc) {
> ... reporting and logging error -- does not happen ...
>} finally {
> osc.unlock()
> println "$osc UNLOCKED FOR CU $sess.currentUser.login"
>}
> ===
> 
> and in one place in my logs, there is
> 
> ===
> 26.1 14:06:03: 
> er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] LOCKED FOR 
> CU CEZProdej
> ... saved successfully!
> 26.1 14:06:03: 
> er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] LOCKED FOR 
> CU EPETas
> ... saved successfully!
> er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] UNLOCKED 
> FOR CU CEZProdej
> er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] UNLOCKED 
> FOR CU EPETas
> ===
> 
> What the darn?!? This should not be possible, or am I completely missing the 
> point of osc.lock()?!? :-O
> 
> In the vicinity, all the other logs looks all right, no exception not other 
> error reported.
> 
> As usual, I'll be pretty grateful for any insight,
> OC
> 
> 
> ___
> 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/chill%40gevityinc.com
> 
> This email sent to ch...@gevityinc.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

Re: ERXObjectStoreCoordinator can be locked twice?!?

[Chuck Hill]

This could just be a thread priority thing.  When the first thread does the 
unlock, the second locks and proceeds and the println output to the log is 
delayed.  Ive definitely see that with NSLog were the order of output from 
concurrent threads is sometimes out of sequence in the logs.

That or something is dreadfully wrong.

Chuck

On 2015-01-27, 3:04 PM, "OC" wrote:

Hello there,

since I wrote an awk script to check whether my OSCs get unlocked properly, 
I've bumped into one very strange thing in the locks.

First, my code is pretty straightforward (assuming we should lock OSC at all, 
which is debatable -- based on http://terminalapp.net/dr-optimistic-locking/; 
Chuck says well all right, though it should be sufficient to catch some 
notifications instead):

===
EOEditingContext ec=auction.editingContext()
EOObjectStore osc=ec.rootObjectStore()
osc.lock()
try {
logln "$osc LOCKED FOR CU $sess.currentUser.login"
EOEditingContext tempec=ERXEC.newEditingContext()
... creating localInstanceIn as needed, updating them as 
appropriate ...
tempec.saveChanges()
println "... saved successfully!"
   } catch (exc) {
... reporting and logging error -- does not happen ...
   } finally {
osc.unlock()
println "$osc UNLOCKED FOR CU $sess.currentUser.login"
   }
===

and in one place in my logs, there is

===
26.1 14:06:03: 
er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] LOCKED FOR 
CU CEZProdej
... saved successfully!
26.1 14:06:03: 
er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] LOCKED FOR 
CU EPETas
... saved successfully!
er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] UNLOCKED FOR 
CU CEZProdej
er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] UNLOCKED FOR 
CU EPETas
===

What the darn?!? This should not be possible, or am I completely missing the 
point of osc.lock()?!? :-O

In the vicinity, all the other logs looks all right, no exception not other 
error reported.

As usual, I'll be pretty grateful for any insight,
OC


___
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/chill%40gevityinc.com

This email sent to ch...@gevityinc.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

Re: ERXObjectStoreCoordinator can be locked twice?!?

[OC]

Ramsey,

On 28. 1. 2015, at 1:07, Ramsey Gurley  wrote:

> BTW, OC, are you using binary blobs for your banners in the database? Because 
> if you are, the ERXOSCPool leaks memory and big snapshots make it leak much 
> faster.

I'm using _lots_ of blobs for diverse reasons.

Darn.

How to work around the problem? To completely get rid of

ERXObjectStoreCoordinatorPool.maxCoordinators=ANYTHING

comment it out from Properties?

(Well for my single-instance app it would do, but what with multi-instance 
ones, which need Remote Coordinator?)

thanks a lot,
OC


 ___
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

Re: ERXObjectStoreCoordinator can be locked twice?!?

[OC]

On 28. 1. 2015, at 0:32, Chuck Hill  wrote:

> OK, so that handily explains the OSC lock logging below – they are different 
> OSC instances.

I suppose toStrings logs out the hashCode, and if it does, they are the same 
instance:

>> ===
>> 26.1 14:06:03: 
>> er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] LOCKED 
>> FOR CU CEZProdej
>> ... saved successfully!
>> 26.1 14:06:03: 
>> er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] LOCKED 
>> FOR CU EPETas
>> ... saved successfully!


-- "@5d5e3b92" in both cases. There are other cases with 
"er.extensions.eof.ERXObjectStoreCoordinator@52ab6c19[name=unnamed]", which I 
assume is another instance of OSC, and which indeed do not clash with 
"@5d5e3b92" at all. (The third one was never used, it seems.)

>> ===
>> EOEditingContext ec=auction.editingContext()
>> EOObjectStore osc=ec.rootObjectStore()
>> osc.lock()
>> try {
>> logln "$osc LOCKED FOR CU $sess.currentUser.login"
>> EOEditingContext tempec=ERXEC.newEditingContext()
>> ... creating localInstanceIn as needed, updating them as 
>> appropriate …
> 
> Wat?
> 
> http://i0.kym-cdn.com/photos/images/newsfeed/000/173/580/Wat.jpg?1315930588
> 
> I don’t understand why this would be necessary, and I’m afraid to ask ;-) 
> Anyway,
> 
> You’ve met Miguel, right?  :-)
> http://terminalapp.net/dr-optimistic-locking/

Well that's the source of my code; actually we have discussed it a short time 
ago

===
On 24. 1. 2015, at 0:30, Chuck Hill  wrote:
 EOEditingContext ec=auction.editingContext()
 EOObjectStore osc=ec.rootObjectStore()
 osc.lock()
>>> Why are you locking this?  Nothing in the code below needs it.
>>> 
>> Learnt it here: http://terminalapp.net/dr-optimistic-locking/ -- have I 
>> misunderstood something of importance?
>> 
> Ah, that Miguel, always worrying!  :-)  OK, I see what you are after.  IIRC, 
> you can also handle this by catching notifications.  That discussion was a 
> long time ago, I forget the particulars and don’t have time to re-read all of 
> it now.
> 
> Chuck
> 
try {
 EOEditingContext tempec=ERXEC.newEditingContext()
 tempec.fetchTimestamp=System.currentTimeMillis()
 ... ... ...
===


> //You should be doing this if you want to ensure a peer ec in the same osc
> EOEditingContext tempec = ERXEC.newEditingContext(osc);
> Yes with multiple stacks NOT doing that could lead to unexpected results.

Thanks, that looks like a pretty important point! :)

The source of my code is Miguel all right -- at 
http://terminalapp.net/dr-optimistic-locking/ he suggests to lock OSC and also 
he says “Do as I wrote on the previous article” (and also, incidentally, 
“create multiple EOF stacks”).

The “previous article” is 
http://terminalapp.net/recovering-from-optimistic-locking-exceptions/, where 
the code looks like

===
EOEditingContext context = new EOEditingContext();
===

which I have just replaced by -- in my faulty opinion equivalent -- 
EOEditingContext tempec=ERXEC.newEditingContext(). I simply did not know I 
should use any argument there, ane Miguel does not point that out in any of his 
articles...

That's all. Well I'm going to replace it by “ERXEC.newEditingContext(osc)”, 
hopefully it will help!

Well perhaps before I do that -- is the Miguel's approach completely wrong? 
Should I trash the complete code and replace it by something else, with an 
utterly different approach?

Thanks a big lot,
OC


 ___
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

Re: ERXObjectStoreCoordinator can be locked twice?!?

[Ramsey Gurley]

On Jan 27, 2015, at 4:32 PM, Chuck Hill  wrote:

> 
> 
> On 2015-01-27, 3:28 PM, "Ramsey Gurley" wrote:
> 
> 
> On Jan 27, 2015, at 4:19 PM, Chuck Hill  wrote:
> 
>> Are you using this?
>> 
>> /**
>>  * This class implements EOF stack pooling including EOF stack 
>> synchronizing. 
>>  * It provides a special ERXEC.Factory in order to work without any changes 
>> in existing 
>>  * applications. The number of EOObjectStoreCoordinators can be set with the 
>>  * system Property 
>> er.extensions.ERXObjectStoreCoordinatorPool.maxCoordinators. 
>>  * Each Session will become one EOObjectStoreCoordinator and the method 
>>  * newEditingContext will always return an 
>> EOEditingContext 
>>  * with the same EOObjectStoreCoordinator for the same 
>> WOSession. 
>>  * This first release uses round-robin pooling, future versions might use 
>> better algorithms 
>>  * to decide which EOObjectStoreCoordinator will be used for 
>> the next new 
>>  * WOSession.The code is tested in a heavy  multithreaded 
>> application 
>>  * and afawk no deadlock occures, neither in EOF nor directly in Java.
>>  * 
>>  * @author David Teran, Frank Caputo @ cluster9
>>  */
>> publicclass ERXObjectStoreCoordinatorPool {
> 
> I think so. From a different thread:
> 
> another weird case: this application is run single-instance (but 
> ERXObjectStoreCoordinatorPool.maxCoordinators=3, 
> WOAllowsConcurrentRequestHandling=true).
> 
> 
> OK, so that handily explains the OSC lock logging below – they are different 
> OSC instances.  Single instance and three stacks seems odd, like someone 
> maybe misunderstood what this was doing?
> 
> 
>> On 2015-01-27, 3:04 PM, "OC" wrote:
>> 
>> Hello there,
>> 
>> since I wrote an awk script to check whether my OSCs get unlocked properly, 
>> I've bumped into one very strange thing in the locks.
>> 
>> First, my code is pretty straightforward (assuming we should lock OSC at 
>> all, which is debatable -- based on 
>> http://terminalapp.net/dr-optimistic-locking/; Chuck says well all right, 
>> though it should be sufficient to catch some notifications instead):
>> 
>> ===
>> EOEditingContext ec=auction.editingContext()
>> EOObjectStore osc=ec.rootObjectStore()
>> osc.lock()
>> try {
>> logln "$osc LOCKED FOR CU $sess.currentUser.login"
>> EOEditingContext tempec=ERXEC.newEditingContext()
>> ... creating localInstanceIn as needed, updating them as 
>> appropriate …
> 
> Wat?
> 
> http://i0.kym-cdn.com/photos/images/newsfeed/000/173/580/Wat.jpg?1315930588
> 
> I don’t understand why this would be necessary, and I’m afraid to ask ;-) 
> Anyway,
> 
> You’ve met Miguel, right?  :-)
> http://terminalapp.net/dr-optimistic-locking/

Interesting, I would have thought locking the ec did lock the OSC.

BTW, OC, are you using binary blobs for your banners in the database? Because 
if you are, the ERXOSCPool leaks memory and big snapshots make it leak much 
faster.

> 
> 
> //You should be doing this if you want to ensure a peer ec in the same osc
> EOEditingContext tempec = ERXEC.newEditingContext(osc);
> 
> Yes with multiple stacks NOT doing that could lead to unexpected results.
> 
> 
> 
>> tempec.saveChanges()
>> println "... saved successfully!"
>>} catch (exc) {
>> ... reporting and logging error -- does not happen ...
>>} finally {
>> osc.unlock()
>> println "$osc UNLOCKED FOR CU $sess.currentUser.login"
>>}
>> ===
>> 
>> and in one place in my logs, there is
>> 
>> ===
>> 26.1 14:06:03: 
>> er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] LOCKED 
>> FOR CU CEZProdej
>> ... saved successfully!
>> 26.1 14:06:03: 
>> er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] LOCKED 
>> FOR CU EPETas
>> ... saved successfully!
>> er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] UNLOCKED 
>> FOR CU CEZProdej
>> er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] UNLOCKED 
>> FOR CU EPETas
>> ===
>> 
>> What the darn?!? This should not be possible, or am I completely missing the 
>> point of osc.lock()?!? :-O
>> 
>> In the vicinity, all the other logs looks all right, no exception not other 
>> error reported.
>> 
>> As usual, I'll be pretty grateful for any insight,
>> OC
>> 
>> 
>> ___
>> 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/chill%40gevityinc.com
>> 
>> This email sent to ch...@gevityinc.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/webob

Re: ERXObjectStoreCoordinator can be locked twice?!?

[Chuck Hill]

On 2015-01-27, 3:28 PM, "Ramsey Gurley" wrote:


On Jan 27, 2015, at 4:19 PM, Chuck Hill 
mailto:ch...@gevityinc.com>> wrote:

Are you using this?

/**
 * This class implements EOF stack pooling including EOF stack synchronizing.
 * It provides a special ERXEC.Factory in order to work without any changes in 
existing
 * applications. The number of EOObjectStoreCoordinators can be set with the
 * system Property 
er.extensions.ERXObjectStoreCoordinatorPool.maxCoordinators.
 * Each Session will become one EOObjectStoreCoordinator and the method
 * newEditingContext will always return an 
EOEditingContext
 * with the same EOObjectStoreCoordinator for the same 
WOSession.
 * This first release uses round-robin pooling, future versions might use 
better algorithms
 * to decide which EOObjectStoreCoordinator will be used for the 
next new
 * WOSession.The code is tested in a heavy  multithreaded 
application
 * and afawk no deadlock occures, neither in EOF nor directly in Java.
 *
 * @author David Teran, Frank Caputo @ cluster9
 */
publicclass ERXObjectStoreCoordinatorPool {

I think so. From a different thread:

another weird case: this application is run single-instance (but 
ERXObjectStoreCoordinatorPool.maxCoordinators=3, 
WOAllowsConcurrentRequestHandling=true).


OK, so that handily explains the OSC lock logging below – they are different 
OSC instances.  Single instance and three stacks seems odd, like someone maybe 
misunderstood what this was doing?


On 2015-01-27, 3:04 PM, "OC" wrote:

Hello there,

since I wrote an awk script to check whether my OSCs get unlocked properly, 
I've bumped into one very strange thing in the locks.

First, my code is pretty straightforward (assuming we should lock OSC at all, 
which is debatable -- based on http://terminalapp.net/dr-optimistic-locking/; 
Chuck says well all right, though it should be sufficient to catch some 
notifications instead):

===
EOEditingContext ec=auction.editingContext()
EOObjectStore osc=ec.rootObjectStore()
osc.lock()
try {
logln "$osc LOCKED FOR CU $sess.currentUser.login"
EOEditingContext tempec=ERXEC.newEditingContext()
... creating localInstanceIn as needed, updating them as 
appropriate …

Wat?

http://i0.kym-cdn.com/photos/images/newsfeed/000/173/580/Wat.jpg?1315930588

I don’t understand why this would be necessary, and I’m afraid to ask ;-) 
Anyway,

You’ve met Miguel, right?  :-)
http://terminalapp.net/dr-optimistic-locking/


//You should be doing this if you want to ensure a peer ec in the same osc
EOEditingContext tempec = ERXEC.newEditingContext(osc);

Yes with multiple stacks NOT doing that could lead to unexpected results.



tempec.saveChanges()
println "... saved successfully!"
   } catch (exc) {
... reporting and logging error -- does not happen ...
   } finally {
osc.unlock()
println "$osc UNLOCKED FOR CU $sess.currentUser.login"
   }
===

and in one place in my logs, there is

===
26.1 14:06:03: 
er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] LOCKED FOR 
CU CEZProdej
... saved successfully!
26.1 14:06:03: 
er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] LOCKED FOR 
CU EPETas
... saved successfully!
er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] UNLOCKED FOR 
CU CEZProdej
er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] UNLOCKED FOR 
CU EPETas
===

What the darn?!? This should not be possible, or am I completely missing the 
point of osc.lock()?!? :-O

In the vicinity, all the other logs looks all right, no exception not other 
error reported.

As usual, I'll be pretty grateful for any insight,
OC


___
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/chill%40gevityinc.com

This email sent to ch...@gevityinc.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/rgurley%40smarthealth.com

This email sent to rgur...@smarthealth.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

Re: ERXObjectStoreCoordinator can be locked twice?!?

[Ramsey Gurley]

On Jan 27, 2015, at 4:19 PM, Chuck Hill  wrote:

> Are you using this?
> 
> /**
>  * This class implements EOF stack pooling including EOF stack synchronizing. 
>  * It provides a special ERXEC.Factory in order to work without any changes 
> in existing 
>  * applications. The number of EOObjectStoreCoordinators can be set with the 
>  * system Property 
> er.extensions.ERXObjectStoreCoordinatorPool.maxCoordinators. 
>  * Each Session will become one EOObjectStoreCoordinator and the method 
>  * newEditingContext will always return an 
> EOEditingContext 
>  * with the same EOObjectStoreCoordinator for the same 
> WOSession. 
>  * This first release uses round-robin pooling, future versions might use 
> better algorithms 
>  * to decide which EOObjectStoreCoordinator will be used for the 
> next new 
>  * WOSession.The code is tested in a heavy  multithreaded 
> application 
>  * and afawk no deadlock occures, neither in EOF nor directly in Java.
>  * 
>  * @author David Teran, Frank Caputo @ cluster9
>  */
> public class ERXObjectStoreCoordinatorPool {

I think so. From a different thread:

another weird case: this application is run single-instance (but 
ERXObjectStoreCoordinatorPool.maxCoordinators=3, 
WOAllowsConcurrentRequestHandling=true).

> 
> 
> 
> On 2015-01-27, 3:04 PM, "OC" wrote:
> 
> Hello there,
> 
> since I wrote an awk script to check whether my OSCs get unlocked properly, 
> I've bumped into one very strange thing in the locks.
> 
> First, my code is pretty straightforward (assuming we should lock OSC at all, 
> which is debatable -- based on http://terminalapp.net/dr-optimistic-locking/; 
> Chuck says well all right, though it should be sufficient to catch some 
> notifications instead):
> 
> ===
> EOEditingContext ec=auction.editingContext()
> EOObjectStore osc=ec.rootObjectStore()
> osc.lock()
> try {
> logln "$osc LOCKED FOR CU $sess.currentUser.login"
> EOEditingContext tempec=ERXEC.newEditingContext()
> ... creating localInstanceIn as needed, updating them as 
> appropriate …

Wat?

http://i0.kym-cdn.com/photos/images/newsfeed/000/173/580/Wat.jpg?1315930588

I don’t understand why this would be necessary, and I’m afraid to ask ;-) 
Anyway,

//You should be doing this if you want to ensure a peer ec in the same osc
EOEditingContext tempec = ERXEC.newEditingContext(osc);


> tempec.saveChanges()
> println "... saved successfully!"
>} catch (exc) {
> ... reporting and logging error -- does not happen ...
>} finally {
> osc.unlock()
> println "$osc UNLOCKED FOR CU $sess.currentUser.login"
>}
> ===
> 
> and in one place in my logs, there is
> 
> ===
> 26.1 14:06:03: 
> er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] LOCKED FOR 
> CU CEZProdej
> ... saved successfully!
> 26.1 14:06:03: 
> er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] LOCKED FOR 
> CU EPETas
> ... saved successfully!
> er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] UNLOCKED 
> FOR CU CEZProdej
> er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] UNLOCKED 
> FOR CU EPETas
> ===
> 
> What the darn?!? This should not be possible, or am I completely missing the 
> point of osc.lock()?!? :-O
> 
> In the vicinity, all the other logs looks all right, no exception not other 
> error reported.
> 
> As usual, I'll be pretty grateful for any insight,
> OC
> 
> 
> ___
> 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/chill%40gevityinc.com
> 
> This email sent to ch...@gevityinc.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/rgurley%40smarthealth.com
> 
> This email sent to rgur...@smarthealth.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

Re: ERXObjectStoreCoordinator can be locked twice?!?

[Chuck Hill]

Are you using this?


/**

 * This class implements EOF stack pooling including EOF stack synchronizing.

 * It provides a special ERXEC.Factory in order to work without any changes in 
existing

 * applications. The number of EOObjectStoreCoordinators can be set with the

 * system Property 
er.extensions.ERXObjectStoreCoordinatorPool.maxCoordinators.

 * Each Session will become one EOObjectStoreCoordinator and the method

 * newEditingContext will always return an 
EOEditingContext

 * with the same EOObjectStoreCoordinator for the same 
WOSession.

 * This first release uses round-robin pooling, future versions might use 
better algorithms

 * to decide which EOObjectStoreCoordinator will be used for the 
next new

 * WOSession.The code is tested in a heavy  multithreaded 
application

 * and afawk no deadlock occures, neither in EOF nor directly in Java.

 *

 * @author David Teran, Frank Caputo @ cluster9

 */

public class ERXObjectStoreCoordinatorPool {



On 2015-01-27, 3:04 PM, "OC" wrote:

Hello there,

since I wrote an awk script to check whether my OSCs get unlocked properly, 
I've bumped into one very strange thing in the locks.

First, my code is pretty straightforward (assuming we should lock OSC at all, 
which is debatable -- based on http://terminalapp.net/dr-optimistic-locking/; 
Chuck says well all right, though it should be sufficient to catch some 
notifications instead):

===
EOEditingContext ec=auction.editingContext()
EOObjectStore osc=ec.rootObjectStore()
osc.lock()
try {
logln "$osc LOCKED FOR CU $sess.currentUser.login"
EOEditingContext tempec=ERXEC.newEditingContext()
... creating localInstanceIn as needed, updating them as 
appropriate ...
tempec.saveChanges()
println "... saved successfully!"
   } catch (exc) {
... reporting and logging error -- does not happen ...
   } finally {
osc.unlock()
println "$osc UNLOCKED FOR CU $sess.currentUser.login"
   }
===

and in one place in my logs, there is

===
26.1 14:06:03: 
er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] LOCKED FOR 
CU CEZProdej
... saved successfully!
26.1 14:06:03: 
er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] LOCKED FOR 
CU EPETas
... saved successfully!
er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] UNLOCKED FOR 
CU CEZProdej
er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] UNLOCKED FOR 
CU EPETas
===

What the darn?!? This should not be possible, or am I completely missing the 
point of osc.lock()?!? :-O

In the vicinity, all the other logs looks all right, no exception not other 
error reported.

As usual, I'll be pretty grateful for any insight,
OC


___
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/chill%40gevityinc.com

This email sent to ch...@gevityinc.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

ERXObjectStoreCoordinator can be locked twice?!?

[OC]

Hello there,

since I wrote an awk script to check whether my OSCs get unlocked properly, 
I've bumped into one very strange thing in the locks.

First, my code is pretty straightforward (assuming we should lock OSC at all, 
which is debatable -- based on http://terminalapp.net/dr-optimistic-locking/; 
Chuck says well all right, though it should be sufficient to catch some 
notifications instead):

===
EOEditingContext ec=auction.editingContext()
EOObjectStore osc=ec.rootObjectStore()
osc.lock()
try {
logln "$osc LOCKED FOR CU $sess.currentUser.login"
EOEditingContext tempec=ERXEC.newEditingContext()
... creating localInstanceIn as needed, updating them as 
appropriate ...
tempec.saveChanges()
println "... saved successfully!"
   } catch (exc) {
... reporting and logging error -- does not happen ...
   } finally {
osc.unlock()
println "$osc UNLOCKED FOR CU $sess.currentUser.login"
   }
===

and in one place in my logs, there is

===
26.1 14:06:03: 
er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] LOCKED FOR 
CU CEZProdej
... saved successfully!
26.1 14:06:03: 
er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] LOCKED FOR 
CU EPETas
... saved successfully!
er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] UNLOCKED FOR 
CU CEZProdej
er.extensions.eof.ERXObjectStoreCoordinator@5d5e3b92[name=unnamed] UNLOCKED FOR 
CU EPETas
===

What the darn?!? This should not be possible, or am I completely missing the 
point of osc.lock()?!? :-O

In the vicinity, all the other logs looks all right, no exception not other 
error reported.

As usual, I'll be pretty grateful for any insight,
OC


 ___
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

Re: Might in some conditions EOUtilities.objectWithPrimaryKeyValue lock the application?

[OC]

Ramsey,

thanks a lot!

> Maybe you can get the admin to dump that into a file for you before they kill 
> ? 

I'll try :)

> EOF has a global lock on the OSC. Looks like some other thread locked the OSC 
> and didn’t unlock it. If you are manually locking and unlocking an EC, you 
> should always...

But if it was (all three) OSCs locked, it would block _before_ fetch and the 
FrontBase log would not contain the appropriate SELECT, or am I wrong?

(Anyway I do that in one specific place -- see e.g., the "locking with more 
coordinators causes an exception?" thread of 24th. I do log both locks and 
unlocks, too, and far as the log goes, no OSC ever stays locked. Nevertheless I 
did bump into one weird thing when I've scanned logs -- will write with another 
subject in a moment!)

> But you probably shouldn’t be manually locking much if you are using an auto 
> locking ec like ERXEC.

I did lock EOs which lead to problems (again see please "locking with more 
coordinators causes an exception?"). Now I am not, and just in one specific 
case where it is enormously important to store sequentially I lock OSC.

Thanks a lot,
OC

> On Jan 27, 2015, at 2:58 PM, OC  wrote:
> 
>> Alas, runs on production server where I have no access -- just am getting 
>> the logs :(
>> 
>> Thanks,
>> OC
>> 
>> On 27. 1. 2015, at 22:41, Ramsey Gurley  wrote:
>> 
>>> If the instance is hung, I’d start with
>>> 
>>> jstack -F 
>>> 
>>> That should give a stack trace on whatever deadlocked it.
>>> 
>>> On Jan 27, 2015, at 2:33 PM, OC  wrote:
>>> 
 Hello there,
 
 another weird case: this application is run single-instance (but 
 ERXObjectStoreCoordinatorPool.maxCoordinators=3, 
 WOAllowsConcurrentRequestHandling=true).
 
 Yesterday after 14:10 users reported “No instance” or “Application not 
 found” WO reports. Now, I log all R/R loops in Application.awake and 
 Application.sleep; indeed at 14:10 a R/R loop did start and never ended, 
 actually, almost nothing happened till the app was restarted by the 
 administrator at 14:20. (I am told JavaMonitor has not been able to stop 
 the instance normally, and it had to be killed/force quit.)
 
 The single thing which did happen looks like this in my log:
 
 ===
 //
 // R/R loop #2218 WorkerThread118 started at 14:10:05 26.1.
 //
 DA: reading CZ banner image for market 101...
 14:20:39.844 WARN  Force Quit received. Exiting now...   //log:NSLog 
 [Thread-3]
 APPLICATION SHUTDOWN SEQUENCE COMPLETE
 ===
 
 The “reading banner“ log comes from a direct action:
 
 ===
 WOActionResults bannerAction {
 def 
 mpk=request().formValueForKey('mkpk'),lang=request().formValueForKey('lang')
 println "DA: reading $lang banner image for market $mpk..."
 if (!mpk || !lang) return null
 ERXEC ec=ERXEC.newEditingContext()
 DBMarket 
 market=EOUtilities.objectWithPrimaryKeyValue(ec,'DBMarket',mpk as Integer)
 println "DA: ... $market" //*
 if (!market) return null
 def 
 mime=market."marketBannerMIME$lang",data=market."marketBannerData$lang"
 println "DA: ... mime '$mime' data $data.length B"
 WOResponse wor=new WOResponse()
 wor.setHeader(mime,"content-type")
 ...
 wor.setContent(data)
 wor
 }
 ===
 
 Note the //* log is not present, which suggests that 
 EOUtilities.objectWithPrimaryKeyValue did lock somehow?!? Neither any 
 other R/R loop starts, which looks like not only WorkerThread118 did 
 block, but that the instance stopped accepting requests at all.
 
 The FrontBase log (which I regret to say I do not fully understand, 
 namely, those “--N lines, of which I get just the timestamp”) looks like 
 this:
 
 ===
 ...
 --6 0x1039f41d8 0x1039f44b0 2015-01-26 14:10:05.53996 "1 0"
 --D 0x1039f41d8 0x1039f44b0 2015-01-26 14:10:05.55851 752 48429
 SELECT t0."C_AUCTION_AMOUNT_STEP", t0."C_AUCTION_AOFFALL", 
 t0."C_AUCTION_MAX_AMOUNT", t0."C_MAX_LENGHT", t0."C_AUCTION_MIN_AMOUNT", 
 t0."C_AUCTION_CHDELAY", t0."C_MIN_LENGTH", t0."C_AUCTION_MINSTART", 
 t0."C_AUCTION_NEXT_SEQ", t0."C_AUCTION_CONCUR", t0."C_CREATION_DATE", 
 t0."C_CREATOR_ID", t0."C_FIELD_IDENTIFIERS_FOR_EDITOR", 
 t0."C_FIELD_IDENTIFIERS_FOR_FILTER", t0."C_FIELD_IDENTIFIERS_FOR_LIST", 
 t0."C_FIELD_IDENTIFIERS_FOR_OFFER", t0."C_FIELD_IDENTIFIERS_FOR_PUBLIC", 
 t0."C_FORM_TEMPLATE_ID", t0."C_MARKET_BANNER_CZ_DATA", 
 t0."C_MARKET_BANNER_EN_DATA", t0."C_MARKET_BANNER_CZ_MIME", 
 t0."C_MARKET_BANNER_EN_MIME", t0."C_SUPPORTS_OFFERS", t0."C_SHORTCUT", 
 t0."C_TITLE", t0."C_UID", t0."C_WIDTHS_FOR_LIST" FROM "T_MARKET" t0 WHERE 

Re: Might in some conditions EOUtilities.objectWithPrimaryKeyValue lock the application?

[Ramsey Gurley]

Maybe you can get the admin to dump that into a file for you before they kill 
? 

EOF has a global lock on the OSC. Looks like some other thread locked the OSC 
and didn’t unlock it. If you are manually locking and unlocking an EC, you 
should always

ec.lock();
try {
//do stuff
} finally {
ec.unlock();
}

But you probably shouldn’t be manually locking much if you are using an auto 
locking ec like ERXEC.

On Jan 27, 2015, at 2:58 PM, OC  wrote:

> Alas, runs on production server where I have no access -- just am getting the 
> logs :(
> 
> Thanks,
> OC
> 
> On 27. 1. 2015, at 22:41, Ramsey Gurley  wrote:
> 
>> If the instance is hung, I’d start with
>> 
>> jstack -F 
>> 
>> That should give a stack trace on whatever deadlocked it.
>> 
>> On Jan 27, 2015, at 2:33 PM, OC  wrote:
>> 
>>> Hello there,
>>> 
>>> another weird case: this application is run single-instance (but 
>>> ERXObjectStoreCoordinatorPool.maxCoordinators=3, 
>>> WOAllowsConcurrentRequestHandling=true).
>>> 
>>> Yesterday after 14:10 users reported “No instance” or “Application not 
>>> found” WO reports. Now, I log all R/R loops in Application.awake and 
>>> Application.sleep; indeed at 14:10 a R/R loop did start and never ended, 
>>> actually, almost nothing happened till the app was restarted by the 
>>> administrator at 14:20. (I am told JavaMonitor has not been able to stop 
>>> the instance normally, and it had to be killed/force quit.)
>>> 
>>> The single thing which did happen looks like this in my log:
>>> 
>>> ===
>>> //
>>> // R/R loop #2218 WorkerThread118 started at 14:10:05 26.1.
>>> //
>>> DA: reading CZ banner image for market 101...
>>> 14:20:39.844 WARN  Force Quit received. Exiting now...   //log:NSLog 
>>> [Thread-3]
>>> APPLICATION SHUTDOWN SEQUENCE COMPLETE
>>> ===
>>> 
>>> The “reading banner“ log comes from a direct action:
>>> 
>>> ===
>>>  WOActionResults bannerAction {
>>>  def 
>>> mpk=request().formValueForKey('mkpk'),lang=request().formValueForKey('lang')
>>>  println "DA: reading $lang banner image for market $mpk..."
>>>  if (!mpk || !lang) return null
>>>  ERXEC ec=ERXEC.newEditingContext()
>>>  DBMarket 
>>> market=EOUtilities.objectWithPrimaryKeyValue(ec,'DBMarket',mpk as Integer)
>>>  println "DA: ... $market" //*
>>>  if (!market) return null
>>>  def 
>>> mime=market."marketBannerMIME$lang",data=market."marketBannerData$lang"
>>>  println "DA: ... mime '$mime' data $data.length B"
>>>  WOResponse wor=new WOResponse()
>>>  wor.setHeader(mime,"content-type")
>>>  ...
>>>  wor.setContent(data)
>>>  wor
>>>  }
>>> ===
>>> 
>>> Note the //* log is not present, which suggests that 
>>> EOUtilities.objectWithPrimaryKeyValue did lock somehow?!? Neither any other 
>>> R/R loop starts, which looks like not only WorkerThread118 did block, but 
>>> that the instance stopped accepting requests at all.
>>> 
>>> The FrontBase log (which I regret to say I do not fully understand, namely, 
>>> those “--N lines, of which I get just the timestamp”) looks like this:
>>> 
>>> ===
>>> ...
>>> --6 0x1039f41d8 0x1039f44b0 2015-01-26 14:10:05.53996 "1 0"
>>> --D 0x1039f41d8 0x1039f44b0 2015-01-26 14:10:05.55851 752 48429
>>> SELECT t0."C_AUCTION_AMOUNT_STEP", t0."C_AUCTION_AOFFALL", 
>>> t0."C_AUCTION_MAX_AMOUNT", t0."C_MAX_LENGHT", t0."C_AUCTION_MIN_AMOUNT", 
>>> t0."C_AUCTION_CHDELAY", t0."C_MIN_LENGTH", t0."C_AUCTION_MINSTART", 
>>> t0."C_AUCTION_NEXT_SEQ", t0."C_AUCTION_CONCUR", t0."C_CREATION_DATE", 
>>> t0."C_CREATOR_ID", t0."C_FIELD_IDENTIFIERS_FOR_EDITOR", 
>>> t0."C_FIELD_IDENTIFIERS_FOR_FILTER", t0."C_FIELD_IDENTIFIERS_FOR_LIST", 
>>> t0."C_FIELD_IDENTIFIERS_FOR_OFFER", t0."C_FIELD_IDENTIFIERS_FOR_PUBLIC", 
>>> t0."C_FORM_TEMPLATE_ID", t0."C_MARKET_BANNER_CZ_DATA", 
>>> t0."C_MARKET_BANNER_EN_DATA", t0."C_MARKET_BANNER_CZ_MIME", 
>>> t0."C_MARKET_BANNER_EN_MIME", t0."C_SUPPORTS_OFFERS", t0."C_SHORTCUT", 
>>> t0."C_TITLE", t0."C_UID", t0."C_WIDTHS_FOR_LIST" FROM "T_MARKET" t0 WHERE 
>>> t0."C_UID" = 101;
>>> --6 0x1039f41d8 0x1039f44b0 2015-01-26 14:10:05.55903 "1 0"
>>> --7 0x1039f41d8 0x1039f44b0 2015-01-26 14:10:05.55905 ""
>>> --8 0x1039f41d8 0x1039f44b0 2015-01-26 14:10:05.55907 "1"
>>> --2 0x1039f41d8 0x1039f44b0 2015-01-26 14:10:05.55976 7 48430
>>> commit;
>>> --6 0x1039f41d8 0x1039f44b0 2015-01-26 14:10:05.55984 "1 0"
>>> --3 0x1040841d8 0x1040844b0 2015-01-26 14:20:40.50016
>>> ...
>>> ===
>>> 
>>> If anybody can see what on earth might have happened, I'd be grateful for 
>>> any advice. Myself, I just can see the app locked _somehow_ and stopped 
>>> working at all, but have no idea why and how to prevent that...
>>> 
>>> Note: the direct action worked flawlessly (and is in the logs) in the same 
>>> instance each previous R/R loop, more than 2000 times.
>>> 
>>> 

Re: Might in some conditions EOUtilities.objectWithPrimaryKeyValue lock the application?

[OC]

Alas, runs on production server where I have no access -- just am getting the 
logs :(

Thanks,
OC

On 27. 1. 2015, at 22:41, Ramsey Gurley  wrote:

> If the instance is hung, I’d start with
> 
> jstack -F 
> 
> That should give a stack trace on whatever deadlocked it.
> 
> On Jan 27, 2015, at 2:33 PM, OC  wrote:
> 
>> Hello there,
>> 
>> another weird case: this application is run single-instance (but 
>> ERXObjectStoreCoordinatorPool.maxCoordinators=3, 
>> WOAllowsConcurrentRequestHandling=true).
>> 
>> Yesterday after 14:10 users reported “No instance” or “Application not 
>> found” WO reports. Now, I log all R/R loops in Application.awake and 
>> Application.sleep; indeed at 14:10 a R/R loop did start and never ended, 
>> actually, almost nothing happened till the app was restarted by the 
>> administrator at 14:20. (I am told JavaMonitor has not been able to stop the 
>> instance normally, and it had to be killed/force quit.)
>> 
>> The single thing which did happen looks like this in my log:
>> 
>> ===
>> //
>> // R/R loop #2218 WorkerThread118 started at 14:10:05 26.1.
>> //
>> DA: reading CZ banner image for market 101...
>> 14:20:39.844 WARN  Force Quit received. Exiting now...   //log:NSLog 
>> [Thread-3]
>> APPLICATION SHUTDOWN SEQUENCE COMPLETE
>> ===
>> 
>> The “reading banner“ log comes from a direct action:
>> 
>> ===
>>   WOActionResults bannerAction {
>>   def 
>> mpk=request().formValueForKey('mkpk'),lang=request().formValueForKey('lang')
>>   println "DA: reading $lang banner image for market $mpk..."
>>   if (!mpk || !lang) return null
>>   ERXEC ec=ERXEC.newEditingContext()
>>   DBMarket 
>> market=EOUtilities.objectWithPrimaryKeyValue(ec,'DBMarket',mpk as Integer)
>>   println "DA: ... $market" //*
>>   if (!market) return null
>>   def 
>> mime=market."marketBannerMIME$lang",data=market."marketBannerData$lang"
>>   println "DA: ... mime '$mime' data $data.length B"
>>   WOResponse wor=new WOResponse()
>>   wor.setHeader(mime,"content-type")
>>   ...
>>   wor.setContent(data)
>>   wor
>>   }
>> ===
>> 
>> Note the //* log is not present, which suggests that 
>> EOUtilities.objectWithPrimaryKeyValue did lock somehow?!? Neither any other 
>> R/R loop starts, which looks like not only WorkerThread118 did block, but 
>> that the instance stopped accepting requests at all.
>> 
>> The FrontBase log (which I regret to say I do not fully understand, namely, 
>> those “--N lines, of which I get just the timestamp”) looks like this:
>> 
>> ===
>> ...
>> --6 0x1039f41d8 0x1039f44b0 2015-01-26 14:10:05.53996 "1 0"
>> --D 0x1039f41d8 0x1039f44b0 2015-01-26 14:10:05.55851 752 48429
>> SELECT t0."C_AUCTION_AMOUNT_STEP", t0."C_AUCTION_AOFFALL", 
>> t0."C_AUCTION_MAX_AMOUNT", t0."C_MAX_LENGHT", t0."C_AUCTION_MIN_AMOUNT", 
>> t0."C_AUCTION_CHDELAY", t0."C_MIN_LENGTH", t0."C_AUCTION_MINSTART", 
>> t0."C_AUCTION_NEXT_SEQ", t0."C_AUCTION_CONCUR", t0."C_CREATION_DATE", 
>> t0."C_CREATOR_ID", t0."C_FIELD_IDENTIFIERS_FOR_EDITOR", 
>> t0."C_FIELD_IDENTIFIERS_FOR_FILTER", t0."C_FIELD_IDENTIFIERS_FOR_LIST", 
>> t0."C_FIELD_IDENTIFIERS_FOR_OFFER", t0."C_FIELD_IDENTIFIERS_FOR_PUBLIC", 
>> t0."C_FORM_TEMPLATE_ID", t0."C_MARKET_BANNER_CZ_DATA", 
>> t0."C_MARKET_BANNER_EN_DATA", t0."C_MARKET_BANNER_CZ_MIME", 
>> t0."C_MARKET_BANNER_EN_MIME", t0."C_SUPPORTS_OFFERS", t0."C_SHORTCUT", 
>> t0."C_TITLE", t0."C_UID", t0."C_WIDTHS_FOR_LIST" FROM "T_MARKET" t0 WHERE 
>> t0."C_UID" = 101;
>> --6 0x1039f41d8 0x1039f44b0 2015-01-26 14:10:05.55903 "1 0"
>> --7 0x1039f41d8 0x1039f44b0 2015-01-26 14:10:05.55905 ""
>> --8 0x1039f41d8 0x1039f44b0 2015-01-26 14:10:05.55907 "1"
>> --2 0x1039f41d8 0x1039f44b0 2015-01-26 14:10:05.55976 7 48430
>> commit;
>> --6 0x1039f41d8 0x1039f44b0 2015-01-26 14:10:05.55984 "1 0"
>> --3 0x1040841d8 0x1040844b0 2015-01-26 14:20:40.50016
>> ...
>> ===
>> 
>> If anybody can see what on earth might have happened, I'd be grateful for 
>> any advice. Myself, I just can see the app locked _somehow_ and stopped 
>> working at all, but have no idea why and how to prevent that...
>> 
>> Note: the direct action worked flawlessly (and is in the logs) in the same 
>> instance each previous R/R loop, more than 2000 times.
>> 
>> Thanks,
>> OC
>> 
>> 
>> ___
>> 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/rgurley%40smarthealth.com
>> 
>> This email sent to rgur...@smarthealth.com
> 


 ___
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list  (Webobjects-dev

Re: Might in some conditions EOUtilities.objectWithPrimaryKeyValue lock the application?

[Ramsey Gurley]

If the instance is hung, I’d start with

jstack -F 

That should give a stack trace on whatever deadlocked it.

On Jan 27, 2015, at 2:33 PM, OC  wrote:

> Hello there,
> 
> another weird case: this application is run single-instance (but 
> ERXObjectStoreCoordinatorPool.maxCoordinators=3, 
> WOAllowsConcurrentRequestHandling=true).
> 
> Yesterday after 14:10 users reported “No instance” or “Application not found” 
> WO reports. Now, I log all R/R loops in Application.awake and 
> Application.sleep; indeed at 14:10 a R/R loop did start and never ended, 
> actually, almost nothing happened till the app was restarted by the 
> administrator at 14:20. (I am told JavaMonitor has not been able to stop the 
> instance normally, and it had to be killed/force quit.)
> 
> The single thing which did happen looks like this in my log:
> 
> ===
> //
> // R/R loop #2218 WorkerThread118 started at 14:10:05 26.1.
> //
> DA: reading CZ banner image for market 101...
> 14:20:39.844 WARN  Force Quit received. Exiting now...   //log:NSLog 
> [Thread-3]
> APPLICATION SHUTDOWN SEQUENCE COMPLETE
> ===
> 
> The “reading banner“ log comes from a direct action:
> 
> ===
>WOActionResults bannerAction {
>def 
> mpk=request().formValueForKey('mkpk'),lang=request().formValueForKey('lang')
>println "DA: reading $lang banner image for market $mpk..."
>if (!mpk || !lang) return null
>ERXEC ec=ERXEC.newEditingContext()
>DBMarket 
> market=EOUtilities.objectWithPrimaryKeyValue(ec,'DBMarket',mpk as Integer)
>println "DA: ... $market" //*
>if (!market) return null
>def 
> mime=market."marketBannerMIME$lang",data=market."marketBannerData$lang"
>println "DA: ... mime '$mime' data $data.length B"
>WOResponse wor=new WOResponse()
>wor.setHeader(mime,"content-type")
>...
>wor.setContent(data)
>wor
>}
> ===
> 
> Note the //* log is not present, which suggests that 
> EOUtilities.objectWithPrimaryKeyValue did lock somehow?!? Neither any other 
> R/R loop starts, which looks like not only WorkerThread118 did block, but 
> that the instance stopped accepting requests at all.
> 
> The FrontBase log (which I regret to say I do not fully understand, namely, 
> those “--N lines, of which I get just the timestamp”) looks like this:
> 
> ===
> ...
> --6 0x1039f41d8 0x1039f44b0 2015-01-26 14:10:05.53996 "1 0"
> --D 0x1039f41d8 0x1039f44b0 2015-01-26 14:10:05.55851 752 48429
> SELECT t0."C_AUCTION_AMOUNT_STEP", t0."C_AUCTION_AOFFALL", 
> t0."C_AUCTION_MAX_AMOUNT", t0."C_MAX_LENGHT", t0."C_AUCTION_MIN_AMOUNT", 
> t0."C_AUCTION_CHDELAY", t0."C_MIN_LENGTH", t0."C_AUCTION_MINSTART", 
> t0."C_AUCTION_NEXT_SEQ", t0."C_AUCTION_CONCUR", t0."C_CREATION_DATE", 
> t0."C_CREATOR_ID", t0."C_FIELD_IDENTIFIERS_FOR_EDITOR", 
> t0."C_FIELD_IDENTIFIERS_FOR_FILTER", t0."C_FIELD_IDENTIFIERS_FOR_LIST", 
> t0."C_FIELD_IDENTIFIERS_FOR_OFFER", t0."C_FIELD_IDENTIFIERS_FOR_PUBLIC", 
> t0."C_FORM_TEMPLATE_ID", t0."C_MARKET_BANNER_CZ_DATA", 
> t0."C_MARKET_BANNER_EN_DATA", t0."C_MARKET_BANNER_CZ_MIME", 
> t0."C_MARKET_BANNER_EN_MIME", t0."C_SUPPORTS_OFFERS", t0."C_SHORTCUT", 
> t0."C_TITLE", t0."C_UID", t0."C_WIDTHS_FOR_LIST" FROM "T_MARKET" t0 WHERE 
> t0."C_UID" = 101;
> --6 0x1039f41d8 0x1039f44b0 2015-01-26 14:10:05.55903 "1 0"
> --7 0x1039f41d8 0x1039f44b0 2015-01-26 14:10:05.55905 ""
> --8 0x1039f41d8 0x1039f44b0 2015-01-26 14:10:05.55907 "1"
> --2 0x1039f41d8 0x1039f44b0 2015-01-26 14:10:05.55976 7 48430
> commit;
> --6 0x1039f41d8 0x1039f44b0 2015-01-26 14:10:05.55984 "1 0"
> --3 0x1040841d8 0x1040844b0 2015-01-26 14:20:40.50016
> ...
> ===
> 
> If anybody can see what on earth might have happened, I'd be grateful for any 
> advice. Myself, I just can see the app locked _somehow_ and stopped working 
> at all, but have no idea why and how to prevent that...
> 
> Note: the direct action worked flawlessly (and is in the logs) in the same 
> instance each previous R/R loop, more than 2000 times.
> 
> Thanks,
> OC
> 
> 
> ___
> 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/rgurley%40smarthealth.com
> 
> This email sent to rgur...@smarthealth.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

Might in some conditions EOUtilities.objectWithPrimaryKeyValue lock the application?

[OC]

Hello there,

another weird case: this application is run single-instance (but 
ERXObjectStoreCoordinatorPool.maxCoordinators=3, 
WOAllowsConcurrentRequestHandling=true).

Yesterday after 14:10 users reported “No instance” or “Application not found” 
WO reports. Now, I log all R/R loops in Application.awake and 
Application.sleep; indeed at 14:10 a R/R loop did start and never ended, 
actually, almost nothing happened till the app was restarted by the 
administrator at 14:20. (I am told JavaMonitor has not been able to stop the 
instance normally, and it had to be killed/force quit.)

The single thing which did happen looks like this in my log:

===
//
// R/R loop #2218 WorkerThread118 started at 14:10:05 26.1.
//
DA: reading CZ banner image for market 101...
14:20:39.844 WARN  Force Quit received. Exiting now...   //log:NSLog 
[Thread-3]
APPLICATION SHUTDOWN SEQUENCE COMPLETE
===

The “reading banner“ log comes from a direct action:

===
WOActionResults bannerAction {
def 
mpk=request().formValueForKey('mkpk'),lang=request().formValueForKey('lang')
println "DA: reading $lang banner image for market $mpk..."
if (!mpk || !lang) return null
ERXEC ec=ERXEC.newEditingContext()
DBMarket market=EOUtilities.objectWithPrimaryKeyValue(ec,'DBMarket',mpk 
as Integer)
println "DA: ... $market" //*
if (!market) return null
def 
mime=market."marketBannerMIME$lang",data=market."marketBannerData$lang"
println "DA: ... mime '$mime' data $data.length B"
WOResponse wor=new WOResponse()
wor.setHeader(mime,"content-type")
...
wor.setContent(data)
wor
}
===

Note the //* log is not present, which suggests that 
EOUtilities.objectWithPrimaryKeyValue did lock somehow?!? Neither any other R/R 
loop starts, which looks like not only WorkerThread118 did block, but that the 
instance stopped accepting requests at all.

The FrontBase log (which I regret to say I do not fully understand, namely, 
those “--N lines, of which I get just the timestamp”) looks like this:

===
...
--6 0x1039f41d8 0x1039f44b0 2015-01-26 14:10:05.53996 "1 0"
--D 0x1039f41d8 0x1039f44b0 2015-01-26 14:10:05.55851 752 48429
SELECT t0."C_AUCTION_AMOUNT_STEP", t0."C_AUCTION_AOFFALL", 
t0."C_AUCTION_MAX_AMOUNT", t0."C_MAX_LENGHT", t0."C_AUCTION_MIN_AMOUNT", 
t0."C_AUCTION_CHDELAY", t0."C_MIN_LENGTH", t0."C_AUCTION_MINSTART", 
t0."C_AUCTION_NEXT_SEQ", t0."C_AUCTION_CONCUR", t0."C_CREATION_DATE", 
t0."C_CREATOR_ID", t0."C_FIELD_IDENTIFIERS_FOR_EDITOR", 
t0."C_FIELD_IDENTIFIERS_FOR_FILTER", t0."C_FIELD_IDENTIFIERS_FOR_LIST", 
t0."C_FIELD_IDENTIFIERS_FOR_OFFER", t0."C_FIELD_IDENTIFIERS_FOR_PUBLIC", 
t0."C_FORM_TEMPLATE_ID", t0."C_MARKET_BANNER_CZ_DATA", 
t0."C_MARKET_BANNER_EN_DATA", t0."C_MARKET_BANNER_CZ_MIME", 
t0."C_MARKET_BANNER_EN_MIME", t0."C_SUPPORTS_OFFERS", t0."C_SHORTCUT", 
t0."C_TITLE", t0."C_UID", t0."C_WIDTHS_FOR_LIST" FROM "T_MARKET" t0 WHERE 
t0."C_UID" = 101;
--6 0x1039f41d8 0x1039f44b0 2015-01-26 14:10:05.55903 "1 0"
--7 0x1039f41d8 0x1039f44b0 2015-01-26 14:10:05.55905 ""
--8 0x1039f41d8 0x1039f44b0 2015-01-26 14:10:05.55907 "1"
--2 0x1039f41d8 0x1039f44b0 2015-01-26 14:10:05.55976 7 48430
commit;
--6 0x1039f41d8 0x1039f44b0 2015-01-26 14:10:05.55984 "1 0"
--3 0x1040841d8 0x1040844b0 2015-01-26 14:20:40.50016
...
===

If anybody can see what on earth might have happened, I'd be grateful for any 
advice. Myself, I just can see the app locked _somehow_ and stopped working at 
all, but have no idea why and how to prevent that...

Note: the direct action worked flawlessly (and is in the logs) in the same 
instance each previous R/R loop, more than 2000 times.

Thanks,
OC


 ___
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

Re: AjaxModalContainer

[Chuck Hill]

Hi Michael,

Those errors don't help much.  They suggest that one or more JavaScript files 
is not getting loaded.

Look in your page source, you should see lines like this:







AOD, for example, is in wonder.js.  Are the URLs in your page correct?  What 
happens if you access them directly?

Chuck

On 2015-01-27, 1:23 AM, "Miguel Angerer" wrote:

I was running it on DirectConnection but i changed it now to Apache and the 
problem is still the same.

I will copy the error code right below this massage.

[Error] ReferenceError: Can't find variable: AOD
eval code (undefined, line 1)
eval ([native code], line 0)
(anonymous function) (prototype.js, line 634)
map ([native code], line 0)
(anonymous function) (prototype.js, line 1256)
evalScripts (prototype.js, line 634)
evalScripts ([native code], line 0)
(anonymous function) (prototype.js, line 434)

[Error] ReferenceError: Can't find variable: ASB
onclick (2.0.3.3.5.2.1.0.1.0.1.1.0.0, line 1)

those are the two errors i get when i inspect the SubmitButton.

Thanks a lot for helping me

Regards Miguel Angerer
On 23 Jan 2015, at 14:17, Miguel Angerer 
mailto:miguel.ange...@rucotec.ch>> wrote:
Hello
I planed to use one of the Ajax Examples in my Projekt.
One of the Bindings for a ModalContainer is called 'locked' which is optional 
but i don't want the modal to close when the user clicks on the outside of the 
box. The modal can just be closed by pressing the save button that why i put 
locked = "true";
Now i have the problem that when i start the application the save button 
doesn't work at all. When i inspect the elements i get a few errors: Can't find 
variable : AOD
Can't find variable : ASB
I have all the important Frameworks but i can't get to the AjaxSubmitButton.
If someone knows anything please help me i appreciate it.
regards, Miguel Angerer


___
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/chill%40gevityinc.com

This email sent to ch...@gevityinc.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

Re: maven.wocommunity.org is down

[Henrique Prange]

Hi Dennis,

The repository is back up. Thanks for reporting the problem.

Cheers,

Henrique

> On 27/01/2015, at 13:36, Dennis Bliefernicht 
>  wrote:
> 
> Hi everyone,
> 
> looks like it is down again, pinging here, hopefully someone can fix it :-)
> 
> Greetings
> Dennis
> ___
> 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/hprange%40gmail.com
> 
> This email sent to hpra...@gmail.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

Re: maven.wocommunity.org is down

[Theodore Petrosky]

sorry my bad. it’s the snow.maven is down!




On Jan 27, 2015, at 10:36 AM, Dennis Bliefernicht 
 wrote:

> Hi everyone,
> 
> looks like it is down again, pinging here, hopefully someone can fix it :-)
> 
> Greetings
> Dennis
> ___
> 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/tedpet5%40yahoo.com
> 
> This email sent to tedp...@yahoo.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

Re: maven.wocommunity.org is down

[Theodore Petrosky]

I just viewed the site!!!

and again. maybe it’s the snow.


On Jan 27, 2015, at 10:36 AM, Dennis Bliefernicht 
 wrote:

> Hi everyone,
> 
> looks like it is down again, pinging here, hopefully someone can fix it :-)
> 
> Greetings
> Dennis
> ___
> 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/tedpet5%40yahoo.com
> 
> This email sent to tedp...@yahoo.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

Re: maven.wocommunity.org is down

[Dennis Bliefernicht]

Hi everyone,

looks like it is down again, pinging here, hopefully someone can fix it :-)

Greetings
Dennis
 ___
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

Re: AjaxModalContainer

[Miguel Angerer]

I was running it on DirectConnection but i changed it now to Apache and the 
problem is still the same.

I will copy the error code right below this massage.

[Error] ReferenceError: Can't find variable: AOD
eval code (undefined, line 1)
eval ([native code], line 0)
(anonymous function) (prototype.js, line 634)
map ([native code], line 0)
(anonymous function) (prototype.js, line 1256)
evalScripts (prototype.js, line 634)
evalScripts ([native code], line 0)
(anonymous function) (prototype.js, line 434)

[Error] ReferenceError: Can't find variable: ASB
onclick (2.0.3.3.5.2.1.0.1.0.1.1.0.0, line 1)

those are the two errors i get when i inspect the SubmitButton.

Thanks a lot for helping me

Regards Miguel Angerer
> On 23 Jan 2015, at 14:17, Miguel Angerer  wrote:
> 
> Hello
> 
> I planed to use one of the Ajax Examples in my Projekt.
> 
> One of the Bindings for a ModalContainer is called ‘locked' which is optional 
> but i don’t want the modal to close when the user clicks on the outside of 
> the box. The modal can just be closed by pressing the save button that why i 
> put locked = “true”;
> 
> Now i have the problem that when i start the application the save button 
> doesn’t work at all. When i inspect the elements i get a few errors: 
> Can’t find variable : AOD
>   Can’t find variable : ASB
> 
> I have all the important Frameworks but i can’t get to the AjaxSubmitButton.
> 
> If someone knows anything please help me i appreciate it.
> 
> regards, Miguel Angerer


 ___
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

Re: wiki.wocommunity.org down

[Stefan Klein]

Just a hint:

The recordings of WOWODC 2014 are not available on the wiki pages.
But you can find them in iTunes Store searching for „WebObjects Podcasts“.

Stefan




> Am 26.01.2015 um 10:58 schrieb Pascal Robert :
> 
> I found a backup from February 2014, so the older version of Confluence with 
> that backup is now online. 
> 
>> Le 2015-01-20 à 14:16, Chuck Hill  a écrit :
>> 
>> There was an unfortunate migration disaster.  Pascal is waiting for guidance 
>> from the vendor.  I am not aware of an alternative, other than 
>> https://archive.org/web/ which is a bit out of date.
>> 
>> 
>> Chuck
>> 
>> 
>> On 2015-01-20, 11:10 AM, "Jeffrey Simpson" wrote:
>> 
>> When I go to the wiki.wocommunity.org I get a confluence upgrade failure 
>> page.  Does anyone know when it is going to be up?
>> 
>> I am installing a new server and do it so seldom that I want to have a walk 
>> through.  Is there an alternative?
>> 
>> 
>> Jeffrey Simpson
>> Senior Software Engineer
>> Information Technology
>> Youth For Understanding USA
>> Telephone: 202.774.5266
>> Toll Free: 800.424.3691
>> Fax:202.588.7570
>> Website: http://yfuusa.org
>> 
>> 
>> 
>> 
>> 
>> ___
>> 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/chill%40gevityinc.com
>> 
>> This email sent to ch...@gevityinc.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/probert%40macti.ca
>> 
>> This email sent to prob...@macti.ca
> 
> 
> ___
> 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/stefan.klein%40buero-sde.de
> 
> This email sent to stefan.kl...@buero-sde.de

 ___
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