[JBoss JIRA] (WFLY-10555) The list-messages and remove-messages don't work on a queue when consumer is connected
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-10555?page=com.atlassian.jira.plugin... ]
Jeff Mesnil commented on WFLY-10555:
------------------------------------
I don't think your test is valid.
You start a consumer that will receives the message from the producer.
As soon as the message is sent by the producer to the broker, the broker will route it to the queue and will to the consumers.
You pause the code in the Consumer class but the consumer remains connected to the broker and will buffer the messages. That's why the queue remains empty.
> The list-messages and remove-messages don't work on a queue when consumer is connected
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-10555
> URL: https://issues.jboss.org/browse/WFLY-10555
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 11.0.0.Final, 13.0.0.Final
> Reporter: Josef Cacek
> Assignee: Jeff Mesnil
> Attachments: helloworld-jms.zip
>
>
> The queue operations {{:list-messages}} and {{:remove-messages}} don't work (return empty set) if a consumer is attached to the server.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (SWSQE-295) Move jaeger-openshift Jenkins job from CNCF CI to B24
by Kevin Earls (JIRA)
Kevin Earls created SWSQE-295:
---------------------------------
Summary: Move jaeger-openshift Jenkins job from CNCF CI to B24
Key: SWSQE-295
URL: https://issues.jboss.org/browse/SWSQE-295
Project: Kiali QE
Issue Type: Bug
Reporter: Kevin Earls
Assignee: Jeeva Kandasamy
Priority: Minor
This is a placeholder to remind you to move the jaeger-openshift jenkins job off of the CNCF CI and instead run it locally. It is contingent on talks between [~mmahoney] and the Jaeger development team.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (SWSQE-294) Investigate ElasticSearch memory requirements on B24 cluster
by Kevin Earls (JIRA)
Kevin Earls created SWSQE-294:
---------------------------------
Summary: Investigate ElasticSearch memory requirements on B24 cluster
Key: SWSQE-294
URL: https://issues.jboss.org/browse/SWSQE-294
Project: Kiali QE
Issue Type: Bug
Reporter: Kevin Earls
Assignee: Guilherme Baufaker Rêgo
Priority: Minor
On minishift and the CNCF CI OpenShift cluster, we install ElasticSearch using the commands:
curl https://raw.githubusercontent.com/RHsyseng/docker-rhel-elasticsearch/5.x/... --output es-cluster-deployment.yml
oc create -f es-cluster-deployment.yml
However, on B24 this fails. The first 2 elasticsearch pods will start up, but then elasticsearch-2 gets into the following failure loop like:
elasticsearch-2 1/1 Running 3 1m
elasticsearch-2 0/1 OOMKilled 3 1m
elasticsearch-2 0/1 CrashLoopBackOff 3 2m
If I increase memory in the es-cluster-deployment.yml to 1Gi it will at least start, but I've found I really need to increase it to 2Gi to do anything non trivial.
We may need to track down the people who originally created this template for help on this.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10557) JPA application deploy fails with "CDI BeanManager not (yet) ready to use"
by Cristhian Camilo Lopez (JIRA)
[ https://issues.jboss.org/browse/WFLY-10557?page=com.atlassian.jira.plugin... ]
Cristhian Camilo Lopez updated WFLY-10557:
------------------------------------------
Component/s: CDI / Weld
JPA / Hibernate
Description:
Deployment of app using JPA converters for enums fails with the following message
{code:java}
10:01:44,044 INFO [org.hibernate.hql.internal.QueryTranslatorFactoryInitiator] (ServerService Thread Pool -- 71) HHH000397: Using ASTQueryTranslatorFactory
10:01:44,047 ERROR [org.hibernate.internal.SessionFactoryImpl] (ServerService Thread Pool -- 71) HHH000177: Error in named query: findEnabledProducts: org.hibernate.QueryException: Could not format constant value to SQL literal: co.cristhian.bugs.product.entity.State.ENABLED [SELECT p FROM co.cristhian.bugs.product.entity.Product p WHERE p.state = co.cristhian.bugs.product.entity.State.ENABLED]
at org.hibernate.QueryException.generateQueryException(QueryException.java:120)
at org.hibernate.QueryException.wrapWithQueryString(QueryException.java:103)
at org.hibernate.hql.internal.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:219)
at org.hibernate.hql.internal.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:143)
at org.hibernate.engine.query.spi.HQLQueryPlan.<init>(HQLQueryPlan.java:120)
at org.hibernate.engine.query.spi.HQLQueryPlan.<init>(HQLQueryPlan.java:81)
at org.hibernate.engine.query.spi.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:153)
at org.hibernate.query.spi.NamedQueryRepository.checkNamedQueries(NamedQueryRepository.java:157)
at org.hibernate.internal.SessionFactoryImpl.checkNamedQueries(SessionFactoryImpl.java:574)
at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:321)
at org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:467)
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:939)
at org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:167)
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:125)
at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:650)
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:209)
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)
at org.jboss.threads.JBossThread.run(JBossThread.java:485)
Caused by: org.hibernate.QueryException: Could not format constant value to SQL literal: co.cristhian.bugs.product.entity.State.ENABLED
at org.hibernate.hql.internal.ast.tree.JavaConstantNode.getRenderText(JavaConstantNode.java:111)
at org.hibernate.hql.internal.ast.SqlGenerator.out(SqlGenerator.java:116)
at org.hibernate.hql.internal.antlr.SqlGeneratorBase.simpleExpr(SqlGeneratorBase.java:3030)
at org.hibernate.hql.internal.antlr.SqlGeneratorBase.expr(SqlGeneratorBase.java:1633)
at org.hibernate.hql.internal.antlr.SqlGeneratorBase.binaryComparisonExpression(SqlGeneratorBase.java:3325)
at org.hibernate.hql.internal.antlr.SqlGeneratorBase.comparisonExpr(SqlGeneratorBase.java:1442)
at org.hibernate.hql.internal.antlr.SqlGeneratorBase.booleanExpr(SqlGeneratorBase.java:934)
at org.hibernate.hql.internal.antlr.SqlGeneratorBase.whereExpr(SqlGeneratorBase.java:780)
at org.hibernate.hql.internal.antlr.SqlGeneratorBase.selectStatement(SqlGeneratorBase.java:213)
at org.hibernate.hql.internal.antlr.SqlGeneratorBase.statement(SqlGeneratorBase.java:146)
at org.hibernate.hql.internal.ast.QueryTranslatorImpl.generate(QueryTranslatorImpl.java:250)
at org.hibernate.hql.internal.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:211)
... 20 more
Caused by: java.lang.IllegalStateException: org.hibernate.resource.beans.container.internal.NotYetReadyException: CDI BeanManager not (yet) ready to use
at org.hibernate.resource.beans.container.internal.JpaCompliantLifecycleStrategy$BeanImpl.initialize(JpaCompliantLifecycleStrategy.java:112)
at org.hibernate.resource.beans.container.internal.CdiBeanContainerExtendedAccessImpl$BeanImpl.initialize(CdiBeanContainerExtendedAccessImpl.java:113)
at org.hibernate.resource.beans.container.internal.CdiBeanContainerExtendedAccessImpl$BeanImpl.getBeanInstance(CdiBeanContainerExtendedAccessImpl.java:119)
at org.hibernate.resource.beans.internal.ManagedBeanRegistryImpl$ContainedBeanManagedBeanAdapter.getBeanInstance(ManagedBeanRegistryImpl.java:139)
at org.hibernate.metamodel.model.convert.internal.JpaAttributeConverterImpl.toRelationalValue(JpaAttributeConverterImpl.java:50)
at org.hibernate.hql.internal.ast.tree.JavaConstantNode.getRenderText(JavaConstantNode.java:89)
... 31 more
Caused by: org.hibernate.resource.beans.container.internal.NotYetReadyException: CDI BeanManager not (yet) ready to use
... 37 more
Caused by: java.lang.NullPointerException
at org.hibernate.resource.beans.container.internal.JpaCompliantLifecycleStrategy$BeanImpl.initialize(JpaCompliantLifecycleStrategy.java:109)
{code}
Steps to Reproduce:
See the example app https://github.com/cristhiank/bug-wildfly-ee8
Compile and deploy
Summary: JPA application deploy fails with "CDI BeanManager not (yet) ready to use" (was: JPA application deploy fails)
Priority: Blocker (was: Major)
Labels: cdi jpa2 wildfly (was: )
Environment:
macOS El Capitan
Java 8
Wildfly 13
Affects Version/s: 13.0.0.Final
Affects: Migration
> JPA application deploy fails with "CDI BeanManager not (yet) ready to use"
> --------------------------------------------------------------------------
>
> Key: WFLY-10557
> URL: https://issues.jboss.org/browse/WFLY-10557
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, JPA / Hibernate
> Affects Versions: 13.0.0.Final
> Environment: macOS El Capitan
> Java 8
> Wildfly 13
> Reporter: Cristhian Camilo Lopez
> Assignee: Jason Greene
> Priority: Blocker
> Labels: cdi, jpa2, wildfly
>
> Deployment of app using JPA converters for enums fails with the following message
> {code:java}
> 10:01:44,044 INFO [org.hibernate.hql.internal.QueryTranslatorFactoryInitiator] (ServerService Thread Pool -- 71) HHH000397: Using ASTQueryTranslatorFactory
> 10:01:44,047 ERROR [org.hibernate.internal.SessionFactoryImpl] (ServerService Thread Pool -- 71) HHH000177: Error in named query: findEnabledProducts: org.hibernate.QueryException: Could not format constant value to SQL literal: co.cristhian.bugs.product.entity.State.ENABLED [SELECT p FROM co.cristhian.bugs.product.entity.Product p WHERE p.state = co.cristhian.bugs.product.entity.State.ENABLED]
> at org.hibernate.QueryException.generateQueryException(QueryException.java:120)
> at org.hibernate.QueryException.wrapWithQueryString(QueryException.java:103)
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:219)
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:143)
> at org.hibernate.engine.query.spi.HQLQueryPlan.<init>(HQLQueryPlan.java:120)
> at org.hibernate.engine.query.spi.HQLQueryPlan.<init>(HQLQueryPlan.java:81)
> at org.hibernate.engine.query.spi.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:153)
> at org.hibernate.query.spi.NamedQueryRepository.checkNamedQueries(NamedQueryRepository.java:157)
> at org.hibernate.internal.SessionFactoryImpl.checkNamedQueries(SessionFactoryImpl.java:574)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:321)
> at org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:467)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:939)
> at org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:167)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:125)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:650)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:209)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: org.hibernate.QueryException: Could not format constant value to SQL literal: co.cristhian.bugs.product.entity.State.ENABLED
> at org.hibernate.hql.internal.ast.tree.JavaConstantNode.getRenderText(JavaConstantNode.java:111)
> at org.hibernate.hql.internal.ast.SqlGenerator.out(SqlGenerator.java:116)
> at org.hibernate.hql.internal.antlr.SqlGeneratorBase.simpleExpr(SqlGeneratorBase.java:3030)
> at org.hibernate.hql.internal.antlr.SqlGeneratorBase.expr(SqlGeneratorBase.java:1633)
> at org.hibernate.hql.internal.antlr.SqlGeneratorBase.binaryComparisonExpression(SqlGeneratorBase.java:3325)
> at org.hibernate.hql.internal.antlr.SqlGeneratorBase.comparisonExpr(SqlGeneratorBase.java:1442)
> at org.hibernate.hql.internal.antlr.SqlGeneratorBase.booleanExpr(SqlGeneratorBase.java:934)
> at org.hibernate.hql.internal.antlr.SqlGeneratorBase.whereExpr(SqlGeneratorBase.java:780)
> at org.hibernate.hql.internal.antlr.SqlGeneratorBase.selectStatement(SqlGeneratorBase.java:213)
> at org.hibernate.hql.internal.antlr.SqlGeneratorBase.statement(SqlGeneratorBase.java:146)
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.generate(QueryTranslatorImpl.java:250)
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:211)
> ... 20 more
> Caused by: java.lang.IllegalStateException: org.hibernate.resource.beans.container.internal.NotYetReadyException: CDI BeanManager not (yet) ready to use
> at org.hibernate.resource.beans.container.internal.JpaCompliantLifecycleStrategy$BeanImpl.initialize(JpaCompliantLifecycleStrategy.java:112)
> at org.hibernate.resource.beans.container.internal.CdiBeanContainerExtendedAccessImpl$BeanImpl.initialize(CdiBeanContainerExtendedAccessImpl.java:113)
> at org.hibernate.resource.beans.container.internal.CdiBeanContainerExtendedAccessImpl$BeanImpl.getBeanInstance(CdiBeanContainerExtendedAccessImpl.java:119)
> at org.hibernate.resource.beans.internal.ManagedBeanRegistryImpl$ContainedBeanManagedBeanAdapter.getBeanInstance(ManagedBeanRegistryImpl.java:139)
> at org.hibernate.metamodel.model.convert.internal.JpaAttributeConverterImpl.toRelationalValue(JpaAttributeConverterImpl.java:50)
> at org.hibernate.hql.internal.ast.tree.JavaConstantNode.getRenderText(JavaConstantNode.java:89)
> ... 31 more
> Caused by: org.hibernate.resource.beans.container.internal.NotYetReadyException: CDI BeanManager not (yet) ready to use
> ... 37 more
> Caused by: java.lang.NullPointerException
> at org.hibernate.resource.beans.container.internal.JpaCompliantLifecycleStrategy$BeanImpl.initialize(JpaCompliantLifecycleStrategy.java:109)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (WFLY-10520) Add Hibernate ORM 5.3 compatibility transformer
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-10520?page=com.atlassian.jira.plugin... ]
Scott Marlow commented on WFLY-10520:
-------------------------------------
Questions/changes from [https://github.com/wildfly/wildfly/pull/11340]
1. Enum org.hibernate.FlushMode.NEVER (0) is deprecated in 5.1, and removed from 5.2; FlushMode.MANUAL (0) should be used instead.
Should the transformer change references to FlushMode.NEVER to FlushMode.MANUAL?
2. ORM 5.1 applications may of seen null returned from org.hibernate.Query.getFirstResult(), under 5.3, applications will never see null.
How does 5.3 handle the same 5.1 conditions that caused getFirstResult() to previously return null? We should document this.
3. ORM 5.1 applications may of seen -1 returned from from org.hibernate.Query.getFirstResult(), under 5.3, applications will never see -1, instead 5.3 will throw an IllegalStateException when a negative number is passed to setFirstResult().
It sounds like the transformer will not ever see the condition where getFirstResult would return -1, since that is not allowed.
4. In 5.3, Integer.MAX_VALUE will be returned from Query.getMaxResults(), the transformer should also check for this value and replace with null reference.
> Add Hibernate ORM 5.3 compatibility transformer
> -----------------------------------------------
>
> Key: WFLY-10520
> URL: https://issues.jboss.org/browse/WFLY-10520
> Project: WildFly
> Issue Type: Task
> Components: JPA / Hibernate
> Reporter: Gail Badner
> Assignee: Scott Marlow
> Fix For: 14.0.0.CR1
>
>
> A compatibility transformer needs to be added to address Hibernate ORM 5.3 API methods that are no longer compatible with 5.1.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month
[JBoss JIRA] (JGRP-2234) Unlocked locks stay locked forever
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2234?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2234:
--------------------------------
Hi Felix,
you can open a PR on GitHub, that I can review and accept.
Cheers,
> Unlocked locks stay locked forever
> ----------------------------------
>
> Key: JGRP-2234
> URL: https://issues.jboss.org/browse/JGRP-2234
> Project: JGroups
> Issue Type: Bug
> Reporter: Bram Klein Gunnewiek
> Assignee: Bela Ban
> Fix For: 4.0.11
>
> Attachments: ClusterSplitLockTest.java, jg_clusterlock_output_testfail.txt
>
>
> As discussed in the mailing list we have issues where locks from the central lock protocol stay locked forever when the coordinator of the cluster disconnects. We can reproduce this with the attached ClusterSplitLockTest.java. Its a race condition and we need to run the test a lot of times (sometimes > 20) before we encounter a failure.
> What we think is happening:
> In a three node cluster (node A, B and C where node A is the coordinator) unlock requests from B and/or C can be missed when node A leaves and B and/or C don't have the new view installed yet. When, for example, node B takes over coordination it creates the lock table based on the back-ups. Lets say node C has locked the lock with name 'lockX'. Node C performs an unlock of 'lockX' just after node A (gracefully) leaves and sends the unlock request to node A since node C doesn't have the correct view installed yet. Node B has recreated the lock table where 'lockX' is locked by Node C. Node C doesn't resend the unlock request so 'lockX' gets locked forever.
> Attached is the testng test we wrote and the output of a test failure.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 1 month