February 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4334) CalendarBasedTimeoutTestCase fails consistently

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-4334?page=com.atlassian.jira.plugin.... ] Thomas Diesler reassigned WFLY-4334: ------------------------------------ Assignee: Thomas Diesler (was: David Lloyd) > CalendarBasedTimeoutTestCase fails consistently > ----------------------------------------------- > > Key: WFLY-4334 > URL: https://issues.jboss.org/browse/WFLY-4334 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Thomas Diesler > Assignee: Thomas Diesler > > Happens on branch 8.x > {code} > Running org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase > Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.352 sec <<< FAILURE! - in org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase > testCalendarBasedTimeout(org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase) Time elapsed: 0.342 sec <<< FAILURE! > java.lang.AssertionError: Eastern European Time > at org.junit.Assert.fail(Assert.java:88) > at org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase.testWithStartInThePast(CalendarBasedTimeoutTestCase.java:539) > at org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase.testCalendarBasedTimeout(CalendarBasedTimeoutTestCase.java:129) > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4334) CalendarBasedTimeoutTestCase fails consistently

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-4334?page=com.atlassian.jira.plugin.... ] Thomas Diesler reassigned WFLY-4334: ------------------------------------ Assignee: David Lloyd (was: Thomas Diesler) > CalendarBasedTimeoutTestCase fails consistently > ----------------------------------------------- > > Key: WFLY-4334 > URL: https://issues.jboss.org/browse/WFLY-4334 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Thomas Diesler > Assignee: David Lloyd > > Happens on branch 8.x > {code} > Running org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase > Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.352 sec <<< FAILURE! - in org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase > testCalendarBasedTimeout(org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase) Time elapsed: 0.342 sec <<< FAILURE! > java.lang.AssertionError: Eastern European Time > at org.junit.Assert.fail(Assert.java:88) > at org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase.testWithStartInThePast(CalendarBasedTimeoutTestCase.java:539) > at org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase.testCalendarBasedTimeout(CalendarBasedTimeoutTestCase.java:129) > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4334) CalendarBasedTimeoutTestCase fails consistently

by Thomas Diesler (JIRA)

Thomas Diesler created WFLY-4334: ------------------------------------ Summary: CalendarBasedTimeoutTestCase fails consistently Key: WFLY-4334 URL: https://issues.jboss.org/browse/WFLY-4334 Project: WildFly Issue Type: Bug Components: EJB Reporter: Thomas Diesler Assignee: David Lloyd Happens on branch 8.x {code} Running org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.352 sec <<< FAILURE! - in org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase testCalendarBasedTimeout(org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase) Time elapsed: 0.342 sec <<< FAILURE! java.lang.AssertionError: Eastern European Time at org.junit.Assert.fail(Assert.java:88) at org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase.testWithStartInThePast(CalendarBasedTimeoutTestCase.java:539) at org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase.testCalendarBasedTimeout(CalendarBasedTimeoutTestCase.java:129) {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (REMJMX-94) Memory leak in remoting-jmx

by Libor Zoubek (JIRA)

Libor Zoubek created REMJMX-94: ---------------------------------- Summary: Memory leak in remoting-jmx Key: REMJMX-94 URL: https://issues.jboss.org/browse/REMJMX-94 Project: Remoting JMX Issue Type: Bug Affects Versions: 1.1.3.Final Reporter: Libor Zoubek Assignee: Darran Lofthouse In RHQ plugin We're experiencing a memory leak when we talk to EAP over remoting-jmx. Leak is very notable once we restart our plugin container (each plugin has in it's own classloader) Classes owned by RHQ Server plugin don't get GCed. I am able to reproduce mem leak without RHQ agent and plugin infrastructure repeating following steps: 1. start new thread 2. assign URL classloader to this thread (point it to jboss-client.jar) 3. connect & disconnect to jmx-remoting endpoint In this test no classes don't get GCed which after serveral iterations ends up in OOM. My test/example is here https://github.com/lzoubek/remotingjmx-leak/blob/master/src/main/java/org... I am not sure if memleak is in remoting-jmx or some other underlying stuff. I thought https://issues.jboss.org/browse/REM3-200 was related, but workaround mentioned does not help. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4333) Transaction must be sticky to ensure consistency for EJB remote invocation with JPA

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4333?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-4333: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1190996 > Transaction must be sticky to ensure consistency for EJB remote invocation with JPA > ----------------------------------------------------------------------------------- > > Key: WFLY-4333 > URL: https://issues.jboss.org/browse/WFLY-4333 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Wolf-Dieter Fink > Assignee: David Lloyd > Priority: Critical > Labels: ejb, transaction > > If an application inside of a server uses standard JavaEE persistence JPA, the current implementation include a local 1. level cache which might end in inconsistent reads within the same (uncommited) transaction. > There are two reasons > - JPA must not flush changes to an entity until commit > - The 1. level cache might not read from the persistence if the entity is already loaded in a transaction > Therefore the server to server invocations of EJB's need to be sticky to one node during a transaction. The granularity must be the application. > It might be worth to use already known nodes for other applications as well. > The stickyness should be enabled automatically if a transaction is active and distributed, which is the default within the current implementation, and use the loadbalancing policy if no transaction is active. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4333) Transaction must be sticky to ensure consistency for EJB remote invocation with JPA

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created WFLY-4333: -------------------------------------- Summary: Transaction must be sticky to ensure consistency for EJB remote invocation with JPA Key: WFLY-4333 URL: https://issues.jboss.org/browse/WFLY-4333 Project: WildFly Issue Type: Bug Components: EJB Reporter: Wolf-Dieter Fink Assignee: David Lloyd Priority: Critical If an application inside of a server uses standard JavaEE persistence JPA, the current implementation include a local 1. level cache which might end in inconsistent reads within the same (uncommited) transaction. There are two reasons - JPA must not flush changes to an entity until commit - The 1. level cache might not read from the persistence if the entity is already loaded in a transaction Therefore the server to server invocations of EJB's need to be sticky to one node during a transaction. The granularity must be the application. It might be worth to use already known nodes for other applications as well. The stickyness should be enabled automatically if a transaction is active and distributed, which is the default within the current implementation, and use the loadbalancing policy if no transaction is active. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4313) Clean-up tests which use Kerberos in the WildFly testsuite

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-4313?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-4313: ----------------------------------------------- Marek Kopecky <mkopecky(a)redhat.com> changed the Status of [bug 1189141|https://bugzilla.redhat.com/show_bug.cgi?id=1189141] from ON_QA to ASSIGNED > Clean-up tests which use Kerberos in the WildFly testsuite > ---------------------------------------------------------- > > Key: WFLY-4313 > URL: https://issues.jboss.org/browse/WFLY-4313 > Project: WildFly > Issue Type: Enhancement > Components: Test Suite > Reporter: Josef Cacek > Assignee: Josef Cacek > > Clean up Kerberos tests and add an unified logic for skipping Kerberos test configurations which proved to be unstable/buggy. By a configuration here is meant combination of Java vendor, version and IP stack. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3174) Add view of batch jobs with ability to view, restart and stop

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-3174?page=com.atlassian.jira.plugin.... ] James Perkins commented on WFLY-3174: ------------------------------------- Is there a way to limit the number of resources returned? With batch there could be hundred(s)+ jobs to be listed. I'm not sure the best way to handle that. Maybe that doesn't matter though, just trying to think of possible issues. > Add view of batch jobs with ability to view, restart and stop > ------------------------------------------------------------- > > Key: WFLY-3174 > URL: https://issues.jboss.org/browse/WFLY-3174 > Project: WildFly > Issue Type: Feature Request > Components: Batch > Reporter: James Perkins > Assignee: James Perkins > > Currently there is no way to view batch jobs for a deployment with in the batch subsystem management. There should be a way to view the batch jobs that have run on various deployments. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4332) Wrong path with Stateless WebService and serviceName

by Janario Oliveira (JIRA)

Janario Oliveira created WFLY-4332: -------------------------------------- Summary: Wrong path with Stateless WebService and serviceName Key: WFLY-4332 URL: https://issues.jboss.org/browse/WFLY-4332 Project: WildFly Issue Type: Bug Components: Web Services Affects Versions: 8.2.0.Final Reporter: Janario Oliveira Assignee: Alessio Soldano When I have a WebService with serviceName and it is a Stateless It adds a different url. e.g. @WebService(serviceName = "StatelessWeb") @Stateless public class StatelessWebService { public boolean executeTest() {return true;} } It will be available in /StatelessWeb/StatelessWebService. Once if it isn't a stateless it will be in /StatelessWeb -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4328) Failed to execute goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha8:build (server-provisioning)

by Carlton Zachary (JIRA)

[ https://issues.jboss.org/browse/WFLY-4328?page=com.atlassian.jira.plugin.... ] Carlton Zachary commented on WFLY-4328: --------------------------------------- I ran this from the wildfly root. > Failed to execute goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha8:build (server-provisioning) > --------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-4328 > URL: https://issues.jboss.org/browse/WFLY-4328 > Project: WildFly > Issue Type: Bug > Components: Build System > Reporter: Carlton Zachary > Assignee: Eduardo Martins > > Getting the following error at the end of the Wildfly build. > {noformat} > [ERROR] Failed to execute goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha8:build (server-provisioning) on project wildfly-build: Execution server-provis > ioning of goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha8:build failed: java.lang.RuntimeException: java.lang.RuntimeException: Failed to process feature pack C:\WildFly9\wildfly\web-feature-pack\target\wildfly-web-feature-pack-9.0.0.Alpha2-SNAPSHOT.zip modules: C:\WildFly9\wildfly\build\target\wildfly-9.0.0.Alpha2-SNAPSHOT\modules\system\layers\base\org\picketbox\main\module.xml -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha8:build (server-provisioning) on project wildfly-build: Execution server-provisioning of goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.0.0.Alpha8:build failed: java.lang.RuntimeException: java.lang.RuntimeException: Failed to process feature pack C:\WildFly9\wildfly\web-feature-pack\target\wildfly-web-feature-pack-9.0.0.Alpha2-SNAPSHOT.zip modules > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) > at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116) > at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80) > at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) > at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155) > at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:160) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) > at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2015