January 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-149) Failures in 'resolve-expression" op appear in server log

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-149?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFCORE-149: ------------------------------------ Fix Version/s: 3.0.0.Alpha1 > Failures in 'resolve-expression" op appear in server log > -------------------------------------------------------- > > Key: WFCORE-149 > URL: https://issues.jboss.org/browse/WFCORE-149 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: ehsavoie Hugonnet > Priority: Minor > Fix For: 3.0.0.Alpha1 > > > I happened to notice this in a server log: > 11:53:48,854 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 3) WFLYCTL0013: Operation ("resolve-expression") failed - address: ([]) - failure description: "WFLYCTL0211: Cannot resolve expression 'expression \"${unresolvable}\"' -- java.lang.IllegalStateException: Failed to resolve expression: ${unresolvable}" > That failure shouldn't end up in the server log; it's just a client mistake unrelated to server operation. > A guess is that it's logged because the OFE has the ISE attached as a cause, in which case a simple fix is to not attach the ISE, which adds no value. > Note the handler has a catch block above the one that throws this OFE that handles a SecurityException case. In that case it *may* be appropriate for something to appear in the logs, assuming tracing how the SE can happen indicates it could be triggered by a user fishing for an exploit. In that case a direct WARN in the log from the ResolveExpressionHandler instead of attaching the SE to the OFE and letting the OperationContext log an ERROR may be more appropriate. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6050) Query timeout (set-tx-query-timeout) not applied within last second before transaction timeout

by Piotr Findeisen (JIRA)

[ https://issues.jboss.org/browse/WFLY-6050?page=com.atlassian.jira.plugin.... ] Piotr Findeisen commented on WFLY-6050: --------------------------------------- The {{WrapperDataSource}} class doesn't seem to exist in IronJacamar's HEAD, so I did not create a PR. I don't know whether the code went (whether it was copied or replaced by something more correct). > Query timeout (set-tx-query-timeout) not applied within last second before transaction timeout > ---------------------------------------------------------------------------------------------- > > Key: WFLY-6050 > URL: https://issues.jboss.org/browse/WFLY-6050 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 9.0.2.Final > Reporter: Piotr Findeisen > Assignee: Jesper Pedersen > > When using {{<set-tx-query-timeout>true</set-tx-query-timeout}}, the query timeout is applied, unless less than 1 second remains until transaction timeout. > This is due to a typo in code converting transaction timeout (millis) into jdbc timeout (seconds). > Widlfy 9.0.2 uses IronJacama 1.2.5, so here's the code (https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.2.5.Final/a...): > {code} > long result = timeout / 1000; > if ((result % 1000) != 0) // <------ the `timeout % 1000` was supposed to be > ++result; > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6050) Query timeout (set-tx-query-timeout) not applied within last second before transaction timeout

by Piotr Findeisen (JIRA)

[ https://issues.jboss.org/browse/WFLY-6050?page=com.atlassian.jira.plugin.... ] Piotr Findeisen updated WFLY-6050: ---------------------------------- Description: When using {{<set-tx-query-timeout>true</set-tx-query-timeout}}, the query timeout is applied, unless less than 1 second remains until transaction timeout. This is due to a typo in code converting transaction timeout (millis) into jdbc timeout (seconds). Widlfy 9.0.2 uses IronJacama 1.2.5, so here's the code (https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.2.5.Final/a...): {code} long result = timeout / 1000; if ((result % 1000) != 0) // <------ the `timeout % 1000` was supposed to be ++result; {code} was: When using {{<set-tx-query-timeout>true</set-tx-query-timeout}}, the query timeout is applied, unless less than 1 second remains until transaction timeout. This is due to a typo in code converting transaction timeout (millis) into jdbc timeout (seconds). Widlfy 9.0.2 uses IronJacama 1.2.5, so here's the code (https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.2.5.Final/a...): {code} long result = timeout / 1000; if ((result % 1000) != 0) // <------ the `timeout % 1000` was supposed to be ++result; {code} > Query timeout (set-tx-query-timeout) not applied within last second before transaction timeout > ---------------------------------------------------------------------------------------------- > > Key: WFLY-6050 > URL: https://issues.jboss.org/browse/WFLY-6050 > Project: WildFly > Issue Type: Bug > Components: JCA > Affects Versions: 9.0.2.Final > Reporter: Piotr Findeisen > Assignee: Jesper Pedersen > > When using {{<set-tx-query-timeout>true</set-tx-query-timeout}}, the query timeout is applied, unless less than 1 second remains until transaction timeout. > This is due to a typo in code converting transaction timeout (millis) into jdbc timeout (seconds). > Widlfy 9.0.2 uses IronJacama 1.2.5, so here's the code (https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.2.5.Final/a...): > {code} > long result = timeout / 1000; > if ((result % 1000) != 0) // <------ the `timeout % 1000` was supposed to be > ++result; > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6050) Query timeout (set-tx-query-timeout) not applied within last second before transaction timeout

by Piotr Findeisen (JIRA)

Piotr Findeisen created WFLY-6050: ------------------------------------- Summary: Query timeout (set-tx-query-timeout) not applied within last second before transaction timeout Key: WFLY-6050 URL: https://issues.jboss.org/browse/WFLY-6050 Project: WildFly Issue Type: Bug Components: JCA Affects Versions: 9.0.2.Final Reporter: Piotr Findeisen Assignee: Jesper Pedersen When using {{<set-tx-query-timeout>true</set-tx-query-timeout}}, the query timeout is applied, unless less than 1 second remains until transaction timeout. This is due to a typo in code converting transaction timeout (millis) into jdbc timeout (seconds). Widlfy 9.0.2 uses IronJacama 1.2.5, so here's the code (https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.2.5.Final/a...): {code} long result = timeout / 1000; if ((result % 1000) != 0) // <------ the `timeout % 1000` was supposed to be ++result; {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2387) CDI injection in entity listeners failing

by Steve Ebersole (JIRA)

[ https://issues.jboss.org/browse/WFLY-2387?page=com.atlassian.jira.plugin.... ] Steve Ebersole commented on WFLY-2387: -------------------------------------- I'd suggest anyone with a vested interest in this issue weigh in on HHH-8706, because it is going to end up being up to JPA providers (Hibernate) to rectify this situation even though it is just bad planning/communication between JPA and CDI (CDI could just as easily handle this). > CDI injection in entity listeners failing > ----------------------------------------- > > Key: WFLY-2387 > URL: https://issues.jboss.org/browse/WFLY-2387 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, Class Loading, JPA / Hibernate > Affects Versions: 8.0.0.Beta1 > Reporter: Emond Papegaaij > Assignee: Scott Marlow > Attachments: TEST-org.jboss.as.test.integration.ee.injection.support.jpa.EntityListenerInjectionSupportTestCase.xml > > > When trying to use CDI injection in JPA entity listeners, deployment fails with the following exception: > {code} > 16:16:37,448 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 15) MSC000001: Failed to start service jboss.persistenceunit."inject-ear.ear#primary": org.jboss.msc.service.StartException in service jboss.persistenceunit."inject-ear.ear#primary": java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader@4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment. > at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169) > at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117) > at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25] > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3] > at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final] > Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader@4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment. > at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75) > at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:128) > at org.jboss.weld.Container.instance(Container.java:65) > at org.jboss.weld.manager.BeanManagerImpl.getBeans(BeanManagerImpl.java:563) > at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:90) > at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358) > at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369) > at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72) > at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60) > at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66) > at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) > at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64) > at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90) > at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:82) > at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:71) > at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory.buildListener(BeanManagerListenerFactory.java:57) > at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.resolveCallbacks(LegacyCallbackProcessor.java:168) > at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.processCallbacksForEntity(LegacyCallbackProcessor.java:71) > at org.hibernate.jpa.event.spi.JpaIntegrator.integrate(JpaIntegrator.java:150) > at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310) > at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837) > at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854) > at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847) > at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396) > at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846) > at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44) > at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151) > ... 8 more > {code} > I've created a small showcase of the problem: https://github.com/papegaaij/listener-injection -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5822) Clustering performance regression in ejbremote-dist-sync scenario

by Richard Achmatowicz (JIRA)

[ https://issues.jboss.org/browse/WFLY-5822?page=com.atlassian.jira.plugin.... ] Richard Achmatowicz commented on WFLY-5822: ------------------------------------------- The reason I ask is that these 4 server tests were the original cause of this issue being created. Take the time, if necessary. > Clustering performance regression in ejbremote-dist-sync scenario > ------------------------------------------------------------------ > > Key: WFLY-5822 > URL: https://issues.jboss.org/browse/WFLY-5822 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 10.0.0.CR5 > Reporter: Michal Vinkler > Assignee: Richard Achmatowicz > Priority: Critical > > Compared to EAP 6, all SYNC scenarios have the same/better performance except of this one, wonder why? > Compare these results: > stress-ejbremote-dist-sync > 7.0.0.ER2: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-str...] > 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-str...] > --------------------------------------- > Just for comparison: ejbremote REPL_SYNC scenario *performs well* on the other hand: > stress-ejbremote-repl-sync > 7.0.0.ER2: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-str...] > 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-str...] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5822) Clustering performance regression in ejbremote-dist-sync scenario

by Michal Vinkler (JIRA)

[ https://issues.jboss.org/browse/WFLY-5822?page=com.atlassian.jira.plugin.... ] Michal Vinkler commented on WFLY-5822: -------------------------------------- It is possible but it will take some time. > Clustering performance regression in ejbremote-dist-sync scenario > ------------------------------------------------------------------ > > Key: WFLY-5822 > URL: https://issues.jboss.org/browse/WFLY-5822 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 10.0.0.CR5 > Reporter: Michal Vinkler > Assignee: Richard Achmatowicz > Priority: Critical > > Compared to EAP 6, all SYNC scenarios have the same/better performance except of this one, wonder why? > Compare these results: > stress-ejbremote-dist-sync > 7.0.0.ER2: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-str...] > 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-str...] > --------------------------------------- > Just for comparison: ejbremote REPL_SYNC scenario *performs well* on the other hand: > stress-ejbremote-repl-sync > 7.0.0.ER2: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-str...] > 6.4.0.GA: [throughput|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-str...] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6049) Modules should be marked private / unsupported

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6049?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-6049: ------------------------------ Description: Mark modules as folows: io.undertow.js unsupported com.github.spullara.mustache private io.netty module should be private org.hibernate.infinispan module should be private was: Mark modules as folows: io.undertow.js unsupported com.github.spullara.mustache private io.netty module should be private > Modules should be marked private / unsupported > ---------------------------------------------- > > Key: WFLY-6049 > URL: https://issues.jboss.org/browse/WFLY-6049 > Project: WildFly > Issue Type: Task > Components: Web (Undertow) > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Priority: Blocker > Labels: release_notes > > Mark modules as folows: > io.undertow.js unsupported > com.github.spullara.mustache private > io.netty module should be private > org.hibernate.infinispan module should be private -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6049) Modules should be marked private / unsupported

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6049?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-6049: ------------------------------ Description: Mark modules as folows: io.undertow.js unsupported com.github.spullara.mustache private io.netty module should be private was: Mark modules as folows: io.undertow.js unsupported com.github.spullara.mustache private > Modules should be marked private / unsupported > ---------------------------------------------- > > Key: WFLY-6049 > URL: https://issues.jboss.org/browse/WFLY-6049 > Project: WildFly > Issue Type: Task > Components: Web (Undertow) > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > Priority: Blocker > Labels: release_notes > > Mark modules as folows: > io.undertow.js unsupported > com.github.spullara.mustache private > io.netty module should be private -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2006) Remove deprecated classes/methods/attributes

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2006?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2006. ---------------------------- Resolution: Done > Remove deprecated classes/methods/attributes > -------------------------------------------- > > Key: JGRP-2006 > URL: https://issues.jboss.org/browse/JGRP-2006 > Project: JGroups > Issue Type: Sub-task > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0 > > > Remove all elements marked with {{@Deprecated}} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2016