[JBoss JIRA] (DROOLS-1324) CNFE when stopping server with enabled scanner
by Karel Suta (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1324?page=com.atlassian.jira.plugi... ]
Karel Suta reassigned DROOLS-1324:
----------------------------------
Assignee: Maciej Swiderski (was: Edson Tirelli)
> CNFE when stopping server with enabled scanner
> ----------------------------------------------
>
> Key: DROOLS-1324
> URL: https://issues.jboss.org/browse/DROOLS-1324
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.5.0.CR2, 7.0.0.Beta2
> Environment: Kie server 6.5.0-SNAPSHOT
> Reporter: Karel Suta
> Assignee: Maciej Swiderski
> Priority: Minor
> Labels: reported-by-qe
> Attachments: stacktrace-server.txt
>
>
> When I stop application server with Kie server containing container with started scanner, sometimes I get ClassNotFoundException, see attachment.
> This exception doesn't seem to have any affect on functionality, but still it should be resolved as it may hide some other problem.
> This exception occurs randomly, you may need to start/stop server several times to see it.
> Interesting is that class, which wasn't found by classloader, is actually present in Kie server in artefact sisu-guice-3.2.3-no_aop.jar.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (DROOLS-1324) CNFE when stopping server with enabled scanner
by Karel Suta (JIRA)
Karel Suta created DROOLS-1324:
----------------------------------
Summary: CNFE when stopping server with enabled scanner
Key: DROOLS-1324
URL: https://issues.jboss.org/browse/DROOLS-1324
Project: Drools
Issue Type: Bug
Components: kie server
Affects Versions: 7.0.0.Beta2, 6.5.0.CR2
Environment: Kie server 6.5.0-SNAPSHOT
Reporter: Karel Suta
Assignee: Edson Tirelli
Priority: Minor
Attachments: stacktrace-server.txt
When I stop application server with Kie server containing container with started scanner, sometimes I get ClassNotFoundException, see attachment.
This exception doesn't seem to have any affect on functionality, but still it should be resolved as it may hide some other problem.
This exception occurs randomly, you may need to start/stop server several times to see it.
Interesting is that class, which wasn't found by classloader, is actually present in Kie server in artefact sisu-guice-3.2.3-no_aop.jar.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (DROOLS-1199) Memory leak in KieScanner
by Joni Niemi (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1199?page=com.atlassian.jira.plugi... ]
Joni Niemi commented on DROOLS-1199:
------------------------------------
This bug makes version 6.4.0.Final unusable in a production environment. Your options are either to downgrade or fork and make your own build.
> Memory leak in KieScanner
> -------------------------
>
> Key: DROOLS-1199
> URL: https://issues.jboss.org/browse/DROOLS-1199
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.Final
> Reporter: Viacheslav Krot
> Assignee: Mario Fusco
> Fix For: 7.0.0.Beta1
>
>
> I'm not sure, but it seems there is a memory leak in KieScanner, not in scanner directly, but somewhere in plexus used internally.
> If you start KieScanner with version = LATEST, start it with interval say 1 second and sample memory with visualvm (or any other), you can watch number of instances org.eclipse.sisu.plexus.* growing over time. And they cannot be garbage collected - memory root is timer thread. This happens in drools 6.4.0, in 6.3.0 this issue was absent.
> Eventually application fails with OOM.
> As a workaround we call KieScanner#scan manually in a separate thread pool that is recreated from time to time.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-7283) Update EJB to use txn spi
by Flavia Rainone (JIRA)
Flavia Rainone created WFLY-7283:
------------------------------------
Summary: Update EJB to use txn spi
Key: WFLY-7283
URL: https://issues.jboss.org/browse/WFLY-7283
Project: WildFly
Issue Type: Enhancement
Components: EJB
Affects Versions: 10.1.0.Final
Reporter: Flavia Rainone
Priority: Minor
Fix For: 10.2.0.Final, 11.0.0.Alpha1
Remote references from EJB to internal transaction classes, replacing then by references to the spi.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-7282) Deadlock in BasicAction when jboss remoting and JTA is used
by Flavia Rainone (JIRA)
[ https://issues.jboss.org/browse/WFLY-7282?page=com.atlassian.jira.plugin.... ]
Flavia Rainone updated WFLY-7282:
---------------------------------
Description:
At EJBRemoteTransactionPropagatingInterceptor, a transaction that has been already open at current server could be ignored, thus causing the transaction to be reimported, resulting in the double diamond problem and a deadlock.
Issue created based on discussion at jboss-support-transactions list: http://post-office.corp.redhat.com/archives/jboss-support-transactions/20...
Current jboss remoting implementation on JTA does not provide correct handling of double diamond transaction propagation problem.
If transaction is propagated from one server to other one and then back to the first one then such situation can cause deadlock. Remote calls and transactions are processed but when servers using the same remote resource the prepare phase of 2PC can stuck. Transaction is timed-out later and recovery process rolls it back.
IIOP/JTS does not suffer with this flaw.
was:
At EJBRemoteTransactionPropagatingInterceptor, a transaction that has been already open at current server could be ignored, thus causing the transaction to be reimported, resulting in the double diamond problem.
Summary: Deadlock in BasicAction when jboss remoting and JTA is used (was: Double diamond in EJB Transaction)
> Deadlock in BasicAction when jboss remoting and JTA is used
> -----------------------------------------------------------
>
> Key: WFLY-7282
> URL: https://issues.jboss.org/browse/WFLY-7282
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Reporter: Flavia Rainone
> Assignee: Flavia Rainone
> Fix For: 10.2.0.Final, 11.0.0.Alpha1
>
>
> At EJBRemoteTransactionPropagatingInterceptor, a transaction that has been already open at current server could be ignored, thus causing the transaction to be reimported, resulting in the double diamond problem and a deadlock.
> Issue created based on discussion at jboss-support-transactions list: http://post-office.corp.redhat.com/archives/jboss-support-transactions/20...
> Current jboss remoting implementation on JTA does not provide correct handling of double diamond transaction propagation problem.
> If transaction is propagated from one server to other one and then back to the first one then such situation can cause deadlock. Remote calls and transactions are processed but when servers using the same remote resource the prepare phase of 2PC can stuck. Transaction is timed-out later and recovery process rolls it back.
> IIOP/JTS does not suffer with this flaw.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-7282) Double diamond in EJB Transaction
by Flavia Rainone (JIRA)
[ https://issues.jboss.org/browse/WFLY-7282?page=com.atlassian.jira.plugin.... ]
Flavia Rainone updated WFLY-7282:
---------------------------------
Description:
At EJBRemoteTransactionPropagatingInterceptor, a transaction that has been already open at current server could be ignored, thus causing the transaction to be reimported, resulting in the double diamond problem.
was:At EJBRemoteTransactionPropagatingInterceptor, a transaction that has been already open at current server could be ignored, thus causing the transaction to be reimported, resulting in the double diamond problem.
Steps to Reproduce:
You need a reinvocation at a server that was already participating in the transaction, as the scenario below for example:
server1 -> server2 -> server1
> Double diamond in EJB Transaction
> ---------------------------------
>
> Key: WFLY-7282
> URL: https://issues.jboss.org/browse/WFLY-7282
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Reporter: Flavia Rainone
> Assignee: Flavia Rainone
> Fix For: 10.2.0.Final, 11.0.0.Alpha1
>
>
> At EJBRemoteTransactionPropagatingInterceptor, a transaction that has been already open at current server could be ignored, thus causing the transaction to be reimported, resulting in the double diamond problem.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-7282) Double diamond in EJB Transaction
by Flavia Rainone (JIRA)
Flavia Rainone created WFLY-7282:
------------------------------------
Summary: Double diamond in EJB Transaction
Key: WFLY-7282
URL: https://issues.jboss.org/browse/WFLY-7282
Project: WildFly
Issue Type: Bug
Components: EJB
Affects Versions: 10.1.0.Final
Reporter: Flavia Rainone
Assignee: Flavia Rainone
Fix For: 10.2.0.Final, 11.0.0.Alpha1
At EJBRemoteTransactionPropagatingInterceptor, a transaction that has been already open at current server could be ignored, thus causing the transaction to be reimported, resulting in the double diamond problem.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1791) Strange operation-id handling in domain server reload execution
by Yeray Santana Borges (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1791?page=com.atlassian.jira.plugi... ]
Yeray Santana Borges commented on WFCORE-1791:
----------------------------------------------
It seems the operation-id is sent back to the HC in this method: HostControllerConnection.ServerRegisterRequest.sendRequest. As far as I have been able to check, this is the sequence which enables the operation-id being sent back:
# Reload is executed in a domain mode, so HC sends the current operation-id in the reload operation to the managed server(s)
# On server(s) side, ServerDomainProcessReloadHandler is executed which updates the static instance variable DomainServerCommunicationServices.initialOperationID
# Server(s) is reloaded, the root service for an application server process is ApplicationServerService, its start() method is then invoked which activates two service activators: DomainServerCommunicationServices and an anonymous service activator created in ServerStartTask
# DomainServerCommunicationServices.activate is invoked which creates a new HostControllerConnectionService and installs it, so its HostControllerConnectionService.start method is invoked which creates a new HostControllerConnection instance. This instance is the instance used to send the operation-id back to the HC. In this point the HostControllerConnection has the operation-id updated in point 2) by the reload operation on server side.
# The anonymous service activator in ServerStartTask class is activated too. This class installs the ServerBootOperationsService service. This service in L68 invokes HostControllerClient.resolveBootUpdates which invokes HostControllerConnection.openConnection. The connection is then opened using ServerRegisterRequest which sends the operation-id the HC in ServerRegisterRequest.sendRequest.
# The server is registered then by the HC executing the register operation and without blocking since it has the correct operation-id received before.
> Strange operation-id handling in domain server reload execution
> ---------------------------------------------------------------
>
> Key: WFCORE-1791
> URL: https://issues.jboss.org/browse/WFCORE-1791
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Yeray Santana Borges
> Priority: Minor
>
> When the HC sends a reload op to a managed server it includes an undocumented "operation-id" parameter. But, I don’t see how it is used with a reload. When it was added to the code the intent clearly was that it would be used, but now at least is not. ServerDomainProcessReloadHandler reads it from the op and sets DomainServerCommunicationServices.initialOperationId, but that field is only read when HostControllerConnectionService is instantiated. HostControllerConnectionService then caches the value in a final field. A reload does not result in a new instantiation of HostControllerConnectionService; that object is only instantiated during initial process boot when ServerStartTask is unmarshaled from stdin and run. So changing the DomainServerCommunicationServices.initialOperationId in a reload should do nothing.
> https://github.com/wildfly/wildfly-core/commit/302949cf60823d8aa3989d74df... is the initial commit when this update of the id in reload was added in. The intent was that by providing this id, when the reloading server connects to the HC to get the boot ops, that read of boot ops would be able to "join" any active operation that triggered the reload, and thus would not have to block waiting for that operation to complete.
> Afaict, if the "blocking" param on an op like /host=x/server[-config]=y:reload is set to 'true' the op should deadlock. On the HC, ServerReloadHandler will acquire the exclusive lock by calling context.getServiceRegistry(true). Then ServerInventoryImpl.reloadServer will block waiting for the server to reach STARTED state. But the server won't reach that because it's registration request will not be able to acquire the HC lock.
> Task here is to
> 1) Confirm the above and then
> 2) Either
> a) get the operation-id propagated
> b) or rip the operation-id bit out of reload because investigation showed it was not needed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1791) Strange operation-id handling in domain server reload execution
by Yeray Santana Borges (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1791?page=com.atlassian.jira.plugi... ]
Yeray Santana Borges reassigned WFCORE-1791:
--------------------------------------------
Assignee: Yeray Santana Borges
> Strange operation-id handling in domain server reload execution
> ---------------------------------------------------------------
>
> Key: WFCORE-1791
> URL: https://issues.jboss.org/browse/WFCORE-1791
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Yeray Santana Borges
> Priority: Minor
>
> When the HC sends a reload op to a managed server it includes an undocumented "operation-id" parameter. But, I don’t see how it is used with a reload. When it was added to the code the intent clearly was that it would be used, but now at least is not. ServerDomainProcessReloadHandler reads it from the op and sets DomainServerCommunicationServices.initialOperationId, but that field is only read when HostControllerConnectionService is instantiated. HostControllerConnectionService then caches the value in a final field. A reload does not result in a new instantiation of HostControllerConnectionService; that object is only instantiated during initial process boot when ServerStartTask is unmarshaled from stdin and run. So changing the DomainServerCommunicationServices.initialOperationId in a reload should do nothing.
> https://github.com/wildfly/wildfly-core/commit/302949cf60823d8aa3989d74df... is the initial commit when this update of the id in reload was added in. The intent was that by providing this id, when the reloading server connects to the HC to get the boot ops, that read of boot ops would be able to "join" any active operation that triggered the reload, and thus would not have to block waiting for that operation to complete.
> Afaict, if the "blocking" param on an op like /host=x/server[-config]=y:reload is set to 'true' the op should deadlock. On the HC, ServerReloadHandler will acquire the exclusive lock by calling context.getServiceRegistry(true). Then ServerInventoryImpl.reloadServer will block waiting for the server to reach STARTED state. But the server won't reach that because it's registration request will not be able to acquire the HC lock.
> Task here is to
> 1) Confirm the above and then
> 2) Either
> a) get the operation-id propagated
> b) or rip the operation-id bit out of reload because investigation showed it was not needed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months