[Red Hat JIRA] (SWSQE-1202) UI Automations - Overview Filters Apply
by Hayk Hovsepyan (Jira)
[ https://issues.redhat.com/browse/SWSQE-1202?page=com.atlassian.jira.plugi... ]
Hayk Hovsepyan updated SWSQE-1202:
----------------------------------
Sprint: Kiali Sprint #44, Kiali Sprint #45, Kiali Sprint #46, Kiali Sprint #47, Kiali Sprint #48, Kiali Sprint #49, Kiali Sprint #50, Kiali Sprint #51, Kiali Sprint #52 (was: Kiali Sprint #44, Kiali Sprint #45, Kiali Sprint #46, Kiali Sprint #47, Kiali Sprint #48, Kiali Sprint #49, Kiali Sprint #50, Kiali Sprint #51)
> UI Automations - Overview Filters Apply
> ---------------------------------------
>
> Key: SWSQE-1202
> URL: https://issues.redhat.com/browse/SWSQE-1202
> Project: Kiali QE
> Issue Type: QE Task
> Reporter: Hayk Hovsepyan
> Assignee: Sunil Kondkar
> Priority: Major
> Labels: automation
>
> Overview page contains Filter options.
> We need to automate all filter types apply and result checking.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 5 months
[Red Hat JIRA] (SWSQE-1143) Solve python2 vs. python3 problem on jenkins slaves
by Hayk Hovsepyan (Jira)
[ https://issues.redhat.com/browse/SWSQE-1143?page=com.atlassian.jira.plugi... ]
Hayk Hovsepyan updated SWSQE-1143:
----------------------------------
Sprint: Kiali Sprint #39, Kiali Sprint #40, Kiali Sprint #41, Kiali Sprint #42, Kiali Sprint #43, Kiali Sprint #44, Kiali Sprint #45, Kiali Sprint #46, Kiali Sprint #47, Kiali Sprint #48, Kiali Sprint #49, Kiali Sprint #50, Kiali Sprint #51, Kiali Sprint #52 (was: Kiali Sprint #39, Kiali Sprint #40, Kiali Sprint #41, Kiali Sprint #42, Kiali Sprint #43, Kiali Sprint #44, Kiali Sprint #45, Kiali Sprint #46, Kiali Sprint #47, Kiali Sprint #48, Kiali Sprint #49, Kiali Sprint #50, Kiali Sprint #51)
> Solve python2 vs. python3 problem on jenkins slaves
> ---------------------------------------------------
>
> Key: SWSQE-1143
> URL: https://issues.redhat.com/browse/SWSQE-1143
> Project: Kiali QE
> Issue Type: QE Task
> Reporter: Filip Brychta
> Assignee: Filip Brychta
> Priority: Major
> Labels: infrastructure
>
> Usage of python2 as a default python version on our jenkins slaves causes lot of troubles. It would be good to use python3 everywhere.
> e.g. lot of problem2 with openstack client on python2:
> /usr/lib/python2.7/site-packages/pkg_resources/py2_warn.py:21: UserWarning: Setuptools will stop working on Python 2
> ************************************************************
> You are running Setuptools on Python 2, which is no longer
> supported and
> >>> SETUPTOOLS WILL STOP WORKING <<<
> in a subsequent release (no sooner than 2020-04-20).
> Please ensure you are installing
> Setuptools using pip 9.x or later or pin to `setuptools<45`
> in your environment.
> If you have done those things and are still encountering
> this message, please follow up at
> https://bit.ly/setuptools-py2-warning.
> ************************************************************
> sys.version_info < (3,) and warnings.warn(pre + "*" * 60 + msg + "*" * 60)
> Traceback (most recent call last):
> File "/usr/bin/openstack", line 5, in <module>
> from openstackclient.shell import main
> File "/usr/lib/python2.7/site-packages/openstackclient/shell.py", line 24, in <module>
> from osc_lib import shell
> File "/usr/lib/python2.7/site-packages/osc_lib/shell.py", line 33, in <module>
> from osc_lib.cli import client_config as cloud_config
> File "/usr/lib/python2.7/site-packages/osc_lib/cli/client_config.py", line 18, in <module>
> from openstack.config import exceptions as sdk_exceptions
> File "/usr/lib/python2.7/site-packages/openstack/__init__.py", line 16, in <module>
> import openstack.config
> File "/usr/lib/python2.7/site-packages/openstack/config/__init__.py", line 17, in <module>
> from openstack.config.loader import OpenStackConfig # noqa
> File "/usr/lib/python2.7/site-packages/openstack/config/loader.py", line 33, in <module>
> from openstack.config import cloud_region
> File "/usr/lib/python2.7/site-packages/openstack/config/cloud_region.py", line 44, in <module>
> from openstack import proxy
> File "/usr/lib/python2.7/site-packages/openstack/proxy.py", line 24, in <module>
> from openstack import resource
> File "/usr/lib/python2.7/site-packages/openstack/resource.py", line 49, in <module>
> from openstack import utils
> File "/usr/lib/python2.7/site-packages/openstack/utils.py", line 13, in <module>
> import queue
> ImportError: No module named queue
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 5 months
[Red Hat JIRA] (WFLY-14284) WildFly doesn't stop while waiting for PeriodicRecovery
by Adriano Teixeira de Souza (Jira)
[ https://issues.redhat.com/browse/WFLY-14284?page=com.atlassian.jira.plugi... ]
Adriano Teixeira de Souza commented on WFLY-14284:
--------------------------------------------------
Hi [~ochaloup]
I have some questions to take some decisions about our production environment:
1 - According to what you say, probably this kind of errors won't occur anymore. Can I think in this way?
2 - Will it be safe to delete data / ejb-txn-recovery and data / tx-object-store if this problems occurs again?
3 - Is it safe to put a load balance like haproxy between wildfly remote outbound communication and the target server?
4 - On our tests we notice wildfly 18.0.1 has shown a fewer errors cases than wildfly 20.0.1. I wonder if could be just randomly situation or the version 18.0.1 is more stable than 20.0.1? We ar in doubt on wich to use definitely on our production environment. Could you give us some advice about it?
> WildFly doesn't stop while waiting for PeriodicRecovery
> -------------------------------------------------------
>
> Key: WFLY-14284
> URL: https://issues.redhat.com/browse/WFLY-14284
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Affects Versions: 18.0.1.Final, 20.0.1.Final
> Reporter: Adriano Teixeira de Souza
> Assignee: Michael Musgrove
> Priority: Major
> Attachments: ejb-configs.sh, jboss-ejb-client.xml, server(transaction).log, thread-dump-stop-1.txt
>
>
> I'm testing wildfly 20.0.1 (and 21.0.2 was tested too) for replace our old version of Wildfly 10.
> it happens that frequently we have seen that the stop function of server does not work and we need to kill the process by manual operation on the OS.
> It sounds like a dead look.
> I attatch the thread dump on this.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 5 months
[Red Hat JIRA] (WFLY-14004) AdvancedLdapLoginModuleTestCase fails on Oracle JDK 11.0.8 & JDK 11.0.9
by Richard Opalka (Jira)
[ https://issues.redhat.com/browse/WFLY-14004?page=com.atlassian.jira.plugi... ]
Richard Opalka updated WFLY-14004:
----------------------------------
Summary: AdvancedLdapLoginModuleTestCase fails on Oracle JDK 11.0.8 & JDK 11.0.9 (was: AdvancedLdapLoginModuleTestCase fails on Oracle JDK 11.0.9)
> AdvancedLdapLoginModuleTestCase fails on Oracle JDK 11.0.8 & JDK 11.0.9
> -----------------------------------------------------------------------
>
> Key: WFLY-14004
> URL: https://issues.redhat.com/browse/WFLY-14004
> Project: WildFly
> Issue Type: Bug
> Components: Security, Test Suite
> Reporter: Richard Opalka
> Assignee: Richard Opalka
> Priority: Major
>
> java.lang.AssertionError: Unexpected status code returned after the authentication. expected:<200> but was:<401>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.jboss.as.test.integration.security.common.Utils$2.run(Utils.java:638)
> at org.jboss.as.test.integration.security.common.Utils$2.run(Utils.java:634)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at java.base/javax.security.auth.Subject.doAs(Subject.java:423)
> at org.jboss.as.test.integration.security.common.Utils.makeCallWithKerberosAuthn(Utils.java:634)
> at org.jboss.as.test.integration.security.loginmodules.negotiation.AdvancedLdapLoginModuleTestCase.testDeployment(AdvancedLdapLoginModuleTestCase.java:277)
> at org.jboss.as.test.integration.security.loginmodules.negotiation.AdvancedLdapLoginModuleTestCase.test1(AdvancedLdapLoginModuleTestCase.java:210)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at org.jboss.arquillian.junit.Arquillian$8$1.invokeMethod(Arquillian.java:325)
> at org.jboss.arquillian.junit.MethodInvoker$1.invoke(MethodInvoker.java:18)
> at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:57)
> at jdk.internal.reflect.GeneratedMethodAccessor27.invoke(Unknown Source)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
> at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:50)
> at jdk.internal.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:128)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:118)
> at jdk.internal.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:116)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:83)
> at jdk.internal.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69)
> at jdk.internal.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:139)
> at org.jboss.arquillian.junit.MethodInvoker.invoke(MethodInvoker.java:15)
> at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:332)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:204)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:350)
> at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:215)
> at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:279)
> at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:88)
> at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:66)
> at jdk.internal.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:128)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:114)
> at jdk.internal.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:116)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:83)
> at jdk.internal.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69)
> at jdk.internal.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:273)
> at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:166)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:350)
> at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:177)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:115)
> 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:384)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
> at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 5 months
[Red Hat JIRA] (WFLY-14284) WildFly doesn't stop while waiting for PeriodicRecovery
by Ondrej Chaloupka (Jira)
[ https://issues.redhat.com/browse/WFLY-14284?page=com.atlassian.jira.plugi... ]
Ondrej Chaloupka commented on WFLY-14284:
-----------------------------------------
hi [~adrianots],
thanks for you investigation. The changes you did are those which I would recommend to examine.
For the first part of your question. I'm worry there is no clear documentation on remoting protocols and their differences in current WFLY. We have got a documentation issue for that https://issues.redhat.com/browse/JBEAP-10343 (it's created for JBoss EAP product but it's what's missing in WFLY doc as well).
I can only link you to source code like here: https://github.com/wildfly/jboss-ejb-client/blob/4.0.37.Final/src/main/ja...
About your changes. What you can observe is something I didn't realize but sounds logical. The process of the EJB remoting and transaction propagation means creating a record about remote connection when transaction is persisted to transaction object store after the {{prepare}} phase finishes.
Currently it works in the following way. When the remote connection with transaction propagation starts then the WildFly Transaction Client creates a record for recovery knows how to connect to the remote side. It should be under {{data/ejb-txn-recovery}} directory (https://github.com/wildfly/wildfly-transaction-client/blob/1.1.13.Final/s...). Then after prepare the transaction manager makes a record about transaction was prepared under {{data/tx-object-store}}.
Now, your transaction was somehow corrupted as it was saved with HEURISTIC outcome (https://jbossts.blogspot.com/2019/09/heuristic-exceptions.html) to object store. The heuristic state means the recovery manager is not capable to decide what to do with the transaction and the human intervention is needed. That means it won't be finished by WFLY automatically.
The transaction recovery then retries to connect the remote connection saved in {{data/ejb-txn-recovery}} by WFLY txn client. The client saved this connection to be on protocol {{http-remoting}} and thus it retries with that protocol - I assume ti from the error you get that still contains the same class handling the connection client.transaction@1.0.21.Final//org.wildfly.httpclient.transaction.HttpRemoteTransactionPeer.recover(HttpRemoteTransactionPeer.java:107)
When you remove the {{data}} directory then the recover is not retrying to connect to the remote endpoint endlessly, still waiting for somebody to verify the txn in the heuristic state. With deleting the data directory (or it could be just content of the {{data/ejb-txn-recovery}} and {{data/tx-object-store}} you says that the transaction has no further value for you and you start with clean object store. If it's ok from the app state perspective then it's fine.
Now, the only question is - when you get to the same state of having the HEURISTIC transaction while your app server configures the {{remote+http}} protocol - if the result will be only error reported and no issue for the WFLY shutdown process. From what I can remember using the {{remote+http}} should fix that.
> WildFly doesn't stop while waiting for PeriodicRecovery
> -------------------------------------------------------
>
> Key: WFLY-14284
> URL: https://issues.redhat.com/browse/WFLY-14284
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Affects Versions: 18.0.1.Final, 20.0.1.Final
> Reporter: Adriano Teixeira de Souza
> Assignee: Michael Musgrove
> Priority: Major
> Attachments: ejb-configs.sh, jboss-ejb-client.xml, server(transaction).log, thread-dump-stop-1.txt
>
>
> I'm testing wildfly 20.0.1 (and 21.0.2 was tested too) for replace our old version of Wildfly 10.
> it happens that frequently we have seen that the stop function of server does not work and we need to kill the process by manual operation on the OS.
> It sounds like a dead look.
> I attatch the thread dump on this.
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 5 months
[Red Hat JIRA] (DROOLS-5910) Enable range index for JoinNode
by Kris Verlaenen (Jira)
[ https://issues.redhat.com/browse/DROOLS-5910?page=com.atlassian.jira.plug... ]
Kris Verlaenen updated DROOLS-5910:
-----------------------------------
Sprint: 2020 Week 49-51 (from Nov 30), 2020 Week 52-03 (from Dec 21), 2021 Week 04-06 (from Jan 25) (was: 2020 Week 49-51 (from Nov 30), 2020 Week 52-03 (from Dec 21))
> Enable range index for JoinNode
> -------------------------------
>
> Key: DROOLS-5910
> URL: https://issues.redhat.com/browse/DROOLS-5910
> Project: Drools
> Issue Type: Enhancement
> Components: core engine
> Affects Versions: 7.47.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> Currently, BetaNode range index works only for NotNode and ExistsNode. Inequality constraints in JoinNode (e.g. $p2 : Person( age > $p1.age )) are not indexed in both standard-drl and exec-model.
> https://github.com/kiegroup/drools/blob/master/drools-core/src/main/java/...
> * Enable range index for JoinNode
> * Fix issues based on failed tests
> ** Type coercion
> ** executable-model specific errors
> ** maybe more
> * Add more tests for join
> * Add benchmark to confirm the effect
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 5 months
[Red Hat JIRA] (DROOLS-5883) GDT editor generates wrong DRL if operator 'contains' is used with string literal containing space
by Kris Verlaenen (Jira)
[ https://issues.redhat.com/browse/DROOLS-5883?page=com.atlassian.jira.plug... ]
Kris Verlaenen updated DROOLS-5883:
-----------------------------------
Sprint: 2020 Week 49-51 (from Nov 30), 2020 Week 52-03 (from Dec 21), 2021 Week 04-06 (from Jan 25) (was: 2020 Week 49-51 (from Nov 30), 2020 Week 52-03 (from Dec 21))
> GDT editor generates wrong DRL if operator 'contains' is used with string literal containing space
> ---------------------------------------------------------------------------------------------------
>
> Key: DROOLS-5883
> URL: https://issues.redhat.com/browse/DROOLS-5883
> Project: Drools
> Issue Type: Bug
> Components: Guided Decision Table Editor
> Affects Versions: 7.47.0.Final
> Reporter: Jozef Marko
> Assignee: Jozef Marko
> Priority: Major
> Labels: guided_decision_table, support
>
> Guided Decision Table editor generate wrong DRL when using 'contains' operator with a string literal containing space., which causes evaluation/build error like.
> [KBase: defaultKieBase]: [ERR 102] Line 7:45 mismatched input ')' in rule "Row 1 rule2"
--
This message was sent by Atlassian Jira
(v8.13.1#813001)
3 years, 5 months