[JBoss JIRA] (WFLY-9809) Update jastow to 2.1.0.Final
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-9809?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-9809:
--------------------------------------
Assignee: Flavia Rainone (was: Tomaz Cerar)
[~flavia.rainone] I'm assigning this over during some housekeeping. You'd decide whether this upgrade happens.
> Update jastow to 2.1.0.Final
> ----------------------------
>
> Key: WFLY-9809
> URL: https://issues.jboss.org/browse/WFLY-9809
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Web (Undertow)
> Reporter: Tomaz Cerar
> Assignee: Flavia Rainone
> Priority: Critical
>
> Fixes heaps of issues. including:
> [WFLY-6263][JBEAP-13924][JBEAP-13925][JBEAP-13897] JBEAP-13786
> WFLY-7033
> JBEAP-10134
> WFLY-6263
> WFLY-9368
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 10 months
[JBoss JIRA] (SWSQE-616) Migrate our jenkins slaves to PSI
by Guilherme Baufaker Rêgo (Jira)
[ https://issues.jboss.org/browse/SWSQE-616?page=com.atlassian.jira.plugin.... ]
Guilherme Baufaker Rêgo updated SWSQE-616:
------------------------------------------
Labels: infrastructure (was: )
> Migrate our jenkins slaves to PSI
> ---------------------------------
>
> Key: SWSQE-616
> URL: https://issues.jboss.org/browse/SWSQE-616
> Project: Kiali QE
> Issue Type: Sub-task
> Reporter: Filip Brychta
> Assignee: Filip Brychta
> Priority: Major
> Labels: infrastructure
>
> Before we do the migration we need to answer following questions:
> * do we want to use containers for jenkins slaves in ocp or VMs in openStack?
> * currently we need privileged containers (for kiali-build), is it possible to have it in PSI?
> * check connectivity (stability/latency) to our testing ocp clusters (in our bos lab and in PSI)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 10 months
[JBoss JIRA] (WFLY-11030) Transaction remained in prepared state
by Brian Stansberry (Jira)
[ https://issues.jboss.org/browse/WFLY-11030?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFLY-11030:
---------------------------------------
Assignee: ehsavoie Hugonnet (was: Martyn Taylor)
[~ehugonnet] I'm assigning this over as I don't think it's likely Martyn is dealing with this.
> 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: ehsavoie Hugonnet
> 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.12.1#712002)
5 years, 10 months