[JBoss JIRA] (WFCORE-242) the deployment content is deleted if first undeploy and then deploy the same application using CLI batch
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-242?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-242:
------------------------------------------------
Tomas Hofman <thofman(a)redhat.com> changed the Status of [bug 1162444|https://bugzilla.redhat.com/show_bug.cgi?id=1162444] from NEW to ASSIGNED
> the deployment content is deleted if first undeploy and then deploy the same application using CLI batch
> --------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-242
> URL: https://issues.jboss.org/browse/WFCORE-242
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Reporter: Jay Kumar SenSharma
> Assignee: Emmanuel Hugonnet
> Priority: Minor
>
> - If deploy and undeploy CLI commands executed in a batch mode then it causes missing deployment inside the "data/content" directory which leads to the following error:
> {code}
> [Host Controller] 10:33:42,387 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "example.war")]) - failure description: "WFLYDC0058: No deployment content with hash d85f1e3106bc8a49838a0dccae9e80819c25e02c is available in the deployment content repository for deployment 'example.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart."
> [Host Controller] 10:33:42,390 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (DROOLS-654) Dynamic update with KieContainer.updateToVersion() not working in STREAM mode
by Tihomir Meščić (JIRA)
[ https://issues.jboss.org/browse/DROOLS-654?page=com.atlassian.jira.plugin... ]
Tihomir Meščić updated DROOLS-654:
----------------------------------
Description:
I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration:
{{KieBaseConfiguration config = KieServices.Factory.get()}}
{{.newKieBaseConfiguration();}}
{{config.setOption(EventProcessingOption.STREAM);}}
{{KieContainer kc = ks.newKieContainer( ... releaseId ... );}}
{{KieSession ksession = kc.newKieBase(config).newKieSession();}}
After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
{{kc.updateToVersion( ... newReleaseId... );}}
It seems like all of the facts are removed from the session, and my rules are no longer triggered.
When I do not use the configuration object when creating the session and just use:
{{KieSession ksession = kc.newKieSession();}}
then, everything works as expected, but this is not an option because I need a way to specify the processing mode as {{STREAM}} (and this is the only way I know of).
was:
I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration:
{{KieBaseConfiguration config = KieServices.Factory.get()}}
{{.newKieBaseConfiguration();}}
{{config.setOption(EventProcessingOption.STREAM);}}
{{KieContainer kc = ks.newKieContainer( ... releaseId ... );}}
{{KieSession ksession = kc.newKieBase(config).newKieSession();}}
After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
{{kc.updateToVersion( ... newReleaseId... );}}
It seems like all of the facts are removed from the session, and my rules are no longer triggered.
When I do not use the configuration object when creating the session and just use:
{{KieSession ksession = kc.newKieSession();}}
then, everything works as expected, but this is not an option because I need a way to specify the processing mode as {{STREAM}} (and this is the only way I know of).
> Dynamic update with KieContainer.updateToVersion() not working in STREAM mode
> -----------------------------------------------------------------------------
>
> Key: DROOLS-654
> URL: https://issues.jboss.org/browse/DROOLS-654
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final, 6.2.0.CR2
> Environment: Ubuntu Linux
> Reporter: Tihomir Meščić
> Assignee: Mark Proctor
> Priority: Blocker
>
> I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration:
> {{KieBaseConfiguration config = KieServices.Factory.get()}}
> {{.newKieBaseConfiguration();}}
> {{config.setOption(EventProcessingOption.STREAM);}}
>
> {{KieContainer kc = ks.newKieContainer( ... releaseId ... );}}
> {{KieSession ksession = kc.newKieBase(config).newKieSession();}}
> After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
> {{kc.updateToVersion( ... newReleaseId... );}}
> It seems like all of the facts are removed from the session, and my rules are no longer triggered.
> When I do not use the configuration object when creating the session and just use:
> {{KieSession ksession = kc.newKieSession();}}
> then, everything works as expected, but this is not an option because I need a way to specify the processing mode as {{STREAM}} (and this is the only way I know of).
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (DROOLS-654) Dynamic update with KieContainer.updateToVersion() not working in STREAM mode
by Tihomir Meščić (JIRA)
[ https://issues.jboss.org/browse/DROOLS-654?page=com.atlassian.jira.plugin... ]
Tihomir Meščić updated DROOLS-654:
----------------------------------
Description:
I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration:
{{KieBaseConfiguration config = KieServices.Factory.get()}}
{{.newKieBaseConfiguration();}}
{{config.setOption(EventProcessingOption.STREAM);}}
{{KieContainer kc = ks.newKieContainer( ... releaseId ... );}}
{{KieSession ksession = kc.newKieBase(config).newKieSession();}}
After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
{{kc.updateToVersion( ... newReleaseId... );}}
It seems like all of the facts are removed from the session, and my rules are no longer triggered.
When I do not use the configuration object when creating the session and just use:
{{KieSession ksession = kc.newKieSession();}}
then, everything works as expected, but this is not an option because I need a way to specify the processing mode as {{STREAM}} (and this is the only way I know of).
was:
I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration:
{{KieBaseConfiguration config = KieServices.Factory.get()}}
{{.newKieBaseConfiguration();}}
{{config.setOption(EventProcessingOption.STREAM);}}
{{KieContainer kc = ks.newKieContainer( ... releaseId ... );}}
{{KieSession ksession = kc.newKieBase(config).newKieSession();}}
After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
{{kc.updateToVersion( ... newReleaseId... );}}
It seems like all of the facts are removed from the session, and my rules are no longer triggered.
When I do not use the configuration object when creating the session and just use:
{{KieSession ksession = kc.newKieSession();}}
then, everything works as expected, but this is not an option because I need a way to specify the processing mode as {{STREAM}} (and this is the only way I know of).
> Dynamic update with KieContainer.updateToVersion() not working in STREAM mode
> -----------------------------------------------------------------------------
>
> Key: DROOLS-654
> URL: https://issues.jboss.org/browse/DROOLS-654
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final, 6.2.0.CR2
> Environment: Ubuntu Linux
> Reporter: Tihomir Meščić
> Assignee: Mark Proctor
> Priority: Blocker
>
> I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration:
> {{KieBaseConfiguration config = KieServices.Factory.get()}}
> {{.newKieBaseConfiguration();}}
> {{config.setOption(EventProcessingOption.STREAM);}}
>
> {{KieContainer kc = ks.newKieContainer( ... releaseId ... );}}
> {{KieSession ksession = kc.newKieBase(config).newKieSession();}}
> After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
> {{kc.updateToVersion( ... newReleaseId... );}}
> It seems like all of the facts are removed from the session, and my rules are no longer triggered.
> When I do not use the configuration object when creating the session and just use:
> {{KieSession ksession = kc.newKieSession();}}
> then, everything works as expected, but this is not an option because I need a way to specify the processing mode as {{STREAM}} (and this is the only way I know of).
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (DROOLS-654) Dynamic update with KieContainer.updateToVersion() not working in STREAM mode
by Tihomir Meščić (JIRA)
[ https://issues.jboss.org/browse/DROOLS-654?page=com.atlassian.jira.plugin... ]
Tihomir Meščić updated DROOLS-654:
----------------------------------
Description:
I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration:
{{KieBaseConfiguration config = KieServices.Factory.get()
.newKieBaseConfiguration();
config.setOption(EventProcessingOption.STREAM);
KieContainer kc = ks.newKieContainer( ... releaseId ... );
KieSession ksession = kc.newKieBase(config).newKieSession();}}
After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
{{
kc.updateToVersion( ... newReleaseId... );
}}
It seems like all of the facts are removed from the session, and my rules are no longer triggered.
When I do not use the configuration object when creating the session and just use:
{{
KieSession ksession = kc.newKieSession();
}}
then, everything works as expected, but this is not an option because I need a way to specify the processing mode as STREAM (and this is the only way I know of).
was:
I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration:
{{ KieBaseConfiguration config = KieServices.Factory.get()
.newKieBaseConfiguration();
config.setOption(EventProcessingOption.STREAM);
KieContainer kc = ks.newKieContainer( ... releaseId ... );
KieSession ksession = kc.newKieBase(config).newKieSession();}}
After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
{{
kc.updateToVersion( ... newReleaseId... );
}}
It seems like all of the facts are removed from the session, and my rules are no longer triggered.
When I do not use the configuration object when creating the session and just use:
{{
KieSession ksession = kc.newKieSession();
}}
then, everything works as expected, but this is not an option because I need a way to specify the processing mode as STREAM (and this is the only way I know of).
> Dynamic update with KieContainer.updateToVersion() not working in STREAM mode
> -----------------------------------------------------------------------------
>
> Key: DROOLS-654
> URL: https://issues.jboss.org/browse/DROOLS-654
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final, 6.2.0.CR2
> Environment: Ubuntu Linux
> Reporter: Tihomir Meščić
> Assignee: Mark Proctor
> Priority: Blocker
>
> I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration:
> {{KieBaseConfiguration config = KieServices.Factory.get()
> .newKieBaseConfiguration();
> config.setOption(EventProcessingOption.STREAM);
>
> KieContainer kc = ks.newKieContainer( ... releaseId ... );
> KieSession ksession = kc.newKieBase(config).newKieSession();}}
> After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
> {{
> kc.updateToVersion( ... newReleaseId... );
> }}
> It seems like all of the facts are removed from the session, and my rules are no longer triggered.
> When I do not use the configuration object when creating the session and just use:
> {{
> KieSession ksession = kc.newKieSession();
> }}
> then, everything works as expected, but this is not an option because I need a way to specify the processing mode as STREAM (and this is the only way I know of).
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (DROOLS-654) Dynamic update with KieContainer.updateToVersion() not working in STREAM mode
by Tihomir Meščić (JIRA)
[ https://issues.jboss.org/browse/DROOLS-654?page=com.atlassian.jira.plugin... ]
Tihomir Meščić updated DROOLS-654:
----------------------------------
Description:
I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration:
{{KieBaseConfiguration config = KieServices.Factory.get()}}
{{.newKieBaseConfiguration();}}
{{config.setOption(EventProcessingOption.STREAM);}}
{{KieContainer kc = ks.newKieContainer( ... releaseId ... );}}
{{KieSession ksession = kc.newKieBase(config).newKieSession();}}
After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
{{kc.updateToVersion( ... newReleaseId... );}}
It seems like all of the facts are removed from the session, and my rules are no longer triggered.
When I do not use the configuration object when creating the session and just use:
{{KieSession ksession = kc.newKieSession();}}
then, everything works as expected, but this is not an option because I need a way to specify the processing mode as {{STREAM}} (and this is the only way I know of).
was:
I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration:
{{KieBaseConfiguration config = KieServices.Factory.get()
.newKieBaseConfiguration();
config.setOption(EventProcessingOption.STREAM);
KieContainer kc = ks.newKieContainer( ... releaseId ... );
KieSession ksession = kc.newKieBase(config).newKieSession();}}
After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
{{
kc.updateToVersion( ... newReleaseId... );
}}
It seems like all of the facts are removed from the session, and my rules are no longer triggered.
When I do not use the configuration object when creating the session and just use:
{{
KieSession ksession = kc.newKieSession();
}}
then, everything works as expected, but this is not an option because I need a way to specify the processing mode as STREAM (and this is the only way I know of).
> Dynamic update with KieContainer.updateToVersion() not working in STREAM mode
> -----------------------------------------------------------------------------
>
> Key: DROOLS-654
> URL: https://issues.jboss.org/browse/DROOLS-654
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final, 6.2.0.CR2
> Environment: Ubuntu Linux
> Reporter: Tihomir Meščić
> Assignee: Mark Proctor
> Priority: Blocker
>
> I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration:
> {{KieBaseConfiguration config = KieServices.Factory.get()}}
> {{.newKieBaseConfiguration();}}
> {{config.setOption(EventProcessingOption.STREAM);}}
>
> {{KieContainer kc = ks.newKieContainer( ... releaseId ... );}}
> {{KieSession ksession = kc.newKieBase(config).newKieSession();}}
> After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
> {{kc.updateToVersion( ... newReleaseId... );}}
> It seems like all of the facts are removed from the session, and my rules are no longer triggered.
> When I do not use the configuration object when creating the session and just use:
> {{KieSession ksession = kc.newKieSession();}}
> then, everything works as expected, but this is not an option because I need a way to specify the processing mode as {{STREAM}} (and this is the only way I know of).
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (DROOLS-654) Dynamic update with KieContainer.updateToVersion() not working in STREAM mode
by Tihomir Meščić (JIRA)
[ https://issues.jboss.org/browse/DROOLS-654?page=com.atlassian.jira.plugin... ]
Tihomir Meščić updated DROOLS-654:
----------------------------------
Description:
I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration:
{{
KieBaseConfiguration config = KieServices.Factory.get()
.newKieBaseConfiguration();
config.setOption(EventProcessingOption.STREAM);
KieContainer kc = ks.newKieContainer( ... releaseId ... );
KieSession ksession = kc.newKieBase(config).newKieSession();
}}
After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
{{
kc.updateToVersion( ... newReleaseId... );
}}
It seems like all of the facts are removed from the session, and my rules are no longer triggered.
When I do not use the configuration object when creating the session and just use:
{{
KieSession ksession = kc.newKieSession();
}}
then, everything works as expected, but this is not an option because I need a way to specify the processing mode as STREAM (and this is the only way I know of).
was:
I'm creating my KieSession by setting STREAM as the event processing mode in the configuration:
KieBaseConfiguration config = KieServices.Factory.get()
.newKieBaseConfiguration();
config.setOption(EventProcessingOption.STREAM);
KieContainer kc = ks.newKieContainer( ... releaseId ... );
KieSession ksession = kc.newKieBase(config).newKieSession();
After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
kc.updateToVersion( ... newReleaseId... );
It seems like all of the facts are removed from the session, and my rules are no longer triggered.
When I do not use the configuration object when creating the session and just use:
KieSession ksession = kc.newKieSession();
then, everything works as expected, but this is not an option because I need a way to specify the processing mode as STREAM.
When doing a dynamic update using the KieContainer.updateToVersion()
> Dynamic update with KieContainer.updateToVersion() not working in STREAM mode
> -----------------------------------------------------------------------------
>
> Key: DROOLS-654
> URL: https://issues.jboss.org/browse/DROOLS-654
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final, 6.2.0.CR2
> Environment: Ubuntu Linux
> Reporter: Tihomir Meščić
> Assignee: Mark Proctor
> Priority: Blocker
>
> I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration:
> {{
> KieBaseConfiguration config = KieServices.Factory.get()
> .newKieBaseConfiguration();
> config.setOption(EventProcessingOption.STREAM);
>
> KieContainer kc = ks.newKieContainer( ... releaseId ... );
> KieSession ksession = kc.newKieBase(config).newKieSession();
> }}
> After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
> {{
> kc.updateToVersion( ... newReleaseId... );
> }}
> It seems like all of the facts are removed from the session, and my rules are no longer triggered.
> When I do not use the configuration object when creating the session and just use:
> {{
> KieSession ksession = kc.newKieSession();
> }}
> then, everything works as expected, but this is not an option because I need a way to specify the processing mode as STREAM (and this is the only way I know of).
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (DROOLS-654) Dynamic update with KieContainer.updateToVersion() not working in STREAM mode
by Tihomir Meščić (JIRA)
[ https://issues.jboss.org/browse/DROOLS-654?page=com.atlassian.jira.plugin... ]
Tihomir Meščić updated DROOLS-654:
----------------------------------
Description:
I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration:
{{ KieBaseConfiguration config = KieServices.Factory.get()
.newKieBaseConfiguration();
config.setOption(EventProcessingOption.STREAM);
KieContainer kc = ks.newKieContainer( ... releaseId ... );
KieSession ksession = kc.newKieBase(config).newKieSession();}}
After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
{{
kc.updateToVersion( ... newReleaseId... );
}}
It seems like all of the facts are removed from the session, and my rules are no longer triggered.
When I do not use the configuration object when creating the session and just use:
{{
KieSession ksession = kc.newKieSession();
}}
then, everything works as expected, but this is not an option because I need a way to specify the processing mode as STREAM (and this is the only way I know of).
was:
I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration:
{{
KieBaseConfiguration config = KieServices.Factory.get()
.newKieBaseConfiguration();
config.setOption(EventProcessingOption.STREAM);
KieContainer kc = ks.newKieContainer( ... releaseId ... );
KieSession ksession = kc.newKieBase(config).newKieSession();
}}
After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
{{
kc.updateToVersion( ... newReleaseId... );
}}
It seems like all of the facts are removed from the session, and my rules are no longer triggered.
When I do not use the configuration object when creating the session and just use:
{{
KieSession ksession = kc.newKieSession();
}}
then, everything works as expected, but this is not an option because I need a way to specify the processing mode as STREAM (and this is the only way I know of).
> Dynamic update with KieContainer.updateToVersion() not working in STREAM mode
> -----------------------------------------------------------------------------
>
> Key: DROOLS-654
> URL: https://issues.jboss.org/browse/DROOLS-654
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final, 6.2.0.CR2
> Environment: Ubuntu Linux
> Reporter: Tihomir Meščić
> Assignee: Mark Proctor
> Priority: Blocker
>
> I'm creating my {{KieSession}} by setting {{STREAM}} as the event processing mode in the configuration:
> {{ KieBaseConfiguration config = KieServices.Factory.get()
> .newKieBaseConfiguration();
> config.setOption(EventProcessingOption.STREAM);
>
> KieContainer kc = ks.newKieContainer( ... releaseId ... );
> KieSession ksession = kc.newKieBase(config).newKieSession();}}
> After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
> {{
> kc.updateToVersion( ... newReleaseId... );
> }}
> It seems like all of the facts are removed from the session, and my rules are no longer triggered.
> When I do not use the configuration object when creating the session and just use:
> {{
> KieSession ksession = kc.newKieSession();
> }}
> then, everything works as expected, but this is not an option because I need a way to specify the processing mode as STREAM (and this is the only way I know of).
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (DROOLS-654) Dynamic update with KieContainer.updateToVersion() not working in STREAM mode
by Tihomir Meščić (JIRA)
Tihomir Meščić created DROOLS-654:
-------------------------------------
Summary: Dynamic update with KieContainer.updateToVersion() not working in STREAM mode
Key: DROOLS-654
URL: https://issues.jboss.org/browse/DROOLS-654
Project: Drools
Issue Type: Bug
Affects Versions: 6.2.0.CR2, 6.1.0.Final
Environment: Ubuntu Linux
Reporter: Tihomir Meščić
Assignee: Mark Proctor
Priority: Blocker
I'm creating my KieSession by setting STREAM as the event processing mode in the configuration:
KieBaseConfiguration config = KieServices.Factory.get()
.newKieBaseConfiguration();
config.setOption(EventProcessingOption.STREAM);
KieContainer kc = ks.newKieContainer( ... releaseId ... );
KieSession ksession = kc.newKieBase(config).newKieSession();
After that, everything works fine. But when I try to dynamically update to a new version (containing new rules):
kc.updateToVersion( ... newReleaseId... );
It seems like all of the facts are removed from the session, and my rules are no longer triggered.
When I do not use the configuration object when creating the session and just use:
KieSession ksession = kc.newKieSession();
then, everything works as expected, but this is not an option because I need a way to specify the processing mode as STREAM.
When doing a dynamic update using the KieContainer.updateToVersion()
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (WFLY-825) JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-825?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar commented on WFLY-825:
----------------------------------
8.0.0.Final is quite old and has few known problems in undertow / xnio area that ware fixed in later releases.
Can you try with 8.2.0.Final that was released last week?
> JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance
> --------------------------------------------------------
>
> Key: WFLY-825
> URL: https://issues.jboss.org/browse/WFLY-825
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Environment: operating system - z/OS version 1.13
> JDK version info:
> java version "1.7.0"
> Java(TM) SE Runtime Environment (build pmz6470sr2-20120901_01(SR2))
> IBM J9 VM (build 2.6, JRE 1.7.0 z/OS s390x-64 20120809_118929 (JIT enabled, AOT enabled)
> J9VM - R26_Java726_SR2_20120809_0948_B118929
> JIT - r11.b01_20120808_24925
> GC - R26_Java726_SR2_20120809_0948_B118929
> J9CL - 20120809_118929)
> JCL - 20120831_02 based on Oracle 7u3-b05
> Reporter: Bob Bennett
> Assignee: Jason Greene
> Labels: jboss
> Attachments: relevant-threads.txt, threadstacks.txt, xnio-nio-3.0.8.GA-SNAPSHOT.jar, xnio-nio-3.0.8.GA-SNAPSHOT.jar
>
>
> When I install the jboss-as-7.1.1.Final on a z/OS system with the newest JDK, and start the standalone server, it gets stuck and never completes initialization. It also does not respond to kill, and requires kill -9 to terminate. I have javacore from the hang. I opened an issue with IBM support, and here is their response:
> Hi Bob,
>
> Have you contacted JBoss support for this issue?
>
> From my review of the javacore, every application-related thread is
> waiting on some kind of internal state monitoring code. The most
> prominent cause of waiting appears to be a CountdownLatch used in:
>
> org/jboss/as/controller/ParallelBootOperationStepHandler
> $ParallelBootTransactionControl.operationPrepared
>
> A quick search found this possibly related JBoss bug which was
> introduced because of incompatibilities with Java 7 (although it would appear to have been fixed before your current build, but I'm not certain
> how.) https://issues.jboss.org/browse/AS7-2940?_sscc=t
>
> The CountdownLatch is one of the Concurrency classes, and is very
> simplistic in that it allows an application to direct threads to wait
> until some certain number of actions have occured. The application code
> (JBoss in this case) would need to explain how many countdowns are
> required and which piece of code decrements the counter as needed.
>
> There's not much to say from a JVM perspective other than the threads
> are all waiting for an application-level event (a call to the
> "countDown()" method 'N' times where 'N' is how many JBoss initialized
> the CountDownLatch to originally.)
>
> If the JBoss team believes there is a specific thread not processing for one reason or another, we could look at that from a JVM perspective to see why. Unfortunately we'd need the JBoss team to explain which thread
> they think should be executing and why. A system dump of the problem
> (taken using signal 3, or from the operator console) would potentially allow for the internal state variables associated here to be read out...
> but that won't really be of any use if we don't know what JBoss expects
> them to be.
>
> Regards,
> Java Defect Support
> Please let me know if you need more info, either from myself or IBM JDK support.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months
[JBoss JIRA] (WFLY-3718) UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException
by Gabor Auth (JIRA)
[ https://issues.jboss.org/browse/WFLY-3718?page=com.atlassian.jira.plugin.... ]
Gabor Auth commented on WFLY-3718:
----------------------------------
Ok, I've downloaded, installed and the issue is exists, the root cause is same:
{code}
==> /home/wildfly/wildfly-8.2.0.Final/domain/servers/server-two/log/server.log <==
2014-11-25 11:31:14,351 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (SessionExpirationScheduler - 1) ISPN000136: Execution error: org.infinispan.commons.CacheListenerException: ISPN000280: Caught exception [java.lang.NullPointerException] while invoking method [public void org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(org.infinispan.notifications.cachelistener.event.CacheEntryRemovedEvent)] on listener instance: org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager@294d7185
at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:211)
at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22)
at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation.invoke(AbstractListenerImpl.java:229)
at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation.invoke(AbstractListenerImpl.java:192)
at org.infinispan.notifications.cachelistener.CacheNotifierImpl.notifyCacheEntryRemoved(CacheNotifierImpl.java:230)
at org.infinispan.commands.write.RemoveCommand.notify(RemoveCommand.java:96)
at org.infinispan.commands.write.RemoveCommand.performRemove(RemoveCommand.java:213)
at org.infinispan.commands.write.RemoveCommand.perform(RemoveCommand.java:92)
at org.infinispan.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:91)
at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37)
at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.distribution.TxDistributionInterceptor.handleTxWriteCommand(TxDistributionInterceptor.java:275)
at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitRemoveCommand(TxDistributionInterceptor.java:80)
at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37)
at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.CacheLoaderInterceptor.visitRemoveCommand(CacheLoaderInterceptor.java:132)
at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.EntryWrappingInterceptor.invokeNextAndApplyChanges(EntryWrappingInterceptor.java:321)
at org.infinispan.interceptors.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:402)
at org.infinispan.interceptors.EntryWrappingInterceptor.visitRemoveCommand(EntryWrappingInterceptor.java:216)
at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitRemoveCommand(PessimisticLockingInterceptor.java:145)
at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37)
at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:255)
at org.infinispan.interceptors.TxInterceptor.visitRemoveCommand(TxInterceptor.java:196)
at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37)
at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.statetransfer.StateTransferInterceptor.handleNonTxWriteCommand(StateTransferInterceptor.java:206)
at org.infinispan.statetransfer.StateTransferInterceptor.visitRemoveCommand(StateTransferInterceptor.java:156)
at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.CacheMgmtInterceptor.visitRemoveCommand(CacheMgmtInterceptor.java:166)
at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73)
at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37)
at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:79)
at org.infinispan.commands.AbstractVisitor.visitRemoveCommand(AbstractVisitor.java:37)
at org.infinispan.commands.write.RemoveCommand.acceptVisitor(RemoveCommand.java:57)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1306)
at org.infinispan.CacheImpl.removeInternal(CacheImpl.java:407)
at org.infinispan.CacheImpl.remove(CacheImpl.java:400)
at org.infinispan.DecoratedCache.remove(DecoratedCache.java:406)
at org.infinispan.AbstractDelegatingCache.remove(AbstractDelegatingCache.java:281)
at org.jboss.as.clustering.infinispan.invoker.Remover$RemoveOperation.invoke(Remover.java:49)
at org.jboss.as.clustering.infinispan.invoker.SimpleCacheInvoker.invoke(SimpleCacheInvoker.java:34)
at org.jboss.as.clustering.infinispan.invoker.RetryingCacheInvoker.invoke(RetryingCacheInvoker.java:87)
at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:117)
at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionFactory.remove(CoarseSessionFactory.java:55)
at org.wildfly.clustering.web.infinispan.session.InfinispanSession.invalidate(InfinispanSession.java:74)
at org.wildfly.clustering.web.infinispan.session.ExpiredSessionRemover.remove(ExpiredSessionRemover.java:47)
at org.wildfly.clustering.web.infinispan.session.ExpiredSessionRemover.remove(ExpiredSessionRemover.java:32)
at org.wildfly.clustering.web.infinispan.session.SessionExpirationScheduler$ExpirationTask.run(SessionExpirationScheduler.java:131)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [rt.jar:1.8.0_11]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_11]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [rt.jar:1.8.0_11]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [rt.jar:1.8.0_11]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_11]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_11]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_11]
at org.jboss.threads.JBossThread.run(JBossThread.java:122)
Caused by: java.lang.NullPointerException
at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51)
at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.removed(InfinispanSessionManager.java:238)
at sun.reflect.GeneratedMethodAccessor188.invoke(Unknown Source) [:1.8.0_11]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_11]
at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0_11]
at org.infinispan.notifications.AbstractListenerImpl$ListenerInvocation$1.run(AbstractListenerImpl.java:207)
... 80 more
{code}
> UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-3718
> URL: https://issues.jboss.org/browse/WFLY-3718
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 8.1.0.Final
> Environment: WildFly 8.1.0.Final
> Reporter: Gabor Auth
> Assignee: Paul Ferraro
> Fix For: 8.2.0.Final
>
>
> 2014-07-30 02:12:30,088 ERROR [io.undertow.request] (default task-15) UT005023: Exception handling request to /frontend/images/favicon.ico: java.lang.NullPointerException
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:320)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPostActivationEvents(InfinispanSessionManager.java:309)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:164)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:707) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:62) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_11]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_11]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_11]
> 2014-07-30 02:12:30,786 ERROR [io.undertow.request] (default task-15) Blocking request failed HttpServerExchange{ GET /frontend/images/favicon.ico}: java.lang.NullPointerException
> at org.wildfly.clustering.web.infinispan.session.coarse.CoarseImmutableSessionAttributes.getAttributeNames(CoarseImmutableSessionAttributes.java:51)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findListeners(InfinispanSessionManager.java:320)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.triggerPostActivationEvents(InfinispanSessionManager.java:309)
> at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(InfinispanSessionManager.java:164)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.getSession(DistributableSessionManager.java:115)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:677)
> at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:707)
> at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:711)
> at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:522)
> at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:137)
> at io.undertow.servlet.spec.HttpServletResponseImpl.sendError(HttpServletResponseImpl.java:142)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:273)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_11]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_11]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_11]
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 7 months