Consolidation

[Stephen Cameron]

Hi,

I want to suggest that the 1.12.1 release is not currently of production
quality and that a decision should be made by the development team as to
how to address that.

Maybe there is a case for consolidation of 1.12 before release of 1.13 or
else a recommendation to skip 1.12 and help with 1.13 release testing?

There is a significant issue ISIS-1396 [1] that has been resolved in
1.13.0-SNAPSHOT, this is my primary concern. I was going to say to users
just refresh the page to see the link titles, but I have discovered another
known issue ISIS-1132 [2] that seems to me quite serious, where datetimes
don't display correctly after updates.

Also, I've now found a similar bug to 1132, where I created a mass-update
action (after the edit mode discussion), but this doesn't work as some
property values (strings not datetimes) are not updated correctly in the
viewer. This is quite bizarre and I was sure I had an problem in my code,
but I cannot find one. Updates require a database lookup, which may explain.

Hoping this not taken as criticism.

Steve

[1] https://issues.apache.org/jira/browse/ISIS-1396

[2] https://issues.apache.org/jira/browse/ISIS-1132

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.
> 
> HTH
> Dan
> 
> 
> 
> On 31 May 2016 at 15:12, César Camilo Lugo Marcos 
> >
> 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 

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 
>
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 in places that we've
> > never guessed.
> >
> > On 31 May 2016 at 08:39, Martin Grigorov 

Re: Concurrency

[Dan Haywood]

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 
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 in places that we've
> > never guessed.
> >
> > On 31 May 2016 at 08:39, Martin Grigorov  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 

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  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.
> > >
> > >
> >

AW: ToDo App still not working

[Rade, Joerg / Kuehne + Nagel / Ham GI-DP]

Hi,

does the message mean that a pom is expected?

> [ERROR] Plugin org.apache.isis.tool:isis-maven-plugin:1.13.0-SNAPSHOT or one 
> of its dependencies could not be resolved:
> Failed to read artifact descriptor for 
> org.apache.isis.tool:isis-maven-plugin:jar:1.13.0-SNAPSHOT: Could not find 
> artifact
> org.apache.isis.tool:isis-maven-plugin:pom:1.13.0-SNAPSHOT -> [Help 1]

I don't see one at 
http://repository-estatio.forge.cloudbees.com/snapshot/org/apache/isis/tool/isis-maven-plugin/

-j

Kühne + Nagel (AG & Co.) KG
Rechtsform: Kommanditgesellschaft, Bremen HRA 21928, USt-IdNr.: DE 812773878.
Geschäftsleitung Kühne + Nagel (AG & Co.) KG: Reiner Heiken (Vors.), Martin 
Brinkmann, Matthias Heimbach, Jan-Hendrik Köstergarten, Nicholas Minde, Michael 
Nebel, Lars Wedel, Jens Wollesen.
Persönlich haftende Gesellschafterin: Kühne & Nagel A.G., Rechtsform: 
Aktiengesellschaft nach luxemburgischem Recht, HR-Nr.: B 18745, 
Geschäftsführendes Verwaltungsratsmitglied: Karl Gernandt.
Geschäftsleitung Region Westeuropa: Yngve Ruud (Vors.), Diederick de Vroet, 
Dominic Edmonds, Uwe Hött, Richard Huhn, Björn Johansson, Holger Ketz, Jan 
Kunze.

Wir arbeiten ausschließlich auf Grundlage der Allgemeinen Deutschen 
Spediteurbedingungen 2016 (ADSp 2016). Die ADSp 2016 beschränken in Ziffer 23 
die gesetzliche Haftung für Güterschäden in Höhe von 8,33 SZR/kg je Schadenfall 
bzw. je Schadenereignis auf 1 Million bzw. 2 Millionen Euro oder 2 SZR/kg, je 
nachdem, welcher Betrag höher ist, und bei multimodalen Transporten unter 
Einschluss einer Seebeförderung generell auf 2 SZR/kg. Den vollständigen Text 
der ADSp 2016 übersenden wir Ihnen gerne auf Anfrage und können Sie auch unter 
http://www.kuehne-nagel.com einsehen.

Re: ToDo App still not working

[Stephen Cameron]

sorry, confused again. I did try to set my own project to 1.13.0-SNAPSHOT
and got that same message as Boris, did not make much more effort to
resolve it though.

On Tue, May 31, 2016 at 10:33 PM, Jeroen van der Wal 
wrote:

> Looks unchanged to me [1]
>
> [1]
>
> https://github.com/apache/isis/blob/master/example/application/simpleapp/pom.xml#L58
>
> On 31 May 2016 at 14:15, Stephen Cameron 
> wrote:
>
> > Is there a different repository now listed in the simpleapp?
> >
> > On Tue, May 31, 2016 at 9:53 PM, Jeroen van der Wal  >
> > wrote:
> >
> > > Hi Boris,
> > >
> > > That's weird, I can see the dependency in the snapshot repository [1]
> but
> > > the build does not fetch that. As an intermediate solution you could
> > clone
> > > and build Apache Isis locally [2].
> > >
> > > Unfortunately that leads to integration tests failures caused by the
> > > refactoring currently taking place in 1.13.-SNAPSHOT. By running mvn
> > clean
> > > install -DskipTests you can bypass the tests. Please have a little more
> > > patience to allow these disruptions to be solved.
> > >
> > > Cheers,
> > >
> > > Jeroen
> > >
> > > [1]
> > >
> > >
> >
> http://repository-estatio.forge.cloudbees.com/snapshot/org/apache/isis/tool/isis-maven-plugin/1.13.0-SNAPSHOT/
> > > [2] https://github.com/apache/isis
> > >
> > >
> > > On 31 May 2016 at 11:40, Boris Toninski 
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > I noticed that there are some fixes in the ToDo app, but the build is
> > > > still failing, it gives me:
> > > >
> > > > [ERROR] Plugin org.apache.isis.tool:isis-maven-plugin:1.13.0-SNAPSHOT
> > or
> > > > one of its dependencies could not be resolved: Failed to read
> artifact
> > > > descriptor for
> > > org.apache.isis.tool:isis-maven-plugin:jar:1.13.0-SNAPSHOT:
> > > > Could not find artifact
> > > > org.apache.isis.tool:isis-maven-plugin:pom:1.13.0-SNAPSHOT -> [Help
> 1]
> > > >
> > > >
> > > > I tried to set the version of this artifact to 1.12.1 but then it
> gave
> > me
> > > > another error:
> > > >
> > > > [ERROR] Failed to execute goal
> > > > org.apache.isis.tool:isis-maven-plugin:1.12.1:xsd (default) on
> project
> > > > todoapp-xsd: Execution default of goal
> > > > org.apache.isis.tool:isis-maven-plugin:1.12.1:xsd failed: A required
> > > class
> > > > was missing while executing
> > > > org.apache.isis.tool:isis-maven-plugin:1.12.1:xsd:
> > > > org/apache/isis/core/metamodel/services/ServicesInjectorAware
> > > >
> > > > Thanks,
> > > > Boris
> > > >
> > >
> >
>

Re: ToDo App still not working

[Jeroen van der Wal]

Looks unchanged to me [1]

[1]
https://github.com/apache/isis/blob/master/example/application/simpleapp/pom.xml#L58

On 31 May 2016 at 14:15, Stephen Cameron  wrote:

> Is there a different repository now listed in the simpleapp?
>
> On Tue, May 31, 2016 at 9:53 PM, Jeroen van der Wal 
> wrote:
>
> > Hi Boris,
> >
> > That's weird, I can see the dependency in the snapshot repository [1] but
> > the build does not fetch that. As an intermediate solution you could
> clone
> > and build Apache Isis locally [2].
> >
> > Unfortunately that leads to integration tests failures caused by the
> > refactoring currently taking place in 1.13.-SNAPSHOT. By running mvn
> clean
> > install -DskipTests you can bypass the tests. Please have a little more
> > patience to allow these disruptions to be solved.
> >
> > Cheers,
> >
> > Jeroen
> >
> > [1]
> >
> >
> http://repository-estatio.forge.cloudbees.com/snapshot/org/apache/isis/tool/isis-maven-plugin/1.13.0-SNAPSHOT/
> > [2] https://github.com/apache/isis
> >
> >
> > On 31 May 2016 at 11:40, Boris Toninski 
> > wrote:
> >
> > > Hi,
> > >
> > > I noticed that there are some fixes in the ToDo app, but the build is
> > > still failing, it gives me:
> > >
> > > [ERROR] Plugin org.apache.isis.tool:isis-maven-plugin:1.13.0-SNAPSHOT
> or
> > > one of its dependencies could not be resolved: Failed to read artifact
> > > descriptor for
> > org.apache.isis.tool:isis-maven-plugin:jar:1.13.0-SNAPSHOT:
> > > Could not find artifact
> > > org.apache.isis.tool:isis-maven-plugin:pom:1.13.0-SNAPSHOT -> [Help 1]
> > >
> > >
> > > I tried to set the version of this artifact to 1.12.1 but then it gave
> me
> > > another error:
> > >
> > > [ERROR] Failed to execute goal
> > > org.apache.isis.tool:isis-maven-plugin:1.12.1:xsd (default) on project
> > > todoapp-xsd: Execution default of goal
> > > org.apache.isis.tool:isis-maven-plugin:1.12.1:xsd failed: A required
> > class
> > > was missing while executing
> > > org.apache.isis.tool:isis-maven-plugin:1.12.1:xsd:
> > > org/apache/isis/core/metamodel/services/ServicesInjectorAware
> > >
> > > Thanks,
> > > Boris
> > >
> >
>

Re: ToDo App still not working

[Stephen Cameron]

Is there a different repository now listed in the simpleapp?

On Tue, May 31, 2016 at 9:53 PM, Jeroen van der Wal 
wrote:

> Hi Boris,
>
> That's weird, I can see the dependency in the snapshot repository [1] but
> the build does not fetch that. As an intermediate solution you could clone
> and build Apache Isis locally [2].
>
> Unfortunately that leads to integration tests failures caused by the
> refactoring currently taking place in 1.13.-SNAPSHOT. By running mvn clean
> install -DskipTests you can bypass the tests. Please have a little more
> patience to allow these disruptions to be solved.
>
> Cheers,
>
> Jeroen
>
> [1]
>
> http://repository-estatio.forge.cloudbees.com/snapshot/org/apache/isis/tool/isis-maven-plugin/1.13.0-SNAPSHOT/
> [2] https://github.com/apache/isis
>
>
> On 31 May 2016 at 11:40, Boris Toninski 
> wrote:
>
> > Hi,
> >
> > I noticed that there are some fixes in the ToDo app, but the build is
> > still failing, it gives me:
> >
> > [ERROR] Plugin org.apache.isis.tool:isis-maven-plugin:1.13.0-SNAPSHOT or
> > one of its dependencies could not be resolved: Failed to read artifact
> > descriptor for
> org.apache.isis.tool:isis-maven-plugin:jar:1.13.0-SNAPSHOT:
> > Could not find artifact
> > org.apache.isis.tool:isis-maven-plugin:pom:1.13.0-SNAPSHOT -> [Help 1]
> >
> >
> > I tried to set the version of this artifact to 1.12.1 but then it gave me
> > another error:
> >
> > [ERROR] Failed to execute goal
> > org.apache.isis.tool:isis-maven-plugin:1.12.1:xsd (default) on project
> > todoapp-xsd: Execution default of goal
> > org.apache.isis.tool:isis-maven-plugin:1.12.1:xsd failed: A required
> class
> > was missing while executing
> > org.apache.isis.tool:isis-maven-plugin:1.12.1:xsd:
> > org/apache/isis/core/metamodel/services/ServicesInjectorAware
> >
> > Thanks,
> > Boris
> >
>

ToDo App still not working

[Boris Toninski]

Hi,

I noticed that there are some fixes in the ToDo app, but the build is still 
failing, it gives me:

[ERROR] Plugin org.apache.isis.tool:isis-maven-plugin:1.13.0-SNAPSHOT or one of 
its dependencies could not be resolved: Failed to read artifact descriptor for 
org.apache.isis.tool:isis-maven-plugin:jar:1.13.0-SNAPSHOT: Could not find 
artifact org.apache.isis.tool:isis-maven-plugin:pom:1.13.0-SNAPSHOT -> [Help 1]


I tried to set the version of this artifact to 1.12.1 but then it gave me 
another error:

[ERROR] Failed to execute goal 
org.apache.isis.tool:isis-maven-plugin:1.12.1:xsd (default) on project 
todoapp-xsd: Execution default of goal 
org.apache.isis.tool:isis-maven-plugin:1.12.1:xsd failed: A required class was 
missing while executing org.apache.isis.tool:isis-maven-plugin:1.12.1:xsd: 
org/apache/isis/core/metamodel/services/ServicesInjectorAware

Thanks,
Boris

Re: Concurrency

[Jeroen van der Wal]

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  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

[Martin Grigorov]

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.
>
>