[JBoss JIRA] (WFLY-1966) Hangs in DomainControllerMigrationTestCase
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-1966?page=com.atlassian.jira.plugin.... ]
Brian Stansberry resolved WFLY-1966.
------------------------------------
Assignee: Darran Lofthouse
Resolution: Done
Darran fixed the Subject propagation issue quite a while ago.
> Hangs in DomainControllerMigrationTestCase
> ------------------------------------------
>
> Key: WFLY-1966
> URL: https://issues.jboss.org/browse/WFLY-1966
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Darran Lofthouse
> Fix For: 8.0.0.CR1
>
> Attachments: thread-dump.txt
>
>
> DomainControllerMigrationTestCase is intermittently hanging recently.
> I will attach thread dumps from a recent hang.
> The test driver is hanging here:
> "main" prio=10 tid=0xb7605c00 nid=0x7656 in Object.wait() [0xb7786000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xa99833f8> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at java.lang.Object.wait(Object.java:503)
> at org.jboss.threads.AsyncFutureTask.await(AsyncFutureTask.java:192)
> - eliminated <0xa99833f8> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
> - locked <0xa99833f8> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:76)
> at org.jboss.as.controller.client.helpers.domain.impl.DomainClientImpl.execute(DomainClientImpl.java:86)
> at org.jboss.as.test.integration.domain.management.util.DomainLifecycleUtil.executeForResult(DomainLifecycleUtil.java:580)
> at org.jboss.as.test.integration.domain.DomainControllerMigrationTestCase.testDCFailover(DomainControllerMigrationTestCase.java:206)
> The master HC process is stuck here:
> "management-handler-thread - 2" prio=10 tid=0x8be50400 nid=0x1a92 waiting on condition [0x87604000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xaa032fd0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
> at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at org.jboss.as.controller.remote.BlockingQueueOperationListener.retrievePreparedOperation(BlockingQueueOperationListener.java:84)
> at org.jboss.as.domain.controller.operations.coordination.DomainSlaveHandler.execute(DomainSlaveHandler.java:117)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:608)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:486)
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:275)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:270)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:257)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:142)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:205)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:110)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$2.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> I see nothing relevant in the other thread dumps.
> The master HC is blocking waiting for a response from the slave HC.
> Just before the client makes the request that triggers this, it has reloaded the slave HC. The test is not robust in terms of how it checks that the slave is ready before continuing on with the test; it merely connects directly to the slave checks that the slave's root resource can be read. That can succeed relatively early in boot even before the slave has registered with the master.
> Fixing that may prevent the hangs, but it would likely paper over whatever problem is causing the hangs. A client invoking multi-host operations while a slave is booting and registering is a use case that can't hang.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (WFLY-959) Allow more flexibility in the way EJB authentication is handled with regards to remoting and security-realms
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-959?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse commented on WFLY-959:
---------------------------------------
Re-reading your comment - the answer is No.
The authentication occurs on the establishment of the connection to the server, at that point we do not know what is going to be invoked and that connection can be used to invoke many different services including many different EJB deployments so there is not at this point an underlying subsystem that we can delegate to.
> Allow more flexibility in the way EJB authentication is handled with regards to remoting and security-realms
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-959
> URL: https://issues.jboss.org/browse/WFLY-959
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Reporter: Derek Horton
> Assignee: David Lloyd
>
> My confusion is around the remoting/security-realm setup in the use case
> where multiple EJBs are deployed that use different security-domains and
> the EJBs will be invoked by remote standalone clients. For example,
> ejbX needs to be in the sec-domain-X security-domain, while ejbY needs to
> be in the sec-domain-Y security-domain.
> In this situation, the authentication checks are going to be handled by
> the security-realm that is associated with the remote connector that is
> configured to be used by the EJB subsystem.
> It looks like the security-realm can either handle the authentication
> checks directly (properties file, ldap, etc) or it can defer to the
> jaas security-domain. In both of those situations, it seems that the
> EJBs are limited to a single authentication point. The EJB
> authentication is either going to be handled by a single security-realm
> or the security-realm will defer to a single security-domain.
> I could configure the security-domain to have multiple login modules. I
> assume the same thing could be done with the security-realm.
> Basically the problem that I am trying to solve boils down to this: the
> authentication checks for remote EJBs appear to be checked by either a
> single security-realm or a single security-domain. Is there a way to
> change this?
> One idea I had was to add another remote connector to the EJB subsystem.
> Unfortunately, this does not appear to be possible.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (WFLY-959) Allow more flexibility in the way EJB authentication is handled with regards to remoting and security-realms
by Corey Puffalt (JIRA)
[ https://issues.jboss.org/browse/WFLY-959?page=com.atlassian.jira.plugin.s... ]
Corey Puffalt commented on WFLY-959:
------------------------------------
Darran, my concern was that the so-called complete solution proposed by Jaikiran above is very complicated which is why I was asking whether a simple delegated approach would be feasible. Conceptually this would make a lot more sense to users.
> Allow more flexibility in the way EJB authentication is handled with regards to remoting and security-realms
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-959
> URL: https://issues.jboss.org/browse/WFLY-959
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Reporter: Derek Horton
> Assignee: David Lloyd
>
> My confusion is around the remoting/security-realm setup in the use case
> where multiple EJBs are deployed that use different security-domains and
> the EJBs will be invoked by remote standalone clients. For example,
> ejbX needs to be in the sec-domain-X security-domain, while ejbY needs to
> be in the sec-domain-Y security-domain.
> In this situation, the authentication checks are going to be handled by
> the security-realm that is associated with the remote connector that is
> configured to be used by the EJB subsystem.
> It looks like the security-realm can either handle the authentication
> checks directly (properties file, ldap, etc) or it can defer to the
> jaas security-domain. In both of those situations, it seems that the
> EJBs are limited to a single authentication point. The EJB
> authentication is either going to be handled by a single security-realm
> or the security-realm will defer to a single security-domain.
> I could configure the security-domain to have multiple login modules. I
> assume the same thing could be done with the security-realm.
> Basically the problem that I am trying to solve boils down to this: the
> authentication checks for remote EJBs appear to be checked by either a
> single security-realm or a single security-domain. Is there a way to
> change this?
> One idea I had was to add another remote connector to the EJB subsystem.
> Unfortunately, this does not appear to be possible.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (WFLY-2403) Cannot disable Datasource or XADatasource in standalone and domain modes
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2403?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2403:
-----------------------------------------------
Martin Simka <msimka(a)redhat.com> made a comment on [bug 970679|https://bugzilla.redhat.com/show_bug.cgi?id=970679]
By following steps to reproduce I got:
[standalone@localhost:9999 /] data-source add --name=Test2 --driver-name=h2 --enabled=true --jndi-name=java:jboss/datasources/Test2 --connection-url=jdbc:h2:mem:test2;DB_CLOSE_DELAY=-1
[standalone@localhost:9999 /] data-source disable --name=Test2
operation-requires-reload true
process-state reload-required
[standalone@localhost:9999 /] re
read-attribute read-operation reload
[standalone@localhost:9999 /] reload
[standalone@localhost:9999 /] /subsystem=datasources/data-source=Test2:read-attribute(name=enabled)
{
"outcome" => "success",
"result" => false
}
[standalone@localhost:9999 /]
but there is another problem:
[standalone@localhost:9999 /] data-source add --name=Test2 --driver-name=h2 --enabled=true --jndi-name=java:jboss/datasources/Test2 --connection-url=jdbc:h2:mem:test2;DB_CLOSE_DELAY=-1
[standalone@localhost:9999 /] /subsystem=datasources/data-source=Test2:read-attribute(name=enabled)
{
"outcome" => "success",
"result" => false
}
datasource is not enabled, it requires restart/reload, but it doesn't notifies user.
[standalone@localhost:9999 /] reload
[standalone@localhost:9999 /] /subsystem=datasources/data-source=Test2:read-attribute(name=enabled)
{
"outcome" => "success",
"result" => true
}
Is it part of this issue or is it another issue? Should I create new BZ?
> Cannot disable Datasource or XADatasource in standalone and domain modes
> ------------------------------------------------------------------------
>
> Key: WFLY-2403
> URL: https://issues.jboss.org/browse/WFLY-2403
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Stefano Maestri
> Assignee: Stefano Maestri
>
> Description of problem:
> Cannot disable a Datasource or XADatasource in standalone mode. It's back to enabled state after server reload.
> Version-Release number of selected component (if applicable):
> 6.1
> How reproducible:
> Always
> Steps to Reproduce:
> Use the http management interface or the CLI
> 1.Create a Datasource of XADatasource
> 2.Disable it
> 3.The response indicates a server reload is required
> 4.Execute the reload operation
> Actual results:
> The datasource is back to enabled state
> Expected results:
> The datasource should be in disabled state
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (WFLY-2383) resource-adapter id attribute has to match ra name otherwise MDB is not deployed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2383?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2383:
-----------------------------------------------
Stefano Maestri <smaestri(a)redhat.com> made a comment on [bug 1012044|https://bugzilla.redhat.com/show_bug.cgi?id=1012044]
Well starting w/ your example I've just tried those 3 config:
<subsystem xmlns="urn:jboss:domain:ejb3:1.4">
<mdb>
<resource-adapter-ref resource-adapter-name="wmq.jmsra.rar"/>
<bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
</mdb>
...
<subsystem xmlns="urn:jboss:domain:resource-adapters:1.1">
<resource-adapters>
<resource-adapter id="wmq.jmsra">
<archive>wmq.jmsra.rar</archive>
<subsystem xmlns="urn:jboss:domain:ejb3:1.4">
<mdb>
<resource-adapter-ref resource-adapter-name="wmq.jmsra.rar"/>
<bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
</mdb>
...
<subsystem xmlns="urn:jboss:domain:resource-adapters:1.1">
<resource-adapters>
<resource-adapter id="wmq.jmsra.rar">
<archive>wmq.jmsra.rar</archive>
<subsystem xmlns="urn:jboss:domain:ejb3:1.4">
<mdb>
<resource-adapter-ref resource-adapter-name="ibm-resource-adapter"/>
<bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
</mdb>
...
<subsystem xmlns="urn:jboss:domain:resource-adapters:1.1">
<resource-adapters>
<resource-adapter id="ibm-resource-adapter">
<archive>wmq.jmsra.rar</archive>
All of them worked for me (EAP 6.x branch)
What am I not covering?
> resource-adapter id attribute has to match ra name otherwise MDB is not deployed
> --------------------------------------------------------------------------------
>
> Key: WFLY-2383
> URL: https://issues.jboss.org/browse/WFLY-2383
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Stefano Maestri
> Assignee: Stefano Maestri
>
> The resource-adapter id has to have the same name as the ra archive has. Otherwise the the MDB is not deployed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (WFLY-2428) MDBs should use the full identifier of the resource adapter
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2428?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2428:
-----------------------------------------------
Stefano Maestri <smaestri(a)redhat.com> made a comment on [bug 1012044|https://bugzilla.redhat.com/show_bug.cgi?id=1012044]
Well starting w/ your example I've just tried those 3 config:
<subsystem xmlns="urn:jboss:domain:ejb3:1.4">
<mdb>
<resource-adapter-ref resource-adapter-name="wmq.jmsra.rar"/>
<bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
</mdb>
...
<subsystem xmlns="urn:jboss:domain:resource-adapters:1.1">
<resource-adapters>
<resource-adapter id="wmq.jmsra">
<archive>wmq.jmsra.rar</archive>
<subsystem xmlns="urn:jboss:domain:ejb3:1.4">
<mdb>
<resource-adapter-ref resource-adapter-name="wmq.jmsra.rar"/>
<bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
</mdb>
...
<subsystem xmlns="urn:jboss:domain:resource-adapters:1.1">
<resource-adapters>
<resource-adapter id="wmq.jmsra.rar">
<archive>wmq.jmsra.rar</archive>
<subsystem xmlns="urn:jboss:domain:ejb3:1.4">
<mdb>
<resource-adapter-ref resource-adapter-name="ibm-resource-adapter"/>
<bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>
</mdb>
...
<subsystem xmlns="urn:jboss:domain:resource-adapters:1.1">
<resource-adapters>
<resource-adapter id="ibm-resource-adapter">
<archive>wmq.jmsra.rar</archive>
All of them worked for me (EAP 6.x branch)
What am I not covering?
> MDBs should use the full identifier of the resource adapter
> -----------------------------------------------------------
>
> Key: WFLY-2428
> URL: https://issues.jboss.org/browse/WFLY-2428
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.CR1
> Reporter: Jesper Pedersen
> Assignee: Stefano Maestri
> Fix For: 8.0.0.CR1
>
>
> The .rar suffix shouldn't be stripped anymore, as the resource adapters are registered under their full name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (WFLY-2481) CDI.current().getBeanManager() returns a beanmanager from a different deployment
by Emond Papegaaij (JIRA)
[ https://issues.jboss.org/browse/WFLY-2481?page=com.atlassian.jira.plugin.... ]
Emond Papegaaij commented on WFLY-2481:
---------------------------------------
I don't know why this was moved to WildFly, but the same problem is also present in Glassfish. I've updated the testcase to demonstrate the problem on both WildFly and Glassfish.
> CDI.current().getBeanManager() returns a beanmanager from a different deployment
> --------------------------------------------------------------------------------
>
> Key: WFLY-2481
> URL: https://issues.jboss.org/browse/WFLY-2481
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.0.0.Beta1
> Environment: WildFly master build
> Reporter: Emond Papegaaij
> Assignee: Jozef Hartinger
>
> CDI.current().getBeanManager() uses the classname of the calling class to cache BeanManagers returned. This fails if multiple deployments contain classes with the same name. For example, wicket-cdi-1.1 looks up the BeanManager from org.apache.wicket.cdi.CdiConfiguration. If multiple Wicket-CDI applications are deployed in the same container, every BeanManager lookup will return the instance cached on the first call.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months
[JBoss JIRA] (DROOLS-336) Property Reactivity fails on phreak
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-336?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-336:
------------------------------------------------
Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1029071|https://bugzilla.redhat.com/show_bug.cgi?id=1029071] from NEW to ASSIGNED
> Property Reactivity fails on phreak
> -----------------------------------
>
> Key: DROOLS-336
> URL: https://issues.jboss.org/browse/DROOLS-336
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Mario Fusco
> Assignee: Mario Fusco
>
> In LeftInputAdapterNode a modifyByPass happens, for a sink that has not been reached before. So it thinks it's new, and thus propagates as an insert
> The real bug comes in doInsertObject method. It creates a child LT here, even though once it enters doInsertSegmentMemory the mask intersect fails. This leaves a child LT, that is not propagated. Next time update is called, as the LT is there it thinks it's a modify and propagates as a modify - but it never reached the beta node or the LeftMemory, and thus the memory corruption.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 6 months