Re: JoavaMonitor question

[Paul Hoadley]

Hi Ted,

On 26 Oct 2016, at 8:51 AM, Theodore Petrosky  wrote:

> I think you are saying that JavaMonitor should only be accessed by the direct 
> connect port.
> 
> I never read that anywhere, and I have alway create an instance to 
> JavaMonitor. Is this a bad practice?

I just don’t think you need to do it. Am I understanding you correctly: you’ve 
used JavaMonitor to create and launch another instance of JavaMonitor? If so, 
no I wouldn’t do that. The instance launched by /etc/init.d/webobjects will be 
sufficient, and you can access it via SSH tunnelling as I described elsewhere. 
No need to open 56789 to the outside world. No one should be hitting your 
JavaMonitor instance except you, indirectly via your SSH tunnel.


-- 
Paul Hoadley
http://logicsquad.net/



 ___
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: JoavaMonitor question

[Lon Varscsak]

I think the general thought is that you don’t want that accessible
externally.  If you run it in direct connect mode and then make sure that
port isn’t accessible via your firewall you should be “safe”.

-Lon

On Tue, Oct 25, 2016 at 3:21 PM, Theodore Petrosky 
wrote:

> I think you are saying that JavaMonitor should only be accessed by the
> direct connect port.
>
> I never read that anywhere, and I have alway create an instance to
> JavaMonitor. Is this a bad practice?
>
> Please be kind, I am showing my ignorance here hoping to be edified.
>
>
> Ted
>
>
> On Oct 25, 2016, at 6:17 PM, Paul Hoadley  wrote:
>
> Hi Ted,
>
> On 26 Oct 2016, at 2:48 AM, Theodore Petrosky  wrote:
>
> Why is it that I can only access the application scheduling or Application
> Settings sections of JavaMonitor when I access it with the direct connect
> (:56789)? these sections are not accessible if I use the running app.
> http://something.com/apps/Webobjects/JavaMonitor
>
>
> Are you doing something strange here? Why is JavaMonitor even accessible
> via that URL?
>
>
> --
> Paul Hoadley
> http://logicsquad.net/
>
>
>
>
>
>  ___
> 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/lon.varscsak%40gmail.com
>
> This email sent to lon.varsc...@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: log4j bug causes deadlock?!? (was: which sort of application bugs hang wotaskd?)

[Chuck Hill]

Well, the fix seems easy if that works for you.

From:  on behalf of 
"o...@ocs.cz" 
Date: Tuesday, October 25, 2016 at 2:56 PM
To: WebObjects-Dev 
Subject: Re: log4j bug causes deadlock?!? (was: which sort of application bugs 
hang wotaskd?)

Hmmm, looks like we are not the only one who got bit by that thing in tender 
parts: http://stackoverflow.com/a/7397857

On 25. 10. 2016, at 10:59 PM, OC > wrote:
Chuck,
On 24. 10. 2016, at 18:23, Chuck Hill 
> wrote:
Running “sudo jstack –F ” should dump a trace of all threads.  
Should…
Luckily, it did; just it is sort of weird that it identifies threads by name in 
the deadlock report, but by some unknown ID (perhaps hash of the Thread 
instance, looks like that) in the traces, which makes for sort of difficult 
parsing. I guess I'm not the first one to swear :)
... As for the hang, the code in the logging does seem like a likely culprit.
Actually it looks like the culprit is log4j itself?!? What the heck! Anyroad, 
here's the deadlock report:
===
"model.ReportPDFTask@5f6ce9a5":
  waiting to lock Monitor@0x00012c0008a8 (Object@0x0003f7efb980, a 
org/apache/log4j/spi/RootLogger),
  which is held by "WorkerThread6"
"WorkerThread6":
waiting for ownable synchronizer 0x0003f9538960, (a 
java/util/concurrent/locks/ReentrantLock$NonfairSync),
which is held by "model.ReportPDFTask@5f6ce9a5"
===
the WorkerThread6 problem happens in the “log.info("$tch")” part, it looks like 
this (and although changesFromCommittedSnapshot happens to be part of the 
culprit, I believe the problem is actually caused by the logger itself): 
instead of rendering its argument immediately, as soon as it is determined that 
we should log, it does that self-evidently under a lock:
=== Worker6 (cleaned up considerably) ===
- er.extensions.eof.ERXEC.lockObjectStore() // the lock W6 [2] hangs on, caused 
by...
- er.extensions.eof.ERXGenericRecord.changesFromCommittedSnapshot() // ... 
changesFromCommittedSnapshot ...
- cz.ocs.model.OCSEnterpriseObject.toString() // ... which yours truly dumbly 
uses in toString, alas!
- org.apache.log4j.or.DefaultRenderer.doRender(java.lang.Object) // ... this 
thing happens INSIDE of log4j code
... lot of frames here; self-evidently, some of them acquires and holds 
Monitor@0x00012c0008a8 [1] ...
- org.apache.log4j.Category.info(java.lang.Object) // this is the 
log.info("$tch") of mine
... the loop and the other standard stuff up to dispatchRequest and 
WOWorkerThread.run() ...
===
The "model.ReportPDFTask" actually does not do anything wrong (far as I can 
say) -- it just fetches. A fetch presumably (and understandably) would lock the 
object store. With locked object store, it... logs! (I do not think the stack 
trace is important here; anyway, I have attached it at the end of this message 
for reference.)
Nothing wrong there I believe, it feels right to be able to log with a locked 
object store; but it causes deadlock, for the log tries to acquire its 
Monitor@0x00012c0008a8 -- which is held by Worker6.
Now, although in my case the culprit happens to be unneeded (and generally 
dangerous) changesFromCommittedSnapshot, I believe that
(a) whatever which locks object store in the log would cause deadlock just as 
well
(b) which can be e.g., a fault fired, or lots of other perfectly valid things 
to log.
I do understand why log4j methods accept generic Object and render the result 
inside -- it is reasonable not to render anything unless we want to log with 
the current setting.
What seems to me to be a grave bug though is that this rendering happens under 
a lock, which causes a deadlock if two threads log concurrently and it so 
happens that
(i) one of them logs under object store lock (which I believe is valid and 
correct)
(ii) the other's log contents causes an object store lock (which again I 
believe is valid and correct, see (a) and (b) above).
So, well, is there indeed a grave bug inside of the ubiquitous log4j, or am I 
overlooking something of importance?
And if there is a bug, is there anything better one can do to work around it 
than using toStrings for all non-trivial logs, like 
“log.info("non-trivial-contents".toString())”, which would affect efficiency 
pretty bad?
Thanks and all the best,
OC
=== "model.ReportPDFTask@5f6ce9a5" slightly cleaned up ===
- org.apache.log4j.Category.callAppenders(org.apache.log4j.spi.LoggingEvent) 
@bci=12, line=204 (Compiled frame) // hangs on Monitor@0x00012c0008a8, 
which is held by [1] above
- org.apache.log4j.Category.forcedLog(java.lang.String, 
org.apache.log4j.Priority, java.lang.Object, java.lang.Throwable) @bci=14, 
line=391 (Compiled frame)
- org.apache.log4j.Category.info(java.lang.Object) @bci=38, line=666 (Compiled 
frame)
- 

Re: JoavaMonitor question

[Paul Hoadley]

Hi Ted,

On 26 Oct 2016, at 2:48 AM, Theodore Petrosky  wrote:

> Why is it that I can only access the application scheduling or Application 
> Settings sections of JavaMonitor when I access it with the direct connect 
> (:56789)? these sections are not accessible if I use the running app. 
> http://something.com/apps/Webobjects/JavaMonitor 
> 
Are you doing something strange here? Why is JavaMonitor even accessible via 
that URL?


-- 
Paul Hoadley
http://logicsquad.net/



 ___
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: AWS has surrendered!

[Paul Hoadley]

Hi Flavio,

On 26 Oct 2016, at 1:53 AM, Flavio Donadio  wrote:

> I’m gonna take a look at the script myself.
> 
> From what I understand, it’s a matter of where to find binaries for 
> JavaMonitor, wotaskd and mod_WebObjects.so. And, finally, set some parameters 
> in httpd.conf for mod_WebObjects.
> 
> Right?

Yeah, that’s roughly it. There are a few more steps, but do take a look and see 
how you go.


-- 
Paul Hoadley
http://logicsquad.net/




 ___
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: log4j bug causes deadlock?!? (was: which sort of application bugs hang wotaskd?)

[o...@ocs.cz]

Hmmm, looks like we are not the only one who got bit by that thing in tender 
parts: http://stackoverflow.com/a/7397857

> On 25. 10. 2016, at 10:59 PM, OC  wrote:
> 
> Chuck,
> 
> On 24. 10. 2016, at 18:23, Chuck Hill  wrote:
> 
>> Running “sudo jstack –F ” should dump a trace of all threads.  
>> Should… 
> 
> Luckily, it did; just it is sort of weird that it identifies threads by name 
> in the deadlock report, but by some unknown ID (perhaps hash of the Thread 
> instance, looks like that) in the traces, which makes for sort of difficult 
> parsing. I guess I'm not the first one to swear :)
> 
>> ... As for the hang, the code in the logging does seem like a likely culprit.
> 
> Actually it looks like the culprit is log4j itself?!? What the heck! Anyroad, 
> here's the deadlock report:
> 
> ===
> "model.ReportPDFTask@5f6ce9a5":
>  waiting to lock Monitor@0x00012c0008a8 (Object@0x0003f7efb980, a 
> org/apache/log4j/spi/RootLogger),
>  which is held by "WorkerThread6"
> "WorkerThread6":
> waiting for ownable synchronizer 0x0003f9538960, (a 
> java/util/concurrent/locks/ReentrantLock$NonfairSync),
> which is held by "model.ReportPDFTask@5f6ce9a5"
> ===
> 
> the WorkerThread6 problem happens in the “log.info("$tch")” part, it looks 
> like this (and although changesFromCommittedSnapshot happens to be part of 
> the culprit, I believe the problem is actually caused by the logger itself): 
> instead of rendering its argument immediately, as soon as it is determined 
> that we should log, it does that self-evidently under a lock:
> 
> === Worker6 (cleaned up considerably) ===
> - er.extensions.eof.ERXEC.lockObjectStore() // the lock W6 [2] hangs on, 
> caused by...
> - er.extensions.eof.ERXGenericRecord.changesFromCommittedSnapshot() // ... 
> changesFromCommittedSnapshot ...
> - cz.ocs.model.OCSEnterpriseObject.toString() // ... which yours truly dumbly 
> uses in toString, alas!
> - org.apache.log4j.or.DefaultRenderer.doRender(java.lang.Object) // ... this 
> thing happens INSIDE of log4j code
> ... lot of frames here; self-evidently, some of them acquires and holds 
> Monitor@0x00012c0008a8 [1] ...
> - org.apache.log4j.Category.info(java.lang.Object) // this is the 
> log.info("$tch") of mine
> ... the loop and the other standard stuff up to dispatchRequest and 
> WOWorkerThread.run() ...
> ===
> 
> The "model.ReportPDFTask" actually does not do anything wrong (far as I can 
> say) -- it just fetches. A fetch presumably (and understandably) would lock 
> the object store. With locked object store, it... logs! (I do not think the 
> stack trace is important here; anyway, I have attached it at the end of this 
> message for reference.)
> 
> Nothing wrong there I believe, it feels right to be able to log with a locked 
> object store; but it causes deadlock, for the log tries to acquire its 
> Monitor@0x00012c0008a8 -- which is held by Worker6.
> 
> Now, although in my case the culprit happens to be unneeded (and generally 
> dangerous) changesFromCommittedSnapshot, I believe that
> 
> (a) whatever which locks object store in the log would cause deadlock just as 
> well
> (b) which can be e.g., a fault fired, or lots of other perfectly valid things 
> to log.
> 
> I do understand why log4j methods accept generic Object and render the result 
> inside -- it is reasonable not to render anything unless we want to log with 
> the current setting.
> 
> What seems to me to be a grave bug though is that this rendering happens 
> under a lock, which causes a deadlock if two threads log concurrently and it 
> so happens that
> 
> (i) one of them logs under object store lock (which I believe is valid and 
> correct)
> (ii) the other's log contents causes an object store lock (which again I 
> believe is valid and correct, see (a) and (b) above).
> 
> So, well, is there indeed a grave bug inside of the ubiquitous log4j, or am I 
> overlooking something of importance?
> 
> And if there is a bug, is there anything better one can do to work around it 
> than using toStrings for all non-trivial logs, like 
> “log.info("non-trivial-contents".toString())”, which would affect efficiency 
> pretty bad?
> 
> Thanks and all the best,
> OC
> 
> === "model.ReportPDFTask@5f6ce9a5" slightly cleaned up ===
> - org.apache.log4j.Category.callAppenders(org.apache.log4j.spi.LoggingEvent) 
> @bci=12, line=204 (Compiled frame) // hangs on Monitor@0x00012c0008a8, 
> which is held by [1] above
> - org.apache.log4j.Category.forcedLog(java.lang.String, 
> org.apache.log4j.Priority, java.lang.Object, java.lang.Throwable) @bci=14, 
> line=391 (Compiled frame)
> - org.apache.log4j.Category.info(java.lang.Object) @bci=38, line=666 
> (Compiled frame)
> - 
> er.extensions.eof.ERXEOAccessUtilities.logExpression(com.webobjects.eoaccess.EOAdaptorChannel,
>  com.webobjects.eoaccess.EOSQLExpression, long) @bci=406, line=1307 (Compiled 
> frame)
> - 
> 

log4j bug causes deadlock?!? (was: which sort of application bugs hang wotaskd?)

[OC]

Chuck,

On 24. 10. 2016, at 18:23, Chuck Hill  wrote:

> Running “sudo jstack –F ” should dump a trace of all threads.  
> Should… 

Luckily, it did; just it is sort of weird that it identifies threads by name in 
the deadlock report, but by some unknown ID (perhaps hash of the Thread 
instance, looks like that) in the traces, which makes for sort of difficult 
parsing. I guess I'm not the first one to swear :)

> ... As for the hang, the code in the logging does seem like a likely culprit.

Actually it looks like the culprit is log4j itself?!? What the heck! Anyroad, 
here's the deadlock report:

===
"model.ReportPDFTask@5f6ce9a5":
  waiting to lock Monitor@0x00012c0008a8 (Object@0x0003f7efb980, a 
org/apache/log4j/spi/RootLogger),
  which is held by "WorkerThread6"
"WorkerThread6":
 waiting for ownable synchronizer 0x0003f9538960, (a 
java/util/concurrent/locks/ReentrantLock$NonfairSync),
 which is held by "model.ReportPDFTask@5f6ce9a5"
===

the WorkerThread6 problem happens in the “log.info("$tch")” part, it looks like 
this (and although changesFromCommittedSnapshot happens to be part of the 
culprit, I believe the problem is actually caused by the logger itself): 
instead of rendering its argument immediately, as soon as it is determined that 
we should log, it does that self-evidently under a lock:

=== Worker6 (cleaned up considerably) ===
 - er.extensions.eof.ERXEC.lockObjectStore() // the lock W6 [2] hangs on, 
caused by...
 - er.extensions.eof.ERXGenericRecord.changesFromCommittedSnapshot() // ... 
changesFromCommittedSnapshot ...
 - cz.ocs.model.OCSEnterpriseObject.toString() // ... which yours truly dumbly 
uses in toString, alas!
 - org.apache.log4j.or.DefaultRenderer.doRender(java.lang.Object) // ... this 
thing happens INSIDE of log4j code
... lot of frames here; self-evidently, some of them acquires and holds 
Monitor@0x00012c0008a8 [1] ...
 - org.apache.log4j.Category.info(java.lang.Object) // this is the 
log.info("$tch") of mine
... the loop and the other standard stuff up to dispatchRequest and 
WOWorkerThread.run() ...
===

The "model.ReportPDFTask" actually does not do anything wrong (far as I can 
say) -- it just fetches. A fetch presumably (and understandably) would lock the 
object store. With locked object store, it... logs! (I do not think the stack 
trace is important here; anyway, I have attached it at the end of this message 
for reference.)

Nothing wrong there I believe, it feels right to be able to log with a locked 
object store; but it causes deadlock, for the log tries to acquire its 
Monitor@0x00012c0008a8 -- which is held by Worker6.

Now, although in my case the culprit happens to be unneeded (and generally 
dangerous) changesFromCommittedSnapshot, I believe that

(a) whatever which locks object store in the log would cause deadlock just as 
well
(b) which can be e.g., a fault fired, or lots of other perfectly valid things 
to log.

I do understand why log4j methods accept generic Object and render the result 
inside -- it is reasonable not to render anything unless we want to log with 
the current setting.

What seems to me to be a grave bug though is that this rendering happens under 
a lock, which causes a deadlock if two threads log concurrently and it so 
happens that

(i) one of them logs under object store lock (which I believe is valid and 
correct)
(ii) the other's log contents causes an object store lock (which again I 
believe is valid and correct, see (a) and (b) above).

So, well, is there indeed a grave bug inside of the ubiquitous log4j, or am I 
overlooking something of importance?

And if there is a bug, is there anything better one can do to work around it 
than using toStrings for all non-trivial logs, like 
“log.info("non-trivial-contents".toString())”, which would affect efficiency 
pretty bad?

Thanks and all the best,
OC

=== "model.ReportPDFTask@5f6ce9a5" slightly cleaned up ===
 - org.apache.log4j.Category.callAppenders(org.apache.log4j.spi.LoggingEvent) 
@bci=12, line=204 (Compiled frame) // hangs on Monitor@0x00012c0008a8, 
which is held by [1] above
 - org.apache.log4j.Category.forcedLog(java.lang.String, 
org.apache.log4j.Priority, java.lang.Object, java.lang.Throwable) @bci=14, 
line=391 (Compiled frame)
 - org.apache.log4j.Category.info(java.lang.Object) @bci=38, line=666 (Compiled 
frame)
 - 
er.extensions.eof.ERXEOAccessUtilities.logExpression(com.webobjects.eoaccess.EOAdaptorChannel,
 com.webobjects.eoaccess.EOSQLExpression, long) @bci=406, line=1307 (Compiled 
frame)
 - 
er.extensions.eof.ERXAdaptorChannelDelegate.adaptorChannelDidEvaluateExpression(com.webobjects.eoaccess.EOAdaptorChannel,
 com.webobjects.eoaccess.EOSQLExpression) @bci=76, line=81 (Compiled frame)
 - com.webobjects.foundation._NSDelegate.perform(java.lang.String, 
java.lang.Object, java.lang.Object) @bci=14, line=163 (Compiled frame)
 - 

AW: ProofOfConcept of EOF-JPA-Compatibility-Layer

[Wolfgang Hartmann]

Hy,


In case someone had a look at the project and had a hard time to setup it up 
properly, I've extended it a little bit:

- Now there is a WO-Framework-Projekt for the compatibility layer and a 
WO-Application-Project with the first unit-tests which (hopefully) demonstrates 
that the concept could work.


Best regards,

Wolfy


Von: Wolfgang Hartmann 
Gesendet: Sonntag, 23. Oktober 2016 22:50:55
An: webobjects-dev@lists.apple.com
Betreff: WG: ProofOfConcept of EOF-JPA-Compatibility-Layer



Von: Wolfgang Hartmann 
Gesendet: Sonntag, 23. Oktober 2016 22:49:55
An: halbei...@hotmail.com
Betreff: ProofOfConcept of EOF-JPA-Compatibility-Layer


Sorry if this message is repeated, but I think the new version of the 
Web-Outlook broke the format of the last e-mails
-

Hy,

I have created a ProofOfConcept of an EOF-JPA-Compatibility-Layer. The basic 
concept is that in comparison to Cayenne it is not a persistency-framework 
beside of EOF, but a layer underneath EOF. Basically every call to EOF will be 
forwarded to JPA.

Therefore if the CompatiblityLayer would be finished you just could replace the 
EOF-Fetching-Framework with JPA without having to rewrite all your UseCase-, 
Fetching-or Persistency-Code. So this could be used to transfer an application 
away from EOF to another JPA-Compatible-Framework (e.g. Hibernate) very fast.

Details on the idea of the framework, the similaryity of EOF and JPA and the 
code itself is available on GitHub:
https://github.com/Wolfy42/EOF-JPA-CompatibilityLayer

Every feedback on the concept of the CompatibilityLayer or the code is 
appreciated!

Best regards,
Wolfy
 ___
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: AWS has surrendered!

[Flavio Donadio]

Paul,


I’m gonna take a look at the script myself.

From what I understand, it’s a matter of where to find binaries for 
JavaMonitor, wotaskd and mod_WebObjects.so. And, finally, set some parameters 
in httpd.conf for mod_WebObjects.

Right?


Cheers,
Flavio


> On 25 Oct 2016, at 01:34, Paul Hoadley  wrote:
> 
> Hi Flavio,
> 
> On 25 Oct 2016, at 1:06 AM, Flavio Donadio  wrote:
> 
>> Paul: if you can share that updated script, it would be nice.
> 
> The modifications largely relate to the specifics of our infrastructure setup 
> (where various artifacts come from, how to retrieve the app bundles, and so 
> on), so it wouldn’t be widely useful. If anyone has any particular issues, 
> whether they’re EC2-, Amazon Linux- or simply Unix-related, please post them 
> and we can definitely work them through.
> 
> 
> -- 
> Paul Hoadley
> http://logicsquad.net/
> 
> 
> 


 ___
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: id uuid type

[Samuel Pelletier]

Hi Theodore,

Can you be more specific about the problem you experience ? 

Any errors or description of wrong behaviour can help a lot here. 

Samuel


> Le 23 oct. 2016 à 21:33, Theodore Petrosky  a écrit :
> 
> I spent the day chasing my tail. If I use the new uuid type for my id column, 
> I lose the ability to use ERCoreBL.
> 
> is there a way to use the new uuid column type and  keep ERCoreBusinessLogic 
> intact?
> 
> Or am I missing something obvious?
> 
> Ted
> ___
> 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/samuel%40samkar.com
> 
> This email sent to sam...@samkar.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