December 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMICROCONT-115) VirtualFile.finalize closing stream causes read errors on in use streams

by Scott M Stark (JIRA)

VirtualFile.finalize closing stream causes read errors on in use streams ------------------------------------------------------------------------ Key: JBMICROCONT-115 URL: http://jira.jboss.com/jira/browse/JBMICROCONT-115 Project: JBoss MicroContainer Issue Type: Bug Components: VFS Affects Versions: JBossMC_2_0_0 Beta Reporter: Scott M Stark Assigned To: Scott M Stark Fix For: JBossMC_2_0_0_CR1 In looking into the JBAS-3867 read error, I found that the VirtualFile finalizer behavior of closing the open streams is causing active streams to fail: 06:29:10,515 ERROR [STDERR] java.io.FileInputStream@ba8af9 failed, fd=java.io.FileDescriptor@13c339f[fd=-1,handle=-1,prevHandle=4652], isValid=false, java.io.IOException: Read error 06:29:10,515 ERROR [STDERR] java.io.FileInputStream@ba8af9, fd=4652 already closed at: 06:29:10,515 ERROR [STDERR] java.lang.Thread.dumpThreads(Native Method) 06:29:10,515 ERROR [STDERR] java.lang.Thread.getStackTrace(Thread.java:1383) 06:29:10,515 ERROR [STDERR] java.io.FileInputStream.close(FileInputStream.java:279) 06:29:10,515 ERROR [STDERR] org.jboss.virtual.VirtualFile.closeStreams(VirtualFile.java:210) 06:29:10,515 ERROR [STDERR] org.jboss.virtual.VirtualFile.close(VirtualFile.java:227) 06:29:10,515 ERROR [STDERR] org.jboss.virtual.VirtualFile.finalize(VirtualFile.java:390) 06:29:10,515 ERROR [STDERR] java.lang.ref.Finalizer.invokeFinalizeMethod(NativeMethod) 06:29:10,515 ERROR [STDERR] java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83) 06:29:10,515 ERROR [STDERR] java.lang.ref.Finalizer.access$100(Finalizer.java:14) 06:29:10,515 ERROR [STDERR] java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160) The problem is that one can be using a stream without reference to the VirtualFile. The usage in the web deployer where this occurs is of the form: InputStream[] webXmlStreams = getInputStreams() private InputStream[] getInputStreams() { InputStream jbossWebIS = null; InputStream webIS = null; try { VirtualFile webDD = unit.getMetaDataFile("web.xml"); if (webDD != null) webIS = webDD.openStream(); } catch (IOException e) { log.debug("Failed to find web.xml"); } try { VirtualFile webDD = unit.getMetaDataFile("jboss-web.xml"); if (webDD != null) jbossWebIS = webDD.openStream(); } catch (IOException e) { log.debug("Failed to find jboss-web.xml"); } InputStream[] streams = {webIS, jbossWebIS}; return streams; } so the VirtualFiles associated with the descriptors have no references, but the streams do. -- 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

19 years

1
2
0 / 0

[JBoss JIRA] Created: (JBAOP-288) Unify API used by AspectDeployer with AOP 2.0

by Kabir Khan (JIRA)

Unify API used by AspectDeployer with AOP 2.0 --------------------------------------------- Key: JBAOP-288 URL: http://jira.jboss.com/jira/browse/JBAOP-288 Project: JBoss AOP Issue Type: Task Security Level: Public (Everyone can see) Reporter: Kabir Khan Assigned To: Kabir Khan Fix For: 1.5.2.GA The AspectDeployer will be built from Branch_4_0 for both AOP 1.5.x and AOP 2.0 -- 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

19 years

2
6
0 / 0

[JBoss JIRA] Updated: (JBAS-3198) Problems with separated ClassLoaders for EARs and pooled invoker (PooledInvokerHA).

by Jim Moran (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3198?page=all ] Jim Moran updated JBAS-3198: ---------------------------- Attachment: example.zip Example to illustrate bug You need to set jboss.server.dir build property to point to a standard 'default' server config directory > Problems with separated ClassLoaders for EARs and pooled invoker (PooledInvokerHA). > ----------------------------------------------------------------------------------- > > Key: JBAS-3198 > URL: http://jira.jboss.com/jira/browse/JBAS-3198 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: ClassLoading > Affects Versions: JBossAS-4.0.5.CR1 > Environment: Windows XP, HP-UX 11, JDK 1.4.2 and 1.5 > Reporter: Eric Hambuch > Assigned To: Tom Elrod > Priority: Critical > Fix For: JBossAS-5.0.0.CR1, JBossAS-4.2.0.CR1, JBossAS-4.0.5.SP1 > > Attachments: example.zip > > > When using the pooled invoker (PooledInvokerHA) in the "all" configuration with separated classloaders for each EAR (as described in Wiki:ClassLoadingConfiguration) an invocation to a bean causes confusion to the separated classloaders. > More detailed: > I switched from jrmpha-invoker (which creates a new thread for each request which is really bad) to pooledha invoker in a clustered environment. I have to Stateless Session Beans that share the same bean interface. Each Session Bean is deployed in a separate EAR. In "ear-deployer.xml" I switched "isolated" to "true" to separate the classloaders of the EARs. > When I call the first bean everything works fine. But when I try to call the second bean (same interface, but different bean!) JBoss throws the following exception: > java.rmi.ServerException: RuntimeException; nested exception is: > java.lang.IllegalArgumentException: argument type mismatch > at org.jboss.ejb.plugins.LogInterceptor.handleException(LogInterceptor.java:386) > at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:196) > at org.jboss.ejb.plugins.CleanShutdownInterceptor.invoke(CleanShutdownInterceptor.java:264) > at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122) > at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:624) > at org.jboss.ejb.Container.invoke(Container.java:873) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141) > at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80) > at org.jboss.mx.server.Invocation.invoke(Invocation.java:72) > at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245) > at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644) > at org.jboss.invocation.pooled.server.PooledInvokerHA.invoke(PooledInvokerHA.java:146) > at org.jboss.invocation.pooled.server.ServerThread.processInvocation(ServerThread.java:213) > at org.jboss.invocation.pooled.server.ServerThread.dorun(ServerThread.java:268) > at org.jboss.invocation.pooled.server.ServerThread.run(ServerThread.java:139) > Caused by: java.lang.IllegalArgumentException: argument type mismatch > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at org.jboss.invocation.Invocation.performCall(Invocation.java:345) > at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:214) > at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:149) > at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:48) > at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:106) > at org.jboss.ejb.plugins.AbstractTxInterceptorBMT.invokeNext(AbstractTxInterceptorBMT.java:158) > at org.jboss.ejb.plugins.TxInterceptorBMT.invoke(TxInterceptorBMT.java:62) > at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:154) > at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:153) > at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:192) > The IllegalArgumentException comes from the fact that the Method.invoke() is called with a class of the wrong classloader (class from other EAR). > With jrmpha-invoker everything works fine. Maybe the thread pool causes a mixture of the classloaders? > I created a minimized example that can be provided if required. -- 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

19 years

1
0
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-668) Basic client-side failover logic

by Ovidiu Feodorov (JIRA)

Basic client-side failover logic -------------------------------- Key: JBMESSAGING-668 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-668 Project: JBoss Messaging Issue Type: Sub-task Components: JMS Clustering Reporter: Ovidiu Feodorov Assigned To: Clebert Suconic Fix For: 1.2.0.Beta1 -- 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

19 years

1
1
0 / 0

[JBoss JIRA] Commented: (JGRP-33) JGroups throws OutOfMemoryError after running for a few hours

by Bela Ban (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-33?page=comments#action_12348148 ] Bela Ban commented on JGRP-33: ------------------------------ Tony: please use the mailing lists to discuss issue such as these. JIRA should just be used to create issues. If you have a use case (with code) that describes how to get an OOM, that would help. You can turn local messages off through Channel.setOpt(Channel.LOCAL, Boolean.FALSE); > JGroups throws OutOfMemoryError after running for a few hours > ------------------------------------------------------------- > > Key: JGRP-33 > URL: http://jira.jboss.com/jira/browse/JGRP-33 > Project: JGroups > Issue Type: Bug > Affects Versions: 2.2.8 > Environment: SUN JDK 1.4.2_05 & SUN JDK 1.5.0 on Windows & Unix platforms > Reporter: B.S.Navin > Assigned To: Bela Ban > Fix For: 2.2.8 > > Attachments: fc-fast-udp-tcpping.xml, fc-fast-udp.xml, JGroupsMemTest.java, PublishThread2.java, runj10.sh > > > I ran 10 instances of a simple program with 3 threads. The max memory is kept as the JVM default (64M). The 10 programs join the same JGroup and the threads in the programs keep publishing a small hashmap at 5 second intervals. > The heap memory consumed (Runtime.totalMemory() - Runtime.freeMemory()) slowly increases over a period of 4-5 hours and reaches the default max limit (64M) when it starts throwing OutOfMemory errors on all instances. > I have run the program on unix and windows machines with 1G RAM. > Not able to make much from an HProf output of one of the instances. > This seems to be the cause for the JBossCache bug "http://jira.jboss.com/jira/browse/JBCACHE-31" too. > I have tried out a UDP/PING and a UDP/TCPPING combination and this problem occurs in both cases. -- 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

19 years

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3505) jar-versions.xml file needs to be downloaded to JBoss installation folder even if the user chooses Run installer option.

by Sankarkumar Ramsankar (JIRA)

jar-versions.xml file needs to be downloaded to JBoss installation folder even if the user chooses Run installer option. ------------------------------------------------------------------------------------------------------------------------ Key: JBAS-3505 URL: http://jira.jboss.com/jira/browse/JBAS-3505 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Installer Affects Versions: JBossAS-4.0.4.GA, JBossAS-4.0.3 SP1 Environment: Windows All Reporter: Sankarkumar Ramsankar Assigned To: Alex Pinkin Priority: Minor jar-versions.xml file is getting downloaded only if the user choose download option. If the user choose "Run Installer" option then jar-versions.xml does not download into install folder. jar-versions.xml file needs to be downloaded in any type of installation either download or run installer. -- 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

19 years

2
1
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1120) TinyMCE update with last version / wysiwyg html editor

by Antoine Herzog (JIRA)

TinyMCE update with last version / wysiwyg html editor ------------------------------------------------------ Key: JBPORTAL-1120 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1120 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Portal CMS Affects Versions: 2.4 Final Environment: JBPortal 2.4 GA Reporter: Antoine Herzog Assigned To: Roy Russo Priority: Trivial The version 2.0.8 (2006-10-23) of Tiny MCE has a lot of bug fixed, compared to the one use in JBoss Portal 2.4GA. And a lot of features added. It is worth upgrading it in the next version of portal. see : http://tinymce.moxiecode.com/tinymce/changelog -- 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

19 years

2
1
0 / 0

[JBoss JIRA] Closed: (JBAS-3065) Validate the ejb3/java ee 5 preview configs of the installer

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3065?page=all ] Dimitris Andreadis closed JBAS-3065. ------------------------------------ Fix Version/s: JBossAS-4.0.4.GA Resolution: Done Done since 4.0.4.GA. > Validate the ejb3/java ee 5 preview configs of the installer > ------------------------------------------------------------ > > Key: JBAS-3065 > URL: http://jira.jboss.com/jira/browse/JBAS-3065 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Build System, Installer > Reporter: Scott M Stark > Assigned To: Scott M Stark > Fix For: JBossAS-4.0.4.GA > > > Container task for ejb3/webservices/seam demo/tutorial examples being able to work the the ejb3 related configs of the installer. -- 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

19 years

1
0
0 / 0

[JBoss JIRA] Commented: (JGRP-33) JGroups throws OutOfMemoryError after running for a few hours

by Tony Starks (JIRA)

[ http://jira.jboss.com/jira/browse/JGRP-33?page=comments#action_12348138 ] Tony Starks commented on JGRP-33: --------------------------------- Bela, i am experienceing a similar problem as the issue author. Where can one check whether or not the sender ever receives its own messages ? > JGroups throws OutOfMemoryError after running for a few hours > ------------------------------------------------------------- > > Key: JGRP-33 > URL: http://jira.jboss.com/jira/browse/JGRP-33 > Project: JGroups > Issue Type: Bug > Affects Versions: 2.2.8 > Environment: SUN JDK 1.4.2_05 & SUN JDK 1.5.0 on Windows & Unix platforms > Reporter: B.S.Navin > Assigned To: Bela Ban > Fix For: 2.2.8 > > Attachments: fc-fast-udp-tcpping.xml, fc-fast-udp.xml, JGroupsMemTest.java, PublishThread2.java, runj10.sh > > > I ran 10 instances of a simple program with 3 threads. The max memory is kept as the JVM default (64M). The 10 programs join the same JGroup and the threads in the programs keep publishing a small hashmap at 5 second intervals. > The heap memory consumed (Runtime.totalMemory() - Runtime.freeMemory()) slowly increases over a period of 4-5 hours and reaches the default max limit (64M) when it starts throwing OutOfMemory errors on all instances. > I have run the program on unix and windows machines with 1G RAM. > Not able to make much from an HProf output of one of the instances. > This seems to be the cause for the JBossCache bug "http://jira.jboss.com/jira/browse/JBCACHE-31" too. > I have tried out a UDP/PING and a UDP/TCPPING combination and this problem occurs in both cases. -- 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

19 years

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-338) Anycast

by Bela Ban (JIRA)

Anycast ------- Key: JGRP-338 URL: http://jira.jboss.com/jira/browse/JGRP-338 Project: JGroups Issue Type: Feature Request Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.6 Send a message to N target members, where N is less than the group size (multicast) and more than 1 (unicast). This will allow for RpcDispatcher.callRemoteMethods() to provide a list of target members, and each transport decides individually whether to use multicast of multiple unicasts. Used for Buddy Replication in JBossCache -- 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

19 years

1
6
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2006