Cheers, The online demo (http://mmyco.co.uk:8180/isis-onlinedemo/wicket/) is as reponsive as my local chats demo, the former is reasonable given the server is on the other side of the planet, but the later should fly. I wondered if it was logging in debug mode, but your theory sounds a similar issue.
On Wed, Jun 10, 2015 at 9:06 PM, Dan Haywood <[email protected]> wrote: > On 10 June 2015 at 11:51, Stephen Cameron <[email protected]> > wrote: > > > > > > > One question, response does seem a bit slow to me, given that all tiers > are > > on the same machine, and one user, is this normal? I guess maybe yes as > > there is no page compiling/caching? > > > > We have noticed that Isis has slowed down over the last release or so > (especially when I compare to some screencasts I made a while back on > earlier versions). I do have a theory on that. > > Prior to 1.8.0 we had an @ActionInteraction annotation (also > @PropertyInteraction, @CollectionInteraction), and if present these allowed > a domain event to be fired for those annotated members. In fact, the event > would be fired five times, for > hide/disable/validate/pre-execute/post-execute. Subscribers on the event > could/can veto the action etc as required. > > In 1.8.0 we deprecated those annotations and introduced > @Action(domainEvent=...) etc. What I've realised since is that we now > *always* raise these events for every member, using default event classes > if the domainEvent isn't specified. That's an awful lot of events being > fired. > > If my tests confirm that is the issue, then for 1.9.0 I'm thinking of > extending @Action to be able to turn domainEvents off globally and then > enable as required (ie reinstate the pre-1.8.0 behaviour). > > will let you know. > > Dan > > > > > > > > > > > [1] https://github.com/Stephen-Cameron-Data-Services/isis-chats > > >
