[JBoss JIRA] (WFLY-7835) StatefulSessionSynchronizationInterceptor can`t see that current tx replaced by arjuna`s tx reaper and can`t aquire it`s own component lock
by Tom Jenkinson (Jira)
[ https://issues.jboss.org/browse/WFLY-7835?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson reassigned WFLY-7835:
-----------------------------------
Assignee: Tom Jenkinson (was: Amos Feng)
> StatefulSessionSynchronizationInterceptor can`t see that current tx replaced by arjuna`s tx reaper and can`t aquire it`s own component lock
> --------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7835
> URL: https://issues.jboss.org/browse/WFLY-7835
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Affects Versions: 10.0.0.Final
> Environment: wildfly 10.0.0.Final
> java 8u101
> narayana-jts-integration-5.2.12.Final
> SFSB with CMT
> Reporter: kostd kostd
> Assignee: Tom Jenkinson
> Priority: Minor
> Attachments: log-fragment-7835
>
>
> full log will be attached, now short chronology:
> 1. ~02:20 default task-186 starts request processing. During request where was call to ExtendedPersistenceContainer (SFSB with CMT).
> So StatefulSessionSynchronizationInterceptor#processInvocation called and component lock aquired (owner = current tx, see StatefulSessionSynchronizationInterceptor#getLockOwner). This event not catched in logfile, because regular behavour not logged.
> 2. 02:39:26: tx timeout reached (20min), so arjuna`s reaper thread trying cancel tx. Now current tx == null ( ?):
> {quote}
> 02:39:26,882 WARN [arjuna] (Transaction Reaper Worker 73) ARJUNA012381: Action id 0:ffff0aa010c9:22fba49e:5848e8ad:446f10c completed with multiple threads - thread default task-186 was in progress with java.net.SocketInputStream.socketRead0(Native Method)
> {quote}
> 3. 02:39:32: query timeout in task thread reached:
> {quote}
> 02:39:32,806 ERROR [sql] (default task-186) SQL query error: 2c344b99 (executed in 1 205 917 ms): java.sql.SQLTimeoutException: ORA-01013: пользователем запрошена отмена текущей операции
> {quote}
> this event seems not interest.
> 4. 02:39:32: arjuna`s reaper thread trying to release component lock but fails because does not own`em:
> {quote}
> 02:39:32,808 WARN [txn] (Transaction Reaper Worker 73) WFLYTX0027: The pre-jca synchronization org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor$StatefulSessionSynchronization@58e72087 associated with tx TransactionImple < ac, BasicAction: 0:ffff0aa010c9:22fba49e:5848e8ad:446f10c status: ActionStatus.ABORTED > failed during after completion: java.lang.IllegalMonitorStateException
> {quote}
> 5. 02:39: task-thread contiunes request processing: hibernate noticed that current tx replaced(removed) by arjuna`s reaper:
> {quote}
> {code}
> 02:39:32,822 WARN [lifecycle] (default task-186) #{viewModel.save}: javax.persistence.PersistenceException: org.hibernate.HibernateException: Transaction was rolled back in a different thread!: javax.faces.FacesException: #{viewModel.save}: javax.persistence.PersistenceException: org.hibernate.HibernateException: Transaction was rolled back in a different thread!
> {code}
> {quote}
> 6. but StatefulSessionSynchronizationInterceptor not noticed. StatefulSessionSynchronizationInterceptor trying to aquire same lock, but owner changed, was current tx and now current thread (?):
> {quote}
> 02:39:37,827 ERROR [invocation] (default task-186) WFLYEJB0034: EJB Invocation failed on component ExtendedPersistenceContainer for method public javax.persistence.EntityManager ru.argustelecom.system.inf.transaction.ExtendedPersistenceContainer.getEntityManager(): javax.ejb.ConcurrentAccessTimeoutException: WFLYEJB0228: EJB 3.1 FR 4.3.14.1 concurrent access timeout on ExtendedPersistenceContainer - could not obtain lock within 5000 MILLISECONDS
> {quote}
> So, next two clauses is bug-behavour or by-desighn behavour:
> c1. arjuna`s reaper thread trying release component lock through StatefulSessionSynchronizationInterceptor, but does not owns this lock.
> c2. StatefulSessionSynchronizationInterceptor can`t see that current tx replaced and trying to aquire it`s own component lock with different owners. In second try lock cannot be aquired during any timeout
> ?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (DROOLS-3470) [GDT] Limited Entry Table, checkboxes are not rendered when enter is pressed
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3470?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-3470:
--------------------------------
Description:
Two attachments show the problem. One picture shows all checkboxes of limited entry decision table are shown correctly. The second picture shows checkboxes are not visible when description is in edit mode. See steps to reproduce.
This issue occurs just for limited entry decision table. Extended entry decision table works fine. Next this problem occurs just if the description column edit mode is started by pressing enter. Double click by mouse doesn't cause this issue.
h2. Acceptance criteria
There exists [selenium test|https://github.com/jboss-integration/bxms-qe-tests/blob/master/test-...] for limited entry tables, however due to this DROOLS-3470 issue it has to be ignored, see [PR|https://github.com/jboss-integration/bxms-qe-tests/pull/2150].
was:
Two attachments show the problem. One picture shows all checkboxes of limited entry decision table are shown correctly. The second picture shows checkboxes are not visible when description is in edit mode. See steps to reproduce.
This issue occurs just for limited entry decision table. Extended entry decision table works fine. Next this problem occurs just if the description column edit mode is started by pressing enter. Double click by mouse doesn't cause this issue.
> [GDT] Limited Entry Table, checkboxes are not rendered when enter is pressed
> ----------------------------------------------------------------------------
>
> Key: DROOLS-3470
> URL: https://issues.jboss.org/browse/DROOLS-3470
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor
> Affects Versions: 7.16.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Minor
> Labels: drools-tools, regression
> Attachments: Screenshot from 2019-01-04 08-55-58.png, Screenshot from 2019-01-04 08-56-05.png
>
>
> Two attachments show the problem. One picture shows all checkboxes of limited entry decision table are shown correctly. The second picture shows checkboxes are not visible when description is in edit mode. See steps to reproduce.
> This issue occurs just for limited entry decision table. Extended entry decision table works fine. Next this problem occurs just if the description column edit mode is started by pressing enter. Double click by mouse doesn't cause this issue.
> h2. Acceptance criteria
> There exists [selenium test|https://github.com/jboss-integration/bxms-qe-tests/blob/master/test-...] for limited entry tables, however due to this DROOLS-3470 issue it has to be ignored, see [PR|https://github.com/jboss-integration/bxms-qe-tests/pull/2150].
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (DROOLS-3470) [GDT] Limited Entry Table, checkboxes are not rendered when enter is pressed
by Jozef Marko (Jira)
Jozef Marko created DROOLS-3470:
-----------------------------------
Summary: [GDT] Limited Entry Table, checkboxes are not rendered when enter is pressed
Key: DROOLS-3470
URL: https://issues.jboss.org/browse/DROOLS-3470
Project: Drools
Issue Type: Bug
Components: Guided Decision Table Editor
Affects Versions: 7.16.0.Final
Reporter: Jozef Marko
Assignee: Michael Anstis
Attachments: Screenshot from 2019-01-04 08-55-58.png, Screenshot from 2019-01-04 08-56-05.png
Two attachments show the problem. One picture shows all checkboxes of limited entry decision table are shown correctly. The second picture shows checkboxes are not visible when description is in edit mode. See steps to reproduce.
This issue occurs just for limited entry decision table. Extended entry decision table works fine. Next this problem occurs just if the description column edit mode is started by pressing enter. Double click by mouse doesn't cause this issue.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (WFLY-11082) ClassCastExceptions and unexpected ServletContainerInitializer executions
by Bartosz Baranowski (Jira)
[ https://issues.jboss.org/browse/WFLY-11082?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski commented on WFLY-11082:
-------------------------------------------
[ERROR] org.jboss.as.test.integration.deployment.dependencies.ServletContainerInitializerClassLoadersIT Time elapsed: 61.394 s <<< ERROR!
org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container
at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:168)
at org.jboss.as.arquillian.container.CommonDeployableContainer.start(CommonDeployableContainer.java:123)
at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:85)
at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:92)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:143)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:85)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:143)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:85)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:92)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:143)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:75)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:116)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
Caused by: java.util.concurrent.TimeoutException: Managed server was not started within [60] s
at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:161)
... 64 more
> ClassCastExceptions and unexpected ServletContainerInitializer executions
> -------------------------------------------------------------------------
>
> Key: WFLY-11082
> URL: https://issues.jboss.org/browse/WFLY-11082
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 14.0.1.Final
> Reporter: Alexander Kudrevatykh
> Assignee: Bartosz Baranowski
> Priority: Major
> Attachments: dependencies.zip
>
>
> I got unexpected ClassCastExceptions in setup as in attached test
> ServiceLoader provide only one instance of SCI, but wildlfy executes it twice
> More weird - wrong Set of classes passed to onStartup method - classes are not extends @HandlesTypes annotation (because they loaded with different classloaders)
> sorry for complex description, look for attached test
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (WFLY-11082) ClassCastExceptions and unexpected ServletContainerInitializer executions
by Bartosz Baranowski (Jira)
[ https://issues.jboss.org/browse/WFLY-11082?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski reassigned WFLY-11082:
-----------------------------------------
Assignee: Bartosz Baranowski (was: Jason Greene)
> ClassCastExceptions and unexpected ServletContainerInitializer executions
> -------------------------------------------------------------------------
>
> Key: WFLY-11082
> URL: https://issues.jboss.org/browse/WFLY-11082
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 14.0.1.Final
> Reporter: Alexander Kudrevatykh
> Assignee: Bartosz Baranowski
> Priority: Major
> Attachments: dependencies.zip
>
>
> I got unexpected ClassCastExceptions in setup as in attached test
> ServiceLoader provide only one instance of SCI, but wildlfy executes it twice
> More weird - wrong Set of classes passed to onStartup method - classes are not extends @HandlesTypes annotation (because they loaded with different classloaders)
> sorry for complex description, look for attached test
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (JGRP-2288) S3_PING: Under certain conditions, subclusters fail to merge after network partition
by Nick Sawadsky (Jira)
[ https://issues.jboss.org/browse/JGRP-2288?page=com.atlassian.jira.plugin.... ]
Nick Sawadsky commented on JGRP-2288:
-------------------------------------
[~belaban] Thanks!
> S3_PING: Under certain conditions, subclusters fail to merge after network partition
> ------------------------------------------------------------------------------------
>
> Key: JGRP-2288
> URL: https://issues.jboss.org/browse/JGRP-2288
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.15
> Reporter: Nick Sawadsky
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.16, 3.6.17
>
>
> Repro steps:
> 1. Set up a cluster of four nodes, two on one machine (Host 1) and two on another (Host 2). Let's call the nodes A, B, C, and D.
> 2. Configure all 4 nodes with S3_PING as the discovery mechanism. Set remove_all_files_on_view_change to true.
> 3. Start up nodes in the order A, B, C, D.
> 4. In the S3 bucket, there should be a single file with all four nodes listed. Node A should be flagged as the coordinator. Ensure that the UUID for node B is larger than the UUID for node C, when compared as two's complement integers. If this is not the case, shut down all nodes and restart in order. Repeat until the desired relationship is achieved. Note that with two's complement, a UUID having a first hex digit of 8 or higher is treated as negative for comparison purposes. So, for example, a UUID starting with 'a' is less than a UUID starting with 'b' which is less than a UUID starting with '1'.
> 5. On Host 1, use iptables to block all traffic going to and coming from Host 2.
> sudo iptables -A INPUT -s <Host 2 IP addr> -j DROP
> sudo iptables -A OUTPUT -d <Host 2 IP addr> -j DROP
> 6. Allow a few minutes for the nodes to detect the network partition. Eventually you should see two files in the S3 bucket.
> 7. Using Ctrl-C, stop node A.
> 8. You should soon find only a single file in the bucket, containing a single entry for node B. This is a result of the remove_all_files_on_view_change setting on S3_PING, which we set to true to avoid accumulation of old files in the bucket.
> 9. Resolve the network partition:
> sudo iptables -F OUTPUT
> sudo iptables -F INPUT
> 10. You will find that, even after many minutes, the subclusters are not merged.
> I believe the reason why the subclusters are never merged is as follows:
> - MERGE3 on nodes B, C and D uses S3_PING to find members to send INFO messages to. Each one finds only node B in the discovery file. As a result, only node B's view consistency checker has anything to work with.
> - On node B, the consistency checker can see that there are two coordinators, B and C. However, node C has a lower UUID, so node B defers to it to perform the merge. Node C never performs the merge because, as mentioned above, it is not receiving any INFO messages.
> I this this problem would affect FILE_PING as well, and other protocols derived from FILE_PING. Looking at the latest 4.x code, it appears the problem still exists there.
> I think the crux of the issue is that the coordinator on Host 2 (node C) does not re-create its discovery file after it is deleted by node B. Would it be reasonable for FILE_PING.findMembers() to create the discovery file if the node is a coordinator and the file doesn't exist?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (REMJMX-158) Unauthorized access exception when closing JMX console and RBAC is set on server
by Richard Opalka (Jira)
[ https://issues.jboss.org/browse/REMJMX-158?page=com.atlassian.jira.plugin... ]
Richard Opalka updated REMJMX-158:
----------------------------------
Git Pull Request: https://github.com/jbossas/remoting-jmx/pull/35
> Unauthorized access exception when closing JMX console and RBAC is set on server
> --------------------------------------------------------------------------------
>
> Key: REMJMX-158
> URL: https://issues.jboss.org/browse/REMJMX-158
> Project: Remoting JMX
> Issue Type: Bug
> Components: Connection
> Reporter: Richard Opalka
> Assignee: Richard Opalka
> Priority: Major
> Fix For: 3.1.0.Beta1
>
>
> javax.management.JMRuntimeException: WFLYJMX0037: Unauthorized access
> at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1204)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.authorizeMBeanOperation(PluggableMBeanServerImpl.java:1190)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.removeNotificationListener(PluggableMBeanServerImpl.java:946)
> at org.jboss.as.jmx.BlockingNotificationMBeanServer.removeNotificationListener(BlockingNotificationMBeanServer.java:243)
> at org.jboss.as.jmx.AuthorizingMBeanServer.removeNotificationListener(AuthorizingMBeanServer.java:352)
> at org.jboss.remotingjmx.protocol.v2.ServerProxy$RemoteNotificationManager.removeNotificationListener(ServerProxy.java:229)
> at org.jboss.remotingjmx.protocol.v2.ServerProxy$RemoteNotificationManager.removeNotificationListeners(ServerProxy.java:239)
> at org.jboss.remotingjmx.protocol.v2.ServerProxy$RemoteNotificationManager.removeNotificationListener(ServerProxy.java:222)
> at org.jboss.remotingjmx.protocol.v2.ServerProxy$RemoteNotificationManager.access$1900(ServerProxy.java:199)
> at org.jboss.remotingjmx.protocol.v2.ServerProxy.end(ServerProxy.java:167)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever.handleEnd(ServerCommon.java:216)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$notifyEnd$0(RemoteConnectionChannel.java:291)
> at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:957)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months