[JBoss JIRA] (WFLY-12063) ClassFormatError on JDK13
by Richard Opalka (Jira)
[ https://issues.jboss.org/browse/WFLY-12063?page=com.atlassian.jira.plugin... ]
Richard Opalka resolved WFLY-12063.
-----------------------------------
Fix Version/s: 18.0.0.Final
Resolution: Done
I tested WildFly & WildFly Core against JDK13 and all tests passed for me.
> ClassFormatError on JDK13
> -------------------------
>
> Key: WFLY-12063
> URL: https://issues.jboss.org/browse/WFLY-12063
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Reporter: Richard Opalka
> Assignee: Scott Marlow
> Priority: Critical
> Labels: blocker-WF18, jdk13
> Fix For: 18.0.0.Final
>
> Attachments: server.log, test.log
>
>
> The following commit https://github.com/wildfly/wildfly/commit/b6d141b06404a4c23ead1d04d6e26fc... introduced JDK13 regression in WildFly.
> Affected tests are:
> ---
> [ERROR] Errors:
> [ERROR] MultiplePuTestCase.org.jboss.as.test.integration.jpa.basic.multiplepersistenceunittest.MultiplePuTestCase » Deployment
> [ERROR] EntityListenersTestCase.org.jboss.as.test.integration.jpa.entitylistener.EntityListenersTestCase » Deployment
> [ERROR] EPCPropagationTestCase.org.jboss.as.test.integration.jpa.epcpropagation.EPCPropagationTestCase » Deployment
> [ERROR] AuditJoinTableoverBidirectionalTest.org.jboss.as.test.integration.jpa.hibernate.envers.AuditJoinTableoverBidirectionalTest » Deployment
> [ERROR] AuditJoinTableoverOnetoManyJoinColumnTest.org.jboss.as.test.integration.jpa.hibernate.envers.AuditJoinTableoverOnetoManyJoinColumnTest » Deployment
> [ERROR] ManagementTestCase.getEntityInsertCountAttribute:98 » Deployment Cannot deploy...
> [ERROR] JPA2LCTestCase.org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase » Deployment
> [ERROR] JpaStatisticsTestCase.org.jboss.as.test.integration.jpa.secondlevelcache.JpaStatisticsTestCase » Deployment
> [ERROR] TransactionTestCase.org.jboss.as.test.integration.jpa.transaction.TransactionTestCase » Deployment
> [INFO]
> [ERROR] Tests run: 1553, Failures: 0, Errors: 9, Skipped: 14
> ---
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 10 months
[JBoss JIRA] (WFWIP-203) Transaction recovery may hit a wrong server when remote side works with multiple pods
by Ondrej Chaloupka (Jira)
Ondrej Chaloupka created WFWIP-203:
--------------------------------------
Summary: Transaction recovery may hit a wrong server when remote side works with multiple pods
Key: WFWIP-203
URL: https://issues.jboss.org/browse/WFWIP-203
Project: WildFly WIP
Issue Type: Bug
Components: OpenShift
Reporter: Ondrej Chaloupka
Assignee: Ondrej Chaloupka
When server to server calls ejb remote calls where transaction context is propagated then ejb call can be routed to a one pod where the recovery call may directed to a different pod.
Such situation causes a consistency issue.
Let's say the scenario: the first server (let's call it `tx-client`) makes remote ejb call to remote server which is on of the servers joint in cluster named `tx-server-0` and `tx-server-1`. The `tx-client` calls the `tx-server-1`. The processing continues up to the start of the 2PC and the `tx-server-1` crashes (or host goes down, network issue happens...).
`tx-client` understands that the process was not succesful and ask recovery manager to retry and finish.
The recovery manager starts to call the remote server based on data saved in the object store of `tx-client`.
But unfortunately the recovery remote call goes *not* to the `tx-server-1` but to `tx-server-0`. The `tx-client` gets error code `XAException.XAER_NOTA` (`-4`) and removes data from its object store (`/opt/eap/standalone/data/tx-object-store/`, `/opt/eap/standalone/data/ejb-xa-recovery`) and then never finishes in-doubt transactions at `tx-server-1`.
It's in doubt if it's issue of OpenShift configuration or if it's a trouble of WFTC/ejb/remoting layer in WildFly.
This is tested with WFLY Operator from 2019-09-26 `@90a2b3b`.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 10 months
[JBoss JIRA] (DROOLS-4536) Test scenarios fails with default values
by Toni Rikkola (Jira)
[ https://issues.jboss.org/browse/DROOLS-4536?page=com.atlassian.jira.plugi... ]
Toni Rikkola commented on DROOLS-4536:
--------------------------------------
They should. I'll check them as soon as I can.
> Test scenarios fails with default values
> ----------------------------------------
>
> Key: DROOLS-4536
> URL: https://issues.jboss.org/browse/DROOLS-4536
> Project: Drools
> Issue Type: Bug
> Components: Test Scenarios Editor
> Affects Versions: 7.25.0.Final
> Reporter: Sudhish Nair
> Assignee: Toni Rikkola
> Priority: Minor
> Labels: drools-tools, support
> Attachments: Screenshot from 2019-09-16 12-34-12.png, latestjbpmfailed.png, latestjbpmpassed.png, sample.drl
>
>
> In test scenarios (Legacy test scenario) expect section, if we don't edit the default numeric values in expect section then test scenario fails, but if we edit and enter the same value it passes, sometimes we have to type a different value, run the test, then retype 0/0.0 for it to pass.
> The issue is always reproducible.
> h2. Acceptance test
> - Default empty text (/)
> - Default int zero (x)
> - Default double zero (x)
> - Default boolean true (/)
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 10 months