[JBoss JIRA] (DROOLS-4545) GDST V&V: Clean up situations where the webworker fails
by Toni Rikkola (Jira)
Toni Rikkola created DROOLS-4545:
------------------------------------
Summary: GDST V&V: Clean up situations where the webworker fails
Key: DROOLS-4545
URL: https://issues.jboss.org/browse/DROOLS-4545
Project: Drools
Issue Type: Bug
Components: Guided Decision Table Editor
Reporter: Toni Rikkola
Assignee: Toni Rikkola
Problem: If the project does not compile, you can edit the table, but editing fires errors in the Verifier Webworker. This is because the Verifier needs a project that compiles and creates a valid DMO.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 10 months
[JBoss JIRA] (WFLY-12572) Improve credential and role group
by Ilia Vassilev (Jira)
[ https://issues.jboss.org/browse/WFLY-12572?page=com.atlassian.jira.plugin... ]
Ilia Vassilev moved SECURITY-1005 to WFLY-12572:
------------------------------------------------
Project: WildFly (was: PicketBox )
Key: WFLY-12572 (was: SECURITY-1005)
Workflow: GIT Pull Request workflow (was: classic default workflow)
Component/s: Security
(was: JBossSX, Security-SPI)
> Improve credential and role group
> ---------------------------------
>
> Key: WFLY-12572
> URL: https://issues.jboss.org/browse/WFLY-12572
> Project: WildFly
> Issue Type: Enhancement
> Components: Security
> Reporter: Bartosz Baranowski
> Assignee: Bartosz Baranowski
> Priority: Major
>
> CredntialIdentity(to match SimpleIdentity):
> - add equals
> - add hashCode
> RoleGroup:
> - add clone on interface level, so we dont need to cast to implementation
--
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)
[ https://issues.jboss.org/browse/WFWIP-203?page=com.atlassian.jira.plugin.... ]
Ondrej Chaloupka resolved WFWIP-203.
------------------------------------
Resolution: Done
The trouble was cause with the wrong setup in the operator, fixed by https://github.com/wildfly/wildfly-operator/issues/70
> 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
> Priority: Blocker
> Attachments: tx-client-0.log, tx-server-0.log, tx-server-1.log
>
>
> 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