[JBoss JIRA] (JBRULES-3658) Constraint disappearing from rete network due to alpha node hashing
by Adar Dembo (JIRA)
Adar Dembo created JBRULES-3658:
-----------------------------------
Summary: Constraint disappearing from rete network due to alpha node hashing
Key: JBRULES-3658
URL: https://issues.jboss.org/browse/JBRULES-3658
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-compiler
Affects Versions: 5.4.0.Final
Environment: java version "1.6.0_32"
Java(TM) SE Runtime Environment (build 1.6.0_32-b05)
Java HotSpot(TM) 64-Bit Server VM (build 20.7-b02, mixed mode)
Reporter: Adar Dembo
Assignee: Mark Proctor
Under very specific conditions, the alpha node hashing in CompositeObjectSinkAdapter can "drop" viable sinks from the RETE network. Specifically, if two alpha nodes represent the same constraint, the hashing will view them as identical even if the outbound sinks from these nodes differ.
Using ReteooVisitor from the Drools Eclipse plugin as inspiration, I wrote some code to walk my knowledge base from a particular ObjectTypeNode and describe each node along the way. The results are below:
{noformat}
[ObjectTypeNode(56)::EntryPoint::DEFAULT objectType=[ClassObjectType class=com.cloudera.cmf.model.DbRoleConfigGroup] expiration=-1ms ]
X [AlphaNode(219) constraint=roleType == "GATEWAY"] (hashCode -578253791, index 1)
[JoinNode(220) - [ClassObjectType class=com.cloudera.cmf.model.DbRoleConfigGroup]]
[ AccumulateNode(221) ]
[RuleTerminalNode(222): rule=Compute mapred_submit_replication for MR2 Service]
[AlphaNode(214) constraint=roleType == "GATEWAY"] (hashCode -578253791, index 1)
[JoinNode(215) - [ClassObjectType class=com.cloudera.cmf.model.DbRoleConfigGroup]]
[ AccumulateNode(216) ]
[RuleTerminalNode(217): rule=Compute mapred_submit_replication for MapReduce Service]
X [AlphaNode(57) constraint=roleType == HdfsServiceHandler.RoleNames.NAMENODE.name()]
[JoinNode(58) - [ClassObjectType class=com.cloudera.cmf.model.DbRoleConfigGroup]]
[RuleTerminalNode(59): rule=Compute dfs_namenode_handler_count for an NN role config group]
X [AlphaNode(194) constraint=roleType == MapReduceServiceHandler.RoleNames.TASKTRACKER.name()]
[JoinNode(195) - [ClassObjectType class=com.cloudera.cmf.model.DbRoleConfigGroup]]
[ExistsNode(197) - [ClassObjectType class=com.cloudera.cmf.model.DbService]]
[RuleTerminalNode(198): rule=Configure MapReduce TT instrumentation with MGMT]
[NotNode(199) - [ClassObjectType class=com.cloudera.cmf.model.DbService]]
[RuleTerminalNode(200): rule=Configure MapReduce TT instrumentation without MGMT]
X [AlphaNode(210) constraint=roleType == MapReduceServiceHandler.RoleNames.JOBTRACKER.name()]
[JoinNode(211) - [ClassObjectType class=com.cloudera.cmf.model.DbRoleConfigGroup]]
[RuleTerminalNode(212): rule=Compute mapred_job_tracker_handler_count for MapReduce Service]
X [AlphaNode(62) constraint=roleType == HueServiceHandler.RoleNames.BEESWAX_SERVER.name()]
[JoinNode(63) - [ClassObjectType class=com.cloudera.cmf.model.DbRoleConfigGroup]]
[RuleTerminalNode(64): rule=Assign Beeswax Warehouse dir]
X [JoinNode(235) - [ClassObjectType class=com.cloudera.cmf.model.DbRoleConfigGroup]]
[QueryTerminalNode(236): query=FIND_ALL_ROLE_CONFIG_GROUPS]
{noformat}
Every node that made it into the adapter's hashedSinkMap, hashableSinks, or otherSinks is marked with an 'X'. Note that alpha node 214 is missing. It was in hashedSinkMap, but was evicted when alpha node 219 was added, because 219 hashes to the same key. Without alpha node 214, the rest of a rule underneath it becomes orphaned and never fires.
--
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
13 years, 9 months
[JBoss JIRA] (AS7-5771) add daemon in thread factory configuration
by Mathieu Lachance (JIRA)
Mathieu Lachance created AS7-5771:
-------------------------------------
Summary: add daemon in thread factory configuration
Key: AS7-5771
URL: https://issues.jboss.org/browse/AS7-5771
Project: Application Server 7
Issue Type: Enhancement
Affects Versions: 7.1.1.Final
Reporter: Mathieu Lachance
it is currently not possible to flag thread as daemon in the threads subsystem.
it would be nice to do it like that :
<subsystem xmlns="urn:jboss:domain:threads:1.1">
<thread-factory ... daemon="true" />
...
</subsystem>
--
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
13 years, 9 months
[JBoss JIRA] (AS7-5772) ServerInventory#reconnectServer should take auto-start into account
by Emanuel Muckenhuber (JIRA)
Emanuel Muckenhuber created AS7-5772:
----------------------------------------
Summary: ServerInventory#reconnectServer should take auto-start into account
Key: AS7-5772
URL: https://issues.jboss.org/browse/AS7-5772
Project: Application Server 7
Issue Type: Task
Components: Domain Management
Reporter: Emanuel Muckenhuber
Fix For: 7.2.0.CR1
When reconnecting to stopped (but not removed) servers, the ServerInventory should take the auto-start property into account. Otherwise the process will just get removed, however started with the next :reload of the HC.
--
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
13 years, 9 months
[JBoss JIRA] (AS7-4981) Server instance cannot start after host-contoroller and server instance processes are killed at once in domain mode
by Masafumi Miura (JIRA)
Masafumi Miura created AS7-4981:
-----------------------------------
Summary: Server instance cannot start after host-contoroller and server instance processes are killed at once in domain mode
Key: AS7-4981
URL: https://issues.jboss.org/browse/AS7-4981
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Affects Versions: 7.1.2.Final (EAP)
Environment: This issue is reproducible in the following versions:
* EAP 6.0.0 Beta2
* jboss-as-7.1.2.Final
* jboss-as-7.1.3.Final-SNAPSHOT
Reporter: Masafumi Miura
Assignee: Brian Stansberry
When host-contoroller and server instance processes are killed at once in domain mode, the host-controller process is auto-restarted successfully by process-controller but the server instance process is not auto-restarted with the following ERROR in process-controller.log:
{noformat:title=process-controller.log|borderStyle=solid}
16:24:47,599 INFO [org.jboss.as.process.Host Controller.status] (reaper for Host Controller) JBAS012010: Process 'Host Controller' finished with an exit status of 137
16:24:47,601 INFO [org.jboss.as.process-controller.server] (reaper for Host Controller) JBAS012020: Waiting 1 seconds until trying to restart process Host Controller.
16:24:47,624 INFO [org.jboss.as.process.Server:server-one.status] (reaper for Server:server-one) JBAS012010: Process 'Server:server-one' finished with an exit status of 137
16:24:48,602 INFO [org.jboss.as.process.Host Controller.status] (reaper for Host Controller) JBAS012017: Starting process 'Host Controller'
16:24:57,088 ERROR [org.jboss.as.process.Server:server-one.status] (ProcessController-threads - 4) JBAS012007: Failed to send reconnect message to process 'Server:server-one' input stream: java.io.IOException: Broken pipe
at java.io.FileOutputStream.writeBytes(Native Method) [rt.jar:1.6.0_24]
at java.io.FileOutputStream.write(FileOutputStream.java:297) [rt.jar:1.6.0_24]
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) [rt.jar:1.6.0_24]
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) [rt.jar:1.6.0_24]
at org.jboss.as.process.ManagedProcess.reconnect(ManagedProcess.java:170) [jboss-as-process-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.process.ProcessController.sendReconnectProcess(ProcessController.java:336) [jboss-as-process-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.process.ProcessControllerServerHandler$InitMessageHandler$ConnectedMessageHandler.handleMessage(ProcessControllerServerHandler.java:224) [jboss-as-process-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.process.protocol.ConnectionImpl.safeHandleMessage(ConnectionImpl.java:269) [jboss-as-process-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.process.protocol.ConnectionImpl$1$1.run(ConnectionImpl.java:223) [jboss-as-process-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.6.0_24]
at java.lang.Thread.run(Thread.java:679) [rt.jar:1.6.0_24]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA.jar:2.0.0.GA]
{noformat}
After the above happens, server instance proccess cannot start. When I try to invoke stop and start operation by cli (For instance, /host=slave/server-config=server-one:stop and /host=slave/server-config=server-one:start), the following ERROR is thrown in host-controller.log:
{noformat:title=host-controller.log|borderStyle=solid}
16:26:02,501 INFO [org.jboss.as.host.controller] (domain-connection-threads - 1) JBAS010923: Stopping server server-one
16:26:11,211 ERROR [org.jboss.as.controller.management-operation] (domain-connection-threads - 1) JBAS014612: Operation ("start") failed - address: ([
("host" => "slave"),
("server-config" => "server-one")
]): java.lang.IllegalStateException
at org.jboss.as.host.controller.ManagedServer.start(ManagedServer.java:192) [jboss-as-host-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.host.controller.ServerInventoryImpl.startServer(ServerInventoryImpl.java:166) [jboss-as-host-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.host.controller.DomainModelControllerService$DelegatingServerInventory.startServer(DomainModelControllerService.java:557) [jboss-as-host-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.host.controller.operations.ServerStartHandler$1.execute(ServerStartHandler.java:80) [jboss-as-host-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397) [jboss-as-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284) [jboss-as-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211) [jboss-as-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.domain.controller.operations.coordination.OperationCoordinatorStepHandler.executeDirect(OperationCoordinatorStepHandler.java:161) [jboss-as-host-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.domain.controller.operations.coordination.OperationCoordinatorStepHandler.execute(OperationCoordinatorStepHandler.java:112) [jboss-as-host-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.domain.controller.operations.coordination.PrepareStepHandler.execute(PrepareStepHandler.java:85) [jboss-as-host-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:397) [jboss-as-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:284) [jboss-as-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:211) [jboss-as-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:126) [jboss-as-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:111) [jboss-as-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:112) [jboss-as-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.execute(TransactionalProtocolOperationHandler.java:95) [jboss-as-controller-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:286) [jboss-as-protocol-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:491) [jboss-as-protocol-7.1.3.Final-SNAPSHOT.jar:7.1.3.Final-SNAPSHOT]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.6.0_24]
at java.lang.Thread.run(Thread.java:679) [rt.jar:1.6.0_24]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA.jar:2.0.0.GA]
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] (AS7-5662) Cannot start a managed server anymore if it's failed and the host controller is reloaded/restarted
by Simone Gotti (JIRA)
Simone Gotti created AS7-5662:
---------------------------------
Summary: Cannot start a managed server anymore if it's failed and the host controller is reloaded/restarted
Key: AS7-5662
URL: https://issues.jboss.org/browse/AS7-5662
Project: Application Server 7
Issue Type: Feature Request
Components: Domain Management
Affects Versions: 7.1.3.Final (EAP), 7.2.0.Alpha1
Reporter: Simone Gotti
Assignee: Brian Stansberry
This issue should incorporate the one reported in AS7-4981.
I opened a new one just to describe the problem and various possible fixes.
I can reproduce it with also with the latest 7.1 and master branches.
Before creating a pull request I'll like to know what you think about the possibile patches provided below.
The problem can happen also if a server is failed and you restart/reload the host controller after some time (not only when you kill the managed server and the host controller together). The unique fix is to restart the process controller and so all the managed servers...
The problem is that, when the host controller reloads/restarts it receives the registered processes from the process controller and a Failed process is marked as not running (the value of isRunning was also broken before the fix in AS7-5610).
In the host controller a new ManagedServer is created with internalState and requiredState defined as STOPPED.
So:
*) When you ask for a start of the managed server it will start trying to register the managed server with the process controller but as it's already registered the process controller will return a warning (JBAS012004: Attempted to register duplicate named process %s) and no callback to the host controller will happen living the managed server in a PROCESS_ADDING state.
*) When you ask for a stop of the managed server you'll get that you cannot stop and already stopped server.
I tried to fix this with this patch:
(7.1) https://github.com/motaboy/jboss-as/commit/306db0fbfcb74a6c6781f7918877e1...
(master) https://github.com/motaboy/jboss-as/commit/2a96fd496c8745507b38b3d69e49f3...
With this patch if the process state returned by the process controller is not running then the host controller will deregister the managed server from the process controller.
Another case is when you ask a process to stop and while it's stopping you'll reload/restart/kill the host controller. With the above patch the managed server will be deregistred from the process controller, then when the processFinished notification is received an error (JBAS010913: No server called %s available) as it was already removed from the ServerInventory on the host controller. Apart from the error this is not a problem as you can start the server without any problem.
I made another patch to handle also this situation. To handle it the host controller needs to know if the process is really down, or it's up but stopping. So I added also this information to the one returned by the process controller (in the meantime I also changed isRunning to return true also if the process is up but stopping)
(7.1) https://github.com/motaboy/jboss-as/commit/be3260b1b1ff4fb5ffc545f395f216...
(master) https://github.com/motaboy/jboss-as/commit/b17692716c9c32ee40d78424dcb542...
I also modified the RespawnTestCase to test also the first case (managed server failed and host controller is reloaded) (this test was disabled by AS7-5242):
(7.1) https://github.com/motaboy/jboss-as/commit/b321db77db298871a39c0a445c73db...
(master) https://github.com/motaboy/jboss-as/commit/c88c595ee657b45cbfebe8eac4b5ab...
Thanks!
--
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
13 years, 9 months
[JBoss JIRA] (AS7-5763) timeout handling waiting for future
by Alexey Loubyansky (JIRA)
Alexey Loubyansky created AS7-5763:
--------------------------------------
Summary: timeout handling waiting for future
Key: AS7-5763
URL: https://issues.jboss.org/browse/AS7-5763
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Reporter: Alexey Loubyansky
Assignee: Brian Stansberry
The issue was reported in AS7-5350 which points to a CLI testcase that fails on windows.
The test starts a CLI process and deliberately specifies a wrong port for the controller expecting a failure during connection. The CLI sends a read-attribute operation request on connect to make sure the connection is working. The test is waiting for a response from the controller for 10 sec and then times out. The time out of the ModelControllerClient is 5 sec. The test still fails after 10 sec time out but the error output stream of the CLI process does contain the stack trace of the expected exception, i.e. that the controller was not available at the specified address.
When the testcase times out, it destroys the CLI process, perhaps, this triggers some actions and the exception is finally thrown and the stack trace gets logged but it's too late.
--
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
13 years, 9 months
[JBoss JIRA] (AS7-5769) " Remote connection failed: javax.security.sa sl.SaslException: Authentication failed: all available authentication mechanisms" failed appears randomally
by Alexey S. (JIRA)
Alexey S. created AS7-5769:
------------------------------
Summary: " Remote connection failed: javax.security.sa sl.SaslException: Authentication failed: all available authentication mechanisms" failed appears randomally
Key: AS7-5769
URL: https://issues.jboss.org/browse/AS7-5769
Project: Application Server 7
Issue Type: Bug
Components: EJB
Affects Versions: 7.1.1.Final
Environment: windows
Reporter: Alexey S.
Assignee: jaikiran pai
Priority: Critical
Hello everybody and JBoss guys.
Very simple and critical issue.
Our system runs Grails app which is an EJB Client.
Randomally it gots
[Remoting "config-based-ejb-client-endpoint" read-1] ERR
OR remote.connection - JBREM000200: Remote connection failed: javax.security.sa
sl.SaslException: Authentication failed: all available authentication mechanisms
failed
java.lang.IllegalStateException: No EJB receiver available for handling blablabla.
Just to make myself clear- same code, same place, same connection, everything is reproducable when client and server are on the same PC: sometimes EJB invocation works and sometimes raises this "
[Remoting "config-based-ejb-client-endpoint" read-1] ERR
OR remote.connection - JBREM000200: Remote connection failed: javax.security.sa
sl.SaslException: Authentication failed: all available authentication mechanisms
failed
java.lang.IllegalStateException: No EJB receiver available for handling blablabla.
Seems this is a showstopper issue, what do you think about?
--
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
13 years, 9 months
[JBoss JIRA] (AS7-5767) Empty messaging subsystem can not be persisted
by Jeff Mesnil (JIRA)
Jeff Mesnil created AS7-5767:
--------------------------------
Summary: Empty messaging subsystem can not be persisted
Key: AS7-5767
URL: https://issues.jboss.org/browse/AS7-5767
Project: Application Server 7
Issue Type: Feature Request
Affects Versions: 7.1.3.Final (EAP)
Reporter: Jeff Mesnil
Fix For: 7.1.4.Final (EAP)
When the messaging subsystem is persisted, it requires to have defined hornetq-server nodes but that's not correct.
E.g. when the messaging subsystem is added through the CLI, it should be marshalled even though there is no hornetq-server
The XSD for the messaging subsystem is correct: minOccurs for hornetq-server element is 0.
--
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
13 years, 9 months