[JBoss JIRA] (WFLY-11030) Transaction remained in prepared state
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-11030?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet moved WFWIP-118 to WFLY-11030:
------------------------------------------------
Project: WildFly (was: WildFly WIP)
Key: WFLY-11030 (was: WFWIP-118)
Component/s: JMS
(was: Artemis)
> Transaction remained in prepared state
> --------------------------------------
>
> Key: WFLY-11030
> URL: https://issues.jboss.org/browse/WFLY-11030
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Erich Duda
> Assignee: Martyn Taylor
> Priority: Critical
>
> *Scenario*
> * Start group A of two servers (node-1 and node-3) Servers are not in cluster.
> * Send messages to queue on node-1.
> * Start another group B of two servers(node-2 and node-4). Servers are not in cluster.
> * Deploy mdb on both servers in A group. This mdb reads messages from local queue and perform insert into oracle 11 gr2 database, and also sends messages to remote queue on group B.
> * Mdb deployed on nodes in group B inserts messages from local queue to oracle 11 gr2 database.
> * Kill server node-1. Restart failed node. Process all messages and verify both mdbs performed database insert
> After node-1 is killed and restarted, there are still transactions in prepare state and they are not cleared in 10 minutes. The transactions remains on servers from group B.
> Logs from test can be found in build - https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/mnovak-verifier-...
> *Investigation of issue is in progress. It is not known what component causes it.*
> Clebert looked at the logs but there weren't traces from Arjuna. The above build contains also Arjuna traces. Copy paste Clebert's analyses.
> {quote}I looked at the output from the clients, and filtered the processing
> for one XA that's never commited..
> I looked for the XID on
> base64:AAAAAAAAAAAAAP__ChBkGmqipH1benkDAAAJdQAAAAMAAAAAAAAAAAAAAAAAAP__ChBkGmqipH1benkDAAAJaDUyODcHAgIA
> and filtered the onMessage that generated it (attached the log as
> processingOneMessage.txt):
> This XID was never commited simply because the TM never did it.
> Probably because of some issue on the JDBC.. but there are no errors,
> no exceptions.. totally clean on artemis side.
> There are no logging for TM or the MDB itself to correlate other
> failures. With the information I have I am certain there were nothing
> from Artemis side that would have caused it.
> In any case.. this is not replicated at all.. and not related to 87.
> This is simply the TM getting confused for some issue on the JDBC.
> As far as I am concerned I have fixed the replicated shutdown case.
> and i will send PRs upstream now.{quote}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFLY-11029) Undelivered messages in remote jca topology after restart
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-11029?page=com.atlassian.jira.plugin... ]
ehsavoie Hugonnet moved WFWIP-90 to WFLY-11029:
-----------------------------------------------
Project: WildFly (was: WildFly WIP)
Key: WFLY-11029 (was: WFWIP-90)
Component/s: Clustering
JMS
(was: Artemis)
(was: Clustering)
> Undelivered messages in remote jca topology after restart
> ---------------------------------------------------------
>
> Key: WFLY-11029
> URL: https://issues.jboss.org/browse/WFLY-11029
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, JMS
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
>
> There are undelivered messages in scenario with where servers in remote JCA topology are restarted. There are undelivered message after test.
> Test scenario:
> * Start 2 server in Artemis cluster
> * Start 2 servers with MDB connected to Artemis cluster
> ** MDB resends messages from InQueue to OutQueue from/to remote cluster
> * Send messages to InQueue
> * Restart all server (one by one)
> * Consumes messages from OutQueue
> Results:
> After the test there are missing messages in OutQueue.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (SWSQE-421) Kiali Test Mesh support for ReplicationControllers and DeploymentConfig
by Lucas Ponce (JIRA)
Lucas Ponce created SWSQE-421:
---------------------------------
Summary: Kiali Test Mesh support for ReplicationControllers and DeploymentConfig
Key: SWSQE-421
URL: https://issues.jboss.org/browse/SWSQE-421
Project: Kiali QE
Issue Type: Dev Task
Reporter: Lucas Ponce
Assignee: Michael Foley
Related to KIALI-1284, Kiali will support several types for deployments.
Currently, only Deployment objects are fully supported on list pages.
Also, to sync with the current OpenShift Web Console, we plan to support: Deployment, ReplicaSet, ReplicationController and DeploymentConfig (this one is not a kubernetes object, but only OpenShift one).
So, in order to help in the testing, Kiali Test Mesh could add these new types: ReplicationController and DeploymentConfig to deploy a test scenario that we can use for our testing.
I.e.
{code}
DEPLOYMENT_TYPE=ReplicaController NUM_SERVICES=2 NUM_VERSIONS=2 make openshift-deploy-kiali-test-circle
DEPLOYMENT_TYPE=DeploymentConfig NUM_SERVICES=2 NUM_VERSIONS=2 make openshift-deploy-kiali-test-circle
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFWIP-118) Transaction remained in prepared state
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFWIP-118?page=com.atlassian.jira.plugin.... ]
Miroslav Novak commented on WFWIP-118:
--------------------------------------
Reducing priority as it's not regression.
[~martyn-taylor] [~clebert.suconic] afaik this one is about using all initial connectors when XAResouce.recover() is called. Issue is still valid.
> Transaction remained in prepared state
> --------------------------------------
>
> Key: WFWIP-118
> URL: https://issues.jboss.org/browse/WFWIP-118
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Erich Duda
> Assignee: Kabir Khan
> Priority: Critical
>
> *Scenario*
> * Start group A of two servers (node-1 and node-3) Servers are not in cluster.
> * Send messages to queue on node-1.
> * Start another group B of two servers(node-2 and node-4). Servers are not in cluster.
> * Deploy mdb on both servers in A group. This mdb reads messages from local queue and perform insert into oracle 11 gr2 database, and also sends messages to remote queue on group B.
> * Mdb deployed on nodes in group B inserts messages from local queue to oracle 11 gr2 database.
> * Kill server node-1. Restart failed node. Process all messages and verify both mdbs performed database insert
> After node-1 is killed and restarted, there are still transactions in prepare state and they are not cleared in 10 minutes. The transactions remains on servers from group B.
> Logs from test can be found in build - https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/mnovak-verifier-...
> *Investigation of issue is in progress. It is not known what component causes it.*
> Clebert looked at the logs but there weren't traces from Arjuna. The above build contains also Arjuna traces. Copy paste Clebert's analyses.
> {quote}I looked at the output from the clients, and filtered the processing
> for one XA that's never commited..
> I looked for the XID on
> base64:AAAAAAAAAAAAAP__ChBkGmqipH1benkDAAAJdQAAAAMAAAAAAAAAAAAAAAAAAP__ChBkGmqipH1benkDAAAJaDUyODcHAgIA
> and filtered the onMessage that generated it (attached the log as
> processingOneMessage.txt):
> This XID was never commited simply because the TM never did it.
> Probably because of some issue on the JDBC.. but there are no errors,
> no exceptions.. totally clean on artemis side.
> There are no logging for TM or the MDB itself to correlate other
> failures. With the information I have I am certain there were nothing
> from Artemis side that would have caused it.
> In any case.. this is not replicated at all.. and not related to 87.
> This is simply the TM getting confused for some issue on the JDBC.
> As far as I am concerned I have fixed the replicated shutdown case.
> and i will send PRs upstream now.{quote}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFWIP-118) Transaction remained in prepared state
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFWIP-118?page=com.atlassian.jira.plugin.... ]
Miroslav Novak reassigned WFWIP-118:
------------------------------------
Assignee: Martyn Taylor (was: Kabir Khan)
> Transaction remained in prepared state
> --------------------------------------
>
> Key: WFWIP-118
> URL: https://issues.jboss.org/browse/WFWIP-118
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Erich Duda
> Assignee: Martyn Taylor
> Priority: Critical
>
> *Scenario*
> * Start group A of two servers (node-1 and node-3) Servers are not in cluster.
> * Send messages to queue on node-1.
> * Start another group B of two servers(node-2 and node-4). Servers are not in cluster.
> * Deploy mdb on both servers in A group. This mdb reads messages from local queue and perform insert into oracle 11 gr2 database, and also sends messages to remote queue on group B.
> * Mdb deployed on nodes in group B inserts messages from local queue to oracle 11 gr2 database.
> * Kill server node-1. Restart failed node. Process all messages and verify both mdbs performed database insert
> After node-1 is killed and restarted, there are still transactions in prepare state and they are not cleared in 10 minutes. The transactions remains on servers from group B.
> Logs from test can be found in build - https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/mnovak-verifier-...
> *Investigation of issue is in progress. It is not known what component causes it.*
> Clebert looked at the logs but there weren't traces from Arjuna. The above build contains also Arjuna traces. Copy paste Clebert's analyses.
> {quote}I looked at the output from the clients, and filtered the processing
> for one XA that's never commited..
> I looked for the XID on
> base64:AAAAAAAAAAAAAP__ChBkGmqipH1benkDAAAJdQAAAAMAAAAAAAAAAAAAAAAAAP__ChBkGmqipH1benkDAAAJaDUyODcHAgIA
> and filtered the onMessage that generated it (attached the log as
> processingOneMessage.txt):
> This XID was never commited simply because the TM never did it.
> Probably because of some issue on the JDBC.. but there are no errors,
> no exceptions.. totally clean on artemis side.
> There are no logging for TM or the MDB itself to correlate other
> failures. With the information I have I am certain there were nothing
> from Artemis side that would have caused it.
> In any case.. this is not replicated at all.. and not related to 87.
> This is simply the TM getting confused for some issue on the JDBC.
> As far as I am concerned I have fixed the replicated shutdown case.
> and i will send PRs upstream now.{quote}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFWIP-118) Transaction remained in prepared state
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFWIP-118?page=com.atlassian.jira.plugin.... ]
Miroslav Novak updated WFWIP-118:
---------------------------------
Component/s: Artemis
> Transaction remained in prepared state
> --------------------------------------
>
> Key: WFWIP-118
> URL: https://issues.jboss.org/browse/WFWIP-118
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Erich Duda
> Assignee: Kabir Khan
> Priority: Blocker
>
> *Scenario*
> * Start group A of two servers (node-1 and node-3) Servers are not in cluster.
> * Send messages to queue on node-1.
> * Start another group B of two servers(node-2 and node-4). Servers are not in cluster.
> * Deploy mdb on both servers in A group. This mdb reads messages from local queue and perform insert into oracle 11 gr2 database, and also sends messages to remote queue on group B.
> * Mdb deployed on nodes in group B inserts messages from local queue to oracle 11 gr2 database.
> * Kill server node-1. Restart failed node. Process all messages and verify both mdbs performed database insert
> After node-1 is killed and restarted, there are still transactions in prepare state and they are not cleared in 10 minutes. The transactions remains on servers from group B.
> Logs from test can be found in build - https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/mnovak-verifier-...
> *Investigation of issue is in progress. It is not known what component causes it.*
> Clebert looked at the logs but there weren't traces from Arjuna. The above build contains also Arjuna traces. Copy paste Clebert's analyses.
> {quote}I looked at the output from the clients, and filtered the processing
> for one XA that's never commited..
> I looked for the XID on
> base64:AAAAAAAAAAAAAP__ChBkGmqipH1benkDAAAJdQAAAAMAAAAAAAAAAAAAAAAAAP__ChBkGmqipH1benkDAAAJaDUyODcHAgIA
> and filtered the onMessage that generated it (attached the log as
> processingOneMessage.txt):
> This XID was never commited simply because the TM never did it.
> Probably because of some issue on the JDBC.. but there are no errors,
> no exceptions.. totally clean on artemis side.
> There are no logging for TM or the MDB itself to correlate other
> failures. With the information I have I am certain there were nothing
> from Artemis side that would have caused it.
> In any case.. this is not replicated at all.. and not related to 87.
> This is simply the TM getting confused for some issue on the JDBC.
> As far as I am concerned I have fixed the replicated shutdown case.
> and i will send PRs upstream now.{quote}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months
[JBoss JIRA] (WFWIP-118) Transaction remained in prepared state
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFWIP-118?page=com.atlassian.jira.plugin.... ]
Miroslav Novak updated WFWIP-118:
---------------------------------
Priority: Critical (was: Blocker)
> Transaction remained in prepared state
> --------------------------------------
>
> Key: WFWIP-118
> URL: https://issues.jboss.org/browse/WFWIP-118
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Erich Duda
> Assignee: Kabir Khan
> Priority: Critical
>
> *Scenario*
> * Start group A of two servers (node-1 and node-3) Servers are not in cluster.
> * Send messages to queue on node-1.
> * Start another group B of two servers(node-2 and node-4). Servers are not in cluster.
> * Deploy mdb on both servers in A group. This mdb reads messages from local queue and perform insert into oracle 11 gr2 database, and also sends messages to remote queue on group B.
> * Mdb deployed on nodes in group B inserts messages from local queue to oracle 11 gr2 database.
> * Kill server node-1. Restart failed node. Process all messages and verify both mdbs performed database insert
> After node-1 is killed and restarted, there are still transactions in prepare state and they are not cleared in 10 minutes. The transactions remains on servers from group B.
> Logs from test can be found in build - https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/mnovak-verifier-...
> *Investigation of issue is in progress. It is not known what component causes it.*
> Clebert looked at the logs but there weren't traces from Arjuna. The above build contains also Arjuna traces. Copy paste Clebert's analyses.
> {quote}I looked at the output from the clients, and filtered the processing
> for one XA that's never commited..
> I looked for the XID on
> base64:AAAAAAAAAAAAAP__ChBkGmqipH1benkDAAAJdQAAAAMAAAAAAAAAAAAAAAAAAP__ChBkGmqipH1benkDAAAJaDUyODcHAgIA
> and filtered the onMessage that generated it (attached the log as
> processingOneMessage.txt):
> This XID was never commited simply because the TM never did it.
> Probably because of some issue on the JDBC.. but there are no errors,
> no exceptions.. totally clean on artemis side.
> There are no logging for TM or the MDB itself to correlate other
> failures. With the information I have I am certain there were nothing
> from Artemis side that would have caused it.
> In any case.. this is not replicated at all.. and not related to 87.
> This is simply the TM getting confused for some issue on the JDBC.
> As far as I am concerned I have fixed the replicated shutdown case.
> and i will send PRs upstream now.{quote}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 10 months