[JBoss JIRA] (ELY-1682) Fallback to another SASL client mechanism when SASL client initialisation fails
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-1682?page=com.atlassian.jira.plugin.s... ]
David Lloyd commented on ELY-1682:
----------------------------------
The aggregate SaslClientFactory does not have any practical recourse for failing to construct a SaslClient, as the caller cannot really know which one failed. The SaslClientFactory interface accepts a list of candidate mechanisms and then returns an instance using one of those mechanisms.
One possible solution is to modify our SASL client implementations to not fail on construction, but instead defer failure to the first negotiation step. This could easily be done by defining and returning a {{FailedSaslClient}} which is initialized with the mechanism name.
In addition, factories acquired from external providers could possibly be (individually) wrapped so that a failure on construction can be caught and wrapped as well.
> Fallback to another SASL client mechanism when SASL client initialisation fails
> -------------------------------------------------------------------------------
>
> Key: ELY-1682
> URL: https://issues.jboss.org/browse/ELY-1682
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SASL
> Affects Versions: 1.7.0.CR1
> Reporter: Martin Choma
> Attachments: org.jboss.eapqe.krbldap.eap71.tests.krb.ejb.KerberosEjbGssapiTestCase-output.txt
>
>
> {code:title=HipChat conversation}
> Martin Choma: I have got this situation here; Server is authenticated with GSSAPI and PLAIN. Client has only username/password credential - no kerberos credential.
> But client tries to create GssapiSaslClient as well (which make problem on IBM). Once I set .setSaslMechanismSelector(SaslMechanismSelector.fromString("PLAIN")) scenario works ok.
> I wonder could Authentication Client be smart enough to not try to initialize authentication mechanisms which it has not credentials for?
> Darran Lofthouse: Client side GSSAPI we tend not to have configured credentials as the mech obtains from OS level. The mech should fail and allow the next mech to be selected
> Martin Choma: Ok, so I will create issue. Seems on client side this mechanism fallback does not work properly. (At least in IBM JDK case).
> In this case it is initialization of mechanism which is failing, so maybe fallback does not have chance to get involved.
> Darran Lofthouse: Sounds possible, if a mech can not initialise we should likely treat it as a failed mech and move on - maybe something needed in Remoting
> though for that one as that is where that loop happens but start with an ELY issue
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (DROOLS-3044) Update ScenarioGridModel inherited methods to align Simulation model
by Daniele Zonca (JIRA)
Daniele Zonca created DROOLS-3044:
-------------------------------------
Summary: Update ScenarioGridModel inherited methods to align Simulation model
Key: DROOLS-3044
URL: https://issues.jboss.org/browse/DROOLS-3044
Project: Drools
Issue Type: Bug
Components: Scenario Simulation and Testing
Reporter: Daniele Zonca
Assignee: Gabriele Cardosi
Current design of ScenarioGridModel defines new methods to edit data of the grid and keep aligned internal Simulation model and parent "default" methods only update the grid (UI).
Implement the opposite logic to have default behaviour with methods that keep synced grid and Simulation and other optional methods that change only the UI.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (WFLY-11078) LogManager stops any logging output after changing "encoding" attribute to file-handler
by Masafumi Miura (JIRA)
[ https://issues.jboss.org/browse/WFLY-11078?page=com.atlassian.jira.plugin... ]
Masafumi Miura commented on WFLY-11078:
---------------------------------------
The same issue happens when you start the instance after editing "standalone.xml" manually and adding "encoding" attribute in the file-handler:
{code}
<periodic-rotating-file-handler name="FILE" autoflush="true">
<encoding value="UTF-8"/> <!-- add this -->
<formatter>
<named-formatter name="PATTERN"/>
</formatter>
<file relative-to="jboss.server.log.dir" path="server.log"/>
<suffix value=".yyyy-MM-dd"/>
<append value="true"/>
</periodic-rotating-file-handler>
{code}
In this scenario, you can avoid this issue by adding "handler.FILE.encoding=UTF-8" in logging.properties when you add "<encoding value="UTF-8"/>" in standalone.xml. Otherwise, you need to restart the instance.
> LogManager stops any logging output after changing "encoding" attribute to file-handler
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-11078
> URL: https://issues.jboss.org/browse/WFLY-11078
> Project: WildFly
> Issue Type: Bug
> Components: Logging
> Affects Versions: 14.0.0.Final
> Reporter: Masafumi Miura
> Assignee: James Perkins
>
> When setting "encoding" attribute on the file handler (file-handler, periodic-rotating-file-handler, size-rotating-file-handler, and periodic-size-rotating-file-handler) in CLI, LogManager throw the following error message in the console log and stops any logging output to the file-handler.
> Note that the stack trace below "org.jboss.logmanager.Logger.logRaw(Logger.java:850)" can differ. It looks like this error just happens on the first logging output after the configuration change.
> Even after executing ":reload" the instance via CLI, no log message are output to the file-handler. The instance needs to restart to output the file-handler.
> {code}
> LogManager error of type FLUSH_FAILURE: Error on flush
> java.io.IOException: Stream Closed
> at java.io.FileOutputStream.writeBytes(Native Method)
> at java.io.FileOutputStream.write(FileOutputStream.java:326)
> at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
> at org.jboss.logmanager.handlers.UninterruptibleOutputStream.flush(UninterruptibleOutputStream.java:110)
> at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:297)
> at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
> at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
> at java.io.BufferedWriter.flush(BufferedWriter.java:254)
> at org.jboss.logmanager.handlers.WriterHandler.safeFlush(WriterHandler.java:170)
> at org.jboss.logmanager.handlers.WriterHandler.flush(WriterHandler.java:139)
> at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:105)
> at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:67)
> at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:77)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:333)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
> at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
> at org.jboss.logmanager.Logger.log(Logger.java:802)
> at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:53)
> at org.jboss.logging.Logger.logf(Logger.java:2398)
> at org.jboss.as.mail.extension.MailLogger_$logger.unboundMailSession(MailLogger_$logger.java:42)
> at org.jboss.as.mail.extension.MailSessionAdd$1.handleEvent(MailSessionAdd.java:150)
> at org.jboss.msc.service.ServiceControllerImpl$LifecycleListenerTask.execute(ServiceControllerImpl.java:1857)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1364)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (DROOLS-3037) [DMN Designer] Added item definition has not icon of structure
by Guilherme Carreiro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-3037?page=com.atlassian.jira.plugi... ]
Guilherme Carreiro edited comment on DROOLS-3037 at 9/26/18 9:14 AM:
---------------------------------------------------------------------
[~jomarko],
I don't think that the absence of the the icons in some Data Types is a bug. The initial prototypes show that only Data Types with children has an icon, see:
!initial-prototypes.png|thumbnail!
However, the UX team worked in a enhancement for this topic, and now we have two kinds of icons in the dialog (one for simple Data Types and other for structure Data Types):
https://issues.jboss.org/browse/DROOLS-2876?focusedCommentId=13634494&pag...
We don't have a JIRA for applying the changed suggested by the DROOLS-2876, so we can keep this one. But, maybe we could change it from "Bug" to "Task" ;-)
Thanks.
was (Author: karreiro):
[~jomarko],
I don't think that the absence of the the icons in some Data Types is a bug. The initial prototypes explicitly show that only Data Types with children has an icon, see:
!initial-prototypes.png|thumbnail!
However, the UX team worked in a enhancement for this topic, and now we have two kinds of icons in the dialog (one for simple data types and other for structure data types):
https://issues.jboss.org/browse/DROOLS-2876?focusedCommentId=13634494&pag...
We don't have a JIRA for applying the changed suggested by the DROOLS-2876, so we can keep this one. But, maybe we could change it from "Bug" to "Task" ;-)
Thanks.
> [DMN Designer] Added item definition has not icon of structure
> --------------------------------------------------------------
>
> Key: DROOLS-3037
> URL: https://issues.jboss.org/browse/DROOLS-3037
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.12.0.Final
> Reporter: Jozef Marko
> Assignee: Guilherme Carreiro
> Labels: drools-tools
> Attachments: Screenshot from 2018-09-26 12-33-28.png, initial-prototypes.png
>
>
> If user add custom item definition and define it as structure, the item definition misses the structure icon set the attached picture. There is new custom structure item definition *a* without icon. Compare it with other structure item definitions.
> h2. Acceptance test
> - Check added item definition has icon when it is top level
> - Check added item definition has icon when used in nested level
> - Check item definition has not structure icon when changed from structure to something else
> - Check item definition has structure icon when changed from something else to structure
> - Check item definition has structure icon if item definition is recursive
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (DROOLS-3037) [DMN Designer] Added item definition has not icon of structure
by Guilherme Carreiro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-3037?page=com.atlassian.jira.plugi... ]
Guilherme Carreiro commented on DROOLS-3037:
--------------------------------------------
[~jomarko],
I don't think that the absence of the the icons in some Data Types is not a but. The initial prototypes explicitly show that only Data Types with children has an icon, see:
!initial-prototypes.png|thumbnail!
However, the UX team worked in a enhancement for this topic, and now we have two kinds of icons in the dialog (one for simple data types and other for structure data types):
https://issues.jboss.org/browse/DROOLS-2876?focusedCommentId=13634494&pag...
We don't have a JIRA for applying the changed suggested by the DROOLS-2876, so we can keep this one. But, maybe we could change it from "Bug" to "Task" ;-)
Thanks.
> [DMN Designer] Added item definition has not icon of structure
> --------------------------------------------------------------
>
> Key: DROOLS-3037
> URL: https://issues.jboss.org/browse/DROOLS-3037
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.12.0.Final
> Reporter: Jozef Marko
> Assignee: Guilherme Carreiro
> Labels: drools-tools
> Attachments: Screenshot from 2018-09-26 12-33-28.png, initial-prototypes.png
>
>
> If user add custom item definition and define it as structure, the item definition misses the structure icon set the attached picture. There is new custom structure item definition *a* without icon. Compare it with other structure item definitions.
> h2. Acceptance test
> - Check added item definition has icon when it is top level
> - Check added item definition has icon when used in nested level
> - Check item definition has not structure icon when changed from structure to something else
> - Check item definition has structure icon when changed from something else to structure
> - Check item definition has structure icon if item definition is recursive
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (DROOLS-3037) [DMN Designer] Added item definition has not icon of structure
by Guilherme Carreiro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-3037?page=com.atlassian.jira.plugi... ]
Guilherme Carreiro edited comment on DROOLS-3037 at 9/26/18 9:13 AM:
---------------------------------------------------------------------
[~jomarko],
I don't think that the absence of the the icons in some Data Types is a bug. The initial prototypes explicitly show that only Data Types with children has an icon, see:
!initial-prototypes.png|thumbnail!
However, the UX team worked in a enhancement for this topic, and now we have two kinds of icons in the dialog (one for simple data types and other for structure data types):
https://issues.jboss.org/browse/DROOLS-2876?focusedCommentId=13634494&pag...
We don't have a JIRA for applying the changed suggested by the DROOLS-2876, so we can keep this one. But, maybe we could change it from "Bug" to "Task" ;-)
Thanks.
was (Author: karreiro):
[~jomarko],
I don't think that the absence of the the icons in some Data Types is not a but. The initial prototypes explicitly show that only Data Types with children has an icon, see:
!initial-prototypes.png|thumbnail!
However, the UX team worked in a enhancement for this topic, and now we have two kinds of icons in the dialog (one for simple data types and other for structure data types):
https://issues.jboss.org/browse/DROOLS-2876?focusedCommentId=13634494&pag...
We don't have a JIRA for applying the changed suggested by the DROOLS-2876, so we can keep this one. But, maybe we could change it from "Bug" to "Task" ;-)
Thanks.
> [DMN Designer] Added item definition has not icon of structure
> --------------------------------------------------------------
>
> Key: DROOLS-3037
> URL: https://issues.jboss.org/browse/DROOLS-3037
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.12.0.Final
> Reporter: Jozef Marko
> Assignee: Guilherme Carreiro
> Labels: drools-tools
> Attachments: Screenshot from 2018-09-26 12-33-28.png, initial-prototypes.png
>
>
> If user add custom item definition and define it as structure, the item definition misses the structure icon set the attached picture. There is new custom structure item definition *a* without icon. Compare it with other structure item definitions.
> h2. Acceptance test
> - Check added item definition has icon when it is top level
> - Check added item definition has icon when used in nested level
> - Check item definition has not structure icon when changed from structure to something else
> - Check item definition has structure icon when changed from something else to structure
> - Check item definition has structure icon if item definition is recursive
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (WFLY-11079) [GSS](7.1.z) LogManager stops any logging output after changing "encoding" attribute to file-handler
by Masafumi Miura (JIRA)
Masafumi Miura created WFLY-11079:
-------------------------------------
Summary: [GSS](7.1.z) LogManager stops any logging output after changing "encoding" attribute to file-handler
Key: WFLY-11079
URL: https://issues.jboss.org/browse/WFLY-11079
Project: WildFly
Issue Type: Bug
Components: Logging
Affects Versions: 14.0.0.Final
Reporter: Masafumi Miura
Assignee: James Perkins
When setting "encoding" attribute on the file handler (file-handler, periodic-rotating-file-handler, size-rotating-file-handler, and periodic-size-rotating-file-handler) in CLI, LogManager throw the following error message in the console log and stops any logging output to the file-handler.
Note that the stack trace below "org.jboss.logmanager.Logger.logRaw(Logger.java:850)" can differ. It looks like this error just happens on the first logging output after the configuration change.
Even after executing ":reload" the instance via CLI, no log message are output to the file-handler. The instance needs to restart to output the file-handler.
{code}
LogManager error of type FLUSH_FAILURE: Error on flush
java.io.IOException: Stream Closed
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(FileOutputStream.java:326)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
at org.jboss.logmanager.handlers.UninterruptibleOutputStream.flush(UninterruptibleOutputStream.java:110)
at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:297)
at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
at java.io.BufferedWriter.flush(BufferedWriter.java:254)
at org.jboss.logmanager.handlers.WriterHandler.safeFlush(WriterHandler.java:170)
at org.jboss.logmanager.handlers.WriterHandler.flush(WriterHandler.java:139)
at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:105)
at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:67)
at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:77)
at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:333)
at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
at org.jboss.logmanager.Logger.log(Logger.java:802)
at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:53)
at org.jboss.logging.Logger.logf(Logger.java:2398)
at org.jboss.as.mail.extension.MailLogger_$logger.unboundMailSession(MailLogger_$logger.java:42)
at org.jboss.as.mail.extension.MailSessionAdd$1.handleEvent(MailSessionAdd.java:150)
at org.jboss.msc.service.ServiceControllerImpl$LifecycleListenerTask.execute(ServiceControllerImpl.java:1857)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1364)
at java.lang.Thread.run(Thread.java:748)
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (DROOLS-3037) [DMN Designer] Added item definition has not icon of structure
by Guilherme Carreiro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-3037?page=com.atlassian.jira.plugi... ]
Guilherme Carreiro updated DROOLS-3037:
---------------------------------------
Attachment: initial-prototypes.png
> [DMN Designer] Added item definition has not icon of structure
> --------------------------------------------------------------
>
> Key: DROOLS-3037
> URL: https://issues.jboss.org/browse/DROOLS-3037
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.12.0.Final
> Reporter: Jozef Marko
> Assignee: Guilherme Carreiro
> Labels: drools-tools
> Attachments: Screenshot from 2018-09-26 12-33-28.png, initial-prototypes.png
>
>
> If user add custom item definition and define it as structure, the item definition misses the structure icon set the attached picture. There is new custom structure item definition *a* without icon. Compare it with other structure item definitions.
> h2. Acceptance test
> - Check added item definition has icon when it is top level
> - Check added item definition has icon when used in nested level
> - Check item definition has not structure icon when changed from structure to something else
> - Check item definition has structure icon when changed from something else to structure
> - Check item definition has structure icon if item definition is recursive
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (WFLY-11078) LogManager stops any logging output after changing "encoding" attribute to file-handler
by Masafumi Miura (JIRA)
Masafumi Miura created WFLY-11078:
-------------------------------------
Summary: LogManager stops any logging output after changing "encoding" attribute to file-handler
Key: WFLY-11078
URL: https://issues.jboss.org/browse/WFLY-11078
Project: WildFly
Issue Type: Bug
Components: Logging
Affects Versions: 14.0.0.Final
Reporter: Masafumi Miura
Assignee: James Perkins
When setting "encoding" attribute on the file handler (file-handler, periodic-rotating-file-handler, size-rotating-file-handler, and periodic-size-rotating-file-handler) in CLI, LogManager throw the following error message in the console log and stops any logging output to the file-handler.
Note that the stack trace below "org.jboss.logmanager.Logger.logRaw(Logger.java:850)" can differ. It looks like this error just happens on the first logging output after the configuration change.
Even after executing ":reload" the instance via CLI, no log message are output to the file-handler. The instance needs to restart to output the file-handler.
{code}
LogManager error of type FLUSH_FAILURE: Error on flush
java.io.IOException: Stream Closed
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(FileOutputStream.java:326)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
at org.jboss.logmanager.handlers.UninterruptibleOutputStream.flush(UninterruptibleOutputStream.java:110)
at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:297)
at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141)
at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229)
at java.io.BufferedWriter.flush(BufferedWriter.java:254)
at org.jboss.logmanager.handlers.WriterHandler.safeFlush(WriterHandler.java:170)
at org.jboss.logmanager.handlers.WriterHandler.flush(WriterHandler.java:139)
at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:105)
at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:67)
at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:77)
at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:333)
at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:341)
at org.jboss.logmanager.Logger.logRaw(Logger.java:850)
at org.jboss.logmanager.Logger.log(Logger.java:802)
at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:53)
at org.jboss.logging.Logger.logf(Logger.java:2398)
at org.jboss.as.mail.extension.MailLogger_$logger.unboundMailSession(MailLogger_$logger.java:42)
at org.jboss.as.mail.extension.MailSessionAdd$1.handleEvent(MailSessionAdd.java:150)
at org.jboss.msc.service.ServiceControllerImpl$LifecycleListenerTask.execute(ServiceControllerImpl.java:1857)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1364)
at java.lang.Thread.run(Thread.java:748)
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months
[JBoss JIRA] (WFLY-10744) WFLYEJB0421: Invocation cannot proceed as component is shutting down
by tommaso borgato (JIRA)
[ https://issues.jboss.org/browse/WFLY-10744?page=com.atlassian.jira.plugin... ]
tommaso borgato updated WFLY-10744:
-----------------------------------
Affects Version/s: 14.0.1.Final
> WFLYEJB0421: Invocation cannot proceed as component is shutting down
> --------------------------------------------------------------------
>
> Key: WFLY-10744
> URL: https://issues.jboss.org/browse/WFLY-10744
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB, Server
> Affects Versions: 14.0.1.Final, 14.0.0.Beta2
> Reporter: tommaso borgato
> Assignee: Paul Ferraro
> Labels: clean_undeploy
>
> Observed in scenario [eap-7x-failover-ejb-ejbservlet-undeploy-repl-sync-haproxy|https://jenkins...].
> In a 4 nodes cluster, the clusterbench application is un-deployed & re-deployed in turn from each node: the error is observed on nodes 3 and 4 right after un-deployment is stated:
> {noformat}
> [JBossINF] [0m[0m04:17:13,541 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 84) WFLYUT0022: Unregistered web context: '/clusterbench-passivating' from server 'default-server'
> [JBossINF] [0m[0m04:17:13,543 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 88) WFLYUT0022: Unregistered web context: '/clusterbench' from server 'default-server'
> [JBossINF] [0m[0m04:17:13,547 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 91) WFLYUT0022: Unregistered web context: '/clusterbench-granular' from server 'default-server'
> [JBossINF] [0m[0m04:17:13,582 INFO [org.infinispan.CLUSTER] (ServerService Thread Pool -- 89) [Context=clusterbench-ee7.ear/clusterbench-ee7-ejb.jar] ISPN100008: Updating cache members list [perf21, perf18, perf19], topology id 24
> [JBossINF] [0m[31m04:17:13,580 ERROR [io.undertow.request] (default task-46) UT005023: Exception handling request to /clusterbench/ejbservlet: org.jboss.as.ejb3.component.EJBComponentUnavailableException: WFLYEJB0421: Invocation cannot proceed as component is shutting down
> [JBossINF] at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:59)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> [JBossINF] at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> [JBossINF] at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> [JBossINF] at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> [JBossINF] at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
> [JBossINF] at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:619)
> [JBossINF] at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> [JBossINF] at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> [JBossINF] at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> [JBossINF] at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> [JBossINF] at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:81)
> [JBossINF] at org.jboss.test.clusterbench.ejb.stateful.LocalStatefulSB$$$view3.getSerialAndIncrement(Unknown Source)
> [JBossINF] at sun.reflect.GeneratedMethodAccessor36.invoke(Unknown Source)
> [JBossINF] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [JBossINF] at java.lang.reflect.Method.invoke(Method.java:498)
> [JBossINF] at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:411)
> [JBossINF] at org.jboss.weld.module.ejb.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:134)
> [JBossINF] at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> [JBossINF] at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:106)
> [JBossINF] at org.jboss.test.clusterbench.ejb.stateful.LocalStatefulSB$Proxy$_$$_Weld$EnterpriseProxy$.getSerialAndIncrement(Unknown Source)
> [JBossINF] at org.jboss.test.clusterbench.ejb.stateful.LocalStatefulSB$Proxy$_$$_WeldClientProxy.getSerialAndIncrement(Unknown Source)
> [JBossINF] at org.jboss.test.clusterbench.web.ejb.LocalEjbServlet.doGet(LocalEjbServlet.java:38)
> [JBossINF] at javax.servlet.http.HttpServlet.service(HttpServlet.java:686)
> [JBossINF] at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> [JBossINF] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> [JBossINF] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> [JBossINF] at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> [JBossINF] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> [JBossINF] at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> [JBossINF] at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> [JBossINF] at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> [JBossINF] at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> [JBossINF] at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> [JBossINF] at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> [JBossINF] at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> [JBossINF] at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> [JBossINF] at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> [JBossINF] at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> [JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> [JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> [JBossINF] at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> [JBossINF] at java.lang.Thread.run(Thread.java:748)
> [JBossINF]
> [JBossINF] [0m[31m04:17:13,580 ERROR [io.undertow.request] (default task-35) UT005023: Exception handling request to /clusterbench/ejbservlet: org.jboss.as.ejb3.component.EJBComponentUnavailableException: WFLYEJB0421: Invocation cannot proceed as component is shutting down
> [JBossINF] at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:59)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> [JBossINF] at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> [JBossINF] at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> [JBossINF] at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> [JBossINF] at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
> [JBossINF] at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:619)
> [JBossINF] at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> [JBossINF] at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> [JBossINF] at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> [JBossINF] at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> [JBossINF] at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> [JBossINF] at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:81)
> [JBossINF] at org.jboss.test.clusterbench.ejb.stateful.LocalStatefulSB$$$view3.getSerialAndIncrement(Unknown Source)
> [JBossINF] at sun.reflect.GeneratedMethodAccessor36.invoke(Unknown Source)
> [JBossINF] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [JBossINF] at java.lang.reflect.Method.invoke(Method.java:498)
> [JBossINF] at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:411)
> [JBossINF] at org.jboss.weld.module.ejb.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:134)
> [JBossINF] at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> [JBossINF] at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:106)
> [JBossINF] at org.jboss.test.clusterbench.ejb.stateful.LocalStatefulSB$Proxy$_$$_Weld$EnterpriseProxy$.getSerialAndIncrement(Unknown Source)
> [JBossINF] at org.jboss.test.clusterbench.ejb.stateful.LocalStatefulSB$Proxy$_$$_WeldClientProxy.getSerialAndIncrement(Unknown Source)
> [JBossINF] at org.jboss.test.clusterbench.web.ejb.LocalEjbServlet.doGet(LocalEjbServlet.java:38)
> [JBossINF] at javax.servlet.http.HttpServlet.service(HttpServlet.java:686)
> [JBossINF] at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> [JBossINF] at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> [JBossINF] at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> [JBossINF] at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> [JBossINF] at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> [JBossINF] at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> [JBossINF] at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> [JBossINF] at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> [JBossINF] at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> [JBossINF] at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> [JBossINF] at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> [JBossINF] at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> [JBossINF] at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> [JBossINF] at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> [JBossINF] at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> [JBossINF] at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> [JBossINF] at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> [JBossINF] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> [JBossINF] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> [JBossINF] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> [JBossINF] at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> [JBossINF] at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> [JBossINF] at java.lang.Thread.run(Thread.java:748)
> [JBossINF]
> [JBossINF] [0m[0m04:17:13,602 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 89) ISPN000029: Passivating all entries to disk
> [JBossINF] [0m[0m04:17:13,601 INFO [org.infinispan.CLUSTER] (ServerService Thread Pool -- 94) [Context=clusterbench-ee7.ear.clusterbench-ee7-web-granular.war] ISPN100008: Updating cache members list [perf21, perf18, perf19], topology id 24
> [JBossINF] [0m[0m04:17:13,605 INFO [org.infinispan.CLUSTER] (ServerService Thread Pool -- 95) [Context=clusterbench-ee7.ear.clusterbench-ee7-web-passivating.war] ISPN100008: Updating cache members list [perf21, perf18, perf19], topology id 24
> [JBossINF] [0m[0m04:17:13,616 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 95) ISPN000029: Passivating all entries to disk
> [JBossINF] [0m[0m04:17:13,622 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 95) ISPN000030: Passivated 0 entries in 5 milliseconds
> [JBossINF] [0m[0m04:17:13,617 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 94) ISPN000029: Passivating all entries to disk
> [JBossINF] [0m[0m04:17:13,622 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 94) ISPN000030: Passivated 0 entries in 5 milliseconds
> [JBossINF] [0m[0m04:17:13,635 INFO [org.infinispan.CLUSTER] (ServerService Thread Pool -- 98) [Context=clusterbench-ee7.ear.clusterbench-ee7-web-default.war] ISPN100008: Updating cache members list [perf21, perf18, perf19], topology id 24
> [JBossINF] [0m[0m04:17:13,655 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 94) WFLYCLINF0003: Stopped clusterbench-ee7.ear.clusterbench-ee7-web-granular.war cache from web container
> [JBossINF] [0m[0m04:17:13,655 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 95) WFLYCLINF0003: Stopped clusterbench-ee7.ear.clusterbench-ee7-web-passivating.war cache from web container
> [JBossINF] [0m[0m04:17:13,655 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 98) ISPN000029: Passivating all entries to disk
> [JBossINF] [0m[0m04:17:13,961 INFO [org.infinispan.eviction.impl.PassivationManagerImpl] (ServerService Thread Pool -- 89) ISPN000030: Passivated 4002 entries in 359 milliseconds
> [JBossINF] [0m[33m04:17:13,968 WARN [org.infinispan.transaction.impl.TransactionTable] (ServerService Thread Pool -- 89) ISPN000100: Stopping, but there are 0 local transactions and 1 remote transactions that did not finish in time.
> [JBossINF] [0m[0m04:17:14,004 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 89) WFLYCLINF0003: Stopped clusterbench-ee7.ear/clusterbench-ee7-ejb.jar cache from ejb container
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 7 months