December 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-7782) NPE in logs if listener service fails to start

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-7782: ------------------------------------ Summary: NPE in logs if listener service fails to start Key: WFLY-7782 URL: https://issues.jboss.org/browse/WFLY-7782 Project: WildFly Issue Type: Bug Components: Web (Undertow) Reporter: Stuart Douglas Assignee: Stuart Douglas -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2139) Implement DNS-based PING

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/JGRP-2139?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec commented on JGRP-2139: ------------------------------------------- A very naive implementation may look like the following: {code} Hashtable env = new Hashtable(); env.put("java.naming.factory.initial", "com.sun.jndi.dns.DnsContextFactory"); env.put("java.naming.provider.url", "dns://192.168.0.17"); DirContext ictx = new InitialDirContext(env); Attributes attrs1 = ictx.getAttributes("infinispan-server.myproject.svc.cluster.local", new String[]{"A"}); // prints out: // Attributes: {a=A: 172.17.0.5, 172.17.0.6, 172.17.0.8} {code} The main idea is that Pods need to governed by a [Headless Service|http://kubernetes.io/docs/user-guide/services/#headless-services]. Here's an example: {noformat} apiVersion: v1 kind: List items: - apiVersion: v1 kind: DeploymentConfig metadata: name: infinispan-server namespace: myproject labels: app: infinispan-server spec: triggers: - type: ConfigChange replicas: 1 test: false selector: app: infinispan-server deploymentconfig: infinispan-server template: metadata: creationTimestamp: null labels: app: infinispan-server deploymentconfig: infinispan-server spec: containers: - name: infinispan-server image: 'jboss/infinispan-server:8.2.5.Final' args: - cloud - '-Djboss.default.jgroups.stack=kubernetes' ports: - containerPort: 7600 protocol: TCP - containerPort: 8080 protocol: TCP - containerPort: 8181 protocol: TCP - containerPort: 8888 protocol: TCP - containerPort: 9990 protocol: TCP - containerPort: 11211 protocol: TCP - containerPort: 11222 protocol: TCP - containerPort: 57600 protocol: TCP env: - name: OPENSHIFT_KUBE_PING_NAMESPACE valueFrom: {fieldRef: {apiVersion: v1, fieldPath: metadata.namespace}} resources: terminationMessagePath: /dev/termination-log imagePullPolicy: Always restartPolicy: Always terminationGracePeriodSeconds: 30 dnsPolicy: ClusterFirst securityContext: - apiVersion: v1 kind: Service metadata: name: infinispan-server labels: app: infinispan-server spec: clusterIP: None type: ClusterIP ports: - name: 8080-tcp protocol: TCP port: 8080 targetPort: 8080 selector: app: infinispan-server deploymentconfig: infinispan-server - apiVersion: v1 kind: Route metadata: name: infinispan-server labels: app: infinispan-server spec: to: kind: Service name: infinispan-server port: targetPort: 8080-tcp {noformat} > Implement DNS-based PING > ------------------------ > > Key: JGRP-2139 > URL: https://issues.jboss.org/browse/JGRP-2139 > Project: JGroups > Issue Type: Enhancement > Environment: * OpenShift and Kubernetes (service discovery is done using SRV records) > * Any other environment that use {{A}} or {{SRV}} DNS records > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > > DNS Discovery might be very useful in Cloud environments (such as Kubernetes or OpenShift). They expose Services (which act as Load Balancers and Clustered Virtual IPs for Pods (Docker Containers)) with DNS {{SRV}} entries using the following scheme: {{_port._proto.ENDPOINT.service.namespace.sv.cluster.local}} (see [this issue|https://github.com/kubernetes/kubernetes/issues/29420] for more information). > The implementation should also allow the following: > * Change the DNS Server address > * Change or override TTL values > * Change DNS record type (either {{A}} or {{SRV}} > ** If the record type is {{SRV}}, it should also allow parting port > The implementation might be based on Oracle DNS tutorial: http://docs.oracle.com/javase/7/docs/technotes/guides/jndi/jndi-dns.html -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7728) Increased Memory footprint in recent builds

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7728?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-7728: -------------------------------------- It looks like there is a lot of memory (~1mb) used up in the shared TLD descriptions, which AFAIK are not used anywhere. We could probably not parse any descriptions and just discard them (for both shared and non shared TLD's). > Increased Memory footprint in recent builds > ------------------------------------------- > > Key: WFLY-7728 > URL: https://issues.jboss.org/browse/WFLY-7728 > Project: WildFly > Issue Type: Bug > Components: Server > Affects Versions: 11.0.0.Alpha1 > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Priority: Critical > > In our test scenario (see below) memory footprint has been increased between EAP 7.0.0.GA and current EAP 7.1.0.DR7 for more than 8% (~8MB) for Full profile and more than 9% (~6.5MB) for web profile. Could you please comment whether this is intended. > Test scenario: > # Start EAP instance. > # Measure its memory footprint - try to get the lowest possible footprint, that means force garbage collection a few times right before measuring. We enforce GC 10 times. > We see an increase both in heap size (~ 29 vs. 34 MB) and the metaspace size (~ 64 vs. 68 MB) - these numbers are for standalone-full profile. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7457) UT005013 causes OutOfMemoryError

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7457?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-7457. ---------------------------------- Resolution: Cannot Reproduce Bug I am going to need more information to reproduce this. I have tested this locally and even on unclean close I don't see any leak > UT005013 causes OutOfMemoryError > -------------------------------- > > Key: WFLY-7457 > URL: https://issues.jboss.org/browse/WFLY-7457 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.1.0.Final > Reporter: Steve Vater > Assignee: Stuart Douglas > Labels: new_and_noteworthy > > There's some F5 WAF within the network where our WildFly is running. The WAF sends multiple Keep Alive-Requests to our WAF via TCP, but without sending "close_notify" after the communication has ended. > Undertow throws UT005013, which is correct, but this causes the JVM to run out of Memory. The keepalive is sent 12 times per minute (every 5 seconds) to our WildFly. > We already installed an update of Undertow (1.4.3); This didn't help. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7704) JVM segfault: mod_cluster subsystem cannot handle wildfly-openssl integration

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-7704?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-7704. ---------------------------------- Fix Version/s: 11.0.0.Alpha1 Resolution: Done > JVM segfault: mod_cluster subsystem cannot handle wildfly-openssl integration > ----------------------------------------------------------------------------- > > Key: WFLY-7704 > URL: https://issues.jboss.org/browse/WFLY-7704 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.1.0.Final > Reporter: Michal Karm Babacek > Assignee: Stuart Douglas > Priority: Critical > Fix For: 11.0.0.Alpha1 > > > h3. Preface > mod_cluster subsystem doesn't use Security Realms, unfortunately, so one must replicate SSL configuration both in security realms and in mod_cluster subsystem. > Apparently, there is a confusion about setting protocol and cipher suite in integration between mod_cluster subsystem and wildfly-openssl: > {noformat} > at org.wildfly.openssl.OpenSSLEngine.setEnabledProtocols(OpenSSLEngine.java:754) > at org.wildfly.openssl.OpenSSLSocket.setEnabledCipherSuites(OpenSSLSocket.java:204) > at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.initSocket(JSSESocketFactory.java:384) > at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.createSocket(JSSESocketFactory.java:124) > {noformat} > h3. Configuration > {code} > <security-realm name="JBossTestServer"> > <server-identities> > <ssl protocol="openssl.TLS"> > <engine enabled-cipher-suites="TLS_RSA_WITH_AES_128_GCM_SHA256"/> > <keystore provider="JKS" path="/opt/noe-tests/resources/ssl/proper/server-cert-key.jks" keystore-password="tomcat" alias="javaserver"/> > </ssl> > </server-identities> > <authentication> > <truststore path="/opt/noe-tests/resources/ssl/proper/ca-cert.jks" keystore-password="tomcat"/> > </authentication> > </security-realm> > <subsystem xmlns="urn:jboss:domain:modcluster:2.0"> > <mod-cluster-config advertise-socket="modcluster" connector="https"> > <dynamic-load-provider> > <load-metric type="cpu"/> > </dynamic-load-provider> > <ssl key-alias="javaclient" password="tomcat" certificate-key-file="/opt/noe-tests/resources/ssl/proper/client-cert-key.jks" cipher-suite="TLS_RSA_WITH_AES_128_GCM_SHA256" protocol="openssl.TLS" ca-certificate-file="/opt/noe-tests/resources/ssl/proper/ca-cert.jks"/> > </mod-cluster-config> > </subsystem> > [org.wildfly.openssl.SSL] OpenSSL Version OpenSSL 1.0.2h-fips 3 May 2016 > {code} > h3. JVM segfault > Java Stackstrace on MCMP handler registration: [OpenSSLEngine.java:L754|https://github.com/wildfly/wildfly-openssl/blob/1...] > {noformat} > 12:01:02,249 ERROR [org.jboss.mod_cluster.undertow] (UndertowEventHandlerAdapter - 1) Unsupported protocol TLS_RSA_WITH_AES_128_GCM_SHA256: java.lang.IllegalArgumentException: Unsupported protocol TLS_RSA_WITH_AES_128_GCM_SHA256 > at org.wildfly.openssl.OpenSSLEngine.setEnabledProtocols(OpenSSLEngine.java:754) > at org.wildfly.openssl.OpenSSLSocket.setEnabledCipherSuites(OpenSSLSocket.java:204) > at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.initSocket(JSSESocketFactory.java:384) > at org.jboss.modcluster.mcmp.impl.JSSESocketFactory.createSocket(JSSESocketFactory.java:124) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnection(DefaultMCMPHandler.java:850) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy.getConnectionWriter(DefaultMCMPHandler.java:886) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:514) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:605) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:387) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.status(DefaultMCMPHandler.java:365) > at org.jboss.modcluster.ModClusterService.status(ModClusterService.java:454) > at org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter.run(UndertowEventHandlerAdapter.java:179) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) > at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {noformat}causes JVM segfault: {noformat}# > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x00007fd40e7798c5, pid=29489, tid=0x00007fd44f7f7700 > #{noformat} > Java and Native stacktrace: for a call from Java [byte\[\] getSessionId0(long ssl)|https://github.com/wildfly/wildfly-openssl/blob/1.0.0.Alpha4/java/sr...] to C [getting session from underlying OpenSSL integration fails|https://github.com/wildfly/wildfly-openssl/blob/1.0.0.Alpha4/libwfs...: [0x00007fd44f6f7000,0x00007fd44f7f8000], sp=0x00007fd44f7f6358, free space=1020k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > C [libssl.so+0x478c5] SSL_SESSION_get_id+0x5 > C [libwfssl.so+0x4a0b] Java_org_wildfly_openssl_SSLImpl_getSessionId0+0x6b > j org.wildfly.openssl.SSLImpl.getSessionId0(J)[B+0 > j org.wildfly.openssl.SSLImpl.getSessionId(J)[B+1 > j org.wildfly.openssl.OpenSSLEngine.shutdown()V+42 > j org.wildfly.openssl.OpenSSLEngine.finalize()V+5 > J 1218 C1 java.lang.ref.Finalizer.runFinalizer(Lsun/misc/JavaLangAccess;)V (62 bytes) @ 0x00007fd4593dbf84 [0x00007fd4593dba00+0x584] > J 1217 C1 java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;Lsun/misc/JavaLangAccess;)V (6 bytes) @ 0x00007fd4593db69c [0x00007fd4593db640+0x5c] > j java.lang.ref.Finalizer$FinalizerThread.run()V+45 > v ~StubRoutines::call_stub > V [libjvm.so+0x657fbb] > V [libjvm.so+0x6593b7] > V [libjvm.so+0x659877] > V [libjvm.so+0x6a9371] > V [libjvm.so+0x9de335] > V [libjvm.so+0x9de590] > V [libjvm.so+0x8a18b2] > C [libpthread.so.0+0x7aa1] > Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) > j org.wildfly.openssl.SSLImpl.getSessionId0(J)[B+0 > j org.wildfly.openssl.SSLImpl.getSessionId(J)[B+1 > j org.wildfly.openssl.OpenSSLEngine.shutdown()V+42 > j org.wildfly.openssl.OpenSSLEngine.finalize()V+5 > J 1218 C1 java.lang.ref.Finalizer.runFinalizer(Lsun/misc/JavaLangAccess;)V (62 bytes) @ 0x00007fd4593dbf84 [0x00007fd4593dba00+0x584] > J 1217 C1 java.lang.ref.Finalizer.access$100(Ljava/lang/ref/Finalizer;Lsun/misc/JavaLangAccess;)V (6 bytes) @ 0x00007fd4593db69c [0x00007fd4593db640+0x5c] > j java.lang.ref.Finalizer$FinalizerThread.run()V+45 > v ~StubRoutines::call_stub{noformat} > h3. OpenSSL 1.0.2h > This is the declaration of the called [SSL_SESSION_get_id|https://github.com/openssl/openssl/blob/OpenSSL_1_0_2h...] and this is the definition in [ssl_sess.c|https://github.com/openssl/openssl/blob/OpenSSL_1_0_2h/ssl/ssl...] > h3. Conclusion > IMHO it wouldn't do any harm to check whether {{session}} ain't NULL before passing it on down to OpenSSL, but it is only the aftermath, not the original cause I suppose. It might be worth checking whether the bug is actually not simply in the mod_cluster java part, in calling {{org.wildfly.openssl.OpenSSLEngine}} with confused protocols/cipher suites. > Cheers > -K- -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6939) Usage of static fields from java.lang classes as EL expressions in JSPs doesn't work

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-6939?page=com.atlassian.jira.plugin.... ] James Perkins reopened WFLY-6939: --------------------------------- Assignee: James Perkins (was: jaikiran pai) This seems to require an import, which may be correct, of the constant class in order for this to work. It also does not work with inner classes, https://developer.jboss.org/thread/273323. > Usage of static fields from java.lang classes as EL expressions in JSPs doesn't work > ------------------------------------------------------------------------------------ > > Key: WFLY-6939 > URL: https://issues.jboss.org/browse/WFLY-6939 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Final, 10.1.0.CR1 > Reporter: jaikiran pai > Assignee: James Perkins > Fix For: 10.1.0.Final, 11.0.0.Alpha1 > > > Java EE7 (which supports EL 3.0 spec) allows JSPs to use EL expressions like: > {code} > <html> > <body> > foo: --- ${Boolean.TRUE} ---<br> > bar: --- ${Integer.MAX_VALUE} ---<br> > </body> > </html> > {code} > However, the {code}${Boolean.TRUE}{code} and {code}${Integer.MAX_VALUE}{code} in the above example aren't evaluated correctly and instead a blank string is rendered for them. > More details in the linked forum thread https://developer.jboss.org/thread/271825 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2110) Upgrade to Remoting JMX 3.0.0.Beta2

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFCORE-2110: ---------------------------------------- Summary: Upgrade to Remoting JMX 3.0.0.Beta2 Key: WFCORE-2110 URL: https://issues.jboss.org/browse/WFCORE-2110 Project: WildFly Core Issue Type: Component Upgrade Components: JMX Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Alpha16 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-134) Release Remoting JMX 3.0.0.Beta2

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-134?page=com.atlassian.jira.plugin... ] Darran Lofthouse resolved REMJMX-134. ------------------------------------- Resolution: Done > Release Remoting JMX 3.0.0.Beta2 > -------------------------------- > > Key: REMJMX-134 > URL: https://issues.jboss.org/browse/REMJMX-134 > Project: Remoting JMX > Issue Type: Release > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta2 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-133) Upgrade to WildFly Elytron 1.1.0.Beta17

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/REMJMX-133?page=com.atlassian.jira.plugin... ] Darran Lofthouse resolved REMJMX-133. ------------------------------------- Resolution: Done > Upgrade to WildFly Elytron 1.1.0.Beta17 > --------------------------------------- > > Key: REMJMX-133 > URL: https://issues.jboss.org/browse/REMJMX-133 > Project: Remoting JMX > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta2 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-134) Release Remoting JMX 3.0.0.Beta2

by Darran Lofthouse (JIRA)

Darran Lofthouse created REMJMX-134: --------------------------------------- Summary: Release Remoting JMX 3.0.0.Beta2 Key: REMJMX-134 URL: https://issues.jboss.org/browse/REMJMX-134 Project: Remoting JMX Issue Type: Release Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 3.0.0.Beta2 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 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 December 2016