[JBoss JIRA] (WFLY-3266) Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3266?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3266:
-----------------------------------------------
Panagiotis Sotiropoulos <psotirop(a)redhat.com> changed the Status of [bug 1088463|https://bugzilla.redhat.com/show_bug.cgi?id=1088463] from ASSIGNED to POST
> Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3266
> URL: https://issues.jboss.org/browse/WFLY-3266
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Final
> Reporter: Wolf-Dieter Fink
> Assignee: David Lloyd
> Priority: Critical
>
> In case of large parameter input for EJB invocations the ejb-client throw the Exception below.
> The underlying OutOfMemory is complete hidden, neither in the server.log nor in the ejb-client with TRACE a hint will be found.
> java.lang.IllegalStateException: EJBCLIENT000032: Cannot retry a request which hasn't previously been completed
> at org.jboss.ejb.client.EJBClientInvocationContext.retryRequest(EJBClientInvocationContext.java:200)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:256)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:265)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
> at com.sun.proxy.$Proxy6.uploadData(Unknown Source)
> at de.info.biene.konsens.TestServiceWithAPITest.testUploadData(TestServiceWithAPITest.java:81)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 4 months
[JBoss JIRA] (WFLY-3266) Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3266?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3266:
-----------------------------------------------
Panagiotis Sotiropoulos <psotirop(a)redhat.com> changed the Status of [bug 1088463|https://bugzilla.redhat.com/show_bug.cgi?id=1088463] from NEW to ASSIGNED
> Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swallowed
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3266
> URL: https://issues.jboss.org/browse/WFLY-3266
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Final
> Reporter: Wolf-Dieter Fink
> Assignee: David Lloyd
> Priority: Critical
>
> In case of large parameter input for EJB invocations the ejb-client throw the Exception below.
> The underlying OutOfMemory is complete hidden, neither in the server.log nor in the ejb-client with TRACE a hint will be found.
> java.lang.IllegalStateException: EJBCLIENT000032: Cannot retry a request which hasn't previously been completed
> at org.jboss.ejb.client.EJBClientInvocationContext.retryRequest(EJBClientInvocationContext.java:200)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:256)
> at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:265)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
> at com.sun.proxy.$Proxy6.uploadData(Unknown Source)
> at de.info.biene.konsens.TestServiceWithAPITest.testUploadData(TestServiceWithAPITest.java:81)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 4 months
[JBoss JIRA] (WFLY-3492) JSSE configuration in security domain wrongly acceptes empty parameters
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3492?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3492:
-----------------------------------------------
Kabir Khan <kkhan(a)redhat.com> changed the Status of [bug 1080069|https://bugzilla.redhat.com/show_bug.cgi?id=1080069] from POST to ASSIGNED
> JSSE configuration in security domain wrongly acceptes empty parameters
> -----------------------------------------------------------------------
>
> Key: WFLY-3492
> URL: https://issues.jboss.org/browse/WFLY-3492
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.1.0.Final
> Reporter: Chao Wang
> Assignee: Alexey Loubyansky
>
> Description from https://bugzilla.redhat.com/show_bug.cgi?id=1080069:
> {noformat}
> When adding a jsse configuration in security domain through CLI, it's not persisted correctly.
> Steps to reproduce:
> * Run CLI (./jboss-cli.sh -c) and use this commands to configure new security domain:
> /subsystem=security/security-domain=trust-domain:add
> /subsystem=security/security-domain=trust-domain/jsse=classic:add(truststore=>{password=1234test,url=/home/jcacek/projects/ocsp-check/build/trusted-clients.jks})
> reload
> * check standalone.xml, where should be sth. like
> <security-domain name="trust-domain">
> <jsse truststore-password="1234test" truststore-url="/home/jcacek/projects/ocsp-check/build/trusted-clients.jks"/>
> </security-domain>
> But there is:
> <security-domain name="trust-domain">
> <jsse/>
> </security-domain>
> {noformat}
> {noformat}
> I had a mistake in the second command, it should be:
> /subsystem=security/security-domain=trust-domain/jsse=classic:add(truststore={password=>1234test,url=>/home/jcacek/projects/ocsp-check/build/trusted-clients.jks})
> Then it works.
> Nevertheless it's probably still a bug, when the original command returns:
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 4 months
[JBoss JIRA] (WFLY-3492) JSSE configuration in security domain wrongly acceptes empty parameters
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3492?page=com.atlassian.jira.plugin.... ]
Kabir Khan reopened WFLY-3492:
------------------------------
Assignee: Alexey Loubyansky (was: Chao Wang)
> JSSE configuration in security domain wrongly acceptes empty parameters
> -----------------------------------------------------------------------
>
> Key: WFLY-3492
> URL: https://issues.jboss.org/browse/WFLY-3492
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.1.0.Final
> Reporter: Chao Wang
> Assignee: Alexey Loubyansky
>
> Description from https://bugzilla.redhat.com/show_bug.cgi?id=1080069:
> {noformat}
> When adding a jsse configuration in security domain through CLI, it's not persisted correctly.
> Steps to reproduce:
> * Run CLI (./jboss-cli.sh -c) and use this commands to configure new security domain:
> /subsystem=security/security-domain=trust-domain:add
> /subsystem=security/security-domain=trust-domain/jsse=classic:add(truststore=>{password=1234test,url=/home/jcacek/projects/ocsp-check/build/trusted-clients.jks})
> reload
> * check standalone.xml, where should be sth. like
> <security-domain name="trust-domain">
> <jsse truststore-password="1234test" truststore-url="/home/jcacek/projects/ocsp-check/build/trusted-clients.jks"/>
> </security-domain>
> But there is:
> <security-domain name="trust-domain">
> <jsse/>
> </security-domain>
> {noformat}
> {noformat}
> I had a mistake in the second command, it should be:
> /subsystem=security/security-domain=trust-domain/jsse=classic:add(truststore={password=>1234test,url=>/home/jcacek/projects/ocsp-check/build/trusted-clients.jks})
> Then it works.
> Nevertheless it's probably still a bug, when the original command returns:
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 4 months
[JBoss JIRA] (WFLY-951) It is not possible to enable AtomicActionExpiryScanner in EAP 6.x
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-951?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on WFLY-951:
----------------------------------------------
Shaun Appleton <sappleto(a)redhat.com> changed the Status of [bug 1086742|https://bugzilla.redhat.com/show_bug.cgi?id=1086742] from NEW to CLOSED
> It is not possible to enable AtomicActionExpiryScanner in EAP 6.x
> -----------------------------------------------------------------
>
> Key: WFLY-951
> URL: https://issues.jboss.org/browse/WFLY-951
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transactions
> Environment: JBoss EAP 6.01
> Reporter: Tom Ross
> Assignee: Stefano Maestri
> Fix For: 9.0.0.Beta1
>
>
> It should be possible to add AtomicActionExpiryScanner to the EAP 6 configuration as outline below:
> {noformat}
> <system-properties>
> <property name="RecoveryEnvironmentBean.expiryScannerClassNames" value="com.arjuna.ats.internal.arjuna.recovery.ExpiredTransactionStatusManagerScanner\\s+com.arjuna.ats.internal.arjuna.recovery.AtomicActionExpiryScanner"/>
> </system-properties>
> {noformat}
> Unfortunately the value of the RecoveryEnvironmentBean.expiryScannerClassNames seems to be overwritten in the ArjunaRecoveryManagerService class. As a result there is no easy way of removing transaction manager debris from object store.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 4 months
[JBoss JIRA] (WFLY-3519) process-id-uuid and related attribute should consider alternatives/required attributes in :write-attribute handler
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3519?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3519:
-----------------------------------------------
tom.jenkinson(a)redhat.com changed the Status of [bug 1090406|https://bugzilla.redhat.com/show_bug.cgi?id=1090406] from ASSIGNED to POST
> process-id-uuid and related attribute should consider alternatives/required attributes in :write-attribute handler
> ------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3519
> URL: https://issues.jboss.org/browse/WFLY-3519
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transactions
> Reporter: Stefano Maestri
> Assignee: Stefano Maestri
>
> The transaction subsystem causes the server fails to start (is halted) when just process-id-uuid is set to false without specifying the process-id-socket-binding.
> When you run commands:
> /subsystem=transactions:write-attribute(name=process-id-uuid,value=false)
> :reload
> Server fails with exception [1]
> The transaction subsystem should block changes that causes the server would fail on reload. The user should get information that the process-id-socket-binding has to be set before reload could proceed, i.e., fail the reload operation.
> [1]
> 11:13:53,630 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:141) [jboss-as-controller-7.4.0.Final-redhat-10.jar:7.4.0.Final-redhat-10]
> at org.jboss.as.server.ServerService.boot(ServerService.java:321) [jboss-as-server-7.4.0.Final-redhat-10.jar:7.4.0.Final-redhat-10]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:253) [jboss-as-controller-7.4.0.Final-redhat-10.jar:7.4.0.Final-redhat-10]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55]
> Caused by: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[287,17]
> Message: JBAS014723: Must include one of the following elements: SOCKET, UUID
> at org.jboss.as.controller.parsing.ParseUtils.missingOneOf(ParseUtils.java:194) [jboss-as-controller-7.4.0.Final-redhat-10.jar:7.4.0.Final-redhat-10]
> at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.parseProcessIdEnvironmentElement(TransactionSubsystem14Parser.java:390)
> at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.parseCoreEnvironmentElement(TransactionSubsystem14Parser.java:340)
> at org.jboss.as.txn.subsystem.TransactionSubsystem15Parser.readElement(TransactionSubsystem15Parser.java:59)
> at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.readElement(TransactionSubsystem14Parser.java:110)
> at org.jboss.as.txn.subsystem.TransactionSubsystem14Parser.readElement(TransactionSubsystem14Parser.java:53)
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final-redhat-2.jar:1.1.0.Final-redhat-2]
> at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69) [staxmapper-1.1.0.Final-redhat-2.jar:1.1.0.Final-redhat-2]
> at org.jboss.as.server.parsing.StandaloneXml.parseServerProfile(StandaloneXml.java:1035) [jboss-as-server-7.4.0.Final-redhat-10.jar:7.4.0.Final-redhat-10]
> at org.jboss.as.server.parsing.StandaloneXml.readServerElement_1_4(StandaloneXml.java:469) [jboss-as-server-7.4.0.Final-redhat-10.jar:7.4.0.Final-redhat-10]
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:145) [jboss-as-server-7.4.0.Final-redhat-10.jar:7.4.0.Final-redhat-10]
> at org.jboss.as.server.parsing.StandaloneXml.readElement(StandaloneXml.java:107) [jboss-as-server-7.4.0.Final-redhat-10.jar:7.4.0.Final-redhat-10]
> at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final-redhat-2.jar:1.1.0.Final-redhat-2]
> at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final-redhat-2.jar:1.1.0.Final-redhat-2]
> at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:133) [jboss-as-controller-7.4.0.Final-redhat-10.jar:7.4.0.Final-redhat-10]
> ... 3 more
> 11:13:53,635 FATAL [org.jboss.as.server] (Controller Boot Thread) JBAS015957: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 4 months
[JBoss JIRA] (WFLY-3492) JSSE configuration in security domain wrongly acceptes empty parameters
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3492?page=com.atlassian.jira.plugin.... ]
Kabir Khan commented on WFLY-3492:
----------------------------------
https://github.com/kabir/wildfly/tree/cli-complex-attributes reverts Chao's commit, and should be the basis for any PR fixing this in the CLI.
> JSSE configuration in security domain wrongly acceptes empty parameters
> -----------------------------------------------------------------------
>
> Key: WFLY-3492
> URL: https://issues.jboss.org/browse/WFLY-3492
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.1.0.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
>
> Description from https://bugzilla.redhat.com/show_bug.cgi?id=1080069:
> {noformat}
> When adding a jsse configuration in security domain through CLI, it's not persisted correctly.
> Steps to reproduce:
> * Run CLI (./jboss-cli.sh -c) and use this commands to configure new security domain:
> /subsystem=security/security-domain=trust-domain:add
> /subsystem=security/security-domain=trust-domain/jsse=classic:add(truststore=>{password=1234test,url=/home/jcacek/projects/ocsp-check/build/trusted-clients.jks})
> reload
> * check standalone.xml, where should be sth. like
> <security-domain name="trust-domain">
> <jsse truststore-password="1234test" truststore-url="/home/jcacek/projects/ocsp-check/build/trusted-clients.jks"/>
> </security-domain>
> But there is:
> <security-domain name="trust-domain">
> <jsse/>
> </security-domain>
> {noformat}
> {noformat}
> I had a mistake in the second command, it should be:
> /subsystem=security/security-domain=trust-domain/jsse=classic:add(truststore={password=>1234test,url=>/home/jcacek/projects/ocsp-check/build/trusted-clients.jks})
> Then it works.
> Nevertheless it's probably still a bug, when the original command returns:
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 4 months
[JBoss JIRA] (WFCORE-40) Deadlock while logging
by Andreas Kaster (JIRA)
[ https://issues.jboss.org/browse/WFCORE-40?page=com.atlassian.jira.plugin.... ]
Andreas Kaster updated WFCORE-40:
---------------------------------
Attachment: stack_140901_2254
Attached the stack file from the last crash
> Deadlock while logging
> ----------------------
>
> Key: WFCORE-40
> URL: https://issues.jboss.org/browse/WFCORE-40
> Project: WildFly Core
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Logging
> Environment: CentOS 6.5 64bit, java7u45 64bit (and 32 bit, the same behavior)
> Reporter: Stefan Schueffler
> Assignee: James Perkins
> Priority: Critical
> Attachments: stack_140901_2254
>
>
> We hit really often a deadlock? in org.jboss.stdio.StdioContext$DelegatingPrintStream.println(StdioContext.java:474)
> Even if the "StdioContext" belongs to Jboss-Logging, the problem occurs in our production wildfly installation twice to 4 times a day - all threads are deadlocking while trying to log.debug, log.error, or (sometimes) System.out.println from our application code, and wildfly does not respond anymore...
> The partial stacktrace always is similar to this one:
> {code}
> "default task-64" prio=10 tid=0x4c539c00 nid=0x5ef9 waiting for monitor entry [0x495e0000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at java.io.PrintStream.println(PrintStream.java:806)
> - waiting to lock <0x5ee0adf8> (a java.io.PrintStream)
> at org.jboss.stdio.StdioContext$DelegatingPrintStream.println(StdioContext.java:474)
> at jsp.communications.statuschange.selectStatus_jsp._jspService(selectStatus_jsp.java:413)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:69)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82)
> {code}
> While investigating the StdioContext - class, i really wondered whether the used "locking/checking by using a threadlocal" could have worked in a multi-threaded environment (it should have the very same problems as every "double checking" algorithm without proper synchronization).
> If all threads are hanging in this particular lock, only a full wildfly-restart recovers in our case.
> My preferred solution would be a rework of the used org.jboss.stdio. classes, as the used idioms of ThreadLocals for reentrant-checks are at least highly unusual?
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 4 months
[JBoss JIRA] (WFLY-3464) Nonexistent ldap group causes authentication to fail in security-realm
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3464?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3464:
-----------------------------------------------
Josef Cacek <jcacek(a)redhat.com> changed the Status of [bug 1128176|https://bugzilla.redhat.com/show_bug.cgi?id=1128176] from ON_QA to VERIFIED
> Nonexistent ldap group causes authentication to fail in security-realm
> -----------------------------------------------------------------------
>
> Key: WFLY-3464
> URL: https://issues.jboss.org/browse/WFLY-3464
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.1.0.Final
> Reporter: Derek Horton
> Assignee: Darran Lofthouse
>
> The LdapGroupSearcher code will fail if it tries to lookup a group that
> does not exist on the local ldap server.
> This can happen when the ldap systems are configured as trusted domains.
> Even though the security-realm is not configured to use the trusted domain
> (it is configured to only look at a single ldap server), the
> user's entry on one ldap server could point at a group that exists on
> the other (trusted) ldap server.
> The LdapGroupSearcher code attempts to lookup this role and it fails. This
> failure is sent back to the http server which results in an HTTP 500 error
> and leaves the user with no way to authenticate/login.
> There is currently not a way to tell the group searcher code to ignore the
> group/role that cannot be found.
> 2014-06-06 12:44:39,819 TRACE [org.jboss.as.domain.management.security] (XNIO-1 task-1) Group found with distinguishedName=cn=TestManagedRole,ou=People,dc=my-ds-domain,dc=com
> 2014-06-06 12:44:39,821 TRACE [org.jboss.as.domain.management.security] (XNIO-1 task-1) Failure supplementing Subject: javax.naming.NameNotFoundException: [LDAP: error code 32 - No Such Object]; remaining name 'cn=TestManagedRole,ou=People,dc=my-ds-domain,dc=com'
> at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3112) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3033) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2840) [rt.jar:1.7.0_45]
> at com.sun.jndi.ldap.LdapCtx.c_getAttributes(LdapCtx.java:1332) [rt.jar:1.7.0_45]
> at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_getAttributes(ComponentDirContext.java:231) [rt.jar:1.7.0_45]
> at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:139) [rt.jar:1.7.0_45]
> at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.getAttributes(PartialCompositeDirContext.java:127) [rt.jar:1.7.0_45]
> at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142) [rt.jar:1.7.0_45]
> at javax.naming.directory.InitialDirContext.getAttributes(InitialDirContext.java:142) [rt.jar:1.7.0_45]
> at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:256) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapGroupSearcherFactory$PrincipalToGroupSearcher.search(LdapGroupSearcherFactory.java:191) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapCacheService$NoCacheCache.search(LdapCacheService.java:223) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroupEntries(LdapSubjectSupplementalService.java:218) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroups(LdapSubjectSupplementalService.java:195) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.loadGroups(LdapSubjectSupplementalService.java:188) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.LdapSubjectSupplementalService$LdapSubjectSupplemental.supplementSubject(LdapSubjectSupplementalService.java:163) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.management.security.SecurityRealmService$1.createSubjectUserInfo(SecurityRealmService.java:200) [wildfly-domain-management-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:155) [wildfly-domain-http-interface-8.1.0.Final.jar:8.1.0.Final]
> at org.jboss.as.domain.http.server.security.RealmIdentityManager.verify(RealmIdentityManager.java:120) [wildfly-domain-http-interface-8.1.0.Final.jar:8.1.0.Final]
> at io.undertow.security.impl.BasicAuthenticationMechanism.authenticate(BasicAuthenticationMechanism.java:110) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at org.jboss.as.domain.http.server.security.AuthenticationMechanismWrapper.authenticate(AuthenticationMechanismWrapper.java:57) [wildfly-domain-http-interface-8.1.0.Final.jar:8.1.0.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:281) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:298) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:268) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:131) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:106) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:99) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50) [undertow-core-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:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 4 months
[JBoss JIRA] (WFCORE-40) Deadlock while logging
by Stefan Schueffler (JIRA)
[ https://issues.jboss.org/browse/WFCORE-40?page=com.atlassian.jira.plugin.... ]
Stefan Schueffler commented on WFCORE-40:
-----------------------------------------
Unfortunately i'm not able to provide an easy to reproduce kickstart project. None of my test-projects (using jmeter for load, different loggings, System.out, Stacktraces and so on) leads to the same locking/blocking of threads.
Apart from this, in our live production environment the error is always the same: either we reduce logging to an absolute minimum (i.e. no logging at all), or we will run in the locking/waiting for lock situation sooner or later (at least once a day).
I found this issue in jira, which sounds the same in terms of "problem description/behavior" : endless loop in fillInStackTrace. (Un)fortunately, this bug is solved (according to the jira ticket), and the fixed version is installed in wildfly - so, we do not have the exact same problem here, but a very similar problem behavior...
https://issues.jboss.org/browse/XNIO-215
> Deadlock while logging
> ----------------------
>
> Key: WFCORE-40
> URL: https://issues.jboss.org/browse/WFCORE-40
> Project: WildFly Core
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Logging
> Environment: CentOS 6.5 64bit, java7u45 64bit (and 32 bit, the same behavior)
> Reporter: Stefan Schueffler
> Assignee: James Perkins
> Priority: Critical
>
> We hit really often a deadlock? in org.jboss.stdio.StdioContext$DelegatingPrintStream.println(StdioContext.java:474)
> Even if the "StdioContext" belongs to Jboss-Logging, the problem occurs in our production wildfly installation twice to 4 times a day - all threads are deadlocking while trying to log.debug, log.error, or (sometimes) System.out.println from our application code, and wildfly does not respond anymore...
> The partial stacktrace always is similar to this one:
> {code}
> "default task-64" prio=10 tid=0x4c539c00 nid=0x5ef9 waiting for monitor entry [0x495e0000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at java.io.PrintStream.println(PrintStream.java:806)
> - waiting to lock <0x5ee0adf8> (a java.io.PrintStream)
> at org.jboss.stdio.StdioContext$DelegatingPrintStream.println(StdioContext.java:474)
> at jsp.communications.statuschange.selectStatus_jsp._jspService(selectStatus_jsp.java:413)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:69)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82)
> {code}
> While investigating the StdioContext - class, i really wondered whether the used "locking/checking by using a threadlocal" could have worked in a multi-threaded environment (it should have the very same problems as every "double checking" algorithm without proper synchronization).
> If all threads are hanging in this particular lock, only a full wildfly-restart recovers in our case.
> My preferred solution would be a rework of the used org.jboss.stdio. classes, as the used idioms of ThreadLocals for reentrant-checks are at least highly unusual?
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 4 months