[JBoss JIRA] (WFLY-13334) MP Opentracing tests are not passing with a Security Manager
by Emmanuel Hugonnet (Jira)
Emmanuel Hugonnet created WFLY-13334:
----------------------------------------
Summary: MP Opentracing tests are not passing with a Security Manager
Key: WFLY-13334
URL: https://issues.redhat.com/browse/WFLY-13334
Project: WildFly
Issue Type: Bug
Components: MP OpenTracing, Security Manager, Test Suite
Affects Versions: 19.0.1.Final
Reporter: Emmanuel Hugonnet
Assignee: Emmanuel Hugonnet
Failing tests :
EarOpenTracingTestCase.testEarServicesUseDifferentTracersAfterReloadorg.wildfly.test.integration.microprofile.opentracing
EarOpenTracingTestCase.testEarServicesUseDifferentTracersorg.wildfly.test.integration.microprofile.opentracing
EarOpenTracingWithWeldProbeTestCase.testEarServicesUseDifferentTracersAfterReloadorg.wildfly.test.integration.microprofile.opentracing
EarOpenTracingWithWeldProbeTestCase.testEarServicesUseDifferentTracersorg.wildfly.test.integration.microprofile.opentracing
MultiTracerTestCase.testMultipleWarServicesUseDifferentTracersorg.wildfly.test.integration.microprofile.opentracing
MultiTracerTestCase.testMultipleWarServicesUseDifferentTracersAfterReloadorg.wildfly.test.integration.microprofile.opentracing
MultiWarOpenTracingTestCase.testMultipleWarServicesUseDifferentTracersorg.wildfly.test.integration.microprofile.opentracing
MultiWarOpenTracingTestCase.testMultipleWarServicesUseDifferentTracersAfterReloadorg.wildfly.test.integration.microprofile.opentracing
OnOffOpenTracingTestCase.testOpenTracingMultinodeServerorg.wildfly.test.integration.microprofile.opentracing
ResourceWithCDITestCase.tracedEndpointYieldsSpanorg.wildfly.test.integration.microprofile.opentracing
ResourceWithCustomOperationNameBeanTestCase.customOperationNameorg.wildfly.test.integration.microprofile.opentracing
SimpleRestClientTestCase.clientRequestSpanJoinsServerorg.wildfly.test.integration.microprofile.opentracing
SubsystemConfigurationTestCase.checkJaegerTracerAttributesorg.wildfly.test.integration.microprofile.opentracing
SubsystemConfigurationTestCase.checkNoopTracerConfigurationorg.wildfly.test.integration.microprofile.opentracing
30ms
14
Failed
WildCardTestCase.wildCardPathorg.wildfly.test.integration.microprofile.opentracing
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-13322) Ability to configure JSF Implementation that uses the jsf-injection module instead of copying jars
by Brad Maxwell (Jira)
[ https://issues.redhat.com/browse/WFLY-13322?page=com.atlassian.jira.plugi... ]
Brad Maxwell updated WFLY-13322:
--------------------------------
Description:
Currently to configure a different JSF Implementation in a module, these steps below are followed:
1. $ mkdir -p modules/com/sun/jsf-impl/JSF_IMPL_NAME-JSF_VERSION
2. Copy the wildfly-jsf-injection and weld-core-jsf JAR files from EAP_HOME/modules/system/layers/base/org/jboss/as/jsf-injection/main/ to the modules/com/sun/jsf-impl/JSF_IMPL_NAME-JSF_VERSION/ subdirectory.
For initial setup, the jars that need to be copied may be from modules/system/layers/base/org/jboss/as/jsf-injection/main or if an Update is applied, then it should be from the latest dir of the form system/layers/base/.overlays/layer-base-jboss-eap-7.2.z.CP/org/jboss/as/jsf-injection/main
After a new Update, if a bug gets fixed in the jars, then the user needs to copy the updated jars into their custom module.
It would be better if the user can just create a module with their jars and depend on the org/jboss/as/jsf-injection module and then the JSF subsystem make it work.
was:
Modifying modules under modules/system/ should not be required as this breaks patching and requires users to keep re applying the configuration or copying jars around when a patch is applied.
The user should be able to create a module with a different JSF implementation and depend on org.jboss.as.jsf-injection or such and it work without having to modify the org.jboss.as.jsf-injection module.
> Ability to configure JSF Implementation that uses the jsf-injection module instead of copying jars
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-13322
> URL: https://issues.redhat.com/browse/WFLY-13322
> Project: WildFly
> Issue Type: Enhancement
> Components: JSF
> Reporter: Brad Maxwell
> Assignee: Farah Juma
> Priority: Major
>
> Currently to configure a different JSF Implementation in a module, these steps below are followed:
> 1. $ mkdir -p modules/com/sun/jsf-impl/JSF_IMPL_NAME-JSF_VERSION
> 2. Copy the wildfly-jsf-injection and weld-core-jsf JAR files from EAP_HOME/modules/system/layers/base/org/jboss/as/jsf-injection/main/ to the modules/com/sun/jsf-impl/JSF_IMPL_NAME-JSF_VERSION/ subdirectory.
> For initial setup, the jars that need to be copied may be from modules/system/layers/base/org/jboss/as/jsf-injection/main or if an Update is applied, then it should be from the latest dir of the form system/layers/base/.overlays/layer-base-jboss-eap-7.2.z.CP/org/jboss/as/jsf-injection/main
> After a new Update, if a bug gets fixed in the jars, then the user needs to copy the updated jars into their custom module.
> It would be better if the user can just create a module with their jars and depend on the org/jboss/as/jsf-injection module and then the JSF subsystem make it work.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-13322) Ability to configure JSF Implementation that uses the jsf-injection module instead of copying jars
by Brad Maxwell (Jira)
[ https://issues.redhat.com/browse/WFLY-13322?page=com.atlassian.jira.plugi... ]
Brad Maxwell updated WFLY-13322:
--------------------------------
Summary: Ability to configure JSF Implementation that uses the jsf-injection module instead of copying jars (was: Ability to configure JSF Implementation instead of modifying the system module)
> Ability to configure JSF Implementation that uses the jsf-injection module instead of copying jars
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-13322
> URL: https://issues.redhat.com/browse/WFLY-13322
> Project: WildFly
> Issue Type: Enhancement
> Components: JSF
> Reporter: Brad Maxwell
> Assignee: Farah Juma
> Priority: Major
>
> Modifying modules under modules/system/ should not be required as this breaks patching and requires users to keep re applying the configuration or copying jars around when a patch is applied.
> The user should be able to create a module with a different JSF implementation and depend on org.jboss.as.jsf-injection or such and it work without having to modify the org.jboss.as.jsf-injection module.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-13333) Openapi endpoint returns empty file if schema definition contains non ASCII character
by Márk Petrényi (Jira)
Márk Petrényi created WFLY-13333:
------------------------------------
Summary: Openapi endpoint returns empty file if schema definition contains non ASCII character
Key: WFLY-13333
URL: https://issues.redhat.com/browse/WFLY-13333
Project: WildFly
Issue Type: Bug
Components: MP OpenAPI
Affects Versions: 19.0.0.Final
Reporter: Márk Petrényi
Assignee: Paul Ferraro
Currently the {{/openapi}} endpoint returns empty file if the OpenAPI schema definition contains non ASCII characters (ie. accented letters like á,í...).
I extended the openapi quickstart for demonstration: https://github.com/petrenyi-mark/quickstart/commit/44096980ff36ff2655859f...
It seems like it is related to the content-length, since in {{OpenAPIHttpHandler}} the content-length header is set by {{String.length()}} (line 125). However before the response is actually returned, undertow validates that the actual content-length based on ByteBuffer size is not greater then the one declared in the response header. Since non ASCII characters are usually represented by 2 bytes undertow will fail, thus no content will be returned.
In {{OpenAPIHttpHandler}} setting {{string.getBytes(charset).length}} as Conetnt-Length instead of {{String.length()}} would likely resolve this issue.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFCORE-4900) Wildfly-openssl can not load library wfssl on RHEL6
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFCORE-4900?page=com.atlassian.jira.plug... ]
Darran Lofthouse resolved WFCORE-4900.
--------------------------------------
Fix Version/s: 12.0.0.Beta1
Resolution: Duplicate Issue
Ok I am resolving this one as being a duplicate we already have WFCORE-4878 which is the relevant upstream issue which has also been completed. The upstream issues are handled in their respective repositories so we don't need a WFLY clone for every JBEAP.
> Wildfly-openssl can not load library wfssl on RHEL6
> ---------------------------------------------------
>
> Key: WFCORE-4900
> URL: https://issues.redhat.com/browse/WFCORE-4900
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Tomas Terem
> Assignee: Farah Juma
> Priority: Critical
> Labels: regression
> Fix For: 12.0.0.Beta1
>
>
> Using OpenSSL on RHEL6 cuases UnsatisfiedLinkError when loading the wfssl library.
> {code:java}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.ApplicationRealm.ssl-context: WFLYDM0018: Unable to start service
> at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:116)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: openssl.TLS, provider: openssl, class: org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi)
> at java.security.Provider$Service.newInstance(Provider.java:1617)
> at sun.security.jca.GetInstance.getInstance(GetInstance.java:236)
> at sun.security.jca.GetInstance.getInstance(GetInstance.java:164)
> at javax.net.ssl.SSLContext.getInstance(SSLContext.java:156)
> at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:105)
> ... 8 more
> Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
> at org.wildfly.openssl.SSL.init(SSL.java:87)
> at org.wildfly.openssl.OpenSSLContextSPI.<init>(OpenSSLContextSPI.java:129)
> at org.wildfly.openssl.OpenSSLContextSPI$OpenSSLTLSContextSpi.<init>(OpenSSLContextSPI.java:463)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.security.Provider$Service.newInstance(Provider.java:1595)
> ... 12 more
> Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.wildfly.openssl.SSL.init(SSL.java:82)
> ... 19 more
> Caused by: java.lang.UnsatisfiedLinkError: no wfssl in java.library.path
> at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1871)
> at java.lang.Runtime.loadLibrary0(Runtime.java:871)
> at java.lang.System.loadLibrary(System.java:1124)
> at org.wildfly.openssl.SSL$LibraryLoader.load(SSL.java:288)
> ... 24 more
> {code}
> The issue was fixed by https://github.com/wildfly-security/wildfly-openssl/commit/dfaa7596a040fb... since version 1.0.9.SP03 of wildfly-openssl.
> However Wildfly 19.0.0.Final uses WildFly Core 11.0.0.Final which uses wildfly-openssl 1.0.9.Final without a fix. (current Wildfly Core master uses wildfly-openssl 1.0.10.Final where the fix is present)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFCORE-4904) Remove setting Metaspace
by Moulali Shikalwadi (Jira)
Moulali Shikalwadi created WFCORE-4904:
------------------------------------------
Summary: Remove setting Metaspace
Key: WFCORE-4904
URL: https://issues.redhat.com/browse/WFCORE-4904
Project: WildFly Core
Issue Type: Enhancement
Reporter: Moulali Shikalwadi
Assignee: Moulali Shikalwadi
Unlike perm gen, it is typically not necessary to set a max/min metaspace size[1] for the following reasons:
*Metaspace size is unlimited by default. Since it only holds class metadata, size requirements are minimal.
*It does not require a full gc to resize the metaspace, as it did with the perm generation.
MaxMetaspaceSize includes CompressedClassSpaceSize, so MaxMetaspaceSize should be larger than CompressedClassSpaceSize.
The default MaxMetaspaceSize is 1g:
java -XX:+PrintFlagsFinal -version | grep CompressedClassSpaceSize
uintx CompressedClassSpaceSize = 1073741824
{product}
If MaxMetaspaceSize is set smaller than CompressedClassSpaceSize, the JVM auto adjusts CompressedClassSpaceSize as follows: CompressedClassSpaceSize = MaxMetaspaceSize - (2 * InitialBootClassLoaderMetaspaceSize).[2]
The default EAP Metaspace sizes are less than the default CompressedClassSpaceSize:
-XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m
This adjusts down the MaxMetaspaceSize to 248m:
java -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -XX:+PrintFlagsFinal -version | grep CompressedClassSpaceSize
uintx CompressedClassSpaceSize := 260046848 {product}
We have had a lot of OOME Metaspace cases[3], and support is no longer recommending customers set Metaspace:
"In general, you should not need to set a maximum size, unless you are experiencing large metaspace leaks and would prefer it to fail rather than keep increasing memory size."[1]
This was discussed with the OpenJDK developers[4], and their recommendation was to remove the Metaspace settings, and especially in the context of containers.
References:
[1]https://access.redhat.com/solutions/1489263
[2]https://access.redhat.com/solutions/2132101
[3]https://access.redhat.com/solutions/2038983
[4]http://post-office.corp.redhat.com/archives/support-openjdk/2019-July/m...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months
[JBoss JIRA] (WFLY-13328) Clustering: java.lang.NullPointerException when using HotRod-based distributed session manager and non transactional cache
by Tommasso Borgato (Jira)
[ https://issues.redhat.com/browse/WFLY-13328?page=com.atlassian.jira.plugi... ]
Tommasso Borgato updated WFLY-13328:
------------------------------------
Description:
The error happens in WildFly Clustering tests where WildFly is connected to a JDG Cluster using the HotRod-based distributed session manager and WildFly is using a non transactional cache;
The error is pretty bad because it affects every client call;
Here is the EAP nodes configuration cli script:
{noformat}
embed-server --server-config=standalone-ha.xml
/subsystem=jgroups/channel=ee:write-attribute(name=stack,value=udp)
/subsystem=transactions:write-attribute(name=node-identifier,value=wildfly1)
/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-jdg-server1:add(host=10.16.176.58, port=11222)
/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-jdg-server2:add(host=10.16.176.56, port=11222)
batch
/subsystem=infinispan/remote-cache-container=session_data_cc:add(default-remote-cluster=jdg-server-cluster, module=org.wildfly.clustering.web.hotrod)
/subsystem=infinispan/remote-cache-container=session_data_cc/remote-cluster=jdg-server-cluster:add(socket-bindings=[remote-jdg-server1,remote-jdg-server2])
run-batch
/subsystem=distributable-web/hotrod-session-management=sm_offload:add(remote-cache-container=session_data_cc, granularity=ATTRIBUTE)
/subsystem=distributable-web/hotrod-session-management=sm_offload/affinity=local:add()
/subsystem=distributable-web/hotrod-session-management=sm_offload_granular:add(remote-cache-container=session_data_cc, granularity=ATTRIBUTE)
/subsystem=distributable-web/hotrod-session-management=sm_offload_granular/affinity=local:add()
/subsystem=infinispan/remote-cache-container=session_data_cc/near-cache=invalidation:add(max-entries=1000)
/subsystem=distributable-web:write-attribute(name=default-session-management,value=sm_offload_granular)
{noformat}
The error happens on the client side when trying to retrieve a session attribute from the cache:
{code:java}
SerialBean bean = (SerialBean) session.getAttribute(KEY);
int serial = bean.getSerial(); // bean is null!!!
{code}
The error is:
{noformat}
2020-04-02 12:50:05,189 ERROR [io.undertow.request] (default task-68) UT005023: Exception handling request to /clusterbench/session: java.lang.NullPointerException
at deployment.clusterbench-ee8.ear//org.jboss.test.clusterbench.common.session.CommonHttpSessionServlet.doGet(CommonHttpSessionServlet.java:64)
at javax.servlet.api@2.0.0.Final//javax.servlet.http.HttpServlet.service(HttpServlet.java:503)
at javax.servlet.api@2.0.0.Final//javax.servlet.http.HttpServlet.service(HttpServlet.java:590)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
at io.opentracing.contrib.opentracing-jaxrs2//io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:52)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow@20.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.core@2.0.30.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.core@2.0.30.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.core@2.0.30.Final//io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.core@2.0.30.Final//io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.core@2.0.30.Final//io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.core@2.0.30.Final//io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.core@2.0.30.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow@20.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.core@2.0.30.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow@20.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
at io.undertow.core@2.0.30.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow@20.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow@20.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
at org.wildfly.extension.undertow@20.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
at org.wildfly.extension.undertow@20.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
at org.wildfly.extension.undertow@20.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
at io.undertow.core@2.0.30.Final//io.undertow.server.Connectors.executeRootHandler(Connectors.java:376)
at io.undertow.core@2.0.30.Final//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1348)
at java.base/java.lang.Thread.run(Thread.java:834)
{noformat}
The error disappears when using a transactional cache (see run [eap-7.x-clustering-jdg-session-shutdown-haproxy-hotrod#63|https://eap-qe-...]):
{noformat}
/subsystem=infinispan/remote-cache-container=session_data_cc/component=transaction:add(mode=BATCH)
{noformat}
Complete run here: [eap-7.x-clustering-stress-session-dist-nginx-jdg-hotrod#7|https://eap-qe-...];
Logs attached;
was:
The error happens in WildFly Clustering tests where EAP is connected to a JDG Cluster using the HotRod-based distributed session manager and WildFly is using a non transactional cache;
The error is pretty bad because it affects every client call;
Here is the EAP nodes configuration cli script:
{noformat}
embed-server --server-config=standalone-ha.xml
/subsystem=jgroups/channel=ee:write-attribute(name=stack,value=udp)
/subsystem=transactions:write-attribute(name=node-identifier,value=wildfly1)
/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-jdg-server1:add(host=10.16.176.58, port=11222)
/socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-jdg-server2:add(host=10.16.176.56, port=11222)
batch
/subsystem=infinispan/remote-cache-container=session_data_cc:add(default-remote-cluster=jdg-server-cluster, module=org.wildfly.clustering.web.hotrod)
/subsystem=infinispan/remote-cache-container=session_data_cc/remote-cluster=jdg-server-cluster:add(socket-bindings=[remote-jdg-server1,remote-jdg-server2])
run-batch
/subsystem=distributable-web/hotrod-session-management=sm_offload:add(remote-cache-container=session_data_cc, granularity=ATTRIBUTE)
/subsystem=distributable-web/hotrod-session-management=sm_offload/affinity=local:add()
/subsystem=distributable-web/hotrod-session-management=sm_offload_granular:add(remote-cache-container=session_data_cc, granularity=ATTRIBUTE)
/subsystem=distributable-web/hotrod-session-management=sm_offload_granular/affinity=local:add()
/subsystem=infinispan/remote-cache-container=session_data_cc/near-cache=invalidation:add(max-entries=1000)
/subsystem=distributable-web:write-attribute(name=default-session-management,value=sm_offload_granular)
{noformat}
The error happens on the client side when trying to retrieve a session attribute from the cache:
{code:java}
SerialBean bean = (SerialBean) session.getAttribute(KEY);
int serial = bean.getSerial(); // bean is null!!!
{code}
The error is:
{noformat}
2020-04-02 12:50:05,189 ERROR [io.undertow.request] (default task-68) UT005023: Exception handling request to /clusterbench/session: java.lang.NullPointerException
at deployment.clusterbench-ee8.ear//org.jboss.test.clusterbench.common.session.CommonHttpSessionServlet.doGet(CommonHttpSessionServlet.java:64)
at javax.servlet.api@2.0.0.Final//javax.servlet.http.HttpServlet.service(HttpServlet.java:503)
at javax.servlet.api@2.0.0.Final//javax.servlet.http.HttpServlet.service(HttpServlet.java:590)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
at io.opentracing.contrib.opentracing-jaxrs2//io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:52)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow@20.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.core@2.0.30.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.core@2.0.30.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.core@2.0.30.Final//io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.core@2.0.30.Final//io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.core@2.0.30.Final//io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.core@2.0.30.Final//io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.core@2.0.30.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow@20.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.core@2.0.30.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow@20.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
at io.undertow.core@2.0.30.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow@20.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow@20.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
at org.wildfly.extension.undertow@20.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
at org.wildfly.extension.undertow@20.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
at org.wildfly.extension.undertow@20.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
at io.undertow.core@2.0.30.Final//io.undertow.server.Connectors.executeRootHandler(Connectors.java:376)
at io.undertow.core@2.0.30.Final//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1348)
at java.base/java.lang.Thread.run(Thread.java:834)
{noformat}
The error disappears when using a transactional cache (see run [eap-7.x-clustering-jdg-session-shutdown-haproxy-hotrod#63|https://eap-qe-...]):
{noformat}
/subsystem=infinispan/remote-cache-container=session_data_cc/component=transaction:add(mode=BATCH)
{noformat}
Complete run here: [eap-7.x-clustering-stress-session-dist-nginx-jdg-hotrod#7|https://eap-qe-...];
Logs attached;
> Clustering: java.lang.NullPointerException when using HotRod-based distributed session manager and non transactional cache
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13328
> URL: https://issues.redhat.com/browse/WFLY-13328
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 20.0.0.Beta1
> Reporter: Tommasso Borgato
> Assignee: Paul Ferraro
> Priority: Critical
> Attachments: wlf_20203802-123800-wildfly-service-1-server.zip, wlf_20203802-123800-wildfly-service-2-server.zip, wlf_20203802-123800-wildfly-service-3-server.zip
>
>
> The error happens in WildFly Clustering tests where WildFly is connected to a JDG Cluster using the HotRod-based distributed session manager and WildFly is using a non transactional cache;
> The error is pretty bad because it affects every client call;
> Here is the EAP nodes configuration cli script:
> {noformat}
> embed-server --server-config=standalone-ha.xml
> /subsystem=jgroups/channel=ee:write-attribute(name=stack,value=udp)
> /subsystem=transactions:write-attribute(name=node-identifier,value=wildfly1)
> /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-jdg-server1:add(host=10.16.176.58, port=11222)
> /socket-binding-group=standard-sockets/remote-destination-outbound-socket-binding=remote-jdg-server2:add(host=10.16.176.56, port=11222)
> batch
> /subsystem=infinispan/remote-cache-container=session_data_cc:add(default-remote-cluster=jdg-server-cluster, module=org.wildfly.clustering.web.hotrod)
> /subsystem=infinispan/remote-cache-container=session_data_cc/remote-cluster=jdg-server-cluster:add(socket-bindings=[remote-jdg-server1,remote-jdg-server2])
> run-batch
> /subsystem=distributable-web/hotrod-session-management=sm_offload:add(remote-cache-container=session_data_cc, granularity=ATTRIBUTE)
> /subsystem=distributable-web/hotrod-session-management=sm_offload/affinity=local:add()
> /subsystem=distributable-web/hotrod-session-management=sm_offload_granular:add(remote-cache-container=session_data_cc, granularity=ATTRIBUTE)
> /subsystem=distributable-web/hotrod-session-management=sm_offload_granular/affinity=local:add()
> /subsystem=infinispan/remote-cache-container=session_data_cc/near-cache=invalidation:add(max-entries=1000)
> /subsystem=distributable-web:write-attribute(name=default-session-management,value=sm_offload_granular)
> {noformat}
> The error happens on the client side when trying to retrieve a session attribute from the cache:
> {code:java}
> SerialBean bean = (SerialBean) session.getAttribute(KEY);
> int serial = bean.getSerial(); // bean is null!!!
> {code}
> The error is:
> {noformat}
> 2020-04-02 12:50:05,189 ERROR [io.undertow.request] (default task-68) UT005023: Exception handling request to /clusterbench/session: java.lang.NullPointerException
> at deployment.clusterbench-ee8.ear//org.jboss.test.clusterbench.common.session.CommonHttpSessionServlet.doGet(CommonHttpSessionServlet.java:64)
> at javax.servlet.api@2.0.0.Final//javax.servlet.http.HttpServlet.service(HttpServlet.java:503)
> at javax.servlet.api@2.0.0.Final//javax.servlet.http.HttpServlet.service(HttpServlet.java:590)
> at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at io.opentracing.contrib.opentracing-jaxrs2//io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:52)
> at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow@20.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.core@2.0.30.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)
> at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.core@2.0.30.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.core@2.0.30.Final//io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.core@2.0.30.Final//io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.core@2.0.30.Final//io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.core@2.0.30.Final//io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.core@2.0.30.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow@20.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.core@2.0.30.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow@20.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.core@2.0.30.Final//io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269)
> at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)
> at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)
> at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)
> at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow@20.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow@20.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow@20.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow@20.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at org.wildfly.extension.undertow@20.0.0.Beta1-SNAPSHOT//org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)
> at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)
> at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)
> at io.undertow.servlet@2.0.30.Final//io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
> at io.undertow.core@2.0.30.Final//io.undertow.server.Connectors.executeRootHandler(Connectors.java:376)
> at io.undertow.core@2.0.30.Final//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1348)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
> The error disappears when using a transactional cache (see run [eap-7.x-clustering-jdg-session-shutdown-haproxy-hotrod#63|https://eap-qe-...]):
> {noformat}
> /subsystem=infinispan/remote-cache-container=session_data_cc/component=transaction:add(mode=BATCH)
> {noformat}
> Complete run here: [eap-7.x-clustering-stress-session-dist-nginx-jdg-hotrod#7|https://eap-qe-...];
> Logs attached;
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 3 months