[JBoss JIRA] (WFLY-13439) CVE-2020-6950 jsf-impl: Mojarra: Path traversal via either the loc parameter or the con parameter, incomplete fix of CVE-2018-1437
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFLY-13439?page=com.atlassian.jira.plugi... ]
Farah Juma updated WFLY-13439:
------------------------------
Description:
Path traversal via either the loc parameter or the con parameter, incomplete fix of CVE-2018-14371 https://bugzilla.redhat.com/show_bug.cgi?id=1805006
This was already fixed upstream:
https://github.com/eclipse-ee4j/mojarra/commit/1b434748d9239f42eae8aa7d37...
https://github.com/eclipse-ee4j/mojarra/commit/cefbb9447e7be560e59da2da6b...
was:
Security Tracking Issue
Do not make this issue public.
Impact: Moderate
Public Date: 20-Feb-2020
Resolve Bug By: 19-Feb-2021
In case the dates above are already past, please evaluate this bug in your next prioritization review and make a decision then. Remember to explicitly set CLOSED:WONTFIX if you decide not to fix this bug.
Please see the Security Errata Policy for further details: https://docs.engineering.redhat.com/x/9RBqB
Flaw:
-----
CVE-2020-6950 Mojarra: Path traversal via either the loc parameter or the con parameter, incomplete fix of CVE-2018-14371
https://bugzilla.redhat.com/show_bug.cgi?id=1805006
Eclipse Mojarra before version 2.3.14 is vulnerable to a path traversal flaw via either the loc parameter or the con parameter. An attacker could exploit this to read arbitrary files. It was reported as CVE-2019-0199, but it was an incomplete fix.
Upstream Patch:
https://github.com/eclipse-ee4j/mojarra/commit/1b434748d9239f42eae8aa7d37...
https://github.com/eclipse-ee4j/mojarra/commit/cefbb9447e7be560e59da2da6b...
> CVE-2020-6950 jsf-impl: Mojarra: Path traversal via either the loc parameter or the con parameter, incomplete fix of CVE-2018-1437
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13439
> URL: https://issues.redhat.com/browse/WFLY-13439
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Reporter: Farah Juma
> Assignee: Farah Juma
> Priority: Minor
> Labels: CVE-2020-6950, Security, SecurityTracking, pscomponent:jsf-impl
>
> Path traversal via either the loc parameter or the con parameter, incomplete fix of CVE-2018-14371 https://bugzilla.redhat.com/show_bug.cgi?id=1805006
> This was already fixed upstream:
> https://github.com/eclipse-ee4j/mojarra/commit/1b434748d9239f42eae8aa7d37...
> https://github.com/eclipse-ee4j/mojarra/commit/cefbb9447e7be560e59da2da6b...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13439) CVE-2020-6950 jsf-impl: Mojarra: Path traversal via either the loc parameter or the con parameter, incomplete fix of CVE-2018-1437
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFLY-13439?page=com.atlassian.jira.plugi... ]
Farah Juma updated WFLY-13439:
------------------------------
Summary: CVE-2020-6950 jsf-impl: Mojarra: Path traversal via either the loc parameter or the con parameter, incomplete fix of CVE-2018-1437 (was: CVE-2020-6950 jsf-impl: Mojarra: Path traversal via either the loc parameter or the con parameter, incomplete fix of CVE-2018-14371 [eap-7.3.z])
> CVE-2020-6950 jsf-impl: Mojarra: Path traversal via either the loc parameter or the con parameter, incomplete fix of CVE-2018-1437
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-13439
> URL: https://issues.redhat.com/browse/WFLY-13439
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Reporter: Farah Juma
> Assignee: Farah Juma
> Priority: Minor
> Labels: CVE-2020-6950, Security, SecurityTracking, pscomponent:jsf-impl
>
> Security Tracking Issue
> Do not make this issue public.
> Impact: Moderate
> Public Date: 20-Feb-2020
> Resolve Bug By: 19-Feb-2021
> In case the dates above are already past, please evaluate this bug in your next prioritization review and make a decision then. Remember to explicitly set CLOSED:WONTFIX if you decide not to fix this bug.
> Please see the Security Errata Policy for further details: https://docs.engineering.redhat.com/x/9RBqB
> Flaw:
> -----
> CVE-2020-6950 Mojarra: Path traversal via either the loc parameter or the con parameter, incomplete fix of CVE-2018-14371
> https://bugzilla.redhat.com/show_bug.cgi?id=1805006
> Eclipse Mojarra before version 2.3.14 is vulnerable to a path traversal flaw via either the loc parameter or the con parameter. An attacker could exploit this to read arbitrary files. It was reported as CVE-2019-0199, but it was an incomplete fix.
> Upstream Patch:
> https://github.com/eclipse-ee4j/mojarra/commit/1b434748d9239f42eae8aa7d37...
> https://github.com/eclipse-ee4j/mojarra/commit/cefbb9447e7be560e59da2da6b...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-11566) ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
by Tomasz Adamski (Jira)
[ https://issues.redhat.com/browse/WFLY-11566?page=com.atlassian.jira.plugi... ]
Tomasz Adamski edited comment on WFLY-11566 at 5/7/20 1:07 PM:
---------------------------------------------------------------
[~gaol] We don't need jboss-classfilewriter upgrade but update to WildFly (https://github.com/wildfly/wildfly/pull/13181) is still necessary for this issue to be fixed.
was (Author: tomekadamski):
[~gaol] We don't need classfile-writer upgrade but update to WildFly (https://github.com/wildfly/wildfly/pull/13181) is still necessary for this issue to be fixed.
> ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
> ----------------------------------------------------------------------------------
>
> Key: WFLY-11566
> URL: https://issues.redhat.com/browse/WFLY-11566
> Project: WildFly
> Issue Type: Bug
> Components: Bean Validation, EJB, REST
> Affects Versions: 14.0.0.Final, 15.0.1.Final
> Reporter: Alexander Wagner
> Assignee: Tomasz Adamski
> Priority: Critical
> Labels: downstream_dependency
> Attachments: WFLY-11566-3.tar
>
>
> You got an exception if you call methods on JAX-RS endpoints which are also e.g. a stateless EJB and have Set or List as query parameters.
> As a workaround we use the "@Context UriInfo info" as parameter an read the parameter manually. As a downside this parameters are missing than in automated api generation with e.g. swagger. Without the @NotEmpty annotation it works fine. Without the generic type parameter ie just List it works fine. Making it a simple CDI bean makes it work fine.
> This issue is caused by [commit - WFLY-9628 Allow to switch to Hibernate Validator 6.0 / Bean Validation 2.0|https://github.com/wildfly/wildfly/commit/02f230d91f55f86ee6cadf53832...]
> Steps to reproduce:
> {code:java}
> @Stateless
> @Path("/")
> public class Resource {
> @POST
> @Path("put/list")
> @Consumes(MediaType.APPLICATION_JSON)
> public String putList(@NotEmpty List<String> a) {
> return "Hello bars " + a.stream().collect(Collectors.joining(", "));
> }
> }
> {code}
> {noformat}
> [mkopecky@dhcp-10-40-5-71 bin]$ curl -d '["a","b","c"]' -H "Content-Type: application/json" -X POST http://localhost:8080/jaxrs-wf/put/list
> javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List).
> [mkopecky@dhcp-10-40-5-71 bin]$
> {noformat}
> {noformat}
> javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List).
> at org.hibernate.validator.internal.metadata.aggregated.rule.OverridingMethodMustNotAlterParameterConstraints.apply(OverridingMethodMustNotAlterParameterConstraints.java:24)
> at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.assertCorrectnessOfConfiguration(ExecutableMetaData.java:461)
> at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.build(ExecutableMetaData.java:377)
> at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BuilderDelegate.build(BeanMetaDataImpl.java:788)
> at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BeanMetaDataBuilder.build(BeanMetaDataImpl.java:648)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.createBeanMetaData(BeanMetaDataManager.java:192)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.lambda$getBeanMetaData$0(BeanMetaDataManager.java:160)
> at java.util.concurrent.ConcurrentMap.computeIfAbsent(ConcurrentMap.java:324)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.getBeanMetaData(BeanMetaDataManager.java:159)
> at org.hibernate.validator.internal.engine.ValidationContext$ValidationContextBuilder.forValidateParameters(ValidationContext.java:619)
> at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:254)
> at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:224)
> at org.jboss.resteasy.plugins.validation.GeneralValidatorImpl.validateAllParameters(GeneralValidatorImpl.java:177)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:118)
> at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
> at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:439)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:229)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:135)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
> at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:138)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:215)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:55)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Links:
> * [forum|https://developer.jboss.org/thread/278822]
> * WFLY-11566
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-11566) ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
by Tomasz Adamski (Jira)
[ https://issues.redhat.com/browse/WFLY-11566?page=com.atlassian.jira.plugi... ]
Tomasz Adamski commented on WFLY-11566:
---------------------------------------
[~gaol] We don't need classfile-writer upgrade but update to WildFly (https://github.com/wildfly/wildfly/pull/13181) is still necessary for this issue to be fixed.
> ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
> ----------------------------------------------------------------------------------
>
> Key: WFLY-11566
> URL: https://issues.redhat.com/browse/WFLY-11566
> Project: WildFly
> Issue Type: Bug
> Components: Bean Validation, EJB, REST
> Affects Versions: 14.0.0.Final, 15.0.1.Final
> Reporter: Alexander Wagner
> Assignee: Tomasz Adamski
> Priority: Critical
> Labels: downstream_dependency
> Attachments: WFLY-11566-3.tar
>
>
> You got an exception if you call methods on JAX-RS endpoints which are also e.g. a stateless EJB and have Set or List as query parameters.
> As a workaround we use the "@Context UriInfo info" as parameter an read the parameter manually. As a downside this parameters are missing than in automated api generation with e.g. swagger. Without the @NotEmpty annotation it works fine. Without the generic type parameter ie just List it works fine. Making it a simple CDI bean makes it work fine.
> This issue is caused by [commit - WFLY-9628 Allow to switch to Hibernate Validator 6.0 / Bean Validation 2.0|https://github.com/wildfly/wildfly/commit/02f230d91f55f86ee6cadf53832...]
> Steps to reproduce:
> {code:java}
> @Stateless
> @Path("/")
> public class Resource {
> @POST
> @Path("put/list")
> @Consumes(MediaType.APPLICATION_JSON)
> public String putList(@NotEmpty List<String> a) {
> return "Hello bars " + a.stream().collect(Collectors.joining(", "));
> }
> }
> {code}
> {noformat}
> [mkopecky@dhcp-10-40-5-71 bin]$ curl -d '["a","b","c"]' -H "Content-Type: application/json" -X POST http://localhost:8080/jaxrs-wf/put/list
> javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List).
> [mkopecky@dhcp-10-40-5-71 bin]$
> {noformat}
> {noformat}
> javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List).
> at org.hibernate.validator.internal.metadata.aggregated.rule.OverridingMethodMustNotAlterParameterConstraints.apply(OverridingMethodMustNotAlterParameterConstraints.java:24)
> at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.assertCorrectnessOfConfiguration(ExecutableMetaData.java:461)
> at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.build(ExecutableMetaData.java:377)
> at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BuilderDelegate.build(BeanMetaDataImpl.java:788)
> at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BeanMetaDataBuilder.build(BeanMetaDataImpl.java:648)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.createBeanMetaData(BeanMetaDataManager.java:192)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.lambda$getBeanMetaData$0(BeanMetaDataManager.java:160)
> at java.util.concurrent.ConcurrentMap.computeIfAbsent(ConcurrentMap.java:324)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.getBeanMetaData(BeanMetaDataManager.java:159)
> at org.hibernate.validator.internal.engine.ValidationContext$ValidationContextBuilder.forValidateParameters(ValidationContext.java:619)
> at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:254)
> at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:224)
> at org.jboss.resteasy.plugins.validation.GeneralValidatorImpl.validateAllParameters(GeneralValidatorImpl.java:177)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:118)
> at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
> at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:439)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:229)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:135)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
> at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:138)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:215)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:55)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Links:
> * [forum|https://developer.jboss.org/thread/278822]
> * WFLY-11566
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13438) Database Timers: instances sporadically fail to start in a cluster
by Marcos Scholtz (Jira)
[ https://issues.redhat.com/browse/WFLY-13438?page=com.atlassian.jira.plugi... ]
Marcos Scholtz updated WFLY-13438:
----------------------------------
Summary: Database Timers: instances sporadically fail to start in a cluster (was: Database Timers: instances sporadically hang up when starting in a cluster)
> Database Timers: instances sporadically fail to start in a cluster
> ------------------------------------------------------------------
>
> Key: WFLY-13438
> URL: https://issues.redhat.com/browse/WFLY-13438
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 19.1.0.Final
> Reporter: Marcos Scholtz
> Assignee: Brian Stansberry
> Priority: Major
>
> We use a postgresql database for persistent timers, to control the execution of scheduled tasks in a cluster. It mainly works, but when operating in a cluster and when a server-group is restarted, sometimes individual instances in the cluster fail to start because of an error when reinstating persistent timers.
> Configuration of the Datasource:
> {code}
> <xa-datasource jndi-name="java:/datasources/MonitoringDS" pool-name="MonitoringDS" enabled="true">
> <xa-datasource-property name="ServerName">
> appserver.local
> </xa-datasource-property>
> <xa-datasource-property name="PortNumber">
> 5432
> </xa-datasource-property>
> <xa-datasource-property name="DatabaseName">
> monitoringdb
> </xa-datasource-property>
> <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
> <driver>postgresql</driver>
> <security>
> <user-name>xxx</user-name>
> <password>xxx</password>
> </security>
> </xa-datasource>
> {code}
> Configuration of the timer service:
> {code}
> <timer-service thread-pool-name="default" default-data-store="batch-clustered-store">
> <data-stores>
> <file-data-store name="default-file-store" path="timer-service-data" relative-to="jboss.server.data.dir"/>
> <database-data-store name="batch-clustered-store" datasource-jndi-name="java:/datasources/MonitoringDS" database="'postgresql'" partition="${batch.partition}" refresh-interval="60000" allow-execution="true"/>
> </data-stores>
> </timer-service>
> {code}
> Note we use a system-property on the server-group to determine the partition name.
> Also, we made NO changes to the SQL statements in "timer-sql.properties".
> The timer is generated by a `@Schedule` annotation in an EJB like this:
> {code}
> @Schedule(
> dayOfMonth = "${manual.scheduler.dayofmonth:*}",
> dayOfWeek = "${manual.scheduler.dayofweek:*}",
> hour = "${manual.scheduler.hour:2/6}",
> minute = "${manual.scheduler.minute:2}"
> )
> @TransactionAttribute(TransactionAttributeType.NEVER)
> void doPostboxImport() {
> log.info("Starting Postbox Import");
> BatchRuntime.getJobOperator().start("PostboxImportBatchlet", null);
> }
> {code}
> The error we sporadically get when starting more than one instance at the same time (when all instances try to reinstate timers) is like this:
> {code}
> 14:48:28,117 WARN [com.arjuna.ats.arjuna] (ServerService Thread Pool -- 69) {"tenant": "", "clientId": ""} ARJUNA012078: Abort called illegaly on atomic action 0:ffff7f000001:-27f2652e:5eb2b20f:f
> 14:48:28,118 WARN [org.jboss.as.ejb3.timer] (ServerService Thread Pool -- 69) {"tenant": "", "clientId": ""} WFLYEJB0161: Failed to reinstate timer 'postbox-integration-service.postbox-integration-service.PostboxImport' (id=unavailable) from its persistent state: javax.transaction.NotSupportedException: WFTXN0001: A transaction is already in progress
> at org.wildfly.transaction.client@1.1.9.Final//org.wildfly.transaction.client.ContextTransactionManager.begin(ContextTransactionManager.java:60)
> at org.wildfly.transaction.client@1.1.9.Final//org.wildfly.transaction.client.ContextTransactionManager.begin(ContextTransactionManager.java:54)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.getActivePersistentTimers(TimerServiceImpl.java:984)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.restoreTimers(TimerServiceImpl.java:712)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.activate(TimerServiceImpl.java:223)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.component.EJBComponent.init(EJBComponent.java:595)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.component.stateless.StatelessSessionComponent.init(StatelessSessionComponent.java:110)
> at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.BasicComponent.start(BasicComponent.java:222)
> at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> 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:1377)
> at java.base/java.lang.Thread.run(Thread.java:834)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485)
> 14:48:28,153 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 69) {"tenant": "", "clientId": ""} MSC000001: Failed to start service jboss.deployment.unit."postbox-integration-service-E-SNAPSHOT.war".component.PostboxImport.START: org.jboss.msc.service.StartException in service jboss.deployment.unit."postbox-integration-service-E-SNAPSHOT.war".component.PostboxImport.START: java.lang.RuntimeException: java.lang.NullPointerException
> at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> 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:1377)
> at java.base/java.lang.Thread.run(Thread.java:834)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: java.lang.RuntimeException: java.lang.NullPointerException
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.persistTimer(TimerServiceImpl.java:626)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.createCalendarTimer(TimerServiceImpl.java:537)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.loadAutoTimer(TimerServiceImpl.java:388)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.restoreTimers(TimerServiceImpl.java:774)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.activate(TimerServiceImpl.java:223)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.component.EJBComponent.init(EJBComponent.java:595)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.component.stateless.StatelessSessionComponent.init(StatelessSessionComponent.java:110)
> at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.BasicComponent.start(BasicComponent.java:222)
> at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> ... 8 more
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.addTimer(DatabaseTimerPersistence.java:336)
> at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.persistTimer(TimerServiceImpl.java:607)
> ... 16 more
> {code}
> The error seems similar to the one described in WFLY-13386, but the stack trace and the steps to reproduce it seem different to me, so I'm not sure if it's the same problem. The problem also existed in Wildfly 14 , we just updated to 19.1 (also hoping that his error would be corrected).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (WFLY-13438) Database Timers: instances sporadically hang up when starting in a cluster
by Marcos Scholtz (Jira)
Marcos Scholtz created WFLY-13438:
-------------------------------------
Summary: Database Timers: instances sporadically hang up when starting in a cluster
Key: WFLY-13438
URL: https://issues.redhat.com/browse/WFLY-13438
Project: WildFly
Issue Type: Bug
Affects Versions: 19.1.0.Final
Reporter: Marcos Scholtz
Assignee: Brian Stansberry
We use a postgresql database for persistent timers, to control the execution of scheduled tasks in a cluster. It mainly works, but when operating in a cluster and when a server-group is restarted, sometimes individual instances in the cluster fail to start because of an error when reinstating persistent timers.
Configuration of the Datasource:
{code}
<xa-datasource jndi-name="java:/datasources/MonitoringDS" pool-name="MonitoringDS" enabled="true">
<xa-datasource-property name="ServerName">
appserver.local
</xa-datasource-property>
<xa-datasource-property name="PortNumber">
5432
</xa-datasource-property>
<xa-datasource-property name="DatabaseName">
monitoringdb
</xa-datasource-property>
<xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
<driver>postgresql</driver>
<security>
<user-name>xxx</user-name>
<password>xxx</password>
</security>
</xa-datasource>
{code}
Configuration of the timer service:
{code}
<timer-service thread-pool-name="default" default-data-store="batch-clustered-store">
<data-stores>
<file-data-store name="default-file-store" path="timer-service-data" relative-to="jboss.server.data.dir"/>
<database-data-store name="batch-clustered-store" datasource-jndi-name="java:/datasources/MonitoringDS" database="'postgresql'" partition="${batch.partition}" refresh-interval="60000" allow-execution="true"/>
</data-stores>
</timer-service>
{code}
Note we use a system-property on the server-group to determine the partition name.
Also, we made NO changes to the SQL statements in "timer-sql.properties".
The timer is generated by a `@Schedule` annotation in an EJB like this:
{code}
@Schedule(
dayOfMonth = "${manual.scheduler.dayofmonth:*}",
dayOfWeek = "${manual.scheduler.dayofweek:*}",
hour = "${manual.scheduler.hour:2/6}",
minute = "${manual.scheduler.minute:2}"
)
@TransactionAttribute(TransactionAttributeType.NEVER)
void doPostboxImport() {
log.info("Starting Postbox Import");
BatchRuntime.getJobOperator().start("PostboxImportBatchlet", null);
}
{code}
The error we sporadically get when starting more than one instance at the same time (when all instances try to reinstate timers) is like this:
{code}
14:48:28,117 WARN [com.arjuna.ats.arjuna] (ServerService Thread Pool -- 69) {"tenant": "", "clientId": ""} ARJUNA012078: Abort called illegaly on atomic action 0:ffff7f000001:-27f2652e:5eb2b20f:f
14:48:28,118 WARN [org.jboss.as.ejb3.timer] (ServerService Thread Pool -- 69) {"tenant": "", "clientId": ""} WFLYEJB0161: Failed to reinstate timer 'postbox-integration-service.postbox-integration-service.PostboxImport' (id=unavailable) from its persistent state: javax.transaction.NotSupportedException: WFTXN0001: A transaction is already in progress
at org.wildfly.transaction.client@1.1.9.Final//org.wildfly.transaction.client.ContextTransactionManager.begin(ContextTransactionManager.java:60)
at org.wildfly.transaction.client@1.1.9.Final//org.wildfly.transaction.client.ContextTransactionManager.begin(ContextTransactionManager.java:54)
at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.getActivePersistentTimers(TimerServiceImpl.java:984)
at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.restoreTimers(TimerServiceImpl.java:712)
at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.activate(TimerServiceImpl.java:223)
at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.component.EJBComponent.init(EJBComponent.java:595)
at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.component.stateless.StatelessSessionComponent.init(StatelessSessionComponent.java:110)
at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.BasicComponent.start(BasicComponent.java:222)
at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
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:1377)
at java.base/java.lang.Thread.run(Thread.java:834)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485)
14:48:28,153 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 69) {"tenant": "", "clientId": ""} MSC000001: Failed to start service jboss.deployment.unit."postbox-integration-service-E-SNAPSHOT.war".component.PostboxImport.START: org.jboss.msc.service.StartException in service jboss.deployment.unit."postbox-integration-service-E-SNAPSHOT.war".component.PostboxImport.START: java.lang.RuntimeException: java.lang.NullPointerException
at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
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:1377)
at java.base/java.lang.Thread.run(Thread.java:834)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485)
Caused by: java.lang.RuntimeException: java.lang.NullPointerException
at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.persistTimer(TimerServiceImpl.java:626)
at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.createCalendarTimer(TimerServiceImpl.java:537)
at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.loadAutoTimer(TimerServiceImpl.java:388)
at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.restoreTimers(TimerServiceImpl.java:774)
at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.activate(TimerServiceImpl.java:223)
at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.component.EJBComponent.init(EJBComponent.java:595)
at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.component.stateless.StatelessSessionComponent.init(StatelessSessionComponent.java:110)
at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.BasicComponent.start(BasicComponent.java:222)
at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
... 8 more
Caused by: java.lang.NullPointerException
at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.addTimer(DatabaseTimerPersistence.java:336)
at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.timerservice.TimerServiceImpl.persistTimer(TimerServiceImpl.java:607)
... 16 more
{code}
The error seems similar to the one described in WFLY-13386, but the stack trace and the steps to reproduce it seem different to me, so I'm not sure if it's the same problem. The problem also existed in Wildfly 14 , we just updated to 19.1 (also hoping that his error would be corrected).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (JGRP-2474) Messages about dropped queued message when using IpAddressUUID
by Mirko Streckenbach (Jira)
[ https://issues.redhat.com/browse/JGRP-2474?page=com.atlassian.jira.plugin... ]
Mirko Streckenbach commented on JGRP-2474:
------------------------------------------
I just mentioned that in the last paragraph (no separate issue). I was unsure if this is really an issue, it is just something I observed.
This is as following (slight modified version of the attached program with UUID addresses).
1. First channel is created and becomes coordinator
2. Second channel is created and used connect()
3. viewAccepted is called for both with a view with both channnels
4. After a few desconds, disconnect() is called on the second channel calls disconnect()
5. viewAccepted for the first channel is called with a new view with only the first channels
6. disconnect() returns
After that, the coordinator still tries to send messages to the second channel. I have several messages in the log of the first channel:
FINER: i1:1609 --> i2:1709: resending(#2)
Mai 07, 2020 6:02:21 PM org.jgroups.protocols.TP down
FINER: i1:1609: sending msg to i2:1709, src=i1:1609, headers are GMS: GmsHeader[LEAVE_RSP], UNICAST3: DATA, seqno=2, TP: [cluster=cluster]
Mai 07, 2020 6:02:21 PM org.jgroups.protocols.UNICAST3 retransmit
This goes on for some time.
With 4.1.2 this did not happen. After the disconect() of the second channel, there were no further messages send. Starting with 4.1.3 these retransmits occur.
I've attached the modified program (JGR2.java) and the output (log2.txt)
> Messages about dropped queued message when using IpAddressUUID
> --------------------------------------------------------------
>
> Key: JGRP-2474
> URL: https://issues.redhat.com/browse/JGRP-2474
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.2.3
> Reporter: Mirko Streckenbach
> Assignee: Bela Ban
> Priority: Major
> Attachments: JGR.java, JGR2.java, log-fail-1.txt, log2.txt
>
>
> We upgraded from 4.0.14 to 4.1.8 and ever since then, we had some messages like
> {code}
> Apr 27, 2020 10:30:54 AM org.jgroups.protocols.UNICAST3 addQueuedMessages
> WARNING: i2:1709: dropped queued message i1:1609#2 as its conn_id (0) did not match (entry.conn_id=1)
> {code}
> when ever an application is restarted. Our setup is as follows (most due to network restrictions):
> * Fixed port numbers
> * JDBC_PING
> * We use IpAddressUUID in order to have a "readable" information in the jgroupsping table
> I could track this down to 4.1.2 / 4.1.3: 4.1.2 works as expected, from 4.1.3 I'm seeing the effect observed above.
> I attached a simple example that demonstrates the problem: starts two stacks, shuts down the second (non-coordindator) and starts it again after a couple of seconds. With 4.1.2 this works as expected (no warnings), but 4.1.3 and more recent versions (including 4.2.3) produce warnings. The exact behavior is not completely consistent: in most cases, starting the second app again results in some timeouts and the second app becomes a coordinator itself and a merge view is established later (log attached). In some cases it only creates the warnings shown above (this is what we observe in our real application) and in some cases everything works fine.
> I don't have any warnings in the log if I don't set an AddressGenerator, but I'd like to avoid this.
> While running this on higher debug levels, I observed the following: 4.1.2 will not require an
> ACK for the LEAVE_RSP message. 4.1.3 will. The second app sends the ACK, but the coordinator does not seem to receive or process it properly and retransmits the LEAVE_RSP message again and again. This is independent of the AddressGenerator used,
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months
[JBoss JIRA] (JGRP-2474) Messages about dropped queued message when using IpAddressUUID
by Mirko Streckenbach (Jira)
[ https://issues.redhat.com/browse/JGRP-2474?page=com.atlassian.jira.plugin... ]
Mirko Streckenbach updated JGRP-2474:
-------------------------------------
Attachment: JGR2.java
> Messages about dropped queued message when using IpAddressUUID
> --------------------------------------------------------------
>
> Key: JGRP-2474
> URL: https://issues.redhat.com/browse/JGRP-2474
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.2.3
> Reporter: Mirko Streckenbach
> Assignee: Bela Ban
> Priority: Major
> Attachments: JGR.java, JGR2.java, log-fail-1.txt, log2.txt
>
>
> We upgraded from 4.0.14 to 4.1.8 and ever since then, we had some messages like
> {code}
> Apr 27, 2020 10:30:54 AM org.jgroups.protocols.UNICAST3 addQueuedMessages
> WARNING: i2:1709: dropped queued message i1:1609#2 as its conn_id (0) did not match (entry.conn_id=1)
> {code}
> when ever an application is restarted. Our setup is as follows (most due to network restrictions):
> * Fixed port numbers
> * JDBC_PING
> * We use IpAddressUUID in order to have a "readable" information in the jgroupsping table
> I could track this down to 4.1.2 / 4.1.3: 4.1.2 works as expected, from 4.1.3 I'm seeing the effect observed above.
> I attached a simple example that demonstrates the problem: starts two stacks, shuts down the second (non-coordindator) and starts it again after a couple of seconds. With 4.1.2 this works as expected (no warnings), but 4.1.3 and more recent versions (including 4.2.3) produce warnings. The exact behavior is not completely consistent: in most cases, starting the second app again results in some timeouts and the second app becomes a coordinator itself and a merge view is established later (log attached). In some cases it only creates the warnings shown above (this is what we observe in our real application) and in some cases everything works fine.
> I don't have any warnings in the log if I don't set an AddressGenerator, but I'd like to avoid this.
> While running this on higher debug levels, I observed the following: 4.1.2 will not require an
> ACK for the LEAVE_RSP message. 4.1.3 will. The second app sends the ACK, but the coordinator does not seem to receive or process it properly and retransmits the LEAVE_RSP message again and again. This is independent of the AddressGenerator used,
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 2 months