December 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-3571) Bad interaction between http session passivation and buddy replication

by Brian Stansberry (JIRA)

Bad interaction between http session passivation and buddy replication ---------------------------------------------------------------------- Key: JBAS-3571 URL: http://jira.jboss.com/jira/browse/JBAS-3571 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering, Web (Tomcat) service Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.Beta I've seen server startup issues when in the tc6-cluster.sar buddy replication is enabled AND the cache loader used for passivation is enabled. For now I'm disabling passivation by commenting out the cache loader config; need to sort out what is going on. -- 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, 9 months

3
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-747) Bad interaction between session passivation and buddy replication

by Brian Stansberry (JIRA)

Bad interaction between session passivation and buddy replication ----------------------------------------------------------------- Key: JBCACHE-747 URL: http://jira.jboss.com/jira/browse/JBCACHE-747 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: 2.0.0 I've seen server startup issues when in the tc6-cluster.sar buddy replication is enabled AND the cache loader used for passivation is enabled. May be a generic JBC issue rather than something in the http session code. JBAS-3571 is the main issue; I'm just opening a parallel one in JBC 'cause 2.0.0.Beta will go out before 5.0.0.Beta and I want to be sure I look at this before 2.0.0.Beta. -- 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, 9 months

2
2
0 / 0

[JBoss JIRA] Created: (JBAS-3809) Upgrade JGroups to 2.4

by Bela Ban (JIRA)

Upgrade JGroups to 2.4 ---------------------- Key: JBAS-3809 URL: http://jira.jboss.com/jira/browse/JBAS-3809 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: JGroups service Reporter: Bela Ban Assigned To: Bela Ban Fix For: JBossAS-4.2.0.CR1 Upgrade JGroups to 2.4 -- 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, 9 months

2
7
0 / 0

[JBoss JIRA] Updated: (JBAS-2823) Upgrade commons-logging to Release 1.1.0

by Brian Stansberry (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2823?page=all ] Brian Stansberry updated JBAS-2823: ----------------------------------- Comment: was deleted > Upgrade commons-logging to Release 1.1.0 > ---------------------------------------- > > Key: JBAS-2823 > URL: http://jira.jboss.com/jira/browse/JBAS-2823 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: JBossAS-4.0.2 Final, JBossAS-4.0.3 Final, JBossAS-4.0.3 SP1 > Environment: Windows XP Professional, JDK 1.5.0 > Reporter: Martin Lui > Priority: Optional > > The Apache commons-logging package has release version 1.1.0. > Please upgrade this library to take advantage of items listed in the release notes: > http://jakarta.apache.org/commons/logging/RELEASE-NOTES.txt > It would be helpful if this upgrade can be done to upgrade the server libraries since individual EAR files cannot overwrite this particular library. > Also, looking through the notes and searching for information on the 1.0.4 patch, it appears that the WeakHashTables memory-leak fix is included in 1.1.0. (Bug 31286: http://issues.apache.org/bugzilla/show_bug.cgi?id=31286) > Depending on how JBoss uses this package, upgrading should be as simple as replacing the current package (though I admit I had not try doing so yet). -- 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, 9 months

1
0
0 / 0

Telefonía IP al alcance de TODOS!

by FonoIP

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBESB-264) Add a purely local registry based on file

by Mark Little (JIRA)

Add a purely local registry based on file ----------------------------------------- Key: JBESB-264 URL: http://jira.jboss.com/jira/browse/JBESB-264 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Registry Reporter: Mark Little Assigned To: Mark Little Fix For: 5.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

17 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBESB-216) Null or empty p_xmlString using TestJBossESB.sh in Cygwiin

by Daniel Brum (JIRA)

Null or empty p_xmlString using TestJBossESB.sh in Cygwiin ---------------------------------------------------------- Key: JBESB-216 URL: http://jira.jboss.com/jira/browse/JBESB-216 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 4.0 Beta 1 Maintenance Pack 1 Reporter: Daniel Brum Assigned To: Jason Lenhart Fix For: 4.0 RC1 The testJBossESB.sh from subversion passes the wrong file as a parameter. It passes in paramsDir/FileMoverConfigExampleJason.xml when it should pass in paramsDir/FileMoverConfigExample.xml (notice no "Jason"). Of course, FileMoverConfigExampleJason.xml does not exist in the repository checkout. It would rock if someone with commit access could remove the "Jason" from testJBossESB.sh. It's just subtle enough to miss for quite a while if you're not super careful. While you're at it, I'd recommend making the changes to work with cygwin too (see my previous post for an example, which borrows very heavily from the JBoss AS run.sh) so that future checkouts will work out the box. -- 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, 9 months

3
6
0 / 0

[JBoss JIRA] Created: (JBESB-194) Trailblazer configuration script needs to support being run from both an SVN checkout and a distro download

by Tom Fennelly (JIRA)

Trailblazer configuration script needs to support being run from both an SVN checkout and a distro download ----------------------------------------------------------------------------------------------------------- Key: JBESB-194 URL: http://jira.jboss.com/jira/browse/JBESB-194 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0 Reporter: Tom Fennelly Assigned To: Mark Little Fix For: 4.0 One the the things the Trailblazer "ant confiure" target does is to work out some relative paths for the trailblazer configurations. It uses ant to inject these values into the configurations using a filtering copy process. It's currently coded to work based on the project structure as checked out from SVN. This structure is different to that encountered by the script when run from a distro download. The script needs to be modified to accomodate both structures. If this script is getting replaced for the 4.0 GA release by something like izPack, we can zap this issue. -- 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, 9 months

2
4
0 / 0

[JBoss JIRA] Commented: (JBCACHE-11) Memory based eviction policy

by Elias Ross (JIRA)

[ http://jira.jboss.com/jira/browse/JBCACHE-11?page=comments#action_12348184 ] Elias Ross commented on JBCACHE-11: ----------------------------------- I was thinking of implementing something like this, since it's fairly straightfoward. Or so I thought.... Eviction based on, say a fraction of total free memory, would make sense. In Java 1.5, it is easy to get the MXBean that return heap information, etc. What users might want to do is specify how much memory is allocated for a particular cache (region), or to a percentage of the maximum heap storage for caching... not to simply evict on some arbitrary percentage of memory free. Somehow this seems a bit unstable. If it were possible, calcuating a cache's exact memory footprint would be ideal. I believe, though, with some sort of sampling (and maybe by serializing the data itself), a "good enough" estimate could be obtained. And actually, providing an estimated size of the cache (in bytes) would be useful to know as a user. For commonly-kept objects (such as "String" or "integer"), using the Java "SizeOf" program should produce a good size estimate of these types. Sampling should be done randomly, of course, and if just perhaps 1% of the objects were sampled, > Memory based eviction policy > ---------------------------- > > Key: JBCACHE-11 > URL: http://jira.jboss.com/jira/browse/JBCACHE-11 > Project: JBoss Cache > Issue Type: Feature Request > Affects Versions: 2.0.0.GA > Reporter: Bela Ban > Assigned To: Ben Wang > Priority: Optional > Fix For: 2.1.0.GA > > Original Estimate: 2 weeks > Remaining Estimate: 2 weeks > > (maybe only in JDK 1.5, which has > triggers for low memory) -- 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, 9 months

1
0
0 / 0

[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

17 years, 9 months

1
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2006