June 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-5022) CLONE - Server sometimes crashes during reload operation

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-5022?page=com.atlassian.jira.plugin.s... ] Brian Stansberry updated AS7-5022: ---------------------------------- Assignee: Thomas Diesler (was: Brian Stansberry) >From a quick look at the description, it sounds like some service is not being reliably stopped on reload, which would imply it doesn't have dependency chain that leads back to org.jboss.as.server.Services.JBOSS_AS. > CLONE - Server sometimes crashes during reload operation > -------------------------------------------------------- > > Key: AS7-5022 > URL: https://issues.jboss.org/browse/AS7-5022 > Project: Application Server 7 > Issue Type: Bug > Components: OSGi > Affects Versions: 7.1.2.Final (EAP) > Reporter: Jan Martiska > Assignee: Thomas Diesler > Priority: Critical > Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1 > > > After some number of server reloads, next reload fails.. the number seems random, for me it is between 6 and 150. > this error message pops up during boot: > {noformat} > 15:21:05,036 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 53) JBAS014612: Operation ("add") failed - address: ([("subsystem" => "osgi")]): org.jboss.msc.service.DuplicateServiceException: Service jbosgi.integration.PersistentBundlesHandler is already registered > {noformat} > This shell script can be used for reproduction: > {noformat} > #!/bin/sh > $JBOSS_HOME/bin/standalone.sh > /dev/null & > sleep 10 > for i in `seq 1 150`; do > echo $i > $JBOSS_HOME/bin/jboss-cli.sh -c --command=:reload > sleep 4 > tail --lines=50 $JBOSS_HOME/standalone/log/server.log | grep ERROR > done > {noformat} > Testing environment> RHEL 5 or 6. This happens both when reloading using jboss-cli.sh and jboss-as-controller-client. It seems it has never happened to me when EAP was running in IPv6 mode (java.net.preferIPv4Stack=false), only IPv4. Affects all standalone profiles. It randomly breaks my admin console testsuite, which uses server reloads quite a lot. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AS7-5022) CLONE - Server sometimes crashes during reload operation

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/AS7-5022?page=com.atlassian.jira.plugin.s... ] Brian Stansberry moved JBPAPP-9363 to AS7-5022: ----------------------------------------------- Project: Application Server 7 (was: JBoss Enterprise Application Platform) Key: AS7-5022 (was: JBPAPP-9363) Workflow: GIT Pull Request workflow (was: jira) Affects Version/s: 7.1.2.Final (EAP) (was: EAP 6.0.0 ER 8) Release Notes Docs Status: (was: Not Required) Affects Testing: (was: Blocks Testing) Component/s: OSGi (was: Server boot) (was: OSGi) Security: (was: Public) Fix Version/s: 7.1.3.Final (EAP) 7.2.0.Alpha1 (was: TBD EAP 6) Docs QE Status: (was: NEW) > CLONE - Server sometimes crashes during reload operation > -------------------------------------------------------- > > Key: AS7-5022 > URL: https://issues.jboss.org/browse/AS7-5022 > Project: Application Server 7 > Issue Type: Bug > Components: OSGi > Affects Versions: 7.1.2.Final (EAP) > Reporter: Jan Martiska > Assignee: Brian Stansberry > Priority: Critical > Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1 > > > After some number of server reloads, next reload fails.. the number seems random, for me it is between 6 and 150. > this error message pops up during boot: > {noformat} > 15:21:05,036 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 53) JBAS014612: Operation ("add") failed - address: ([("subsystem" => "osgi")]): org.jboss.msc.service.DuplicateServiceException: Service jbosgi.integration.PersistentBundlesHandler is already registered > {noformat} > This shell script can be used for reproduction: > {noformat} > #!/bin/sh > $JBOSS_HOME/bin/standalone.sh > /dev/null & > sleep 10 > for i in `seq 1 150`; do > echo $i > $JBOSS_HOME/bin/jboss-cli.sh -c --command=:reload > sleep 4 > tail --lines=50 $JBOSS_HOME/standalone/log/server.log | grep ERROR > done > {noformat} > Testing environment> RHEL 5 or 6. This happens both when reloading using jboss-cli.sh and jboss-as-controller-client. It seems it has never happened to me when EAP was running in IPv6 mode (java.net.preferIPv4Stack=false), only IPv4. Affects all standalone profiles. It randomly breaks my admin console testsuite, which uses server reloads quite a lot. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AS7-5016) SSL 403 error in domain management

by Jess Sightler (JIRA)

13 years, 10 months

3
7
0 / 0

[JBoss JIRA] (AS7-5019) Adding multiple server-config in CLI fails.

by Kalle Rosenbaum (JIRA)

13 years, 10 months

1
1
0 / 0

[JBoss JIRA] (AS7-4689) SimpleSecurityManager and JBossCachedAuthenticationManager do not work together correctly when calling remote ejb

by Michael Gronau (JIRA)

Michael Gronau created AS7-4689: ----------------------------------- Summary: SimpleSecurityManager and JBossCachedAuthenticationManager do not work together correctly when calling remote ejb Key: AS7-4689 URL: https://issues.jboss.org/browse/AS7-4689 Project: Application Server 7 Issue Type: Bug Components: EJB Affects Versions: 7.1.2.Final-redhat1 Reporter: Michael Gronau Assignee: jaikiran pai the method SimpleSecurityManager.push(...) is called for every ejb call and here for every call a new instance of SimplePrincipal is created for the SubjectInfo. Then the method authenticate() is called. Here it delegates to the JBossCachedAuthenticationManager which tries to find an already cached principal, but this cannot work, because the get() function of the cache returns null. It returns null, because of the newly created SimplePrincipal for the current invocation. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

4
8
0 / 0

[JBoss JIRA] (JBRULES-3549) drools-decisiontables: Move to Apache POI (support for XLSX and Streaming read)

by Michael Anstis (JIRA)

13 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AS7-4847) modcluster doesn't expose the jvmRoute information via cli. Can't execute *-context operations without it properly.

by Simeon Pinder (JIRA)

Simeon Pinder created AS7-4847: ---------------------------------- Summary: modcluster doesn't expose the jvmRoute information via cli. Can't execute *-context operations without it properly. Key: AS7-4847 URL: https://issues.jboss.org/browse/AS7-4847 Project: Application Server 7 Issue Type: Bug Components: CLI Affects Versions: 7.1.2.Final (EAP) Environment: EAP6 Reporter: Simeon Pinder Assignee: Alexey Loubyansky Priority: Critical The modcluster subsystem needs to expose the 'jvmRoute' identifier via cli for the modcluster subsystem at the configuration level(at subsystem=modcluster/mod-cluster-config=configuration level). Without this information it is ambiguous how and which contexts will be affected when you execute the following operations: disable, disable-context, enable, enable-context, stop, stop-context. The other configuration attributes/operations target cluster-wide configuration, but the previous list of operations can only be executed at the cluster member/node level. In other words, a modcluster group could have 30 members/nodes but the above CLI operations will only affect the virtual-hosts and contexts for one of those nodes as uniquely identified by the jvmRoute. There is currently no consistent way to determine what a valid cluster identifier should be. The jvmRoute can be explicitly set via the 'jboss.mod_cluster.jvmRoute' property or is automatically generated. Either way the correct jvmRoute or modcluster node identifier information needs to be correctly exposed as read-only information for the modcluster subsystem. This post (https://community.jboss.org/message/632900), mentions an 'instance-id' on the web subsytem but it is also 'undefined' even for systems where the jvmRoute has been explicitly set or autogenerated. As the identifier is used by modcluster the identifier should be exposed consistently. Additionally there is no way to read whether a specific context is enabled/disabled. That issue probably needs it's another JIRA though. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

3
6
0 / 0

[JBoss JIRA] (JBMESSAGING-1925) unable to config the node drop time-out for postoffice

by Bond Chan (JIRA)

13 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AS7-4465) Cannot add a hilo-keygenarator for CMP subsystem

by Stefan Negrea (JIRA)

Stefan Negrea created AS7-4465: ---------------------------------- Summary: Cannot add a hilo-keygenarator for CMP subsystem Key: AS7-4465 URL: https://issues.jboss.org/browse/AS7-4465 Project: Application Server 7 Issue Type: Bug Reporter: Stefan Negrea Priority: Critical When attempting to create a hilo-keygenerator on the CMP subsystem the following error is observed: [standalone@localhost:9999 subsystem=cmp] ./hilo-keygenerator=test:add(data-source=ExampleDS) { "outcome" => "failed", "failure-description" => {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.cmp.keygen.HiLoKeyGeneratorFactory.testjboss.data-source.ExampleDSMissing[jboss.cmp.keygen.HiLoKeyGeneratorFactory.testjboss.data-source.ExampleDS]"]}, "rolled-back" => true, "response-headers" => {"process-state" => "reload-required"} } The ExampleDS data source exists so the error message is not valid. Note the missing dot between test and jboss from jboss.cmp.keygen.HiLoKeyGeneratorFactory.testjboss.data-source.ExampleDS. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

3
12
0 / 0

[JBoss JIRA] (JBWEB-241) Max parameter size is not documented.

by Jason Shepherd (JIRA)

13 years, 10 months

2
2
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2012