Performance issue

2016-03-14 Thread Gerald Jones
Aloha Group,

 

Can anyone explain to me what's happening in these lines in our log file?
We are experiencing high application cpu% that seem to coincide with  this
type of activity.  I'm not sure how to explain it.

 

METSAdmin-2

java.lang.RuntimeException: Session Created

at com.mauishuttle.app.Session.(Session.java:20)

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)

at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAcces
sorImpl.java:39)

at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstruc
torAccessorImpl.java:27)

at java.lang.reflect.Constructor.newInstance(Constructor.java:513)

at java.lang.Class.newInstance0(Class.java:355)

at java.lang.Class.newInstance(Class.java:308)

at
com.webobjects.foundation._NSUtilities.instantiateObject(_NSUtilities.java:6
42)

at
com.webobjects.appserver.WOApplication.createSessionForRequest(WOApplication
.java:1974)

at
er.extensions.appserver.ERXApplication.createSessionForRequest(ERXApplicatio
n.java:2361)

at
com.webobjects.appserver.WOApplication._initializeSessionInContext(WOApplica
tion.java:2110)

at com.webobjects.appserver.WOContext.session(WOContext.java:369)

at
com.webobjects.appserver.WOComponent.session(WOComponent.java:1324)

at com.mauishuttle.components.Main.session(Main.java:59)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)

at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)

at java.lang.reflect.Method.invoke(Method.java:597)

at
com.webobjects.foundation.NSKeyValueCoding$ValueAccessor$1.methodValue(NSKey
ValueCoding.java:636)

at
com.webobjects.foundation.NSKeyValueCoding$_MethodBinding.valueInObject(NSKe
yValueCoding.java:1134)

at
com.webobjects.foundation.NSKeyValueCoding$DefaultImplementation.valueForKey
(NSKeyValueCoding.java:1324)

at
com.webobjects.appserver.WOComponent.valueForKey(WOComponent.java:1736)

at
com.webobjects.foundation.NSKeyValueCoding$Utility.valueForKey(NSKeyValueCod
ing.java:447)

at
com.webobjects.foundation.NSKeyValueCodingAdditions$DefaultImplementation.va
lueForKeyPath(NSKeyValueCodingAdditions.java:216)

at
com.webobjects.appserver.WOComponent.valueForKeyPath(WOComponent.java:1804)

at
com.webobjects.appserver._private.WOKeyValueAssociation.valueInComponent(WOK
eyValueAssociation.java:50)

at
com.webobjects.appserver.WOAssociation.booleanValueInComponent(WOAssociation
.java:276)

at
er.extensions.components.conditionals.ERXWOConditional.conditionInComponent(
ERXWOConditional.java:47)

at
er.extensions.components.conditionals.ERXWOConditional.meetsConditionInCompo
nent(ERXWOConditional.java:52)

at
er.extensions.components.conditionals.ERXWOConditional.appendToResponse(ERXW
OConditional.java:124)

at
com.webobjects.appserver._private.WODynamicGroup.appendChildrenToResponse(WO
DynamicGroup.java:126)

at
com.webobjects.appserver._private.WODynamicGroup.appendToResponse(WODynamicG
roup.java:136)

at
com.webobjects.appserver.WOComponent.appendToResponse(WOComponent.java:1122)

at
er.extensions.components.ERXComponent.appendToResponse(ERXComponent.java:195
)

at
com.mauishuttle.components.wrappers.PageWrapper.appendToResponse(PageWrapper
.java:36)

at
com.webobjects.appserver._private.WOComponentReference.appendToResponse(WOCo
mponentReference.java:135)

at
com.webobjects.appserver._private.WODynamicGroup.appendChildrenToResponse(WO
DynamicGroup.java:126)

at
com.webobjects.appserver._private.WODynamicGroup.appendToResponse(WODynamicG
roup.java:136)

at
com.webobjects.appserver.WOComponent.appendToResponse(WOComponent.java:1122)

at
er.extensions.components.ERXComponent.appendToResponse(ERXComponent.java:195
)

at
com.mauishuttle.components.pages.DashboardPage.appendToResponse(DashboardPag
e.java:42)

at
com.webobjects.appserver.WOComponent._appendPageToResponse(WOComponent.java:
1574)

at
com.webobjects.appserver.WOComponent._generateResponseInContext(WOComponent.
java:1543)

at
com.webobjects.appserver.WOComponent.generateResponse(WOComponent.java:1538)

at
com.webobjects.appserver._private.WOActionRequestHandler._handleRequest(WOAc
tionRequestHandler.java:278)

at
com.webobjects.appserver._private.WOActionRequestHandler.handleRequest(WOAct
ionRequestHandler.java:161)

at
er.extensions.appserver.ERXDirectActionRequestHandler.handleRequest(ERXDirec
tActionRequestHandler.java:128)

at
com.webobjects.appserver.WOApplication.dispatchRequest(WOApplication.java:16
87)

at

Re: WebObjects and Apache 2.4 on El Capitan

2016-03-14 Thread Mark Gowdy
Seriously, where were you 4 days ago, when I need all this !!!

My biggest problem with El Capitan was with Apache.  Someone had installed the 
OS X Server components, and it was hi-jacking port 80 (in a kinda random way).
I ended up finding its config, removing port 80 from its list of ports.  
Finally, I installed Apache using brew and got it to work that way instead.

Nuked it from space, was the only way to be sure.

Mark

> On 12 Mar 2016, at 17:14, Patrick Middleton  wrote:
> 
> Hi folks,
> 
> mod_WebObjects?  Since people are still discussing how to build the Apache 
> adaptors on contemporary OSX, maybe I should add some more commentary.
> 
> If you need an Apache module that isn't supplied prebuilt for you, either as 
> part of Apache or as part of what your vendor supplies, always be ready to 
> build your own.  Never go looking to download what someone else has already 
> built.  It's too likely that the pre-built one won't work for you.
> 
> If you compile something in Java ... you get bytecode, and the class format 
> is defined.  Your bytecode can be expected to run in somebody else's JVM.  
> Also, if your code subclassed a class, and the class you subclassed is 
> somehow different, has more member fields, it will all still work just fine.
> 
> In C, by comparison ... Apache is implemented in C.  It is structures and 
> pointers and offsets.  How big are short, int and long?  How does the 
> compiler align these to word boundaries? The size of a structure can be very 
> different if compiled with different compilers or different compilation 
> options, especially compilation options to do with optimization, even if the 
> C source code declaring the structure is the same.  The compiler knows the 
> addresses of fields within a structure by computing offsets from the 
> structure's address; this can cause something in Objective-C 1 called 
> 'fragile base class syndrome' where adding an instance variable to a class 
> breks all subclasses of that class that have instance variables so, avoid 
> all this.  Build your own!
> 
> Apache provides a way round these problems.  Apache modules are supposed to 
> be built via a tool /usr/sbin/apxs ["APache eXtension System"] which is a 
> /usr/bin/perl script to compile and link your source code using the same 
> compiler options as was used to build Apache.
> 
> From memory, we can start by downloading some ProjectWonder source code, and 
> this includes source code for mod_WebObjects, and someone's already added a 
> makefile for building for Apache 2.4 (it's more or less the same as building 
> for Apache 2.2).  I tried this on OSX 10.11 ('El Capitan') mostly to see how 
> it would fail.
> 
> Firstly, the build fails because the Makefiles specify building the FastCGI 
> adaptor and by defautl we're missing some headers.  We can fix that in 
> make.config by setting
> ADAPTORS = CGI Apache2.4
> 
> Secondly, Apache 2.4 was built for El Capitan by cross-compilation on 
> Yosemite (10.10).  There are some references to this which we need to deal 
> with.  Reading /usr/sbin/apxs (on OSX) we find it has a variable 
> installbuilddir = /usr/share/httpd/build and some configuration variables in 
> a file config_vars.mk in that directory.
> 
> There are references to 
> /Applications/Xcode.app/Contents/Developer/Toolchains/OSX10.11.xctoolchain , 
> you might have that if you are on Yosemite and have the El Capitan SDK 
> installed.  There are references to 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.Internal.sdk
>  .  We fix these by making softlinks that refere to what we do have.  For me, 
> this was (as root):
> 
> cd /Applications/Xcode.app/Contents/Developer/Toolchains
> pwd
> ls -l
> ln -s XcodeDefault.xctoolchain OSX10.11.xctoolchain
> ls -l
> cd 
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/
> pwd
> ls -l
> ln -s MacOSX10.11.sdk MacOSX10.11.Internal.sdk
> ls -l
> 
> I also encountered an error about not being able to find httpd.h.  There's 
> this in make.config:
> APACHEINCLUDE_DIR = /usr/include/apache2
> 
> which doesn't work on modern OSX because Apple appears to have decided not to 
> do /usr/include any more.  We need to use the platform SDKs.  I added some 
> stuff to make.config to work out which release of OSX the build was happening 
> on, what the SDK path should be, and using the SDK path when setting 
> APACHEINCLUDE_DIR.
> 
> Next up: there was a linker flag "-macosx_version_min 10.5" which we don't 
> want on OSX 10.8 and later.  I changed this to be a variable which is empty 
> unless on 10.4, 10.5, 10.6 or 10.7.
> 
> And that's enough to get the Adaptors project to compile and link.  I've 
> provided both a patch file of my changes, and a .tar.gz file of the files I 
> changed, which some may find easier to read.  Submitting a patch file to this 
> list is not the approved way of proposing changes to Project 

Re: a trick to model a complex derived relationship?

2016-03-14 Thread Markus Ruggiero
I may be at bit late to the discussion

Isn't what Chuck described basically a sinlge table inheritance?

You could create SUB-Types based on you User and create separate relationships 
to each sub-type (NOT to the generic super type!). This should work 
transparently then.

Model something like this...

User, then AuctionUser as subtype of User, ActionOwner as subtype of User, etc. 
use single table inheritance with userType as restricting qualifier.

Then model respective relationships:

Auction <<-> ActionOwner

This should allow you to create the needed qualifiers for a fetch.

---markus---


> On 07.03.2016, at 19:12, OC  wrote:
> 
> Chuck,
> 
> short version: with key (not keypath) restrictingQualifier it, alas, does not 
> work either.
> 
> Thanks again a big lot for all the help!
> OC
> 
> Long version if anybody interested:
> 
> (a) given there are two entities, Source and Destination, and a relationship 
> Source.rel ->> Destination
> (b) and we need to model a “derived relationship” with a behaviour same as 
> e.g., this Java-side implementation gives:
> 
> def derivedRel() {
>  rel().findAll { it.someAttribute==SOME_VALUE }
> }
> 
> the following trick _does not_ work:
> 
> (i) define a new entity, FilteredDestination, with a restrictingQualifier 
> "someAttribute = SOME_VALUE"
> (ii) define a new relationship, Source.derivedRel ->> FilteredDestination 
> with same joins as rel has
> 
> We hoped that EOF would use the FilteredDestination's restrictingQualifier 
> when resolving Source.derivedRel. Alas, it does not; it simply performs the 
> joins (which were set up through the original "rel" relationship to contain 
> “invalid“ FilteredDestination rows, too), and returns all the rows Source.rel 
> would.
> 
> (The restrictingQualifier is properly used when fetching FilteredDestination 
> directly; alas, not when resolving relationships which lead to it /or, in 
> case of flattened ones, go through it/.)
> 
> 
> On 6. 3. 2016, at 18:38, OC  wrote:
> 
>> Chuck,
>> 
>> On 4. 3. 2016, at 5:26, Chuck Hill  wrote:
>> 
>> Defining additional entities with the appropriate restricting qualifiers 
>> for these conditions might possibly work.  Then you could define the 
>> flattened relationship in terms of these restricted entities.
> 
> ... Thank you for the advice; I'll check the possibility of qualified 
> entities (of which I completely have forgot!), it might lead to a cleaner 
> and more efficient code.
 
 Hmmm, let me see whether I understood you properly. At the moment, I have
 
 (a) entities Auction, UserAuction, User
 (b) relationships Auction.userAuction ->> UserAuction and UserAuction.user 
 -> User
 
 For given Auction, I need to model a relationship auctionOwner -> User, 
 defined (for the testing at the moment simply) as
 (i) Auction.userAuction.user exists
 (ii) Auction.userAuction.user.userType==4
 
 So, I have
 
 - defined a new entity OwnerAuction, which is essentially a copy of 
 UserAuction, but contains 'restrictingQualifier = "user.userType = 4";'
>>> 
>>> Isn’t that one supposed to restrict accessAllowed?
>> 
>> Right. For testing, I sticked with one of the restrictions (which is user 
>> type); the other one (accessAllowed) I intended to add later, when this one 
>> works.
>> 
>>> I think you would want the userType=4 restriction on OwnerAuctionUser (or 
>>> whatever you want to call it).
>> 
>> Aha, so EOF would grant only key (*not* keypath) restrictions when resolving 
>> relationships?
>> 
>> Should occur to me. I'll try, thanks!
>> 
 - defined a new relationship Auction.internalOwnerAuction -> OwnerAuction, 
 with precisely same join as Auction.userAuction
 - defined a flattened relationship Auction.ownerAuction -> User, defined 
 as "internalOwnerAuction.user"
 
 This is what you meant, or did I do something wrong?
>>> 
>>> That is not quite what I had in mind, see above.
>> 
>> Now I see -- I shall try to make two new entities, each one restricted using 
>> only its keys, not keypaths; and hopefully it'll work. We'll see, I'll let 
>> you know.
>> 
>>> ...
>>> It was just an idea on how you might abuse EOF to achieve your goal.  It 
>>> might not work.
>> 
>> Of course, self-evidently EOF was not designed to do things like this, and 
>> it'll be rather a luck if it works.
>> 
>> If the worst comes to the worst, I can go back to my three-phase-manual 
>> implementation, fetching PKs at first, and then “modelling” the conditions 
>> by subsequent fetches (the drawback is _considerably_ more complex Java 
>> code).
>> 
>> Thanks a very 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:
>>