[JBoss JIRA] (JGRP-2407) CompositeMessage: collapse into BytesMessage at the receiver5
by Bela Ban (Jira)
Bela Ban created JGRP-2407:
------------------------------
Summary: CompositeMessage: collapse into BytesMessage at the receiver5
Key: JGRP-2407
URL: https://issues.jboss.org/browse/JGRP-2407
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 5.0
If a sender sends a CompositeMessage, say of an NioMessage of 500 bytes and a BytesMessage of 10 bytes, provide the option to unmarshal the message into a BytesMessage of 510 bytes at the receiver.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (JGRP-2406) MERGE3 not working with TCP using ForkJoinPool
by Olivier Peyrusse (Jira)
[ https://issues.jboss.org/browse/JGRP-2406?page=com.atlassian.jira.plugin.... ]
Olivier Peyrusse updated JGRP-2406:
-----------------------------------
Description:
With JDK11, using the TCP protocol with the ForkJoinPool is causing constant failures of MERGE3.
I consistently observed the following, from the point of view of a member M
- M asks for other coordinator views. It contacts A and B
- A and B send their views
- M waits and timeouts for receiving views and abort the merge
- immediately after aborting the merge, M process messages containing the views of A and B.
In [^timeline.txt], you will see the extracts for logs from the various members at play.
After many experiments, the one parameter causing this issue is in the TCP protocol.
{code:xml}
<TCP
...
thread_pool.use_fork_join_pool="true" />
{code}
Setting {{thread_pool.use_fork_join_pool}} to true repeatedly produces the problem, while using {{thread_pool.use_fork_join_pool}} with false works fine.
Project details:
- as tested within Kubernetes, this project uses KUBE_PING as its discovery protocol
- to understand the reason for the failed merges, I created the protocol MERGE4, that is MERGE3 with additional logs.
- [^logs.tgz] contains all logs from the various members involved in the test.
was:
Using the TCP protocol with the ForkJoinPool is causing constant failures of MERGE3.
I consistently observed the following, from the point of view of a member M
- M asks for other coordinator views. It contacts A and B
- A and B send their views
- M waits and timeouts for receiving views and abort the merge
- immediately after aborting the merge, M process messages containing the views of A and B.
In [^timeline.txt], you will see the extracts for logs from the various members at play.
After many experiments, the one parameter causing this issue is in the TCP protocol.
{code:xml}
<TCP
...
thread_pool.use_fork_join_pool="true" />
{code}
Setting {{thread_pool.use_fork_join_pool}} to true repeatedly produces the problem, while using {{thread_pool.use_fork_join_pool}} with false works fine.
Project details:
- as tested within Kubernetes, this project uses KUBE_PING as its discovery protocol
- to understand the reason for the failed merges, I created the protocol MERGE4, that is MERGE3 with additional logs.
- [^logs.tgz] contains all logs from the various members involved in the test.
> MERGE3 not working with TCP using ForkJoinPool
> ----------------------------------------------
>
> Key: JGRP-2406
> URL: https://issues.jboss.org/browse/JGRP-2406
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.8
> Reporter: Olivier Peyrusse
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.1.9
>
> Attachments: logs.tgz, project.zip, timeline.txt
>
>
> With JDK11, using the TCP protocol with the ForkJoinPool is causing constant failures of MERGE3.
> I consistently observed the following, from the point of view of a member M
> - M asks for other coordinator views. It contacts A and B
> - A and B send their views
> - M waits and timeouts for receiving views and abort the merge
> - immediately after aborting the merge, M process messages containing the views of A and B.
> In [^timeline.txt], you will see the extracts for logs from the various members at play.
> After many experiments, the one parameter causing this issue is in the TCP protocol.
> {code:xml}
> <TCP
> ...
> thread_pool.use_fork_join_pool="true" />
> {code}
> Setting {{thread_pool.use_fork_join_pool}} to true repeatedly produces the problem, while using {{thread_pool.use_fork_join_pool}} with false works fine.
> Project details:
> - as tested within Kubernetes, this project uses KUBE_PING as its discovery protocol
> - to understand the reason for the failed merges, I created the protocol MERGE4, that is MERGE3 with additional logs.
> - [^logs.tgz] contains all logs from the various members involved in the test.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12814) PreDestroy method not called by stateful beans with timeout 0
by Cheng Fang (Jira)
[ https://issues.jboss.org/browse/WFLY-12814?page=com.atlassian.jira.plugin... ]
Cheng Fang updated WFLY-12814:
------------------------------
Description:
When a stateful bean is configured to have timeout value 0, its preDestroy method is not called when removing it. The expected behavior is the bean should timeout and be eligible for removal immediately (since the stateful timeout is 0), and its preDestroy method is called before the bean is removed.
The problem seems to be in {{org.jboss.as.ejb3.cache.simple.SimpleCache}}, which removes the bean with 0 timeout value directly, instead of submitting it to {{org.wildfly.clustering.ee.cache.scheduler.LocalScheduler}} for removal. The direct removal does not have all the proper setup for the preDestroy method to be invoked.
{code:java}
@Stateful
@StatefulTimeout(value = 0, unit = TimeUnit.SECONDS)
//when changed @StatefulTimeout to 1, it works as expected.
//@StatefulTimeout(value = 1, unit = TimeUnit.SECONDS)
public class StatefulHello {
public void hello() {
}
@PreDestroy
private void preDestroy() {
System.out.printf("## preDestroy in StatefulHello%n");
}
}
{code}
was:
When a stateful bean is configured to have timeout value 0, its preDestroy method is not called when removing it. The expected behavior is the bean should timeout and be eligible for removal immediately (since the stateful timeout is 0), and its preDestroy method is called before the bean is removed.
The problem seems to be in {{org.jboss.as.ejb3.cache.simple.SimpleCache}}, which removes the bean with 0 timeout value directly, instead of submitting it to {{org.wildfly.clustering.ee.cache.scheduler.LocalScheduler}} for removal. The direct removal does not have all the proper setup for the preDestroy method to be invoked.
> PreDestroy method not called by stateful beans with timeout 0
> --------------------------------------------------------------
>
> Key: WFLY-12814
> URL: https://issues.jboss.org/browse/WFLY-12814
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 18.0.0.Final
> Reporter: Cheng Fang
> Assignee: Cheng Fang
> Priority: Major
> Fix For: 19.0.0.Beta1
>
>
> When a stateful bean is configured to have timeout value 0, its preDestroy method is not called when removing it. The expected behavior is the bean should timeout and be eligible for removal immediately (since the stateful timeout is 0), and its preDestroy method is called before the bean is removed.
> The problem seems to be in {{org.jboss.as.ejb3.cache.simple.SimpleCache}}, which removes the bean with 0 timeout value directly, instead of submitting it to {{org.wildfly.clustering.ee.cache.scheduler.LocalScheduler}} for removal. The direct removal does not have all the proper setup for the preDestroy method to be invoked.
> {code:java}
> @Stateful
> @StatefulTimeout(value = 0, unit = TimeUnit.SECONDS)
> //when changed @StatefulTimeout to 1, it works as expected.
> //@StatefulTimeout(value = 1, unit = TimeUnit.SECONDS)
> public class StatefulHello {
> public void hello() {
> }
> @PreDestroy
> private void preDestroy() {
> System.out.printf("## preDestroy in StatefulHello%n");
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (DROOLS-4795) [DMN Designer] User is unable to save model when structure is removed
by Jozef Marko (Jira)
Jozef Marko created DROOLS-4795:
-----------------------------------
Summary: [DMN Designer] User is unable to save model when structure is removed
Key: DROOLS-4795
URL: https://issues.jboss.org/browse/DROOLS-4795
Project: Drools
Issue Type: Bug
Components: DMN Editor
Affects Versions: 7.31.0.Final
Reporter: Jozef Marko
Assignee: Michael Anstis
Attachments: edit-and-remove.webm
There is scenario causing user is not able to save the DMN file anymore. If is editing some structure field, but he decides in the middle of editing to rmeove whole structure, the save button of the designer remains disabled.
We should either fix this scenario or drop the *disable save button* feature.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (JBJCA-1396) dataSource.getConnection() returns broken connection after XAResource#commit() failed in the same thread
by Tomas Hofman (Jira)
[ https://issues.jboss.org/browse/JBJCA-1396?page=com.atlassian.jira.plugin... ]
Tomas Hofman resolved JBJCA-1396.
---------------------------------
Resolution: Done
Merged in 1.4.20.
> dataSource.getConnection() returns broken connection after XAResource#commit() failed in the same thread
> --------------------------------------------------------------------------------------------------------
>
> Key: JBJCA-1396
> URL: https://issues.jboss.org/browse/JBJCA-1396
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Affects Versions: WildFly/IronJacamar 1.4.2.Final
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
> Priority: Major
> Attachments: log_and_config.zip, reproducer.zip
>
>
> When retrying Usertransaction on same thread after XAResource#commit() failed, DataSource#getConnection() returns closed connection in new Usertransaction. [1]
> [1]
> {code}
> // 1st attempt.
> UserTransaction.begin();
> Connection conn = dataSource.getConnection();
> Statemnt stmt = conn.createStatement();
> stmt.executeUpdate("...");
> UserTransaction.commit(); // XAResource#commit() failure with ARJUNA016039.
> // retry transaction.
> UserTransaction.begin();
> Connection conn = dataSource.getConnection(); // returned same physical connection of the previous transaction.
> Statemnt stmt = conn.createStatement(); // SQLException thrown by the connection is already closed.
> {code}
> The stacktrace [2] is as follows.
> [2]
> {code}
> // 1st attempt
> WARN [com.arjuna.ats.jta] (default task-1) ARJUNA016039: onePhaseCommit on < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:21fea082:5dc8ed99:f, node_name=1, branch_uid=0:ffff7f000001:21fea082:5dc8ed99:14, subordinatenodename=null, eis_name=java:jboss/datasources/ExampleDS > (LocalXAResourceImpl@6cb4daa9[connectionListener=6a0eecdd connectionManager=36f87501 warned=false currentXid=null productName=H2 productVersion=@PROJECT_VERSION@ (2016-10-31) jndiName=java:jboss/datasources/ExampleDS]) failed with exception XAException.XA_RBROLLBACK: org.jboss.jca.core.spi.transaction.local.LocalXAException: IJ001156: Could not commit local transaction
> at org.jboss.jca.core.tx.jbossts.LocalXAResourceImpl.commit(LocalXAResourceImpl.java:182)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAOnePhaseResource.commit(XAOnePhaseResource.java:120)
> at com.arjuna.ats.internal.arjuna.abstractrecords.LastResourceRecord.topLevelOnePhaseCommit(LastResourceRecord.java:172)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2386)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1497)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:96)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1287)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:94)
> at org.wildfly.transaction.client.LocalTransaction.commitAndDissociate(LocalTransaction.java:75)
> at org.wildfly.transaction.client.ContextTransactionManager.commit(ContextTransactionManager.java:71)
> at org.wildfly.transaction.client.LocalUserTransaction.commit(LocalUserTransaction.java:53)
> 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.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:410)
> at org.jboss.weld.bean.builtin.CallableMethodHandler.invoke(CallableMethodHandler.java:42)
> at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:106)
> at org.jboss.weldx.transaction.UserTransaction$$Proxy$_$$_Weld$Proxy$.commit(Unknown Source)
> at com.example.HelloServlet.doGet(HelloServlet.java:65)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:686)
> ...
> // 2nd attempt
> ERROR [stderr] (default task-1) org.h2.jdbc.JdbcSQLException: The object is already closed [90007-193]
> ERROR [stderr] (default task-1) at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> ERROR [stderr] (default task-1) at org.h2.message.DbException.get(DbException.java:179)
> ERROR [stderr] (default task-1) at org.h2.message.DbException.get(DbException.java:155)
> ERROR [stderr] (default task-1) at org.h2.message.DbException.get(DbException.java:144)
> ERROR [stderr] (default task-1) at org.h2.jdbc.JdbcConnection.checkClosed(JdbcConnection.java:1480)
> ERROR [stderr] (default task-1) at org.h2.jdbc.JdbcConnection.checkClosed(JdbcConnection.java:1458)
> ERROR [stderr] (default task-1) at org.h2.jdbc.JdbcConnection.createStatement(JdbcConnection.java:202)
> ERROR [stderr] (default task-1) at org.jboss.jca.adapters.jdbc.WrappedConnection$1.produce(WrappedConnection.java:357)
> ERROR [stderr] (default task-1) at org.jboss.jca.adapters.jdbc.WrappedConnection$1.produce(WrappedConnection.java:355)
> ERROR [stderr] (default task-1) at org.jboss.jca.adapters.jdbc.SecurityActions.executeInTccl(SecurityActions.java:97)
> ERROR [stderr] (default task-1) at org.jboss.jca.adapters.jdbc.WrappedConnection.createStatement(WrappedConnection.java:355)
> ERROR [stderr] (default task-1) at com.example.HelloServlet.doGet(HelloServlet.java:59)
> ...
> {code}
> The following document [3] indicates the XAResource#commit() with onePhase=true has possibility to close the connection when the commit fails. So the connection closing seems to be correct.
> [3]
> {code}
> "If the resource manager did not commit the transaction and the paramether onePhase is set to true, the resource manager may throw one of the XA_RB* exceptions.
> Upon return, the resource manager has rolled back the branch's work and has released all held resources."
> https://docs.oracle.com/javase/8/docs/api/javax/transaction/xa/XAResource...
> {code}
> And if java.sql.Connection#close() is called before Usertransaction#commit() on 1st attempt, DataSource returns a valid/useful connection on 2nd Usertransaction. [4]
> But it seems to be difficult to know for user why getConnection() returns closed connection when the above issue occurred.
> [4]
> {code}
> // 1st attempt.
> UserTransaction.begin();
> Connection conn = dataSource.getConnection();
> Statemnt stmt = conn.createStatement();
> stmt.executeUpdate("...");
> conn.close(); // connection close is called before commit.
> UserTransaction.commit(); // XAResource#commit() failure with ARJUNA016039.
> // retry transaction.
> UserTransaction.begin();
> Connection conn = dataSource.getConnection(); // valid connection will be returned.
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (JBJCA-1396) dataSource.getConnection() returns broken connection after XAResource#commit() failed in the same thread
by Tomas Hofman (Jira)
[ https://issues.jboss.org/browse/JBJCA-1396?page=com.atlassian.jira.plugin... ]
Tomas Hofman commented on JBJCA-1396:
-------------------------------------
PR: https://github.com/ironjacamar/ironjacamar/pull/694
> dataSource.getConnection() returns broken connection after XAResource#commit() failed in the same thread
> --------------------------------------------------------------------------------------------------------
>
> Key: JBJCA-1396
> URL: https://issues.jboss.org/browse/JBJCA-1396
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC
> Affects Versions: WildFly/IronJacamar 1.4.2.Final
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
> Priority: Major
> Attachments: log_and_config.zip, reproducer.zip
>
>
> When retrying Usertransaction on same thread after XAResource#commit() failed, DataSource#getConnection() returns closed connection in new Usertransaction. [1]
> [1]
> {code}
> // 1st attempt.
> UserTransaction.begin();
> Connection conn = dataSource.getConnection();
> Statemnt stmt = conn.createStatement();
> stmt.executeUpdate("...");
> UserTransaction.commit(); // XAResource#commit() failure with ARJUNA016039.
> // retry transaction.
> UserTransaction.begin();
> Connection conn = dataSource.getConnection(); // returned same physical connection of the previous transaction.
> Statemnt stmt = conn.createStatement(); // SQLException thrown by the connection is already closed.
> {code}
> The stacktrace [2] is as follows.
> [2]
> {code}
> // 1st attempt
> WARN [com.arjuna.ats.jta] (default task-1) ARJUNA016039: onePhaseCommit on < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:21fea082:5dc8ed99:f, node_name=1, branch_uid=0:ffff7f000001:21fea082:5dc8ed99:14, subordinatenodename=null, eis_name=java:jboss/datasources/ExampleDS > (LocalXAResourceImpl@6cb4daa9[connectionListener=6a0eecdd connectionManager=36f87501 warned=false currentXid=null productName=H2 productVersion=@PROJECT_VERSION@ (2016-10-31) jndiName=java:jboss/datasources/ExampleDS]) failed with exception XAException.XA_RBROLLBACK: org.jboss.jca.core.spi.transaction.local.LocalXAException: IJ001156: Could not commit local transaction
> at org.jboss.jca.core.tx.jbossts.LocalXAResourceImpl.commit(LocalXAResourceImpl.java:182)
> at com.arjuna.ats.internal.jta.resources.arjunacore.XAOnePhaseResource.commit(XAOnePhaseResource.java:120)
> at com.arjuna.ats.internal.arjuna.abstractrecords.LastResourceRecord.topLevelOnePhaseCommit(LastResourceRecord.java:172)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2386)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1497)
> at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:96)
> at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1287)
> at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:94)
> at org.wildfly.transaction.client.LocalTransaction.commitAndDissociate(LocalTransaction.java:75)
> at org.wildfly.transaction.client.ContextTransactionManager.commit(ContextTransactionManager.java:71)
> at org.wildfly.transaction.client.LocalUserTransaction.commit(LocalUserTransaction.java:53)
> 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.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:410)
> at org.jboss.weld.bean.builtin.CallableMethodHandler.invoke(CallableMethodHandler.java:42)
> at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:106)
> at org.jboss.weldx.transaction.UserTransaction$$Proxy$_$$_Weld$Proxy$.commit(Unknown Source)
> at com.example.HelloServlet.doGet(HelloServlet.java:65)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:686)
> ...
> // 2nd attempt
> ERROR [stderr] (default task-1) org.h2.jdbc.JdbcSQLException: The object is already closed [90007-193]
> ERROR [stderr] (default task-1) at org.h2.message.DbException.getJdbcSQLException(DbException.java:345)
> ERROR [stderr] (default task-1) at org.h2.message.DbException.get(DbException.java:179)
> ERROR [stderr] (default task-1) at org.h2.message.DbException.get(DbException.java:155)
> ERROR [stderr] (default task-1) at org.h2.message.DbException.get(DbException.java:144)
> ERROR [stderr] (default task-1) at org.h2.jdbc.JdbcConnection.checkClosed(JdbcConnection.java:1480)
> ERROR [stderr] (default task-1) at org.h2.jdbc.JdbcConnection.checkClosed(JdbcConnection.java:1458)
> ERROR [stderr] (default task-1) at org.h2.jdbc.JdbcConnection.createStatement(JdbcConnection.java:202)
> ERROR [stderr] (default task-1) at org.jboss.jca.adapters.jdbc.WrappedConnection$1.produce(WrappedConnection.java:357)
> ERROR [stderr] (default task-1) at org.jboss.jca.adapters.jdbc.WrappedConnection$1.produce(WrappedConnection.java:355)
> ERROR [stderr] (default task-1) at org.jboss.jca.adapters.jdbc.SecurityActions.executeInTccl(SecurityActions.java:97)
> ERROR [stderr] (default task-1) at org.jboss.jca.adapters.jdbc.WrappedConnection.createStatement(WrappedConnection.java:355)
> ERROR [stderr] (default task-1) at com.example.HelloServlet.doGet(HelloServlet.java:59)
> ...
> {code}
> The following document [3] indicates the XAResource#commit() with onePhase=true has possibility to close the connection when the commit fails. So the connection closing seems to be correct.
> [3]
> {code}
> "If the resource manager did not commit the transaction and the paramether onePhase is set to true, the resource manager may throw one of the XA_RB* exceptions.
> Upon return, the resource manager has rolled back the branch's work and has released all held resources."
> https://docs.oracle.com/javase/8/docs/api/javax/transaction/xa/XAResource...
> {code}
> And if java.sql.Connection#close() is called before Usertransaction#commit() on 1st attempt, DataSource returns a valid/useful connection on 2nd Usertransaction. [4]
> But it seems to be difficult to know for user why getConnection() returns closed connection when the above issue occurred.
> [4]
> {code}
> // 1st attempt.
> UserTransaction.begin();
> Connection conn = dataSource.getConnection();
> Statemnt stmt = conn.createStatement();
> stmt.executeUpdate("...");
> conn.close(); // connection close is called before commit.
> UserTransaction.commit(); // XAResource#commit() failure with ARJUNA016039.
> // retry transaction.
> UserTransaction.begin();
> Connection conn = dataSource.getConnection(); // valid connection will be returned.
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12811) Can not inject MP Config property to a HealthCheck bean
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFLY-12811?page=com.atlassian.jira.plugin... ]
Jeff Mesnil commented on WFLY-12811:
------------------------------------
I can not reproduce this issue (with either a Provider or a boolean). Do you have a reproducer?
Did you activate CDI support in your deployment by adding a beans.xml?
> Can not inject MP Config property to a HealthCheck bean
> -------------------------------------------------------
>
> Key: WFLY-12811
> URL: https://issues.jboss.org/browse/WFLY-12811
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, MP Health
> Affects Versions: 18.0.1.Final
> Reporter: Ivan Straka
> Assignee: Jeff Mesnil
> Priority: Critical
>
> I am playing a bit with MP specs (getting multiple specs to work together). I have been trying to return Health status based on injected config property (MP Config). However it looks like the property is not properly injected to the bean.
> {code:java}
> @Liveness
> @ApplicationScoped
> public class CDIBasedLivenessHealthCheck implements HealthCheck {
> @Inject
> @ConfigProperty(name = "dummy_live")
> private Provider<Boolean> live;
> @Override
> public HealthCheckResponse call() {
> return HealthCheckResponse.named("dummy")
> .state(live.get())
> .build();
> }
> }
> {code}
> I am get following error:
> {code:java}
> 15:41:04,616 ERROR [org.wildfly.extension.microprofile.health.smallrye] (management I/O-2) Error processing Health Checks: java.lang.NullPointerException
> at health.CDIBasedLivenessHealthCheck.call(CDIBasedLivenessHealthCheck.java:26)
> at health.CDIBasedLivenessHealthCheck$Proxy$_$$_WeldClientProxy.call(Unknown Source)
> at org.wildfly.extension.microprofile.health.HealthReporter.jsonObject(HealthReporter.java:120)
> at org.wildfly.extension.microprofile.health.HealthReporter.fillCheck(HealthReporter.java:107)
> at org.wildfly.extension.microprofile.health.HealthReporter.processChecks(HealthReporter.java:96)
> at org.wildfly.extension.microprofile.health.HealthReporter.getHealth(HealthReporter.java:79)
> at org.wildfly.extension.microprofile.health.HealthReporter.getHealth(HealthReporter.java:60)
> at org.wildfly.extension.microprofile.health.HealthContextService$HealthCheckHandler.handleRequest(HealthContextService.java:100)
> at org.jboss.as.domain.http.server.security.RealmReadinessHandler.handleRequest(RealmReadinessHandler.java:51)
> at org.jboss.as.domain.http.server.security.ServerErrorReadinessHandler.handleRequest(ServerErrorReadinessHandler.java:35)
> at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:91)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:211)
> at io.undertow.server.handlers.cache.CacheHandler.handleRequest(CacheHandler.java:92)
> at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:78)
> at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
> at org.jboss.as.domain.http.server.ManagementHttpRequestHandler.handleRequest(ManagementHttpRequestHandler.java:57)
> at org.jboss.as.domain.http.server.cors.CorsHttpHandler.handleRequest(CorsHttpHandler.java:75)
> at org.jboss.as.domain.http.server.ManagementHttpServer$UpgradeFixHandler.handleRequest(ManagementHttpServer.java:672)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:376)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:255)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:162)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:100)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:57)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.QueuedNioTcpServer2.acceptTask(QueuedNioTcpServer2.java:178)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:479)
> {code}
> I believe there is a bug in MP Health integration rather than in weld. After checks are registered here in [CDIExtension|https://github.com/wildfly/wildfly/blob/master/microprofile/...] I am able to call _check.call()_ and I get _UP_ as a result. However during HTTP call here in [HealthReporter|https://github.com/wildfly/wildfly/blob/master/microprofil...] I get NPE.
> I can inject a dummy bean. However if the dummy bean injects a config property, NPE is thrown.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-9450) NPE on jaxrs subsystem of FAILED deployment
by Emilio Cuberos (Jira)
[ https://issues.jboss.org/browse/WFLY-9450?page=com.atlassian.jira.plugin.... ]
Emilio Cuberos commented on WFLY-9450:
--------------------------------------
Hi,
We upgraded from Java/Wildfly10 to java 11/Wildlfy17 and I'm getting that exact same error message:
{code:java}
2019-01-17 11:23:43,046 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 38) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
("deployment" => "xxxxx.war"),
("subsystem" => "jaxrs"),
("rest-resource" => "xxxxxx")
]): java.lang.IllegalArgumentException: value is null
at org.jboss.dmr.ModelNode.<init>(ModelNode.java:185)
{code}
Also, the persistence-units are not found to be injected:
{code:java}
Caused by: java.lang.IllegalArgumentException: WFLYWELD0037: Error injecting persistence unit into CDI managed bean. Can't find a persistence unit named 'xxxxx' in deployment xxxxx.war for injection point private javax.persistence.EntityManager OurRepositoryClass.em"}}
{code}
Please, do you have any tips?
> NPE on jaxrs subsystem of FAILED deployment
> --------------------------------------------
>
> Key: WFLY-9450
> URL: https://issues.jboss.org/browse/WFLY-9450
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 15.0.1.Final
> Reporter: Claudio Miranda
> Assignee: Bartosz Baranowski
> Priority: Major
> Fix For: 19.0.0.Beta1
>
>
> read deployment resources of a server, where one deployment is in failed status, throws a NPE and doesn't return the list of deployed applications.
> To reproduce, get the kitchensink from quickstarts, change the persistence.xml to point to ExampleDS datasource, deploy and assign to main-server-group. Then disable ExampleDS, restart server-one.
> Run the following command:
> {code}
> /host=master/server=server-one:read-children-resources(child-type=deployment,include-runtime,recursive)
> {code}
> {code}
> deploy ~/redhat/git/quickstart/kitchensink/target/kitchensink.war --server-groups=main-server-group
> /profile=default/subsystem=datasources/data-source=ExampleDS:write-attribute(name=enabled,value=false)
> /profile=full/subsystem=datasources/data-source=ExampleDS:write-attribute(name=enabled,value=false)
> /profile=full-ha/subsystem=datasources/data-source=ExampleDS:write-attribute(name=enabled,value=false)
> /host=master/server=server-one:reload
> /host=master/server=server-one:read-children-resources(child-type=deployment,include-runtime,recursive)
> {code}
> The exception in server.log
> {code}
> 2017-10-17 17:08:02,778 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 32) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("deployment" => "kitchensink.war"),
> ("subsystem" => "jaxrs"),
> ("rest-resource" => "org.jboss.as.quickstarts.kitchensink.rest.MemberResourceRESTService")
> ]): java.lang.NullPointerException
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.getDeployment(UndertowDeploymentService.java:170)
> at org.jboss.as.jaxrs.DeploymentRestResourcesDefintion$AbstractRestResReadHandler.execute(DeploymentRestResourcesDefintion.java:183)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:172)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:135)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:231)
> {code}
> The CLI results doesn't display the error message
> {code}
> [domain@localhost:9990 /] /host=master/server=server-one:read-children-resources(child-type=deployment,include-runtime,recursive)
> {
> "outcome" => "success",
> "result" => undefined,
> "failure-description" => undefined
> }
> {code}
> There is a similar problem while reading a specific deployment,
> {code}
> /host=master/server=server-one/deployment=kitchensink.war:read-children-resources(child-type=subsystem,recursive)
> {code}
> results in the following error in server.log
> {code}
> 2017-10-17 17:16:09,857 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 32) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("deployment" => "kitchensink.war"),
> ("subsystem" => "ejb3"),
> ("stateless-session-bean" => "MemberRegistration")
> ]) - failure description: "WFLYEJB0370: EJB component for address [
> (\"deployment\" => \"kitchensink.war\"),
> (\"subsystem\" => \"ejb3\"),
> (\"stateless-session-bean\" => \"MemberRegistration\")
> ] is in
> state DOWN, must be in state UP"
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-9450) NPE on jaxrs subsystem of FAILED deployment
by Emilio Cuberos (Jira)
[ https://issues.jboss.org/browse/WFLY-9450?page=com.atlassian.jira.plugin.... ]
Emilio Cuberos edited comment on WFLY-9450 at 11/21/19 5:23 AM:
----------------------------------------------------------------
Hi,
We upgraded from Java8/Wildfly10 to java 11/Wildlfy17 and I'm getting that exact same error message:
{code:java}
2019-01-17 11:23:43,046 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 38) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
("deployment" => "xxxxx.war"),
("subsystem" => "jaxrs"),
("rest-resource" => "xxxxxx")
]): java.lang.IllegalArgumentException: value is null
at org.jboss.dmr.ModelNode.<init>(ModelNode.java:185)
{code}
Also, the persistence-units are not found to be injected:
{code:java}
Caused by: java.lang.IllegalArgumentException: WFLYWELD0037: Error injecting persistence unit into CDI managed bean. Can't find a persistence unit named 'xxxxx' in deployment xxxxx.war for injection point private javax.persistence.EntityManager OurRepositoryClass.em"}}
{code}
Please, do you have any tips?
was (Author: emiliocuberos):
Hi,
We upgraded from Java/Wildfly10 to java 11/Wildlfy17 and I'm getting that exact same error message:
{code:java}
2019-01-17 11:23:43,046 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 38) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
("deployment" => "xxxxx.war"),
("subsystem" => "jaxrs"),
("rest-resource" => "xxxxxx")
]): java.lang.IllegalArgumentException: value is null
at org.jboss.dmr.ModelNode.<init>(ModelNode.java:185)
{code}
Also, the persistence-units are not found to be injected:
{code:java}
Caused by: java.lang.IllegalArgumentException: WFLYWELD0037: Error injecting persistence unit into CDI managed bean. Can't find a persistence unit named 'xxxxx' in deployment xxxxx.war for injection point private javax.persistence.EntityManager OurRepositoryClass.em"}}
{code}
Please, do you have any tips?
> NPE on jaxrs subsystem of FAILED deployment
> --------------------------------------------
>
> Key: WFLY-9450
> URL: https://issues.jboss.org/browse/WFLY-9450
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 15.0.1.Final
> Reporter: Claudio Miranda
> Assignee: Bartosz Baranowski
> Priority: Major
> Fix For: 19.0.0.Beta1
>
>
> read deployment resources of a server, where one deployment is in failed status, throws a NPE and doesn't return the list of deployed applications.
> To reproduce, get the kitchensink from quickstarts, change the persistence.xml to point to ExampleDS datasource, deploy and assign to main-server-group. Then disable ExampleDS, restart server-one.
> Run the following command:
> {code}
> /host=master/server=server-one:read-children-resources(child-type=deployment,include-runtime,recursive)
> {code}
> {code}
> deploy ~/redhat/git/quickstart/kitchensink/target/kitchensink.war --server-groups=main-server-group
> /profile=default/subsystem=datasources/data-source=ExampleDS:write-attribute(name=enabled,value=false)
> /profile=full/subsystem=datasources/data-source=ExampleDS:write-attribute(name=enabled,value=false)
> /profile=full-ha/subsystem=datasources/data-source=ExampleDS:write-attribute(name=enabled,value=false)
> /host=master/server=server-one:reload
> /host=master/server=server-one:read-children-resources(child-type=deployment,include-runtime,recursive)
> {code}
> The exception in server.log
> {code}
> 2017-10-17 17:08:02,778 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 32) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("deployment" => "kitchensink.war"),
> ("subsystem" => "jaxrs"),
> ("rest-resource" => "org.jboss.as.quickstarts.kitchensink.rest.MemberResourceRESTService")
> ]): java.lang.NullPointerException
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.getDeployment(UndertowDeploymentService.java:170)
> at org.jboss.as.jaxrs.DeploymentRestResourcesDefintion$AbstractRestResReadHandler.execute(DeploymentRestResourcesDefintion.java:183)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:172)
> at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:135)
> at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:231)
> {code}
> The CLI results doesn't display the error message
> {code}
> [domain@localhost:9990 /] /host=master/server=server-one:read-children-resources(child-type=deployment,include-runtime,recursive)
> {
> "outcome" => "success",
> "result" => undefined,
> "failure-description" => undefined
> }
> {code}
> There is a similar problem while reading a specific deployment,
> {code}
> /host=master/server=server-one/deployment=kitchensink.war:read-children-resources(child-type=subsystem,recursive)
> {code}
> results in the following error in server.log
> {code}
> 2017-10-17 17:16:09,857 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 32) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("deployment" => "kitchensink.war"),
> ("subsystem" => "ejb3"),
> ("stateless-session-bean" => "MemberRegistration")
> ]) - failure description: "WFLYEJB0370: EJB component for address [
> (\"deployment\" => \"kitchensink.war\"),
> (\"subsystem\" => \"ejb3\"),
> (\"stateless-session-bean\" => \"MemberRegistration\")
> ] is in
> state DOWN, must be in state UP"
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months