March 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-3797) Restore git history on submarine

by Mario Fusco (Jira)

Mario Fusco created DROOLS-3797: ----------------------------------- Summary: Restore git history on submarine Key: DROOLS-3797 URL: https://issues.jboss.org/browse/DROOLS-3797 Project: Drools Issue Type: Task Reporter: Mario Fusco Assignee: Mario Fusco -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3751) Add decision-table support in Submarine

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-3751?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-3751: -------------------------------- Sprint: (was: 2019 Week 11-13) > Add decision-table support in Submarine > --------------------------------------- > > Key: DROOLS-3751 > URL: https://issues.jboss.org/browse/DROOLS-3751 > Project: Drools > Issue Type: Task > Reporter: Mario Fusco > Assignee: Mario Fusco > Priority: Major > Labels: submarine > Fix For: 8.0.0.Final > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11900) Wildfly 14 + JGroups + Singleton Cluster Not Working

by Bhavesh Kharwa (Jira)

[ https://issues.jboss.org/browse/WFLY-11900?page=com.atlassian.jira.plugin... ] Bhavesh Kharwa commented on WFLY-11900: --------------------------------------- It means clustered singleton is a service that exists on multiple nodes in a cluster, but is active on just a single node at any given time. > Wildfly 14 + JGroups + Singleton Cluster Not Working > ---------------------------------------------------- > > Key: WFLY-11900 > URL: https://issues.jboss.org/browse/WFLY-11900 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Bhavesh Kharwa > Assignee: Paul Ferraro > Priority: Major > Fix For: 14.0.0.Final > > > Singleton cluster is not working if starts both servers at same time. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11900) Wildfly 14 + JGroups + Singleton Cluster Not Working

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-11900?page=com.atlassian.jira.plugin... ] Paul Ferraro commented on WFLY-11900: ------------------------------------- [~bhavesh.rkharwa] Can you elaborate on what you mean by "singleton cluster"? > Wildfly 14 + JGroups + Singleton Cluster Not Working > ---------------------------------------------------- > > Key: WFLY-11900 > URL: https://issues.jboss.org/browse/WFLY-11900 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Bhavesh Kharwa > Assignee: Paul Ferraro > Priority: Major > Fix For: 14.0.0.Final > > > Singleton cluster is not working if starts both servers at same time. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-134) Bad WARN messages: AMQ222211: Storage is back to stable now...

by Francesco Nigro (Jira)

[ https://issues.jboss.org/browse/WFWIP-134?page=com.atlassian.jira.plugin.... ] Francesco Nigro reassigned WFWIP-134: ------------------------------------- Assignee: Francesco Nigro (was: Justin Bertram) > Bad WARN messages: AMQ222211: Storage is back to stable now... > -------------------------------------------------------------- > > Key: WFWIP-134 > URL: https://issues.jboss.org/browse/WFWIP-134 > Project: WildFly WIP > Issue Type: Bug > Components: Artemis > Reporter: Miroslav Novak > Assignee: Francesco Nigro > Priority: Major > > There are unwanted WARN messages: > {code} > 13:47:48,158 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 15.0.0.Alpha1-SNAPSHOT (WildFly Core 7.0.0.Alpha4) started in 8017ms - Started 495 of 723 services (489 services are lazy, passive or on-demand) > 13:47:50,235 WARN [org.apache.activemq.artemis.core.server] (Thread-0 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@371ff371)) AMQ222183: Blocking message production on address 'jms.queue.InQueue'; size is currently: 10,635,300 bytes; max-size-bytes on address: 10,485,760, global-max-size is 10,635,300 > 13:47:52,642 WARN [org.apache.activemq.artemis.core.server] (Thread-4 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@371ff371)) AMQ222211: Storage is back to stable now, under max-disk-usage. > 13:47:57,642 WARN [org.apache.activemq.artemis.core.server] (Thread-15 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@371ff371)) AMQ222211: Storage is back to stable now, under max-disk-usage. > ... > {code} > when server has configured {{global-max-memory-size}} and address-full-policy to BLOCK. Once {{global-max-memory-size}} then starts to log above warnings which with max-disk-usage. Which is not correct as no disk limitation was reached. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11900) Wildfly 14 + JGroups + Singleton Cluster Not Working

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11900?page=com.atlassian.jira.plugin... ] Brian Stansberry reassigned WFLY-11900: --------------------------------------- Component/s: Clustering Priority: Major (was: Blocker) Assignee: Paul Ferraro (was: Brian Stansberry) > Wildfly 14 + JGroups + Singleton Cluster Not Working > ---------------------------------------------------- > > Key: WFLY-11900 > URL: https://issues.jboss.org/browse/WFLY-11900 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Bhavesh Kharwa > Assignee: Paul Ferraro > Priority: Major > Fix For: 14.0.0.Final > > > Singleton cluster is not working if starts both servers at same time. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11906) Managed Executor Task Fails with CDI if created from Batchlet

by Matej Novotny (Jira)

[ https://issues.jboss.org/browse/WFLY-11906?page=com.atlassian.jira.plugin... ] Matej Novotny commented on WFLY-11906: -------------------------------------- The {{Start Batch with Send using Async CDI Event}} is actually coming from Arjuna since the {{CDI.current()}} is invoked there (within {{JNDIBean.create()}}. This will be changed in https://issues.jboss.org/browse/WFLY-11858 as a part of another issue. So both, WFLY-11906 and WFLY-11907 are actually about the ability to invoke {{CDI.current()}} from within a different thread pool. Once it's the once Weld provides with async observer notificaiton and once it's the pool linked to how batchlets are done on MES, do I get it right? > Managed Executor Task Fails with CDI if created from Batchlet > ------------------------------------------------------------- > > Key: WFLY-11906 > URL: https://issues.jboss.org/browse/WFLY-11906 > Project: WildFly > Issue Type: Bug > Components: Batch, CDI / Weld, Concurrency Utilities > Affects Versions: 16.0.0.Final > Environment: Java 8 > Reporter: Cody Lerum > Assignee: Cheng Fang > Priority: Major > > This previously was working (verified in reproducer) on Wildfly 14.0.1 > Inside of a batchlet if a Managed Executor Task is executed and that Task uses CDI.current() an exception is thrown > {code:java} > 11:00:02,343 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) java.lang.IllegalStateException: WFLYWELD0039: Singleton not set for ModuleClassLoader for Module "org.jboss.as.ee" version 16.0.0.Final from local module loader @78e94dcf (finder: local module finder @233fe9b6 (roots: V:\opt\wildfly-16.0.0.Final\modules,V:\opt\wildfly-16.0.0.Final\modules\system\layers\base)). This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment. > 11:00:02,344 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:77) > 11:00:02,344 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:134) > 11:00:02,344 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.weld.Container.instance(Container.java:57) > 11:00:02,344 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.as.weld.WeldProvider.getCDI(WeldProvider.java:69) > 11:00:02,344 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at javax.enterprise.inject.spi.CDI.lambda$getCDIProvider$0(CDI.java:87) > 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:174) > 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.TreeMap$KeySpliterator.tryAdvance(TreeMap.java:2770) > 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:126) > 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:498) > 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:485) > 11:00:02,345 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) > 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.FindOps$FindOp.evaluateSequential(FindOps.java:152) > 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) > 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.stream.ReferencePipeline.findFirst(ReferencePipeline.java:464) > 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at javax.enterprise.inject.spi.CDI.getCDIProvider(CDI.java:88) > 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at javax.enterprise.inject.spi.CDI.current(CDI.java:64) > 11:00:02,346 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at com.outjected.demo.DemoTask.run(DemoTask.java:27) > 11:00:02,347 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.as.ee.concurrent.ControlPointUtils$ControlledRunnable.run(ControlPointUtils.java:105) > 11:00:02,347 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > 11:00:02,347 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:266) > 11:00:02,347 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.concurrent.FutureTask.run(FutureTask.java) > 11:00:02,348 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.glassfish.enterprise.concurrent.internal.ManagedFutureTask.run(ManagedFutureTask.java:141) > 11:00:02,348 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > 11:00:02,348 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > 11:00:02,348 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at java.lang.Thread.run(Thread.java:748) > 11:00:02,349 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:250) > 11:00:02,349 ERROR [stderr] (EE-ManagedExecutorService-default-Thread-1) at org.jboss.as.ee.concurrent.service.ElytronManagedThreadFactory$ElytronManagedThread.run(ElytronManagedThreadFactory.java:85) > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11891) Add tests that enable JPA entity class bytecode enhancement

by Tomasz Adamski (Jira)

[ https://issues.jboss.org/browse/WFLY-11891?page=com.atlassian.jira.plugin... ] Tomasz Adamski reassigned WFLY-11891: ------------------------------------- Assignee: Tomasz Adamski (was: Scott Marlow) > Add tests that enable JPA entity class bytecode enhancement > ----------------------------------------------------------- > > Key: WFLY-11891 > URL: https://issues.jboss.org/browse/WFLY-11891 > Project: WildFly > Issue Type: Enhancement > Components: JPA / Hibernate > Affects Versions: 16.0.0.Final > Reporter: Scott Marlow > Assignee: Tomasz Adamski > Priority: Minor > Attachments: bytebuddy.log, javassist.log > > > Pick a few unit tests and add the following settings to enable [entity bytecode enhancement|http://docs.jboss.org/hibernate/orm/5.3/userguide/html_single...]: > {code} > <property name="hibernate.enhancer.enableDirtyTracking" value="true"/> > <property name="hibernate.enhancer.enableLazyInitialization" value="true"/> > <property name="hibernate.enhancer.enableAssociationManagement" value="true"/> > {code} > Steps to reproduce: > * Build WildFly > * cd testsuite/integration/basic > * mvn clean install -Dtest=org.jboss.as.test.integration.jpa.transaction.TransactionTestCase > * mvn clean install -Dtest=org.jboss.as.test.integration.jpa.hibernate.management.ManagementTestCase > * mvn clean install -Dtest=org.jboss.as.test.integration.jpa.entitylistener.EntityListenersTestCase > * mvn clean install -Dtest=org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase > Note that the org.jboss.as.test.integration.jpa.transaction.TransactionTestCase test should pass since javassist is specified in the persistence.xml but that seems to be ignored (we still get the ByteBuddy failure). > To workaround failures, prestart wildfly via: ./standalone.sh -Dhibernate.bytecode.provider=javassist and then run tests. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-647) Investigate if it's possible to use our baremetal machines for OCP 4.1

by Filip Brychta (Jira)

[ https://issues.jboss.org/browse/SWSQE-647?page=com.atlassian.jira.plugin.... ] Filip Brychta commented on SWSQE-647: ------------------------------------- RHEL CoreOS *is* RHEL. There's no differentation on supported hardware. (On this topic we are just about to get https://github.com/openshift/installer/pull/1459 merged which fully switches RHEL CoreOS to RHEL8 base, so the same hardware compatibility applies generally there) > Investigate if it's possible to use our baremetal machines for OCP 4.1 > ---------------------------------------------------------------------- > > Key: SWSQE-647 > URL: https://issues.jboss.org/browse/SWSQE-647 > Project: Kiali QE > Issue Type: QE Task > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > > According to https://docs.google.com/presentation/d/1fB_5Wz48AlstS9cBqjhO90k-51WgTBEB4... > Control plane resides exclusively on Red Hat CoreOS 8 (IPI & UPI) > So we need to find out if it's possible to install CoreOS 8 on our machines -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 7 months

1
0
0 / 0

[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 Thomas Jenkinson (Jira)

[ https://issues.jboss.org/browse/WFLY-7835?page=com.atlassian.jira.plugin.... ] Thomas Jenkinson reassigned WFLY-7835: -------------------------------------- Assignee: Ondrej Chaloupka (was: Thomas Jenkinson) > 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: Ondrej Chaloupka > 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)

6 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2019