October 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-4636) Fix org.jboss.test.deployers.* failures

by Dimitris Andreadis (JIRA)

Fix org.jboss.test.deployers.* failures --------------------------------------- Key: JBAS-4636 URL: http://jira.jboss.com/jira/browse/JBAS-4636 Project: JBoss Application Server Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Dimitris Andreadis Fix For: JBossAS-5.0.0.Beta3 Looking at the testsuite runs: http://cruisecontrol.jboss.com/cc/artifacts/jboss-head-testsuite-sun-1.5/... There is a whole group of deployer tests that need to be further qualified/fixed, with linked issues created org.jboss.test.deployers.client.test 4 4 0 6.208 org.jboss.test.deployers.ear.test 5 5 0 10.343 org.jboss.test.deployers.ejb.test 4 4 0 9.456 org.jboss.test.deployers.jbas2904.test 1 1 0 1.659 org.jboss.test.deployers.rar.test 4 4 0 6.285 org.jboss.test.deployers.sar.test 4 4 0 16.937 org.jboss.test.deployers.web.test 4 4 0 30.319 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 11 months

4
12
0 / 0

[JBoss JIRA] Created: (JGRP-528) NAKACK: spurious retransmission requests

by Bela Ban (JIRA)

NAKACK: spurious retransmission requests ----------------------------------------- Key: JGRP-528 URL: http://jira.jboss.com/jira/browse/JGRP-528 Project: JGroups Issue Type: Task Affects Versions: 2.5 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.6 Every now and then, spurious retransmission requests are received: NAKACK.handleXmitReq(): (requester=192.168.5.2:4397, local_addr=192.168.5.2:4393) message 192.168.5.2:4393::600 not found in retransmission table of 192.168.5.2:4393: [650 : 1050 (1100) (size=x, missing=0, highest stability=650)] It turns out that message #600 *was* actually retransmitted correctly, but the retransmission timer was cancelled too late, so that we got 1 or 2 spurious retransmit requests for the same message. This doesn't happen very frequently, and only under heavy load (e.g. 8 nodes, every node sends 5M 5K messages with 500 threads). Note that this issue DOES NOT LEAD TO INCORRECT BEHAVIOR ! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 11 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-4083) Ejb timers fire before the ear completely deploys

by Vadim Kopichenko (JIRA)

Ejb timers fire before the ear completely deploys ------------------------------------------------- Key: JBAS-4083 URL: http://jira.jboss.com/jira/browse/JBAS-4083 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB2, Scheduling/Timers Affects Versions: JBossAS-4.0.5.GA, JBossAS-4.0.4.GA Environment: WinNT, Sun JDK 1.5 Reporter: Vadim Kopichenko Assigned To: Scott M Stark Consider the following usecase. The is an ear containing several ejb modules. One of them has a ejb2.1 timed cmp entity bean. If the timer associated with the bean fires during application deployment unexpected errors happen, cause other beans could be not already deployed. This breaks application logic. The problem happens both while server starts/stops and while hot ear's redeployment. It would be much better if timers began to fire after the application had completely deployed. I've also experienced a similar problem with undeployment. Timer code was executed about a half of second after the undeployment had begun. Several ejb modules had been already undeployed by that moment. I guess that timer actually fired exactly before the undeployment had begun but the ejbTimeout executed later due to threads syncronization issue. Please, try also to investigate if this can be avoided. PS Some kind of patch or workaround for 4.0.5 (or even a hint about how this can be fixed) would be greatly appreciated. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 11 months

4
3
0 / 0

[JBoss JIRA] Created: (JBWEB-84) Class Cast Exception - when using CometProcessor - Jboss 4.2.0

by Vali Dumitru (JIRA)

Class Cast Exception - when using CometProcessor - Jboss 4.2.0 -------------------------------------------------------------- Key: JBWEB-84 URL: http://jira.jboss.com/jira/browse/JBWEB-84 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Environment: Windows Reporter: Vali Dumitru Assigned To: Mladen Turk I have a servlet that implements CometProcessor interface. Whenever I try to access it I get : java.lang.ClassCastException: org.jboss.web.tomcat.filters.ReplyHeaderFilter at org.apache.catalina.core.ApplicationFilterChain.internalDoFilterEvent(ApplicationFilterChain.java:398) at org.apache.catalina.core.ApplicationFilterChain.doFilterEvent(ApplicationFilterChain.java:363) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:227) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104) at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:241) at org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:896) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:701) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2031) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) What is this? Is there a workaround? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 11 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-4773) Move the JBossWS integration tests to the AS test module

by Heiko Braun (JIRA)

Move the JBossWS integration tests to the AS test module -------------------------------------------------------- Key: JBAS-4773 URL: http://jira.jboss.com/jira/browse/JBAS-4773 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Test Suite Reporter: Heiko Braun Assigned To: Heiko Braun Fix For: JBossAS-4.2.3.GA The JBossWS integration test need to reside with the AS. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 11 months

3
2
0 / 0

[JBoss JIRA] Created: (JBAS-4508) Add a way to defined dependencies for a JCA adapter

by Georges Berscheid (JIRA)

Add a way to defined dependencies for a JCA adapter --------------------------------------------------- Key: JBAS-4508 URL: http://jira.jboss.com/jira/browse/JBAS-4508 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: JCA service Affects Versions: JBossAS-4.2.0.GA Environment: Any Reporter: Georges Berscheid Currently there is no way to define that a resource adapter has a dependency on different component. Adrian has suggested to add support for a jboss-ra.xml file that let you define those dependencies (see forum entry). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 11 months

3
8
0 / 0

[JBoss JIRA] Created: (BPEL-268) provide a people task management example

by Alejandro Guizar (JIRA)

provide a people task management example ---------------------------------------- Key: BPEL-268 URL: http://jira.jboss.com/jira/browse/BPEL-268 Project: JBoss jBPM BPEL Issue Type: Task Security Level: Public (Everyone can see) Components: Documents Affects Versions: jBPM BPEL 1.1 beta 3 Reporter: Alejandro Guizar Assigned To: Alejandro Guizar Fix For: jBPM BPEL 1.1 GA Put together a simple example demonstrating how the task management facilities found in jPDL can be leveraged in BPEL. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 11 months

2
6
0 / 0

[JBoss JIRA] Created: (JBCACHE-1191) Work with contributor to translate JBoss Cache documentation into Spanish

by Manik Surtani (JIRA)

Work with contributor to translate JBoss Cache documentation into Spanish ------------------------------------------------------------------------- Key: JBCACHE-1191 URL: http://jira.jboss.com/jira/browse/JBCACHE-1191 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Manik Surtani Assigned To: Michael Smith Fix For: 2.2.0.GA See email sent in to the jbosscache-dev list: http://lists.jboss.org/pipermail/jbosscache-dev/2007-September/002031.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 11 months

4
8
0 / 0

[JBoss JIRA] Created: (JBAS-4382) EnterpriseContext lock counting is not synchronized

by Adrian Brock (JIRA)

EnterpriseContext lock counting is not synchronized --------------------------------------------------- Key: JBAS-4382 URL: http://jira.jboss.com/jira/browse/JBAS-4382 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB2 Reporter: Adrian Brock Assigned To: Scott M Stark Fix For: JBossAS-4.2.0.GA The lock counting in org.jboss.ejb.EnterpriseContext is not synchronized. The lock ivar is not even volatile. This variable needs replacing with synchronized method blocks or an oswego concurrent SynchronizedInt. This bug could either cause passivation to be invoked when it shouldn't or vice versa. Additionally, even with this fix, the usage in StatefulSessionInstanceInterceptor needs replacing with something more atomic! if (!ctx.isLocked()) { //take it! ctx.lock(); } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 11 months

3
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-1108) Move CacheListeners to their own thread pool

by Jason T. Greene (JIRA)

Move CacheListeners to their own thread pool -------------------------------------------- Key: JBCACHE-1108 URL: http://jira.jboss.com/jira/browse/JBCACHE-1108 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Reporter: Jason T. Greene Assigned To: Manik Surtani Fix For: 2.0.0.CR3 User CacheListeners should be dispatched in their own thread pool to prevent reentrancy problems and delays on cache operations. Evection listeners should still be executed in the app thread. -Jason -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

17 years, 11 months

2
8
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 October 2007