October 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFWIP-218) server scale down keeps data in client's data/ejb-xa-recovery and transactions on client aren't commited

by Tomasz Adamski (Jira)

[ https://issues.jboss.org/browse/WFWIP-218?page=com.atlassian.jira.plugin.... ] Tomasz Adamski updated WFWIP-218: --------------------------------- Comment: was deleted (was: The problem is this issue is as follows: 1. transaction log on on server is cleared correctly 2. server's stateful-set is scaled down (pod referenced by client disappears) 3. client checks in-doubt resource but cannot connect to the server In OpenShift environment with wildfly-operator, we can be sure that if the server's stateful-set was scaled down correctly then it logs must have been cleared. As a result, client records can be discarded. This is not true in general (bare-metal) where the server may go down and still have records in the log. in the context of above I would propose: 1. workaround - provide the customer with a manual procedure (if connection error to the server's pod occurs but the pod was scaled down correctly remove log records). This is not elegant, but this is an emergency and I don't expect it to be used often. 2. solution - if operating within OpenShift client cannot connect to one of the server's pods, client checks with OpenShift API whether the server's pod was scaled down. If it was, the record can be discarded. I would suggest downgrading this issue with provided workaround and later work on the target solution (which would require OpenShift integration and has to be researched).) > server scale down keeps data in client's data/ejb-xa-recovery and transactions on client aren't commited > -------------------------------------------------------------------------------------------------------- > > Key: WFWIP-218 > URL: https://issues.jboss.org/browse/WFWIP-218 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Martin Simka > Assignee: Ondrej Chaloupka > Priority: Blocker > > this follows up on WFWIP-206 > While testing tx recovery in OpenShift I see that scale down of pod that has transaction in-doubt on it isn't successful > Scenario: > *ejb client* (app tx-client, pod tx-client-0): > * EJB business method > ** lookup remote EJB > ** enlist XA resource 1 to transaction > ** enlist XA resource 2 to transaction > ** call remote EJB > *ejb server* (app tx-server, pod tx-server-0): > * EJB business method > ** enlist XA resource 1 to transaction > ** enlist XA resource 2 to transaction > *testTxStatelessServerSecondCommitThrowRmFail* > ejb server XA resource 2 fails with {{XAException(XAException.XAER_RMFAIL)}} > Then the test calls scale down (size from 1 to 0) on tx-server pod. Server scale down completes but sometimes there some records left in {{<JBOSS_HOME>/standalone/data/ejb-xa-recovery}} on tx-client and transactions on client aren't commited. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12313) Implement MP OpenAPI

by Michael Edgar (Jira)

[ https://issues.jboss.org/browse/WFLY-12313?page=com.atlassian.jira.plugin... ] Michael Edgar commented on WFLY-12313: -------------------------------------- Hi [~pferraro], please go ahead and add your comments in github and we can discuss anything of larger scope here. I was able to get the /openapi context working this week by using the {{org.wildfly.undertow.host}} capability with dynamic server and virtual host segments. Those two options are also configurable in the subsystem, but default to {{default-server}} and {{default-host}}. I am definitely open to any ideas/suggestions/improvements. > Implement MP OpenAPI > -------------------- > > Key: WFLY-12313 > URL: https://issues.jboss.org/browse/WFLY-12313 > Project: WildFly > Issue Type: Feature Request > Reporter: Michael Edgar > Assignee: Paul Ferraro > Priority: Major > > Please integrate MicroProfile OpenAPI. > Details about MP OpenAPI: > https://github.com/eclipse/microprofile-open-api/releases/tag/1.1.2 > Maybe it is possible to use SmallRye implementation: > https://github.com/smallrye/smallrye-open-api -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3065) Droolog: Prolog-like features/front-end in Drools

by Edoardo Vacchi (Jira)

[ https://issues.jboss.org/browse/DROOLS-3065?page=com.atlassian.jira.plugi... ] Edoardo Vacchi resolved DROOLS-3065. ------------------------------------ Resolution: Deferred > Droolog: Prolog-like features/front-end in Drools > ------------------------------------------------- > > Key: DROOLS-3065 > URL: https://issues.jboss.org/browse/DROOLS-3065 > Project: Drools > Issue Type: Epic > Reporter: Edoardo Vacchi > Assignee: Edoardo Vacchi > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4572) a fact with many properties causes a problem with "not" rule in executable-model

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-4572?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-4572: -------------------------------- Sprint: 2019 Week 38-40 (from Sep 16) > a fact with many properties causes a problem with "not" rule in executable-model > -------------------------------------------------------------------------------- > > Key: DROOLS-4572 > URL: https://issues.jboss.org/browse/DROOLS-4572 > Project: Drools > Issue Type: Bug > Components: executable model > Affects Versions: 7.27.0.Final > Environment: - executable-model > - Without property reactive > Reporter: Toshiya Kobayashi > Assignee: Mario Fusco > Priority: Major > Labels: support > > Under the conditions: > - executable-model > - "drools.propertySpecific" = "ALLOWED" > - A fact which has more than 128 properties > - A rule with "not" which joins facts > "not" doesn't match so the rule results in an unexpected firing (e.g. an infinite loop) -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12313) Implement MP OpenAPI

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-12313?page=com.atlassian.jira.plugin... ] Paul Ferraro commented on WFLY-12313: ------------------------------------- Hi [~michael.edgar]. I would like to assist in getting this merged for WF19. I'm planning to look over your feature branch this week. I'll have a recommendation for how to best register the /openapi context with Undertow later today. I will also likely have some additional suggestions for the subsystem code itself. Would you prefer I add those comments to this jira? or directly in github? If there's anything significant, I can submit a pull request directly to your branch. > Implement MP OpenAPI > -------------------- > > Key: WFLY-12313 > URL: https://issues.jboss.org/browse/WFLY-12313 > Project: WildFly > Issue Type: Feature Request > Reporter: Michael Edgar > Assignee: Paul Ferraro > Priority: Major > > Please integrate MicroProfile OpenAPI. > Details about MP OpenAPI: > https://github.com/eclipse/microprofile-open-api/releases/tag/1.1.2 > Maybe it is possible to use SmallRye implementation: > https://github.com/smallrye/smallrye-open-api -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4101) Improve "skip from build" feature of Test Scenario

by Daniele Zonca (Jira)

[ https://issues.jboss.org/browse/DROOLS-4101?page=com.atlassian.jira.plugi... ] Daniele Zonca updated DROOLS-4101: ---------------------------------- Story Points: 3 > Improve "skip from build" feature of Test Scenario > -------------------------------------------------- > > Key: DROOLS-4101 > URL: https://issues.jboss.org/browse/DROOLS-4101 > Project: Drools > Issue Type: Task > Components: Scenario Simulation and Testing > Reporter: Daniele Zonca > Assignee: Daniele Zonca > Priority: Major > Labels: ScenarioSimulation > > When a scesim file is marked as to be skipped, it should be listed at least in junit result as skipped while at the moment it is not. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4174) Test Scenario: Add support to recursive types in DMN

by Daniele Zonca (Jira)

[ https://issues.jboss.org/browse/DROOLS-4174?page=com.atlassian.jira.plugi... ] Daniele Zonca updated DROOLS-4174: ---------------------------------- Story Points: 3 > Test Scenario: Add support to recursive types in DMN > ---------------------------------------------------- > > Key: DROOLS-4174 > URL: https://issues.jboss.org/browse/DROOLS-4174 > Project: Drools > Issue Type: Task > Components: Scenario Simulation and Testing > Reporter: Daniele Zonca > Assignee: Daniele Zonca > Priority: Major > Labels: ScenarioSimulation > > Review DMN data type extraction (DMNTypeService) and DMN test scenario template creation (DMNSimulationCreationStrategy) to be sure it works with recursive types. > Please consider that template creation should not expand recursive types at all -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4697) Upgrade WildFly Elytron to 1.10.4.Final

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFCORE-4697?page=com.atlassian.jira.plugi... ] Darran Lofthouse reassigned WFCORE-4697: ---------------------------------------- Assignee: (was: Darran Lofthouse) > Upgrade WildFly Elytron to 1.10.4.Final > --------------------------------------- > > Key: WFCORE-4697 > URL: https://issues.jboss.org/browse/WFCORE-4697 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Ivo Studensky > Priority: Major > Labels: downstream_dependency > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4699) preferIPv6Addresses and preferIPv4Stack System Properties are Mishandled in the Config

by Teresa Miyar Gil (Jira)

[ https://issues.jboss.org/browse/WFCORE-4699?page=com.atlassian.jira.plugi... ] Teresa Miyar Gil moved JBEAP-17706 to WFCORE-4699: -------------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-4699 (was: JBEAP-17706) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Server (was: Server) (was: Web (Undertow)) Affects Version/s: 10.0.0.Final (was: 7.1.4.GA) (was: 7.1.6.GA) (was: 7.2.3.GA) QE Test Coverage: (was: +) > preferIPv6Addresses and preferIPv4Stack System Properties are Mishandled in the Config > -------------------------------------------------------------------------------------- > > Key: WFCORE-4699 > URL: https://issues.jboss.org/browse/WFCORE-4699 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 10.0.0.Final > Environment: * JBoss EAP 7.1/7.2 > * Interface attached to port 0.0.0.0 > * Red Hat Enterprise Linux 7 > * IPv6 disabled in the kernel > sysctl -w net.ipv6.conf.all.disable_ipv6=1 > sysctl -w net.ipv6.conf.default.disable_ipv6=1 > * System properties -Djava.net.preferIPv4Stack=false -Djava.net.preferIPv6Addresses=true > Reporter: Teresa Miyar Gil > Assignee: Teresa Miyar Gil > Priority: Major > Labels: ipv6, startup > > Error is thrown on startup. > Caused by: java.net.SocketException: Protocol family unavailable > at sun.nio.ch.Net.bind0(Native Method) > at sun.nio.ch.Net.bind(Net.java:433) > at sun.nio.ch.Net.bind(Net.java:425) > at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) > at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) > at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:179) > at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310) > at io.undertow.protocols.ssl.UndertowXnioSsl.createSslConnectionServer(UndertowXnioSsl.java:301) > at org.wildfly.extension.undertow.HttpsListenerService.startListening(HttpsListenerService.java:127) > The customer ships a turn key solution that has the two system properties set: -Djava.net.preferIPv4Stack=false -Djava.net.preferIPv6Addresses=true because they are needed for some cases for customers running IPv6, but others want to harden their systems by disabling IPv4. > This works on JBoss EAP 6, but it throws the error on JBoss EAP 7 on the same version of Java. Furthermore, adding just Djava.net.preferIPv4Stack=false has the same issue, even though it the default value, while leaving it off starts. > This appears to be related to controller/src/main/java/org/jboss/as/controller/interfaces/OverallInterfaceCriteria.java#pruneIPTypes where if both properties are null, it leaves the set of candidate addresses alone, but it either are set, it strips out all IPv4 addresses. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-222) when client is scaled down with in-doubt transactions, tx participants on server are resolved with delay

by Ondrej Chaloupka (Jira)

[ https://issues.jboss.org/browse/WFWIP-222?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka closed WFWIP-222. ---------------------------------- Resolution: Rejected The behaviour is expected and the transaction resolution is in hands of different component than the recovery. The transactions on the server were started but was not moved to the {{PREPARED}} state. They are in-flight stored only in memory. It's responsibility of the transaction reaper to finish them. It really does so but the reaper is not dependent on the recovery processing. The reaper roll-backs the transactions after transaction timeout is over. If the reaper is not capable to do so for the remote resources (e.g. WildFly goes down meanwhile) then the database/jms/... will roll-back the transaction after the timeout on its own (aka. prepare was not called -> no promise from the remote resource on the processing was done -> transaction timeouts after the timeout is over) > when client is scaled down with in-doubt transactions, tx participants on server are resolved with delay > -------------------------------------------------------------------------------------------------------- > > Key: WFWIP-222 > URL: https://issues.jboss.org/browse/WFWIP-222 > Project: WildFly WIP > Issue Type: Bug > Reporter: Martin Simka > Assignee: Ondrej Chaloupka > Priority: Blocker > Attachments: tx-server.log > > > this follows up on WFWIP-206 > While testing tx recovery in OpenShift I see that when client is scaled down with in-doubt transactions, tx participants on server are resolved with delay. > Scenario: > *ejb client* (app tx-client, pod tx-client-0): > * EJB business method > ** lookup remote EJB > ** enlist XA resource 1 to transaction > ** enlist XA resource 2 to transaction > ** call remote EJB > *ejb server* (app tx-server, pod tx-server-0): > * EJB business method > ** enlist XA resource 1 to transaction > ** enlist XA resource 2 to transaction > *testTxStatelessClientSecondPrepareJvmHalt* > JVM on client crashes in PREPARE phase of second XA resource on client. Then openshift restarts pod, but pod is immediately scaled down. Transactions on client pod are rollbacked during scale down, but on server they are rollbacked some time later. I'm not sure if it is periodic recovery or tx timeout. > server log with {{com.arjuna}} trace attached. > Feel free to reject if it is expected behavior. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2019