Re: Anyone want to answer this question on Quora re: Isis?

[César Camilo Lugo Marcos]

Hello,

Oscar Bou and myself have answered this question on Quora much more
appropriately and accurately than the first misleading answer. We both
are Apache Isis users, we are not part of the Apache Isis team. I think
you might consider up-voting our answers in quota if you like them. I
think it is at least fair for the great job Apache Isis guys have been
doing.

https://www.quora.com/Whats-your-take-on-Apache-Isis


Cesar.


On Tue, 2016-08-30 at 07:41 +0100, Dan Haywood wrote:
> Hi folks,
> 
> this recent question on Quora [1] has attracted one somewhat inaccurate
> answer; would love to see some more useful answers from actual user
> community if possible.
> 
> Cheers
> Dan
> 
> [1] https://www.quora.com/Whats-your-take-on-Apache-Isis

[Fwd: Re: Error when I compile the project in the google cloud]

[César Camilo Lugo Marcos]

Here it is the one that describes why we choose to use AWS Elastic
Beanstalk and Heroku and stopped trying with Google App Engine. César.


 Forwarded Message 
From: Martin Grigorov 
To: Cesar Lugo 
Cc: Dan Haywood 
Subject: Re: Error when I compile the project in the google cloud
Date: Tue, 10 May 2016 21:18:39 +0200

Hello César,


Please see inline.


On Tue, May 10, 2016 at 6:24 PM, Cesar Lugo 
wrote:
Hello Martin. I am César Lugo, R Director of the company that
is having this issue on Google Cloud with Apache ISIS. I see
your kind response below, and also that you have tried keeping
Wicket libraries compatible with Goggle App Engine in the past,
with no success, due to certain limitations GAE imposes to the
use of some functions of Java. If possible, I would like to ask
you some guidance, to know in your experience, which route of
action would you suggest:

 

a)  Try to overcome those limitations to make the Apache ISIS
apps work in a GAE environment. If so, we would need to hire
some services of someone how has the skills to do this, and keep
in compatible with future versions of Apache ISIS. If this
something you might want to provide us? In your opinion, would
this make sense in terms of effort and ongoing compatibility?


I haven't personally used GAE for any of the projects I have worked on. 
In the past (something like 4-5 years ago) some users have tried to
deploy Wicket applications to GAE and I've tried to help them by
creating 
https://github.com/wicketstuff/core/tree/master/gae-initializer-parent. This 
project provides a Wicket library that automatically reconfigures Wicket to be 
GAE-friendlier. Since then there were no complains about problems with GAE in 
Wicket mailing lists. The reasons could be that wicketstuff-gae-initializer 
solves all the problems (doubtful!) or that people don't use Wicket+GAE 
(likely!).


If the issue is only with Webjars usage then as I suggested in my
earlier mail we could try to make Wicket-Bootstrap Webjars independant.
But I am almost certain that we will hit some other issue after that.
E.g. GAE uses Jetty 7.x which implements Servlet API 2.4 - Apache Isis
requires Servlet API 3.0.1.
Also GAE uses DataNucleus 2.x and Apache Isis uses 4.x.


GAE is intentionally designed this way so that it forbids usage of
non-scalable features of Java (java.io, threads, AWT/Swing, ...). 
I know that its Python version is used wildly. Actually they hired
Python's creator to work on it. Unfortunately this is not the case with
Java (or at least I haven't heard of big success stories).
b)  Discard GAE and try some other PaaS service. I believe this
is what Dan recommends. I see one choice here, AWS Elastic
Beanstalk. I couldn’t find any other that would provide
automatic scaling, load balancing, failover, no downtime version
deployment, monitoring, health management. Any suggestions here?


I'd also go with AWS.
About an year ago I've worked with Dan on a Isis project deployed at
Microsoft Azure. It was a good experience! But the project didn't have
high requirements for scalability. We've setup 3 Nginx instances for
load balancing and 3 Tomcat instances with the application for failover.
The database was a single PostgreSQL instance. 

 

I appreciate in advance.

 

 

Descripción:

https://gallery.mailchimp.com/a51de198df6ec3312c8f1a4f7/images/3f5e209c-acbd-4eb7-ab4e-df592f0d74f7.jpg


  


Cesar Lugo Marcos. 


Director de
Investigacion y
Desarrollo


Tamaulipas #150,
Torre "A" Piso 5
Hipódromo Condesa
06100, México D. F.
Tel.: (55) 5256.4517;
(55) 5286.0283

www.vortech-it.com 



 

 

-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org] 
Sent: Sunday, May 8, 2016 2:23 PM
To: Dan Haywood
Cc: users
Subject: Re: Error when I compile the project in the google
cloud

 

Hi,

 

The problem is not with the compilation of the project but at
runtime during start:

 

at


de.agilecoders.wicket.webjars.WicketWebjars.install(WicketWebjars.java:75)

at


org.apache.isis.viewer.wicket.viewer.IsisWicketApplication.configureWebJars(IsisWicketApplication.java:342)

 

Google AppEngine has many 

Re: Adventures in Apache Isis...

[César Camilo Lugo Marcos]

Deacon,

What a great summary, congratulations!

I want to take the opportunity to add some stuff:

More great stuff:
- We have tested our Apache ISIS application in an AWS cloud load
balanced environment including some level of volume concurrency testing.
So far so good. We are expecting to have millions of users, and so far
it looks like, with proper load balancing and fail-over, it will do the
job.

- We are using it in conjunction with mobile applications leveraging the
flexibility and automation of N.O. restful services. It's just amazing
how it simplifies RESTful services consumption in a mobile environment,
particularly the ability to "join" results with the xo prefix.

More wish list:
- Mutable collections grids in the wicket viewer.
- Image collections shown as images.
- Configurable UI filters by domain entities, allowing to filter by
multiple attributes, with multiple types of filters (radio, range,
boolean condition).
- More business needs oriented add-ons, particularly if they follow
industry-standards through the use of ontologies. So far the ones
available are more technical, and they do a great job, like maps, audit
and multi-tenant.

I think the RO domain model and the restful services are quite mature
and powerful, and the wicket viewer is a little behind but evolving in
the right direction. Also, Dan mentioned that eventually they will add
some more powerful viewers, which sounds quite exciting!.

César.

On Fri, 2016-07-15 at 18:11 +0200, Deacon Frost wrote:
> I successfully delivered my first "real" Apache Isis application today --
> YAY!! -- and would like to share my experience.
> 
> My background: I am a reasonably experienced developer proficient in custom
> application development in C#, Java, Javascript, Python etc. but never
> touched Apache Isis nor Apache Wicket nor DataNucleus before, my Java chops
> are a bit rusty and I am a complete Maven noob.
> 
> I have been following NakedObjects since the early 2000's and am quite
> intrigued by its philosophy and promises but never mad the "plunge" to
> actually implement a project for a client with it. I checked out Apache
> Isis on and off (hey, I even bought and enjoyed Dan's book in 2009 or so)
> but - without wanting to sound blasé - the UI was never quite up to my
> taste (the .NET-Version was even worse). But the recent changes to the look
> and feel of the Bootstrap Wicket interface made me confident to finally be
> able to "sell" it to clients.
> 
> The target application is - in a nutshell - an internal web-application for
> a government department to define and configure traffic webcams (~1000),
> locate them interactively on a map, display their latest images, link them
> to their road network data etc. Nothing too complex but the right size to
> try something new, I guess.
> 
> The great:
> I implemented a working prototype of the application in under a week(!),
> which already looked very polished and had lots of "bells and whistles",
> like a Google Maps interface, display of live images, Excel-export,
> auditing-service, REST-interface etc.. The client was positively surprised
> by the polished looks and richness of features and went for it. So, within
> two weeks after that I was able to implement the complete application,
> reusing most of the work implemented in the prototype.
> 
> I had to implement two Isis wicket components:
> - Display of a map (Locatable) based on OpenStreetMap:
>  I had trouble getting the Google map interface to work in the client's
> environment. It kept complaining about application keys etc. and wasn't
> usable at all. Thanks to the "wicket stuff" implementation of openlayers3
> and a shameless "raid" of Dan's gmap3-isis-component I was able to build an
> openlayers3-isis-component myself, despite my utter isis/wicket noob-ness.
> - Display of static image resources:
>  The "standard" Blob-interface didn't cut it for me because it only
> displays a thumbnail image (which was even of a bigger byte size and lower
> resolution than the original) of an image resource from memory/db. I was
> able to build an Isis ExternalImageUrl-component by copying much of the
> Blob/Clob-component but using static URLs, which works flawlessly for
> displaying the original images based on an "ExternalImageUrl"-Property of
> the entity.
> 
> (Once the dust has settled I want to contribute the openlayers3- and static
> image components. Maybe one of you guys can provide me with a little
> guidance how to set that up...)
> 
> I had some minor questions that got answered instantly by Dan and Co on the
> mailing list. Thanks again!
> 
> The ability to define aspects of the interface in the XML-layout files is
> great (despite some minor quirks with the translation)! Studying the
> TodoApp helps a lot in this regard.
> 
> The not-so-great:
> 
> I think the code base is still quite dynamic, which is good in a way
> because it gets actively developed (does Dan ever sleep? ;)) but it's also
> difficult for a noob to 

Re: error 500

[César Camilo Lugo Marcos]

Jeroen,

We have it configured in Amazon AWS Elastic Beanstalk, using a load
balancer, this is where we redirect port 80 to 8080. Probably the load
balancer is acting as a proxy. Could this be causing the issue?

On Wed, 2016-06-08 at 16:34 +, Arturo Ulises Castañeda Estrada
wrote:
> Hi Jan, I'm not using a proxy server but I configured port 80 in the server 
> and redirects to 8080 port I don't know if this is causing problems.
> 
> De: jan-wil...@mail.youngmediaexperts.nl 
>  en nombre de Jan-Willem Gmelig Meyling 
> 
> Enviado: miércoles, 8 de junio de 2016 11:09:10 a. m.
> Para: users@isis.apache.org
> Asunto: Re: error 500
> 
> Hi Arturo,
> 
> Are you using a proxy server? I have seen this error with 
> grunt-connect-proxy, when I fire two requests simultanuously. Maybe it is 
> related to Cookie header parameters not correctly being passed from one end 
> to another.
> 
> Cheers,
> 
> Jan-Willem
> 
> 
> > Op 8 jun. 2016 om 17:28 heeft Arturo Ulises Castañeda Estrada 
> >  het volgende geschreven:
> >
> > Hi Dan,
> >
> >
> > I have the next problem when I consume a WS with AngularJS.
> >
> >
> > HTTP ERROR 500
> >
> > Problem accessing 
> > /restful/services/SequenceRepository/actions/findSequenceBySequenceId/invoke.
> >  Reason:
> >
> >Server Error
> > Caused by:
> >
> > javax.servlet.ServletException: Filtered request failed.at 
> > org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:384)at
> >  
> > org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)at
> >  
> > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1650)at
> >  
> > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:583)at
> >  
> > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)at
> >  
> > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)at
> >  
> > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)at
> >  
> > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1125)at
> >  
> > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)at 
> > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)at
> >  
> > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1059)at
> >  
> > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)at
> >  
> > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)at
> >  
> > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)at
> >  
> > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)at
> >  org.eclipse.jetty.server.Server.handle(Server.java:497)at 
> > org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)at 
> > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:248)at
> >  
> > org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)at
> >  
> > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:610)at
> >  
> > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:539)at
> >  java.lang.Thread.run(Thread.java:745)Caused by: 
> > org.apache.shiro.session.InvalidSessionException: 
> > java.lang.IllegalStateExceptionat 
> > org.apache.shiro.web.session.HttpServletSession.getAttribute(HttpServletSession.java:148)at
> >  
> > org.apache.shiro.session.ProxiedSession.getAttribute(ProxiedSession.java:121)at
> >  
> > org.apache.shiro.subject.support.DelegatingSubject.getRunAsPrincipalsStack(DelegatingSubject.java:469)at
> >  
> > org.apache.shiro.subject.support.DelegatingSubject.getPrincipals(DelegatingSubject.java:153)at
> >  
> > org.apache.shiro.mgt.DefaultSecurityManager.logout(DefaultSecurityManager.java:547)at
> >  
> > org.apache.shiro.subject.support.DelegatingSubject.logout(DelegatingSubject.java:363)at
> >  
> > org.apache.isis.security.shiro.ShiroAuthenticatorOrAuthorizor.authenticate(ShiroAuthenticatorOrAuthorizor.java:139)at
> >  
> > org.apache.isis.core.runtime.authentication.standard.AuthenticationManagerStandard.authenticate(AuthenticationManagerStandard.java:120)at
> >  
> > org.apache.isis.viewer.restfulobjects.server.authentication.AuthenticationSessionStrategyBasicAuth.lookupValid(AuthenticationSessionStrategyBasicAuth.java:65)at
> >  
> > org.apache.isis.core.webapp.IsisSessionFilter.doFilter(IsisSessionFilter.java:332)at
> >  
> > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1650)at
> >  
> > org.apache.isis.core.webapp.diagnostics.IsisLogOnExceptionFilter.doFilter(IsisLogOnExceptionFilter.java:52)at
> >  
> > 

Re: Concurrency

[César Camilo Lugo Marcos]

Dan,

In our first tests we experienced a very significant improvement. Before
2 concurrent users significantly decreased response time, while 5
friezed the server. Now we have ran 100 and 400 concurrent users, and
response time does not get impacted that much. Very significant
improvement, definitely looks like you are heading in the right
direction. Any updates on this will be appreciated as per [3].

Cesar. 

On Sat, 2016-06-04 at 11:56 +0100, Dan Haywood wrote:
> A further update re [1];
> 
> I've now pushed a commit [2] which seems to have addressed Cesar's issue
> ... removing a synchronized modifier.
> 
> I'm going to do a review of other uses of 'synchronized', to see if they
> are justified or not [3].
> 
> Thx
> Dan
> 
> 
> [1] https://issues.apache.org/jira/browse/ISIS-1421
> [2]
> https://github.com/apache/isis/commit/746176991b523fe9e8ab069392d83ff17af08624
> [3] https://issues.apache.org/jira/browse/ISIS-1428
> 
> 
> 
> 
> On 3 June 2016 at 13:28, Dan Haywood <d...@haywood-associates.co.uk> wrote:
> 
> > Just as an update on this; I've run Cesar's JMeter tests, and it has
> > revealed an issue in Isis core ... my suspicion being a possible
> > synchronized deadlock. [1]
> >
> > Will investigate with a view to fixing in 1.13.0
> >
> > Thx
> > Dan
> >
> >
> > [1] https://issues.apache.org/jira/browse/ISIS-1421
> >
> > On 2 June 2016 at 16:50, César Camilo Lugo Marcos <
> > cesar.l...@sisorg.com.mx> wrote:
> >
> >> Hello.
> >>
> >> We are looking into several recommended topics to tune up the
> >> application.  One of them is the use of JDO Optimistic locking instead
> >> of the Datanucleus default pessimistic locking, to improve concurrency.
> >> I have not found a setting within Datanucleus to change this setting
> >> globally or per transaction, just found this to define the property to
> >> be used as version on the domain object:
> >>
> >> @PersistenceCapable
> >> @Version(strategy=VersionStrategy.VERSION_NUMBER)
> >> public class MyClass
> >> {
> >> ...
> >> }
> >>
> >> Do you know about how to set it globally?
> >>
> >>
> >> On Tue, 2016-05-31 at 18:54 +, César Camilo Lugo Marcos wrote:
> >> > Hello Dan. Answers to your questions:
> >> >
> >> > - which version of Isis are you on?
> >> > 1.12.0
> >> > - how have you implemented the stress test?  is it automated, eg
> >> JMeter, or just adhoc manual testing?
> >> > Using JMeter. We recorded a quite simple script with about 6 read
> >> only operations using th Wicket viewer. All samplers are the recorded HTTP.
> >> > - is this stress testing the app running locally on Tomcat, or up in
> >> the cloud (on Amazon Elastic Beanstalk)?
> >> > We have it installed in the AWS Elastic Beanstalk with PostgreSQL.
> >> > We also made a test on a local host with Tomcat and MySQL,
> >> obtaining very similar results.
> >> > > - how much DB traffic does a single request create?  Is it all
> >> read-only; or are there also writes?
> >> > Quite low traffic, About 6 read only operations per user.
> >> > - for reads, are you seeing any N+1 issues?  if so, have you tried to
> >> prevent them using DataNucleus eager loading hint (the "fetch groups"
> >> concept)?
> >> > Not sure what N+1 is. We are letting Datanucleous handle all
> >> foreign keys and primary keys. We have not configured any fetch groups or
> >> any other configurations than defaults.
> >> > - for writes, are they expected?
> >> > Did not understand this question. Please explain.
> >> > - have you configured any of the various addons that could be writing
> >> to the DB, eg auditing, command or publishing?  are these perhaps enabled
> >> for safe/query-only actions?  If so for any looping within the app itself,
> >> can you eliminate using the QueryResultsCache?
> >> > We are only using the logging add-on, to log login and logout
> >> operations. No auditing, command or publishing add ons.
> >> > - what data volumes is this on?  If large volumes of data, are there
> >> perhaps missing indices?  What's the performance like with small volumes of
> >> data?
> >> > No Data Object or table has more that a few tens of records.
> >> > - is this for in-memory HSQLDB or out-of-memory DB (eg Postgres)?
> >> What's the perform

Re: Concurrency

[César Camilo Lugo Marcos]

Correction, we are using Apache ISIS 1.11.1

Cesar.

On Tue, 2016-05-31 at 18:54 +, César Camilo Lugo Marcos wrote:
> Hello Dan. Answers to your questions:
> 
> - which version of Isis are you on?
> 1.12.0
> - how have you implemented the stress test?  is it automated, eg JMeter, or 
> just adhoc manual testing?
> Using JMeter. We recorded a quite simple script with about 6 read only 
> operations using th Wicket viewer. All samplers are the recorded HTTP.
> - is this stress testing the app running locally on Tomcat, or up in the 
> cloud (on Amazon Elastic Beanstalk)?
> We have it installed in the AWS Elastic Beanstalk with PostgreSQL.
> We also made a test on a local host with Tomcat and MySQL, obtaining very 
> similar results.
> > - how much DB traffic does a single request create?  Is it all read-only; 
> > or are there also writes?
> Quite low traffic, About 6 read only operations per user.
> - for reads, are you seeing any N+1 issues?  if so, have you tried to prevent 
> them using DataNucleus eager loading hint (the "fetch groups" concept)?
> Not sure what N+1 is. We are letting Datanucleous handle all foreign keys 
> and primary keys. We have not configured any fetch groups or any other 
> configurations than defaults.
> - for writes, are they expected?
> Did not understand this question. Please explain.
> - have you configured any of the various addons that could be writing to the 
> DB, eg auditing, command or publishing?  are these perhaps enabled for 
> safe/query-only actions?  If so for any looping within the app itself, can 
> you eliminate using the QueryResultsCache?
> We are only using the logging add-on, to log login and logout operations. 
> No auditing, command or publishing add ons.
> - what data volumes is this on?  If large volumes of data, are there perhaps 
> missing indices?  What's the performance like with small volumes of data?
> No Data Object or table has more that a few tens of records.
> - is this for in-memory HSQLDB or out-of-memory DB (eg Postgres)?  What's the 
> performance like of one versus the other
> This is PostgreSQL. Also tried MySQL with very similar results. Have not 
> tried in memory HSQLDB.
> 
> 
> Cesar.
> 
> 
> On Tue, 2016-05-31 at 18:53 +0100, Dan Haywood wrote:
> 
> 
> Hi Cesar,
> 
> Those action semantics don't play a large part in the transaction
> management; they are mostly used to determine which type of HTTP method to
> expose the action under (GET, PUT or POST) and there is also the constraint
> that contributed/mixin properties/collections can only be supplied by SAFE
> actions.  The _ARE_YOU_SURE variants only impact the Wicket viewer.  The
> _REQUEST_CACHEABLE is only honoured if the action is invoked via the
> wrapper factory.
> 
> As Martin and Jeroen have said, using JProfiler or similar will likely
> yield valuable info.
> 
> If the issue is with database concurrency (which does seem like a good
> hypothesis), then for the most part that is under the management of
> DataNucleus itself.  There are a bunch of configuration properties that can
> be specified in persistor_datanucleus.properties (or isis.properties,
> actually); we strip off any "isis.persistor.datanucleus.impl" prefix and
> pass the rest of the key down to DN to configure.
> 
> Questions for you:
> - which version of Isis are you on?
> - how have you implemented the stress test?  is it automated, eg JMeter, or
> just adhoc manual testing?
> - is this stress testing the app running locally on Tomcat, or up in the
> cloud (on Amazon Elastic Beanstalk)?
> - how much DB traffic does a single request create?  Is it all read-only;
> or are there also writes?
> - for reads, are you seeing any N+1 issues?  if so, have you tried to
> prevent them using DataNucleus eager loading hint (the "fetch groups"
> concept)?
> - for writes, are they expected?
> - have you configured any of the various addons that could be writing to
> the DB, eg auditing, command or publishing?  are these perhaps enabled for
> safe/query-only actions?  If so
> - for any looping within the app itself, can you eliminate using the
> QueryResultsCache?
> - what data volumes is this on?  If large volumes of data, are there
> perhaps missing indices?  What's the performance like with small volumes of
> data?
> - is this for in-memory HSQLDB or out-of-memory DB (eg Postgres)?  What's
> the performance like of one versus the other
> 
> I think what I would look for is fast response times for a 1-user system
> running locally on Tomcat, with an inmemory database, and low data
> volumes.  From there, ramp up in different ways, but change one thing at a
> time.
> 
>

Re: Concurrency

[César Camilo Lugo Marcos]

Hello Dan. Answers to your questions:

- which version of Isis are you on?
1.12.0
- how have you implemented the stress test?  is it automated, eg JMeter, or 
just adhoc manual testing?
Using JMeter. We recorded a quite simple script with about 6 read only 
operations using th Wicket viewer. All samplers are the recorded HTTP.
- is this stress testing the app running locally on Tomcat, or up in the cloud 
(on Amazon Elastic Beanstalk)?
We have it installed in the AWS Elastic Beanstalk with PostgreSQL.
We also made a test on a local host with Tomcat and MySQL, obtaining very 
similar results.
> - how much DB traffic does a single request create?  Is it all read-only; or 
> are there also writes?
Quite low traffic, About 6 read only operations per user.
- for reads, are you seeing any N+1 issues?  if so, have you tried to prevent 
them using DataNucleus eager loading hint (the "fetch groups" concept)?
Not sure what N+1 is. We are letting Datanucleous handle all foreign keys 
and primary keys. We have not configured any fetch groups or any other 
configurations than defaults.
- for writes, are they expected?
Did not understand this question. Please explain.
- have you configured any of the various addons that could be writing to the 
DB, eg auditing, command or publishing?  are these perhaps enabled for 
safe/query-only actions?  If so for any looping within the app itself, can you 
eliminate using the QueryResultsCache?
We are only using the logging add-on, to log login and logout operations. 
No auditing, command or publishing add ons.
- what data volumes is this on?  If large volumes of data, are there perhaps 
missing indices?  What's the performance like with small volumes of data?
No Data Object or table has more that a few tens of records.
- is this for in-memory HSQLDB or out-of-memory DB (eg Postgres)?  What's the 
performance like of one versus the other
This is PostgreSQL. Also tried MySQL with very similar results. Have not 
tried in memory HSQLDB.


Cesar.


On Tue, 2016-05-31 at 18:53 +0100, Dan Haywood wrote:


Hi Cesar,

Those action semantics don't play a large part in the transaction
management; they are mostly used to determine which type of HTTP method to
expose the action under (GET, PUT or POST) and there is also the constraint
that contributed/mixin properties/collections can only be supplied by SAFE
actions.  The _ARE_YOU_SURE variants only impact the Wicket viewer.  The
_REQUEST_CACHEABLE is only honoured if the action is invoked via the
wrapper factory.

As Martin and Jeroen have said, using JProfiler or similar will likely
yield valuable info.

If the issue is with database concurrency (which does seem like a good
hypothesis), then for the most part that is under the management of
DataNucleus itself.  There are a bunch of configuration properties that can
be specified in persistor_datanucleus.properties (or isis.properties,
actually); we strip off any "isis.persistor.datanucleus.impl" prefix and
pass the rest of the key down to DN to configure.

Questions for you:
- which version of Isis are you on?
- how have you implemented the stress test?  is it automated, eg JMeter, or
just adhoc manual testing?
- is this stress testing the app running locally on Tomcat, or up in the
cloud (on Amazon Elastic Beanstalk)?
- how much DB traffic does a single request create?  Is it all read-only;
or are there also writes?
- for reads, are you seeing any N+1 issues?  if so, have you tried to
prevent them using DataNucleus eager loading hint (the "fetch groups"
concept)?
- for writes, are they expected?
- have you configured any of the various addons that could be writing to
the DB, eg auditing, command or publishing?  are these perhaps enabled for
safe/query-only actions?  If so
- for any looping within the app itself, can you eliminate using the
QueryResultsCache?
- what data volumes is this on?  If large volumes of data, are there
perhaps missing indices?  What's the performance like with small volumes of
data?
- is this for in-memory HSQLDB or out-of-memory DB (eg Postgres)?  What's
the performance like of one versus the other

I think what I would look for is fast response times for a 1-user system
running locally on Tomcat, with an inmemory database, and low data
volumes.  From there, ramp up in different ways, but change one thing at a
time.

HTH
Dan



On 31 May 2016 at 15:12, César Camilo Lugo Marcos 
<cesar.l...@sisorg.com.mx<mailto:cesar.l...@sisorg.com.mx>>
wrote:

> Thank you both for the hint. I am looking into JProfiler. Still,
> anything about the concurrency control options?
>
> Cesar.
>
> On Tue, 2016-05-31 at 11:13 +0200, Jeroen van der Wal wrote:
> > I agree with Martin that profiling is the only way to go. To illustrate:
> we
> > recently made some code 8 times faster by a few simple code changes on
> > bottlenecks revealed by JProfiler. And those were i

Re: Concurrency

[César Camilo Lugo Marcos]

Thank you both for the hint. I am looking into JProfiler. Still,
anything about the concurrency control options?

Cesar.

On Tue, 2016-05-31 at 11:13 +0200, Jeroen van der Wal wrote:
> I agree with Martin that profiling is the only way to go. To illustrate: we
> recently made some code 8 times faster by a few simple code changes on
> bottlenecks revealed by JProfiler. And those were in places that we've
> never guessed.
> 
> On 31 May 2016 at 08:39, Martin Grigorov <mgrigo...@apache.org> wrote:
> 
> > Hi,
> >
> > To find out where is the problem you will have to use a profiler like
> > JProfiler, Yourkit, JVisualVM, etc.
> > Even some thread dumps would help to see what is going on.
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >
> > On Mon, May 30, 2016 at 9:00 PM, César Camilo Lugo Marcos <
> > cesar.l...@sisorg.com.mx> wrote:
> >
> > > Hello,
> > >
> > > I would like to add to this topic the following:
> > >
> > > Most of the transactions we are testing in these stress tests are not
> > > bound in ACTIONS, but just plain reads or default transactions using
> > > Apache ISIS wicket viewer defaults. I don't see any place where I could
> > > define semantics for default read or write transactions not bound into
> > > ACTION methods. Is there any place I should look into for that?
> > >
> > > Cesar.
> > >
> > >
> > > On Mon, 2016-05-30 at 18:45 +, César Camilo Lugo Marcos wrote:
> > > > Hello,
> > > >
> > > > We have sarted performing some stress tests to our Apache ISIS
> > > > application. We have found this behavior:
> > > >
> > > > - If we run 1 concurrent user, average response times to the main
> > object
> > > > reads through the wicket viewer are from 1 to 1.5 seconds.
> > > > - If we run 2 concurrent users, same transactions go to average
> > response
> > > > times up to 16 to 27 seconds.
> > > > - If we run 10 concurrent users, the transactions start to slow down
> > > > significantly until the app server freezes and we have to restart it.
> > > >
> > > > As you can see, this is a very significant increase in response time
> > for
> > > > such a slight change in user load (from 1 user to 2 users). So we are
> > > > guessing we should look into the concurrency control.
> > > >
> > > > In the documentation I have found that the only way to influence the
> > way
> > > > Apache ISIS manages transactions and concurrency checking is by using
> > > > the semantics configuration of the ACTION annotation.
> > > >
> > > > semantics=SAFE_AND_REQUEST_CACHEABLE
> > > > semantics=SAFE
> > > > semantics=IDEMPOTENT
> > > > semantics=IDEMPOTENT_ARE_YOU_SURE
> > > > semantics=NON_IDEMPOTENT
> > > > semantics=NON_IDEMPOTENT_ARE_YOU_SURE
> > > >
> > > > I just wanted to confirm if this is the place to look into, or are
> > there
> > > > any other places where we should be looking into too, to solve the
> > > > performance issue.
> > > >
> > > > Cesar.
> > >
> > >
> >

Re: Concurrency

[César Camilo Lugo Marcos]

Hello,

I would like to add to this topic the following:

Most of the transactions we are testing in these stress tests are not
bound in ACTIONS, but just plain reads or default transactions using
Apache ISIS wicket viewer defaults. I don't see any place where I could
define semantics for default read or write transactions not bound into
ACTION methods. Is there any place I should look into for that?

Cesar.


On Mon, 2016-05-30 at 18:45 +, César Camilo Lugo Marcos wrote:
> Hello,
> 
> We have sarted performing some stress tests to our Apache ISIS
> application. We have found this behavior:
> 
> - If we run 1 concurrent user, average response times to the main object
> reads through the wicket viewer are from 1 to 1.5 seconds.
> - If we run 2 concurrent users, same transactions go to average response
> times up to 16 to 27 seconds.
> - If we run 10 concurrent users, the transactions start to slow down
> significantly until the app server freezes and we have to restart it.
> 
> As you can see, this is a very significant increase in response time for
> such a slight change in user load (from 1 user to 2 users). So we are
> guessing we should look into the concurrency control.
> 
> In the documentation I have found that the only way to influence the way
> Apache ISIS manages transactions and concurrency checking is by using
> the semantics configuration of the ACTION annotation. 
> 
> semantics=SAFE_AND_REQUEST_CACHEABLE
> semantics=SAFE
> semantics=IDEMPOTENT
> semantics=IDEMPOTENT_ARE_YOU_SURE
> semantics=NON_IDEMPOTENT
> semantics=NON_IDEMPOTENT_ARE_YOU_SURE
> 
> I just wanted to confirm if this is the place to look into, or are there
> any other places where we should be looking into too, to solve the
> performance issue.
> 
> Cesar.

Concurrency

[César Camilo Lugo Marcos]

Hello,

We have sarted performing some stress tests to our Apache ISIS
application. We have found this behavior:

- If we run 1 concurrent user, average response times to the main object
reads through the wicket viewer are from 1 to 1.5 seconds.
- If we run 2 concurrent users, same transactions go to average response
times up to 16 to 27 seconds.
- If we run 10 concurrent users, the transactions start to slow down
significantly until the app server freezes and we have to restart it.

As you can see, this is a very significant increase in response time for
such a slight change in user load (from 1 user to 2 users). So we are
guessing we should look into the concurrency control.

In the documentation I have found that the only way to influence the way
Apache ISIS manages transactions and concurrency checking is by using
the semantics configuration of the ACTION annotation. 

semantics=SAFE_AND_REQUEST_CACHEABLE
semantics=SAFE
semantics=IDEMPOTENT
semantics=IDEMPOTENT_ARE_YOU_SURE
semantics=NON_IDEMPOTENT
semantics=NON_IDEMPOTENT_ARE_YOU_SURE

I just wanted to confirm if this is the place to look into, or are there
any other places where we should be looking into too, to solve the
performance issue.

Cesar.

Re: Edit modes in Apache Isis

[César Camilo Lugo Marcos]

Dan,

After a quick look, I can see why you are considering nowicket. I particularly 
like these features:

- DDD and NO incorporated too. In line with ISIS.
- Keep the automatic generation of forms from model ISIS concept.
- You customize forms by using HTML, instead of a domain specific language or 
markup language, even using a WYSIWYG editor. If rebuilding a form, you don't 
loose the changes you made to it, changes are merged.
- You can use anything Wicket supports (that includes mutable in-line editing. 
I saw a couple of examples in the Wicket Examples Rebuilt" section, Ajax 
Datatable and Form Input).
- I guess in the ISIS integration you might be able to maintain the ability to 
group actions with properties editing in those cases where it makes sense.

Sounds promising.

Cesar.

On Wed, 2016-05-25 at 18:15 +0100, Dan Haywood


Good input, thanks.

My experience both with Estatio (4 years) but also with the big Naked
Objects system in Ireland (12 years) is that actions only is good enough in
the vast majority of cases ; and where bulk input is genuinely needed, then
we can usually address it with a little lateral thinking.

For Estatio, there's an occasional requirement to bulk upload new tax
rates, and for that we use the isis-module-excel that allows the users to
just upload an excel spreadsheet and process that.  Works quite well.

The risk of allowing general free - form editing in ERP systems is that
users are liable to abuse the freedom... we saw this for example in the
packaged software that Estatio replaced... spare /unused fields end up
being co-opted to store all sorts of adhoc info.  Instead, we should be
exploiting the fact that Isis allows such rapid development by keeping
things tight: relying on actions only means that the conversation as to
*why* the data needs to change can be had, resulting in a richer ubiquitous
language/insights/domain model.

All that said, we'll continue to evolve and improve the default UI, and to
make it easier to allow it to be extended for use cases such as this. One
option is different UIs, or to use custom UIs based on the Restful viewer,
but they are completely different experiences from an end-user
perspective.  Another more seamless/smoother integration might be to
leverage the nowicket framework which allows custom Wicket forms to be
developed quite easily; we've been in touch with its developer, and have
started spiking some things.

Hope that helps explain some of the rationale a little better.

Thanks,
Dan

http://invesdwin.de/nowicket/introduction

Hello. I have to agree with Steve and Hector. In my experience creating
and implementing ERP and large Merchandise Management systems, the
ability to change all fields within a TAB combined with in-line row
entry and editing is a must in a system where you handle a large volume
of transactional data entry (we have been extensively using those
features for the last 25 years or so in our systems, and the users
strongly request them). As an example use case, a user must enter
sometimes tens or even hundreds of rows (a purchase order line item
detail, a price change batch line item, journal entries and so on). Just
try doing that using the mouse and going back and forth on each row.
Luckily in our current applications we are building with Apache ISIS, we
are managing most of the data entry on the mobile devices, which handle
this in-line editing and all form editing easily, leveraging the amazing
ISIS capability to create web services from actions. But we do not see
us using the current Isis forms for that a system where there is volume
data entry in the browser. Having the ISIS ability to associate actions
to enter a group of fields / properties together and trigger some action
is beautiful, but I do not think it should replace all form editing nor
in-line row entry and editing, but they can both work as a complement.

I've heard from Dan that ISIS will have additional viewer options in the
future as a result of its open hexagonal architecture and some join
efforts with the NakedObjects guys, which sounds great!. I hope they
might bring us some UI friendly features like those. I recognize there
have been some recent significant improvements to the UI configuration,
and hope there will be in-line row entry and editing and back to all
form / all TAB editing soon.

Cesar.

On Wed, 2016-05-25 at 05:14 +, Dan Haywood wrote:
> Well, editing is enabled by default, so CRUD is supported.  We certainly
> don't want to make the framework deliberately difficult to use.
>
> I think the best thing for me to say is that editing properties is a
> work-in-progress, and where we're aiming to get to is a JIRA-like
> look-n-feel.  If it works well enough for that app, then I think it should
> suffice for Isis too.
>
> Thx
> Dan
>
>
>
> On 25 May 2016 at 03:36, Stephen Cameron 
> >
wrote:
>
> > I know this has been discussed previously, but it seems such a 

Re: Edit modes in Apache Isis

[César Camilo Lugo Marcos]

Hello. I have to agree with Steve and Hector. In my experience creating
and implementing ERP and large Merchandise Management systems, the
ability to change all fields within a TAB combined with in-line row
entry and editing is a must in a system where you handle a large volume
of transactional data entry (we have been extensively using those
features for the last 25 years or so in our systems, and the users
strongly request them). As an example use case, a user must enter
sometimes tens or even hundreds of rows (a purchase order line item
detail, a price change batch line item, journal entries and so on). Just
try doing that using the mouse and going back and forth on each row.
Luckily in our current applications we are building with Apache ISIS, we
are managing most of the data entry on the mobile devices, which handle
this in-line editing and all form editing easily, leveraging the amazing
ISIS capability to create web services from actions. But we do not see
us using the current Isis forms for that a system where there is volume
data entry in the browser. Having the ISIS ability to associate actions
to enter a group of fields / properties together and trigger some action
is beautiful, but I do not think it should replace all form editing nor
in-line row entry and editing, but they can both work as a complement.

I've heard from Dan that ISIS will have additional viewer options in the
future as a result of its open hexagonal architecture and some join
efforts with the NakedObjects guys, which sounds great!. I hope they
might bring us some UI friendly features like those. I recognize there
have been some recent significant improvements to the UI configuration,
and hope there will be in-line row entry and editing and back to all
form / all TAB editing soon.

Cesar.

On Wed, 2016-05-25 at 05:14 +, Dan Haywood wrote:
> Well, editing is enabled by default, so CRUD is supported.  We certainly
> don't want to make the framework deliberately difficult to use.
> 
> I think the best thing for me to say is that editing properties is a
> work-in-progress, and where we're aiming to get to is a JIRA-like
> look-n-feel.  If it works well enough for that app, then I think it should
> suffice for Isis too.
> 
> Thx
> Dan
> 
> 
> 
> On 25 May 2016 at 03:36, Stephen Cameron  wrote:
> 
> > I know this has been discussed previously, but it seems such a central
> > thing that I have to add my two-bits worth again.
> >
> > Re: "it positions the framework away from the common perception of it being
> > a CRUD framework;"
> >
> > Any database application is at its core a CRUD application, unless its view
> > only. So the key thing, surely, is to show people how much more Isis can do
> > and how easily. It seems you want to be deliberately unfamiliar to users in
> > order to show that its different to those other 'CRUD in five minutes'
> > frameworks.
> >
> > Making a group of properties read-only and providing an action to update
> > all the properties together is a useful pattern, but you seem to be
> > suggesting that this is the right way to do it everywhere because Estatio
> > is done that way.
> >
> > I think the in-situ editing will be good as a default behaviour.
> >
> > On the upside, I think Isis is now a very sweet framework to use in many,
> > many aspects. There is still alot for me to learn, but I am keen to do
> > that, and try to convince others of its merits too.
> >
> > Cheers
> > Steve
> >
> >
> >
> >
> >
> > On Tue, May 24, 2016 at 4:00 PM, Dan Haywood  > >
> > wrote:
> >
> > > Hi Hector,
> > > welcome to the users@ mailing list.
> > >
> > > I'm afraid that there isn't a setting to go back to the previous
> > behaviour,
> > > but there are some good reasons - some practical, some more
> > philosophical -
> > > why this change has been made.
> > >
> > > The practical reason is that with tabs, it's not particularly clear what
> > a
> > > global edit should be... should it be for all properties, including those
> > > not visible on other tabs?  or should it somehow disable being able to
> > > switch tabs when in edit mode? or perhaps there should be not a global
> > edit
> > > but instead an edit per fieldset/member group?  It wasn't at all clear
> > > which was preferable.
> > >
> > > Second, we've had a ticket knocking around for a while to move editing
> > > towards that in JIRA, where one clicks in the field and then can do an
> > > in-situ edit.  The current implementation isn't quite a slick as that,
> > but
> > > the number of clicks is actually the same.
> > >
> > > The philosophical reason is that, actually, it positions the framework
> > away
> > > from the common perception of it being a CRUD framework; instead it is
> > also
> > > for (even mostly for) complex domains where the is significant business
> > > logic to transition from one state of the system to another.  When Jeroen
> > > was implementing Estatio [1] he deliberately made 

Re: 502 Bad Gateway error when running on AWS

[César Camilo Lugo Marcos]

Dan, just wanted to let you know that I was able to open the port 8080
in the AWS EC2 instance as well as in the load balancer, so now the
application is running in AWS Elastic Beanstalk with load balancing and
failover.

Thank you!

On Tue, 2016-05-24 at 15:40 +0100, Dan Haywood wrote:
> I think the --port should come at the end because it's an argument to the
> jar, not an argument to java.
> 
> Otherwise, dunno, I'm afraid.
> 
> Dan
> On 24 May 2016 3:38 pm, "César Camilo Lugo Marcos" <cesar.l...@sisorg.com.mx>
> wrote:
> 
> > I tried with both
> >
> > java -port 80 -jar webapp/target/CQNZ-webapp-1.0-SNAPSHOT-jetty-console.jar
> > java --port 80 -jar
> > webapp/target/CQNZ-webapp-1.0-SNAPSHOT-jetty-console.jar
> >
> >
> > , but there is no java parmeter named port, so it issues an error.
> >
> > Any ideas?
> >
> > On Tue, 2016-05-24 at 14:05 +0100, Dan Haywood wrote:
> >
> >
> > Hi Cesar,
> >
> > I think you can just specify a --port flag in the command line.
> >
> > Probably worth upgrading the jetty-console too, see
> > github.com/eirbjo/jetty-console.
> >
> > Hth
> > Dan
> > On 24 May 2016 1:58 pm, "César Camilo Lugo Marcos" <
> > cesar.l...@sisorg.com.mx<mailto:cesar.l...@sisorg.com.mx>>
> > wrote:
> >
> > Hello, finally I got the application running on AWS Elastic Beanstalk!
> >
> > With some limitations, because the AWS Load Balancer only supports port
> > 80, and not 8080, so I had to eliminate the Load Balancer for now. There
> > are two possible solutions:
> >
> > 1) To open port 8080 on the AWS load balancer. Still looking into it,
> > seems possible but outside the AWS Web console tools, but from AWS CLI
> > line commands.
> >
> > 2) To make the application listen in 80 instead of 8080. We tried with
> > isis.properties adding isis.embedded-web-server.port=80 , and it worked
> > with mvn jetty:run, but not when we compile and create the jar file and
> > execute it with java -jar webapp\target
> > \CQNZ-webapp-1.0-SNAPSHOT-jetty-console.jar .
> >
> > How can we make the application compiled in the jar file work on port 80
> > instead?
> >
> > Cesar.
> >
> >
> >

Re: 502 Bad Gateway error when running on AWS

[César Camilo Lugo Marcos]

I tried with both

java -port 80 -jar webapp/target/CQNZ-webapp-1.0-SNAPSHOT-jetty-console.jar
java --port 80 -jar webapp/target/CQNZ-webapp-1.0-SNAPSHOT-jetty-console.jar


, but there is no java parmeter named port, so it issues an error.

Any ideas?

On Tue, 2016-05-24 at 14:05 +0100, Dan Haywood wrote:


Hi Cesar,

I think you can just specify a --port flag in the command line.

Probably worth upgrading the jetty-console too, see
github.com/eirbjo/jetty-console.

Hth
Dan
On 24 May 2016 1:58 pm, "César Camilo Lugo Marcos" 
<cesar.l...@sisorg.com.mx<mailto:cesar.l...@sisorg.com.mx>>
wrote:

Hello, finally I got the application running on AWS Elastic Beanstalk!

With some limitations, because the AWS Load Balancer only supports port
80, and not 8080, so I had to eliminate the Load Balancer for now. There
are two possible solutions:

1) To open port 8080 on the AWS load balancer. Still looking into it,
seems possible but outside the AWS Web console tools, but from AWS CLI
line commands.

2) To make the application listen in 80 instead of 8080. We tried with
isis.properties adding isis.embedded-web-server.port=80 , and it worked
with mvn jetty:run, but not when we compile and create the jar file and
execute it with java -jar webapp\target
\CQNZ-webapp-1.0-SNAPSHOT-jetty-console.jar .

How can we make the application compiled in the jar file work on port 80
instead?

Cesar.

502 Bad Gateway error when running on AWS

[César Camilo Lugo Marcos]

Hello, finally I got the application running on AWS Elastic Beanstalk!

With some limitations, because the AWS Load Balancer only supports port
80, and not 8080, so I had to eliminate the Load Balancer for now. There
are two possible solutions:

1) To open port 8080 on the AWS load balancer. Still looking into it,
seems possible but outside the AWS Web console tools, but from AWS CLI
line commands.

2) To make the application listen in 80 instead of 8080. We tried with
isis.properties adding isis.embedded-web-server.port=80 , and it worked
with mvn jetty:run, but not when we compile and create the jar file and
execute it with java -jar webapp\target
\CQNZ-webapp-1.0-SNAPSHOT-jetty-console.jar .

How can we make the application compiled in the jar file work on port 80 
instead?

Cesar.

Re: Inline edit

[César Camilo Lugo Marcos]

I'm interested in this enhancement too. Hopefully gets added to the
wicket viewer. I asked about it some time ago, and doesn't seem to be a
priority, lets hear from the Apache ISIS team.

On Mon, 2016-05-16 at 14:59 +0530, sunand p wrote:
> Hi Guys,
> 
> Just a quick question, is it possible to support inline edits for the table
> which got rendered for listing the domain objects?
> 
> 
> Cheers!
> Sunand

Re: RO calls authentication

[César Camilo Lugo Marcos]

Thank you Joan. I followed the link you posted in Github but got an access 
error 404 , is it a private repository?

Cesar


De: johandoornen...@filternet.nl 
Enviado: sábado, 14 de noviembre de 2015 04:21:48 a. m.
Para: users@isis.apache.org
Asunto: Re: RO calls authentication

Maybe checking out this code 1) from an app that I am working on can help you?

I am making unauthorized calls to the endpoints /register and /authenticate.

The other endpoints use basic authentication.

See also docs 2) and further



1) 
https://github.com/johandoornenbal/matching/blob/master/webapp/src/main/java/info/matchingservice/webapp/custom_rest/CustomAuthenticationSessionStrategyBasicAuth.java​


2)
https://isis.apache.org/guides/ug.html#8.9.2.-restful-objects-viewer

Grtz Johan


Hello.



I wrote a simple JavaScript app which makes a call to invoke an Apache Isis
RO web service. When making the GET call I am getting an error that seems to
be due to the fact that I have not included authentication in my app yet. Is
there any reference that I can read to document myself on how to
authenticate to make HTTP calls using authentication?



Cesar.







---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus