[JBoss JIRA] (WFCORE-364) Hangs in mixed domain testsuite
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-364?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-364:
------------------------------------
Fix Version/s: 2.0.0.CR1
(was: 2.0.0.Alpha9)
> Hangs in mixed domain testsuite
> -------------------------------
>
> Key: WFCORE-364
> URL: https://issues.jboss.org/browse/WFCORE-364
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.0.0.CR1
>
> Attachments: testsuite-hang1-server.txt, testsuite-hang2-client.txt, testsuite-hang2-server.txt
>
>
> http://lightning.mw.lab.eng.bos.redhat.com/jenkins/job/wildfly-param-pull...
> https://dl.dropboxusercontent.com/u/712508/mixed-hang-debug.zip contains details.
> 30805.dump is the client and shows the problem is occurring in the @After cleanup of MixedDomainDeploymentTest as it removes deployments from the domain.
> "main" prio=10 tid=0xf7605c00 nid=0x7856 in Object.wait() [0xf776e000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xe50275f0> (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)
> - locked <0xe50275f0> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
> - locked <0xe50275f0> (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:71)
> at org.jboss.as.controller.client.helpers.domain.impl.DomainClientImpl.execute(DomainClientImpl.java:81)
> at org.jboss.as.test.integration.domain.mixed.MixedDomainDeploymentTest.removeDeployment(MixedDomainDeploymentTest.java:441)
> at org.jboss.as.test.integration.domain.mixed.MixedDomainDeploymentTest.cleanDeployments(MixedDomainDeploymentTest.java:343)
> at org.jboss.as.test.integration.domain.mixed.MixedDomainDeploymentTest.confirmNoDeployments(MixedDomainDeploymentTest.java:163)
> 31894.dump shows the master HC. management-handler-thread is blocking on the way out (after sending the commit or rollback) waiting for a final result response from the slave.
> "management-handler-thread - 1" prio=10 tid=0xca0efc00 nid=0x7cdd in Object.wait() [0xc7469000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xeb6d6558> (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)
> - locked <0xeb6d6558> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.threads.AsyncFutureTask.get(AsyncFutureTask.java:266)
> - locked <0xeb6d6558> (a org.jboss.as.protocol.mgmt.ActiveOperationSupport$ActiveOperationImpl)
> at org.jboss.as.controller.client.impl.AbstractDelegatingAsyncFuture.get(AbstractDelegatingAsyncFuture.java:100)
> at org.jboss.as.domain.controller.operations.coordination.DomainSlaveHandler.finalizeOp(DomainSlaveHandler.java:215)
> at org.jboss.as.domain.controller.operations.coordination.DomainSlaveHandler.access$000(DomainSlaveHandler.java:58)
> at org.jboss.as.domain.controller.operations.coordination.DomainSlaveHandler$1.handleResult(DomainSlaveHandler.java:179)
> at org.jboss.as.controller.AbstractOperationContext$Step.handleRollback(AbstractOperationContext.java:805)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:763)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:738)
> (Note that the "handleRollback" method name is a red-herring -- the method should be renamed to a "handleResult" as it now is called no matter what the result.)
> 31986.dump is the slave HC. It shows it is blocking in stage DONE after having sent operationPrepared to the master, waiting for commit or rollback.
> "domain-connection-threads - 1" prio=10 tid=0xc91a8400 nid=0x7d1a waiting on condition [0xc87fe000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xea1fd410> (a java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:236)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ProxyOperationControlProxy.operationPrepared(TransactionalProtocolOperationHandler.java:173)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:337)
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211)
> at org.jboss.as.domain.controller.operations.coordination.ServerOperationsResolverHandler.execute(ServerOperationsResolverHandler.java:128)
> Indication is the commit or rollback message is getting lost. There are no threads shown sending or receiving it.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
6 years
[JBoss JIRA] (DROOLS-37) Operators on java.lang.Comparable object doesn't work if JIT is enable
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-37?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on DROOLS-37:
-----------------------------------------------
Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1233978|https://bugzilla.redhat.com/show_bug.cgi?id=1233978] from ON_QA to VERIFIED
> Operators on java.lang.Comparable object doesn't work if JIT is enable
> ----------------------------------------------------------------------
>
> Key: DROOLS-37
> URL: https://issues.jboss.org/browse/DROOLS-37
> Project: Drools
> Issue Type: Bug
> Affects Versions: 5.5.0.Final
> Environment: Windows XP
> Java 1.5
> joda-time 1.6.2
> Reporter: Jérémy SOULA
> Assignee: Mario Fusco
> Labels: 5.5, comparable, localDate
> Fix For: 5.5.1.Final, 6.0.0.Alpha9
>
> Attachments: drools-bugs.zip
>
>
> In my application, i have rules that used org.joda.time.LocalDate to compare date like
> {noformat}
> rule "toto"
> when
> LocalDateForDroolsTestBean(
> infDate>=supDate
> )
> then
> //Anything
> end
> {noformat}
> With Drools 5.3, all works fine.
> With Drools 5.5, an exception occured because JIT optimizer automaticaly enabled:
> {noformat}
> Exception in thread "main" java.lang.NoSuchMethodError: org.joda.time.LocalDate.compareTo(Lorg/joda/time/LocalDate;)I
> at ConditionEvaluatorf8ba8fa3003345adbf3979e901488f23.evaluate(Unknown Source)
> at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:200)
> at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:157)
> at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:137)
> at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59)
> at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
> at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350)
> at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311)
> at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903)
> at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847)
> at org.drools.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:269)
> at org.drools.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:304)
> at fr.jsoula.jboss.drools.bugs.comparable.ComparableBug.main(ComparableBug.java:39)
> {noformat}
> After search, it seems that the bytecode generated by org.drools.rule.builder.dialect.asm.ClassGenerator can't call the method public int compareTo(Object partial) of org.joda.time.LocalDate. The parameter of the method must be the same class of the current object.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
6 years
[JBoss JIRA] (WFCORE-710) Make ServerOperationResolver handle deployment-overlays similarly to deployments
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-710?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-710:
------------------------------------
Fix Version/s: 2.0.0.CR1
(was: 2.0.0.Alpha9)
[~kabirkhan] I'm moving this to CR1 as Alpha9 is clearly incorrect. But if this won't happen for CR1 please reschedule.
> Make ServerOperationResolver handle deployment-overlays similarly to deployments
> --------------------------------------------------------------------------------
>
> Key: WFCORE-710
> URL: https://issues.jboss.org/browse/WFCORE-710
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Affects Versions: 2.0.0.Alpha2
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 2.0.0.CR1
>
>
> Currently in domain mode a
> {code}
> /deployment-overlay=xxx:add(...)
> {code}
> results in a deployment overlay on ALL servers.
> However for deployments
> {code}
> /deployment=xxx:add(...)
> {code}
> does not get pushed to the servers. This happens when it is associated with a server group:
> {code}
> /server-group=zzz/deployment=xxx:add(...)
> {code}
> Similarly
> {code}
> /deployment-overlay=xxx:add(...)
> {code}
> should not get pushed to the servers, until we have a
> {code}
> /server-group=zzz/deployment=yyy:add(...)
> {code}
> which picks out the servers we want to have the overlay
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
6 years
[JBoss JIRA] (WFCORE-372) Cache role mapping results for the span of the overall operation
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-372?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-372:
------------------------------------
Fix Version/s: 3.0.0.Beta1
(was: 2.0.0.Alpha9)
I'm blindly moving this to 3.0.0.Beta1.
> Cache role mapping results for the span of the overall operation
> ----------------------------------------------------------------
>
> Key: WFCORE-372
> URL: https://issues.jboss.org/browse/WFCORE-372
> Project: WildFly Core
> Issue Type: Sub-task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Darran Lofthouse
> Labels: access_control, management_security,
> Fix For: 3.0.0.Beta1
>
>
> Look into caching role mapping results for the duration of an overall operation. This would be an impl detail of the RoleMapper. With our standard mappers, the mapping results should not be changing in the middle of an operation, so I believe they should be cacheable.
> Likely place to cache them is as an attachment in a context object that will be passed in to the Authorizer. It would have to be passed in to the RoleMapper as well.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
6 years
[JBoss JIRA] (WFCORE-170) Create a shared ScheduledExecutorService
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-170?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-170:
------------------------------------
Fix Version/s: 3.0.0.Alpha1
(was: 2.0.0.Alpha9)
> Create a shared ScheduledExecutorService
> ----------------------------------------
>
> Key: WFCORE-170
> URL: https://issues.jboss.org/browse/WFCORE-170
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha1
>
>
> There are number of ScheduledExecutorService instances being created around wf-core. Create a single service and inject it.
> This will reduce resource usage by creating fewer threads, and will reduce the risk of code mistakes around shutting down the various executors,
> I see these used in:
> LdapCacheService
> RemoteDomainConnectionService
> DeploymentMountProvider
> DeploymentScannerService
> plus the operation response attachment stuff I'm doing will need one.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
6 years
[JBoss JIRA] (WFCORE-91) Review use of Locale in toLowerCase() calls
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-91?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFCORE-91:
-----------------------------------
Fix Version/s: 3.0.0.Alpha1
(was: 2.0.0.Alpha9)
> Review use of Locale in toLowerCase() calls
> -------------------------------------------
>
> Key: WFCORE-91
> URL: https://issues.jboss.org/browse/WFCORE-91
> Project: WildFly Core
> Issue Type: Task
> Components: CLI, Domain Management
> Reporter: Brian Stansberry
> Fix For: 3.0.0.Alpha1
>
>
> There are places where we are converting strings to lower case without specifying Locale.ENGLISH. Some of these may be fine, but some are not and they should all be reviewed:
> {code}
> $ git grep "toLowerCase()"
> cli/src/main/java/org/jboss/as/cli/impl/CommandContextImpl.java: CommandHandler handler = cmdRegistry.getCommandHandler(cmdName.toLowerCase());
> cli/src/main/java/org/jboss/as/cli/impl/CommandContextImpl.java: CommandHandler handler = cmdRegistry.getCommandHandler(cmdName.toLowerCase());
> controller/src/main/java/org/jboss/as/controller/operations/global/ReadResourceDescriptionHandler.java: final AccessControl value = localName != null ? MAP.get(local
> core-model-test/tests/src/test/java/org/jboss/as/core/model/test/access/RoleMappingTestCase.java: return super.toString().toLowerCase();
> core-model-test/tests/src/test/java/org/jboss/as/core/model/test/access/RoleMappingTestCase.java: return super.toString().toLowerCase();
> core-model-test/tests/src/test/java/org/jboss/as/core/model/test/standalone/root/StandaloneRootResourceTestCase.java: String hostName = NetworkUtils.canonize(InetAddress
> domain-management/src/main/java/org/jboss/as/domain/management/security/adduser/ConfirmationChoice.java: String temp = response.toLowerCase(); // We now need to matc
> domain-management/src/test/java/org/jboss/as/domain/management/security/auditlog/AbstractAuditLogHandlerTestCase.java: PathElement.pathElement(PROTOCOL, transpor
> host-controller/src/main/java/org/jboss/as/host/controller/DirectoryGrouping.java: final DirectoryGrouping directoryGrouping = localName != null ? MAP.get(localName.toLo
> host-controller/src/main/java/org/jboss/as/host/controller/HostControllerEnvironment.java: qualifiedHostName = qualifiedHostName.trim().toLowerCase();
> host-controller/src/main/java/org/jboss/as/host/controller/discovery/S3Util.java: String lk=hashKey.toLowerCase();
> server/src/main/java/org/jboss/as/server/ServerEnvironment.java: qualifiedHostName = qualifiedHostName.trim().toLowerCase();
> testsuite-core/domain/src/test/java/org/jboss/as/test/integration/domain/rbac/RbacSoakTest.java: super("TestClient-" + id + " (" + type.toString().toLowerCase() + "
> testsuite-core/domain/src/test/java/org/jboss/as/test/integration/domain/rbac/RbacSoakTest.java: this.description = "TestClient-" + id + " (" + type.toString().toLow
> testsuite-core/shared/src/main/java/org/jboss/as/test/integration/management/interfaces/JmxInterfaceStringUtils.java: return string.replaceAll(regex, replacement).toLowe
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
6 years
[JBoss JIRA] (WFCORE-609) Administrator Encouragement
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-609?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-609:
------------------------------------
Fix Version/s: (was: 2.0.0.Alpha9)
I'm unscheduling this because it needs to be consider in conjunction with other requirements.
> Administrator Encouragement
> ---------------------------
>
> Key: WFCORE-609
> URL: https://issues.jboss.org/browse/WFCORE-609
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
>
> I know the name is not popular so will have a better name ;-)
> Essentially some form of centralised repository to hold warnings raised by subsystems as a server boots.
> Management operations would be provided to query the current warnings.
> As administrators undertake actions to correct a warning it will be dynamically removed by the subsystem that reported it.
> This is not about persistent warnings i.e. the subsystem should raise the warning on every boot and stop raising it if it is no longer relevant.
> e.g. SSL not enabled, warn every time the server starts until it is enabled.
> Warnings will be associated with a severity level and administrative tooling can decide how pro-actively to display the warning, e.g. the console may pop up immediately for a critical warning or use an icon to indicate the presence of a lesser warning.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
6 years
[JBoss JIRA] (WFLY-5240) Log EJB Request
by Brad Maxwell (JIRA)
Brad Maxwell created WFLY-5240:
----------------------------------
Summary: Log EJB Request
Key: WFLY-5240
URL: https://issues.jboss.org/browse/WFLY-5240
Project: WildFly
Issue Type: Bug
Components: EJB
Reporter: Brad Maxwell
Assignee: Brad Maxwell
Log Trace Message when EJB Request comes into the serer
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
6 years