Luis – we do print out a warning now if you don’t specify the –Xmx setting. The best practice is that customers should set their –Xmx setting to the value correct for their environment. This product doesn’t seem like a one size fits all for memory. That said, adjusting the default so the product is usable in its simplest form is probably a good idea. For testing though the max memory should really be predefined so everyone is testing against the same configuration.

So that said, we can create a bug, or rather an enhancement, to change the default values, but I would ask do we know what the min is for each distribution? Etc.

So, in short if you can open the bug we can get the discussion going.

Thank you,

Devin

From: Luis Gomez <ecelgp@...>
Date: Thursday, April 17, 2014 at 12:40 PM
To: Devin Avery <davery@...>
Cc: "Jan Medved (jmedved)" <jmedved@...>, controller-dev <controller-dev@...>, Greg Hall <ghall@...>, "integration-dev@..." <integration-dev@...>, "infrastructure@..." <infrastructure@...>
Subject: Re: [controller-dev] SP edition broken

Hi Devin, thanks for jumping here. Yes we need a fix for this asap, people normally download the editions to test this or that feature and it is very difficult to figure out you need an extra parameter -Xmx in order to run the edition. Please open a bug or I can do it if you are busy.

Thanks/Luis

On Apr 17, 2014, at 3:41 AM, Devin Avery <davery@...> wrote:

Hi Jan -

The memory had always been 1/4th of the OS if you didn’t specify it on the command line. We set the minimum memory to be 1 G if it is undefined (as well as print out a warning). Perhaps there is a need to set the defaults in these other editions to ensure enough memory – we could do that by perhaps customizing an environment script that the run.sh calls into. That would allow us to default the memory to the proper sizes on start up.

If we think this is a requirement we can open a bug to discuss the work in more detail. It would be nice to avoid these memory related questions if we can avoid it (and provide the best OOB experience).

Thank you,

Devin

From: "Jan Medved (jmedved)" <jmedved@...>
Date: Wednesday, April 16, 2014 at 11:10 PM
To: Luis Gomez <ecelgp@...>, controller-dev <controller-dev@...>, Greg Hall <ghall@...>
Cc: "integration-dev@..." <integration-dev@...>, "infrastructure@..." <infrastructure@...>
Subject: Re: [controller-dev] SP edition broken

Thanks Greg! I wanted to respond to the same effect  - I run the SP edition with 2 Gig with no issues. The SP Edition’s memory requirements are larger than the base edition. The heap configuration of the controller changed recently from 2 Gig to 1 Gig - other ] apps and/or editions that need more meory (ritualization?) may run into similar problems too.

Thanks,

Jan

 

From: Luis Gomez <ecelgp@...>
Date: Wednesday, April 16, 2014 at 7:47 PM
To: controller-dev <controller-dev@...>, Greg Hall <ghall@...>
Cc: "integration-dev@..." <integration-dev@...>, "infrastructure@..." <infrastructure@...>
Subject: Re: [controller-dev] SP edition broken

OK, problem turned out to be (thanks Greg) lack of Java memory, so now we need to run SP edition with -Xmx1500m otherwise it does not work at LF (or my local env). Please let me know if I should open a bug for further investigation or this is normal/expected behavior.

BR/Luis

On Apr 16, 2014, at 6:20 PM, Luis Gomez <ecelgp@...> wrote:

More information: the problem has been detected by our system test around 9:00AM (UTC).

Here is the link to download SP edition for quick verification:

https://jenkins.opendaylight.org/integration/job/integration-project-centralized-integration/lastSuccessfulBuild/artifact/distributions/serviceprovider/target/distributions-serviceprovider-0.1.2-SNAPSHOT-osgipackage.zip

Also the SP edition system test has been disabled until this gets fixed.

BR/Luis

On Apr 16, 2014, at 6:04 PM, Luis Gomez <ecelgp@...> wrote:

Hi again,

Can anyone take a look at SP edition? it is totally broken, the controller just dies after a few minutes after start.

BR/Luis

On Apr 16, 2014, at 9:22 AM, Luis Gomez <ecelgp@...> wrote:

Hi experts,

Since this morning base edition build fails complaining about a 3PP controller component:

[ERROR] Failed to execute goal on project distributions-base: Could not resolve dependencies for project org.opendaylight.integration:distributions-base:pom:0.1.2-SNAPSHOT: The following artifacts could not be resolved: org.opendaylight.controller.thirdparty:nagasena:jar:0000.0002.0035.0, org.opendaylight.controller.thirdparty:nagasena-rta:jar:0000.0002.0035.0: Could not find artifact org.opendaylight.controller.thirdparty:nagasena:jar:0000.0002.0035.0 in opendaylight-mirror (http://nexus.opendaylight.org/content/groups/public/) -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn <goals> -rf :distributions-base

Does anybody knows what is this?

Thanks/Luis