|
Jan Medved (jmedved) <jmedved@...>
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
toggle quoted message
Show quoted text
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:
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
|
|
|
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
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
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:
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
|
|
|
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
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
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:
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
|
|
|
I’m thinking that a controller in most cases is the primary application running on a host/VM … perhaps it should take 2/3 of Memory by default? 3/4 even...
On Apr 17, 2014, at 12:40 PM, Luis Gomez < ecelgp@...> wrote: 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
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
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:
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
|
|
|
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
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
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
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:
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
|
|
|
OK Devin, I have opened the enhancement #772 in controller bugzilla
so we can start discussion. Also I made a note that in the meantime
we need either a small fix increasing the the default -Xmx or a big
note in the SP documentation saying -Xmx needs to be adjusted for it
to run.
BR/Luis
On 4/17/2014 10:51 AM, Devin Avery
wrote:
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
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
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
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:
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
|
|
|
Jan Medved (jmedved) <jmedved@...>
Hi Devin,
The printout is good, but for me it scrolls out of sight before I can notice it, because there are too many logs & exceptions scrolling by. The printout is easy to overlook. I +1 the suggestion about an enhancement bug. For the SP edition, we need to set
the default value to 2Gig.
Thanks,
Jan
toggle quoted message
Show quoted text
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
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
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
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:
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
|
|
|
