[JBoss JIRA] (DROOLS-100) DRL compiler accepts rules extending non-existing rules
by Mark Proctor (JIRA)
[ https://issues.jboss.org/browse/DROOLS-100?page=com.atlassian.jira.plugin... ]
Mark Proctor reassigned DROOLS-100:
-----------------------------------
Assignee: Mark Proctor (was: Mario Fusco)
> DRL compiler accepts rules extending non-existing rules
> -------------------------------------------------------
>
> Key: DROOLS-100
> URL: https://issues.jboss.org/browse/DROOLS-100
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final, 6.0.0.Alpha9
> Reporter: Davide Sottara
> Assignee: Mark Proctor
> Fix For: 5.5.1.Final, 6.0.0.Beta2
>
>
> rule "X" extends "Y"
> is accepted even if no rule "Y" is available. "X" will be created with local conditions and actions only.
> This is extremely dangerous and very difficult to debug in two cases:
> - rule "Y" exists but is in a different package (not supported)
> - rule "Y*" exists and "Y" is a spelling mistake
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (WFLY-1629) LSB init script for Debian based distros
by Jorge Solorzano (JIRA)
[ https://issues.jboss.org/browse/WFLY-1629?page=com.atlassian.jira.plugin.... ]
Jorge Solorzano updated WFLY-1629:
----------------------------------
Affects Version/s: 8.0.0.Alpha3
> LSB init script for Debian based distros
> ----------------------------------------
>
> Key: WFLY-1629
> URL: https://issues.jboss.org/browse/WFLY-1629
> Project: WildFly
> Issue Type: Enhancement
> Components: Scripts
> Affects Versions: 8.0.0.Alpha1, 8.0.0.Alpha2, 8.0.0.Alpha3
> Environment: Debian/Ubuntu based
> Reporter: Jorge Solorzano
> Assignee: Brian Stansberry
> Priority: Minor
> Labels: Debian,, Ubuntu, init.d
>
> init.d scripts provided by WildFly are designed for RedHat/Fedora, and it should provide a script that works well in Debian/Ubuntu based distributions.
> I could provide a LSB-compliant init script with all the features required for a complete startup script.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (WFLY-1678) Unable to load Validation support on application redeploy
by Ron Sigal (JIRA)
[ https://issues.jboss.org/browse/WFLY-1678?page=com.atlassian.jira.plugin.... ]
Ron Sigal updated WFLY-1678:
----------------------------
Attachment: server.log
> Unable to load Validation support on application redeploy
> ---------------------------------------------------------
>
> Key: WFLY-1678
> URL: https://issues.jboss.org/browse/WFLY-1678
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, REST
> Affects Versions: 8.0.0.Alpha2
> Reporter: Tomaz Cerar
> Assignee: Ron Sigal
> Fix For: 8.0.0.Beta1
>
> Attachments: server.log, server.log
>
>
> take kitchensink-ear application from quick starts
> http://www.jboss.org/jdf/quickstarts/jboss-as-quickstart/kitchensink-ear/
> after building
> run jboss-as:deploy to deploy app --> everything works
> then undeploy it with jboss-as:undeploy --> all ok
> then deploy it again jboss-as:deploy.
> this deploy will fail with
> {noformat}
> 22:51:52,682 WARN [org.jboss.resteasy.plugins.validation.ValidatorContextResolver] (MSC service thread 1-12) Unable to load Validation support: org.jboss.weld.exceptions.IllegalArgumentException: WELD-001456 Argument resolvedBean
> must not be null
> at org.jboss.weld.util.Preconditions.checkArgumentNotNull(Preconditions.java:40) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:770) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.injection.ParameterInjectionPointImpl.getValueToInject(ParameterInjectionPointImpl.java:76) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.injection.ConstructorInjectionPoint.getParameterValues(ConstructorInjectionPoint.java:138) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.injection.ConstructorInjectionPoint.newInstance(ConstructorInjectionPoint.java:68) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.injection.producer.AbstractInstantiator.newInstance(AbstractInstantiator.java:28) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.injection.producer.BasicInjectionTarget.produce(BasicInjectionTarget.java:86) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.injection.producer.BeanInjectionTarget.produce(BeanInjectionTarget.java:173) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.hibernate.validator.internal.cdi.DestructibleBeanInstance.createAndInjectBeans(DestructibleBeanInstance.java:53) [hibernate-validator-cdi-5.0.1.Final.jar:5.0.1.Final]
> at org.hibernate.validator.internal.cdi.DestructibleBeanInstance.<init>(DestructibleBeanInstance.java:33) [hibernate-validator-cdi-5.0.1.Final.jar:5.0.1.Final]
> at org.hibernate.validator.internal.cdi.ValidatorFactoryBean.createInstance(ValidatorFactoryBean.java:205) [hibernate-validator-cdi-5.0.1.Final.jar:5.0.1.Final]
> at org.hibernate.validator.internal.cdi.ValidatorFactoryBean.createConstraintValidatorFactory(ValidatorFactoryBean.java:191) [hibernate-validator-cdi-5.0.1.Final.jar:5.0.1.Final]
> at org.hibernate.validator.internal.cdi.ValidatorFactoryBean.create(ValidatorFactoryBean.java:118) [hibernate-validator-cdi-5.0.1.Final.jar:5.0.1.Final]
> at org.hibernate.validator.internal.cdi.ValidatorFactoryBean.create(ValidatorFactoryBean.java:47) [hibernate-validator-cdi-5.0.1.Final.jar:5.0.1.Final]
> at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:103) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:93) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.proxies.ValidatorFactory$618047133$Proxy$_$$_WeldClientProxy.getValidator(Unknown Source)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.getValidator(LazyValidatorFactory.java:83)
> at org.jboss.resteasy.plugins.validation.ValidatorContextResolver.getContext(ValidatorContextResolver.java:72) [resteasy-validator-provider-11-3.0.1.Final.jar:]
> at org.jboss.resteasy.plugins.validation.ValidatorContextResolver.getContext(ValidatorContextResolver.java:30) [resteasy-validator-provider-11-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodInvoker.<init>(ResourceMethodInvoker.java:110) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodRegistry.processMethod(ResourceMethodRegistry.java:280) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodRegistry.register(ResourceMethodRegistry.java:251) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:221) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:193) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:179) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:156) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodRegistry.addPerRequestResource(ResourceMethodRegistry.java:75) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.spi.ResteasyDeployment.registration(ResteasyDeployment.java:400) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:241) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) [resteasy-jaxrs-3.0.1.Final.jar:]
> at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:198) [undertow-servlet-1.0.0.Beta1.jar:1.0.0.Beta1]
> at io.undertow.servlet.core.ManagedServlet.start(ManagedServlet.java:107) [undertow-servlet-1.0.0.Beta1.jar:1.0.0.Beta1]
> at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:390) [undertow-servlet-1.0.0.Beta1.jar:1.0.0.Beta1]
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:83)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:70)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> {noformat}
> I have also noticed that this will also fail if there was some other app previously deployed that also used similar technology stacks
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (WFLY-1678) Unable to load Validation support on application redeploy
by Ron Sigal (JIRA)
[ https://issues.jboss.org/browse/WFLY-1678?page=com.atlassian.jira.plugin.... ]
Ron Sigal commented on WFLY-1678:
---------------------------------
Ok, I ran the quickstart with a vanilla wildfly-8.0.0.Alpha3 and got the same problem. Then I unzipped resteasy-jboss-modules-wf8-3.0.2.Final.zip in modules/system/layers/base and the problem went away. I.e., I deployed, ran the app, undeployed, deployed, ran the app, and undeployed.
I'll attach a new server.log.
> Unable to load Validation support on application redeploy
> ---------------------------------------------------------
>
> Key: WFLY-1678
> URL: https://issues.jboss.org/browse/WFLY-1678
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, REST
> Affects Versions: 8.0.0.Alpha2
> Reporter: Tomaz Cerar
> Assignee: Ron Sigal
> Fix For: 8.0.0.Beta1
>
> Attachments: server.log, server.log
>
>
> take kitchensink-ear application from quick starts
> http://www.jboss.org/jdf/quickstarts/jboss-as-quickstart/kitchensink-ear/
> after building
> run jboss-as:deploy to deploy app --> everything works
> then undeploy it with jboss-as:undeploy --> all ok
> then deploy it again jboss-as:deploy.
> this deploy will fail with
> {noformat}
> 22:51:52,682 WARN [org.jboss.resteasy.plugins.validation.ValidatorContextResolver] (MSC service thread 1-12) Unable to load Validation support: org.jboss.weld.exceptions.IllegalArgumentException: WELD-001456 Argument resolvedBean
> must not be null
> at org.jboss.weld.util.Preconditions.checkArgumentNotNull(Preconditions.java:40) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:770) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.injection.ParameterInjectionPointImpl.getValueToInject(ParameterInjectionPointImpl.java:76) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.injection.ConstructorInjectionPoint.getParameterValues(ConstructorInjectionPoint.java:138) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.injection.ConstructorInjectionPoint.newInstance(ConstructorInjectionPoint.java:68) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.injection.producer.AbstractInstantiator.newInstance(AbstractInstantiator.java:28) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.injection.producer.BasicInjectionTarget.produce(BasicInjectionTarget.java:86) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.injection.producer.BeanInjectionTarget.produce(BeanInjectionTarget.java:173) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.hibernate.validator.internal.cdi.DestructibleBeanInstance.createAndInjectBeans(DestructibleBeanInstance.java:53) [hibernate-validator-cdi-5.0.1.Final.jar:5.0.1.Final]
> at org.hibernate.validator.internal.cdi.DestructibleBeanInstance.<init>(DestructibleBeanInstance.java:33) [hibernate-validator-cdi-5.0.1.Final.jar:5.0.1.Final]
> at org.hibernate.validator.internal.cdi.ValidatorFactoryBean.createInstance(ValidatorFactoryBean.java:205) [hibernate-validator-cdi-5.0.1.Final.jar:5.0.1.Final]
> at org.hibernate.validator.internal.cdi.ValidatorFactoryBean.createConstraintValidatorFactory(ValidatorFactoryBean.java:191) [hibernate-validator-cdi-5.0.1.Final.jar:5.0.1.Final]
> at org.hibernate.validator.internal.cdi.ValidatorFactoryBean.create(ValidatorFactoryBean.java:118) [hibernate-validator-cdi-5.0.1.Final.jar:5.0.1.Final]
> at org.hibernate.validator.internal.cdi.ValidatorFactoryBean.create(ValidatorFactoryBean.java:47) [hibernate-validator-cdi-5.0.1.Final.jar:5.0.1.Final]
> at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:103) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:93) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.proxies.ValidatorFactory$618047133$Proxy$_$$_WeldClientProxy.getValidator(Unknown Source)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.getValidator(LazyValidatorFactory.java:83)
> at org.jboss.resteasy.plugins.validation.ValidatorContextResolver.getContext(ValidatorContextResolver.java:72) [resteasy-validator-provider-11-3.0.1.Final.jar:]
> at org.jboss.resteasy.plugins.validation.ValidatorContextResolver.getContext(ValidatorContextResolver.java:30) [resteasy-validator-provider-11-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodInvoker.<init>(ResourceMethodInvoker.java:110) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodRegistry.processMethod(ResourceMethodRegistry.java:280) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodRegistry.register(ResourceMethodRegistry.java:251) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:221) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:193) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:179) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:156) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodRegistry.addPerRequestResource(ResourceMethodRegistry.java:75) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.spi.ResteasyDeployment.registration(ResteasyDeployment.java:400) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:241) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) [resteasy-jaxrs-3.0.1.Final.jar:]
> at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:198) [undertow-servlet-1.0.0.Beta1.jar:1.0.0.Beta1]
> at io.undertow.servlet.core.ManagedServlet.start(ManagedServlet.java:107) [undertow-servlet-1.0.0.Beta1.jar:1.0.0.Beta1]
> at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:390) [undertow-servlet-1.0.0.Beta1.jar:1.0.0.Beta1]
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:83)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:70)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> {noformat}
> I have also noticed that this will also fail if there was some other app previously deployed that also used similar technology stacks
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 12 months
[JBoss JIRA] (WFLY-1678) Unable to load Validation support on application redeploy
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-1678?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-1678:
--------------------------------------
Ron, I think this is caused by the validator memory leak that you are fixing/have already fixed.
> Unable to load Validation support on application redeploy
> ---------------------------------------------------------
>
> Key: WFLY-1678
> URL: https://issues.jboss.org/browse/WFLY-1678
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, REST
> Affects Versions: 8.0.0.Alpha2
> Reporter: Tomaz Cerar
> Assignee: Ron Sigal
> Fix For: 8.0.0.Beta1
>
> Attachments: server.log
>
>
> take kitchensink-ear application from quick starts
> http://www.jboss.org/jdf/quickstarts/jboss-as-quickstart/kitchensink-ear/
> after building
> run jboss-as:deploy to deploy app --> everything works
> then undeploy it with jboss-as:undeploy --> all ok
> then deploy it again jboss-as:deploy.
> this deploy will fail with
> {noformat}
> 22:51:52,682 WARN [org.jboss.resteasy.plugins.validation.ValidatorContextResolver] (MSC service thread 1-12) Unable to load Validation support: org.jboss.weld.exceptions.IllegalArgumentException: WELD-001456 Argument resolvedBean
> must not be null
> at org.jboss.weld.util.Preconditions.checkArgumentNotNull(Preconditions.java:40) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:770) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.injection.ParameterInjectionPointImpl.getValueToInject(ParameterInjectionPointImpl.java:76) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.injection.ConstructorInjectionPoint.getParameterValues(ConstructorInjectionPoint.java:138) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.injection.ConstructorInjectionPoint.newInstance(ConstructorInjectionPoint.java:68) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.injection.producer.AbstractInstantiator.newInstance(AbstractInstantiator.java:28) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.injection.producer.BasicInjectionTarget.produce(BasicInjectionTarget.java:86) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.injection.producer.BeanInjectionTarget.produce(BeanInjectionTarget.java:173) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.hibernate.validator.internal.cdi.DestructibleBeanInstance.createAndInjectBeans(DestructibleBeanInstance.java:53) [hibernate-validator-cdi-5.0.1.Final.jar:5.0.1.Final]
> at org.hibernate.validator.internal.cdi.DestructibleBeanInstance.<init>(DestructibleBeanInstance.java:33) [hibernate-validator-cdi-5.0.1.Final.jar:5.0.1.Final]
> at org.hibernate.validator.internal.cdi.ValidatorFactoryBean.createInstance(ValidatorFactoryBean.java:205) [hibernate-validator-cdi-5.0.1.Final.jar:5.0.1.Final]
> at org.hibernate.validator.internal.cdi.ValidatorFactoryBean.createConstraintValidatorFactory(ValidatorFactoryBean.java:191) [hibernate-validator-cdi-5.0.1.Final.jar:5.0.1.Final]
> at org.hibernate.validator.internal.cdi.ValidatorFactoryBean.create(ValidatorFactoryBean.java:118) [hibernate-validator-cdi-5.0.1.Final.jar:5.0.1.Final]
> at org.hibernate.validator.internal.cdi.ValidatorFactoryBean.create(ValidatorFactoryBean.java:47) [hibernate-validator-cdi-5.0.1.Final.jar:5.0.1.Final]
> at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:103) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:93) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100) [weld-core-impl-2.0.2.Final.jar:2013-06-27 10:15]
> at org.jboss.weld.proxies.ValidatorFactory$618047133$Proxy$_$$_WeldClientProxy.getValidator(Unknown Source)
> at org.jboss.as.ee.beanvalidation.LazyValidatorFactory.getValidator(LazyValidatorFactory.java:83)
> at org.jboss.resteasy.plugins.validation.ValidatorContextResolver.getContext(ValidatorContextResolver.java:72) [resteasy-validator-provider-11-3.0.1.Final.jar:]
> at org.jboss.resteasy.plugins.validation.ValidatorContextResolver.getContext(ValidatorContextResolver.java:30) [resteasy-validator-provider-11-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodInvoker.<init>(ResourceMethodInvoker.java:110) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodRegistry.processMethod(ResourceMethodRegistry.java:280) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodRegistry.register(ResourceMethodRegistry.java:251) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:221) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:193) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:179) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:156) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodRegistry.addPerRequestResource(ResourceMethodRegistry.java:75) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.spi.ResteasyDeployment.registration(ResteasyDeployment.java:400) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:241) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.init(ServletContainerDispatcher.java:112) [resteasy-jaxrs-3.0.1.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.init(HttpServletDispatcher.java:36) [resteasy-jaxrs-3.0.1.Final.jar:]
> at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:198) [undertow-servlet-1.0.0.Beta1.jar:1.0.0.Beta1]
> at io.undertow.servlet.core.ManagedServlet.start(ManagedServlet.java:107) [undertow-servlet-1.0.0.Beta1.jar:1.0.0.Beta1]
> at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:390) [undertow-servlet-1.0.0.Beta1.jar:1.0.0.Beta1]
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:83)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.start(UndertowDeploymentService.java:70)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1942)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1875)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
> {noformat}
> I have also noticed that this will also fail if there was some other app previously deployed that also used similar technology stacks
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] (JGRP-1663) TimeScheduler3 could spawn too many threads
by Igor Mazur (JIRA)
[ https://issues.jboss.org/browse/JGRP-1663?page=com.atlassian.jira.plugin.... ]
Igor Mazur commented on JGRP-1663:
----------------------------------
Thread that took a lock:
Timer temp thread-13011,global,_index-subscriber tid=13619 [RUNNABLE] [DAEMON]
java.net.Socket.connect(SocketAddress, int)
org.jgroups.util.Util.connect(Socket, SocketAddress, int)
org.jgroups.blocks.TCPConnectionMap$TCPConnection.connect(SocketAddress)
org.jgroups.blocks.TCPConnectionMap$Mapper.getConnection(Address)
org.jgroups.blocks.TCPConnectionMap.send(Address, byte[], int, int)
org.jgroups.protocols.TCP.send(Address, byte[], int, int)
org.jgroups.protocols.BasicTCP.sendUnicast(PhysicalAddress, byte[], int, int)
org.jgroups.protocols.TP.sendToSingleMember(Address, byte[], int, int)
org.jgroups.protocols.TP.doSend(Buffer, Address, boolean)
org.jgroups.protocols.TP.send(Message, Address, boolean)
org.jgroups.protocols.TP.down(Event)
org.jgroups.protocols.Discovery$1.run()
org.jgroups.util.TimeScheduler3$Task.run()
java.lang.Thread.run()
About other settings, I will try them. Thank you!
> TimeScheduler3 could spawn too many threads
> -------------------------------------------
>
> Key: JGRP-1663
> URL: https://issues.jboss.org/browse/JGRP-1663
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3.3
> Reporter: Igor Mazur
> Assignee: Bela Ban
> Priority: Optional
> Fix For: 3.4
>
> Attachments: global.xml, site.xml
>
>
> With default timer thread pool settings this code could spawn thousands of threads:
> protected void submitToPool(final Task entry) {
> try {
> pool.execute(entry);
> }
> catch(RejectedExecutionException rejected) { // only thrown if rejection policy is "abort"
> Thread thread=timer_thread_factory != null?
> timer_thread_factory.newThread(entry, "Timer temp thread")
> : new Thread(entry, "Timer temp thread");
> thread.start();
> }
> }
> On my environment I got 19000 threads.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] (JGRP-1664) UNICAST3: ack on reception versus ack on delivery
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1664?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1664:
--------------------------------
The issue with a single message was that it was acked only after the application callback returned; therefore an ack would not be sent until the callback ended. This would cause unneeded retransmissions of the message by the sender, until the ack was received.
> UNICAST3: ack on reception versus ack on delivery
> -------------------------------------------------
>
> Key: JGRP-1664
> URL: https://issues.jboss.org/browse/JGRP-1664
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4
>
>
> In UNICAST3, if ack_batches_immediately is true, a message batch is acked *before* delivering it. So this is basically acking on *reception* rather than *delivery*.
> However, this is not done for single messages. I could change the ack_batches_immediately to ack_on_reception, and - if true - ack single messages also before they're delivered.
> Thus we'd have a single property which governs whether single messages or message batches are acked on reception or delivery.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] (JGRP-1664) UNICAST3: ack on reception versus ack on delivery
by Bela Ban (JIRA)
Bela Ban created JGRP-1664:
------------------------------
Summary: UNICAST3: ack on reception versus ack on delivery
Key: JGRP-1664
URL: https://issues.jboss.org/browse/JGRP-1664
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.4
In UNICAST3, if ack_batches_immediately is true, a message batch is acked *before* delivering it. So this is basically acking on *reception* rather than *delivery*.
However, this is not done for single messages. I could change the ack_batches_immediately to ack_on_reception, and - if true - ack single messages also before they're delivered.
Thus we'd have a single property which governs whether single messages or message batches are acked on reception or delivery.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] (JGRP-1663) TimeScheduler3 could spawn too many threads
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1663?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1663:
--------------------------------
That's definitely not the way TCPPING shuld be used ! I suggest use a different discovery protocol, e.g. TCPGOSSIP or - if multicasting is enabled - MPING.
I also suggest to set TCP.sock_conn_timeout to 200 ms (default:2s), so that TCP connection attempts to down hosts are not filling up the timer thread pool.
TCPPING does its discovery in parallel, so each of the discovery requests causes 50+ timer tasks to be added to the timer.
There's something else going on though as this should not accumulate 19'000 threads. The stack trace you pasted above shows threads waiting for the lock on connection establishment, do you see which thread actually acquired the lock and whether it is blocked itself ?
Also: STABLE.desired_avg_gossip="10": that's causing a STABLE multicast from *every* member every 10ms ! That's not the default and this causes *a lot of traffic*, possibly causing connection establishment to block.
> TimeScheduler3 could spawn too many threads
> -------------------------------------------
>
> Key: JGRP-1663
> URL: https://issues.jboss.org/browse/JGRP-1663
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3.3
> Reporter: Igor Mazur
> Assignee: Bela Ban
> Priority: Optional
> Fix For: 3.4
>
> Attachments: global.xml, site.xml
>
>
> With default timer thread pool settings this code could spawn thousands of threads:
> protected void submitToPool(final Task entry) {
> try {
> pool.execute(entry);
> }
> catch(RejectedExecutionException rejected) { // only thrown if rejection policy is "abort"
> Thread thread=timer_thread_factory != null?
> timer_thread_factory.newThread(entry, "Timer temp thread")
> : new Thread(entry, "Timer temp thread");
> thread.start();
> }
> }
> On my environment I got 19000 threads.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years