[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
[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
[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
[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