[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)
4 years, 9 months
[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)
4 years, 9 months
[JBoss JIRA] (WFWIP-223) disableHTTPRoute = true in runtime does not clean CR.status.hosts
by Jeff Mesnil (Jira)
[ https://issues.jboss.org/browse/WFWIP-223?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFWIP-223:
-----------------------------------
fixed upstream in https://github.com/wildfly/wildfly-operator/pull/95
> disableHTTPRoute = true in runtime does not clean CR.status.hosts
> -----------------------------------------------------------------
>
> Key: WFWIP-223
> URL: https://issues.jboss.org/browse/WFWIP-223
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: operator
>
> Reproducer:
> # create CR
> {code}
> apiVersion: wildfly.org/v1alpha1
> kind: WildFlyServer
> metadata:
> generation: 1
> name: eap-cd
> namespace: default
> spec:
> applicationImage: >-
> brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/jboss-eap-7-tech-preview/eap-cd-openshift-rhel8:17.0-4
> size: 1
> disableHTTPRoute: false
> {code}
> # Edit CR with disableHTTPRoute: true. I would expect Route object will be deleted.
> {code}
> apiVersion: wildfly.org/v1alpha1
> kind: WildFlyServer
> metadata:
> generation: 1
> name: eap-cd
> namespace: default
> spec:
> applicationImage: >-
> brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/jboss-eap-7-tech-preview/eap-cd-openshift-rhel8:17.0-4
> size: 1
> disableHTTPRoute: true
> {code}
> # Route object eap-cd is not deleted but status.hosts is still filled
> {code:yaml}
> apiVersion: wildfly.org/v1alpha1
> kind: WildFlyServer
> metadata:
> creationTimestamp: '2019-10-01T17:20:34Z'
> generation: 2
> name: eap-cd
> namespace: mchoma
> resourceVersion: '629943'
> selfLink: /apis/wildfly.org/v1alpha1/namespaces/mchoma/wildflyservers/eap-cd
> uid: c7535f3f-e46f-11e9-b4ad-02e6008f3048
> spec:
> applicationImage: >-
> image-registry.openshift-image-registry.svc:5000/eapcd-suite-builds/eap-cd-openshift-rhel8:17.0-4
> disableHTTPRoute: false
> env: []
> envFrom: []
> replicas: 1
> status:
> hosts:
> - >-
> eap-cd-route-mchoma.apps.eap-qe-cluster105.eap-qe-cluster105.fw.rhcloud.com
> pods:
> - name: eap-cd-0
> podIP: 10.131.0.246
> state: ACTIVE
> replicas: 1
> scalingdownPods: 0
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 9 months