[JBoss JIRA] Created: (JBMICROCONT-157) Leak due to VirtualFileURLConnection.class.urlCache()
by Scott M Stark (JIRA)
Leak due to VirtualFileURLConnection.class.urlCache()
-----------------------------------------------------
Key: JBMICROCONT-157
URL: http://jira.jboss.com/jira/browse/JBMICROCONT-157
Project: JBoss MicroContainer
Issue Type: Bug
Components: VFS
Affects Versions: JBossMC_2_0_0 Beta3
Reporter: Scott M Stark
Assigned To: Scott M Stark
Fix For: JBossMC_2_0_0_CR1
> I think I got another one.
> There is a static ref to the VFS in VirtualFileURLConnection. In the end
> the VirtualFile is kept in memory. See left bottom on the picture. If
> these are the things to look for, then I got a bundle more.
> Note that the VirtualFile is actually a reference to an EJB3 deployment,
> so it's probably EJB3 code not cleaning up properly. But this shouldn't
> lock down a ref in VFS.
There is definately a memory leak in
VirtualFileURLConnection.class.urlCache(). It grows without bounds.
After an incomplete JBossWS test run 53 megs of heap is tied to this
cache.
--
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
16 years, 1 month
[JBoss JIRA] Created: (JBMICROCONT-185) Deployment tests need completing
by Adrian Brock (JIRA)
Deployment tests need completing
--------------------------------
Key: JBMICROCONT-185
URL: http://jira.jboss.com/jira/browse/JBMICROCONT-185
Project: JBoss MicroContainer
Issue Type: Task
Components: Deployment
Reporter: Adrian Brock
Fix For: JBossMC_2_0_0_CR1
There are a number of TODOs in the deployer tests.
Additionally, some areas could do with some more testing.
Existing TODOs listed here, but really need subtasks
MockEAR tests
// TODO: need to scan for annotationss
if (scan)
{
throw new RuntimeException("Scanning not implemented: "+file.getName());
}
EARStructure test - this looks broken to me?
public void testNotAnEAR() throws Throwable
{
// TODO ??? This gets recognised by the jar deployer assertNotValid("/structure/ear", "notanear");
}
HACK to make tests work with Maven? - AbstractStructureTest
protected VirtualFile getVirtualFile(String root, String path) throws Exception
{
// TODO THIS IS HACK TO MAKE THE TEST WORK IN MAVEN ???
try
{
URL.setURLStreamHandlerFactory(new URLStreamHandlerFactory()
{
public URLStreamHandler createURLStreamHandler(String protocol)
{
if ("vfsfile".equals(protocol))
return new Handler();
return null;
}
});
}
catch (Error ignored)
{
}
URL url = getResource(root);
Field field = URL.class.getDeclaredField("factory");
field.setAccessible(true);
return VFS.getVirtualFile(url, path);
}
VFSStructureBuilderTest - needs proper testing that the correct classpath was obtained
protected void checkClassPath(VFSDeploymentContext context, ContextInfo contextInfo) throws Exception
{
List<ClassPathEntry> classPathEntries = contextInfo.getClassPath();
List<VirtualFile> classPath = context.getClassPath();
if (classPathEntries == null)
assertNull(classPath);
else
{
// TODO test it got the correct classpath
}
}
--
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
16 years, 1 month
[JBoss JIRA] Created: (JBDEPLOY-56) Unexpected error during load of:javax.xml.parsers.SecuritySupport12, via AnnotatedClassFilter.accepts()
by Darryl Miles (JIRA)
Unexpected error during load of:javax.xml.parsers.SecuritySupport12, via AnnotatedClassFilter.accepts()
-------------------------------------------------------------------------------------------------------
Key: JBDEPLOY-56
URL: http://jira.jboss.com/jira/browse/JBDEPLOY-56
Project: JBoss Deployers
Issue Type: Bug
Environment: JBoss 5.0.0.CR1 (JDK6)
Reporter: Darryl Miles
Unexpected exception during deployment operation of WAR.
03:06:58,431 WARN [ClassLoaderManager] Unexpected error during load of:javax.xml.parsers.SecuritySupport12
java.lang.IllegalAccessError: class javax.xml.parsers.SecuritySupport12 cannot access its superclass javax.xml.parsers.SecuritySupport
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:63)
at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:502)
at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:462)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:460)
at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:437)
at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134)
at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131)
at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:452)
at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:254)
at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:148)
at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:196)
at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1009)
at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:728)
at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:372)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at org.jboss.deployment.AnnotatedClassFilter.accepts(AnnotatedClassFilter.java:121)
at org.jboss.deployment.AnnotatedClassFilter.visit(AnnotatedClassFilter.java:102)
at org.jboss.virtual.plugins.vfs.helpers.WrappingVirtualFileHandlerVisitor.visit(WrappingVirtualFileHandlerVisitor.java:62)
at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:264)
at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:279)
at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:279)
at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:209)
at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:277)
at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:209)
at org.jboss.virtual.VFS.visit(VFS.java:330)
at org.jboss.virtual.VirtualFile.visit(VirtualFile.java:383)
at org.jboss.deployment.AnnotationMetaDataDeployer.getClasses(AnnotationMetaDataDeployer.java:215)
at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:182)
at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:97)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:174)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:970)
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:911)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1392)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:784)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:912)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:834)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:672)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:455)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:594)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:541)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:290)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:221)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
03:06:58,449 WARN [ClassLoaderManager] Unexpected error during load of:javax.xml.transform.SecuritySupport12
java.lang.IllegalAccessError: class javax.xml.transform.SecuritySupport12 cannot access its superclass javax.xml.transform.SecuritySupport
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:63)
at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:502)
at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:462)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:460)
at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:437)
at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134)
at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131)
at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:452)
at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:254)
at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:148)
at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:196)
at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1009)
at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:728)
at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:372)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at org.jboss.deployment.AnnotatedClassFilter.accepts(AnnotatedClassFilter.java:121)
at org.jboss.deployment.AnnotatedClassFilter.visit(AnnotatedClassFilter.java:102)
at org.jboss.virtual.plugins.vfs.helpers.WrappingVirtualFileHandlerVisitor.visit(WrappingVirtualFileHandlerVisitor.java:62)
at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:264)
at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:279)
at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:279)
at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:209)
at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:277)
at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:209)
at org.jboss.virtual.VFS.visit(VFS.java:330)
at org.jboss.virtual.VirtualFile.visit(VirtualFile.java:383)
at org.jboss.deployment.AnnotationMetaDataDeployer.getClasses(AnnotationMetaDataDeployer.java:215)
at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:182)
at org.jboss.deployment.AnnotationMetaDataDeployer.deploy(AnnotationMetaDataDeployer.java:97)
at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:174)
at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:970)
at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:911)
at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1392)
at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:784)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:912)
at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:834)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:672)
at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:455)
at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:594)
at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:541)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:290)
at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:221)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
--
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
16 years, 1 month
[JBoss JIRA] Created: (JBAS-4071) Provide information about non-XA resource participating in multibranch transactions
by Mauricio Seeberger (JIRA)
Provide information about non-XA resource participating in multibranch transactions
-----------------------------------------------------------------------------------
Key: JBAS-4071
URL: http://jira.jboss.com/jira/browse/JBAS-4071
Project: JBoss Application Server
Issue Type: Patch
Security Level: Public (Everyone can see)
Components: Other, Transaction Manager
Affects Versions: JBossAS-5.0.0.Beta1, JBossAS-4.0.5.GA
Environment: Linux 2.6.9 RHEL4 on AMD64 and jdk 1.5.0_09-amd64.
Reporter: Mauricio Seeberger
When you have more than one non-XA resource participating in a multibranch transaction, then you have a problem in your code and sooner or later it will result in inconsistent data. But JBoss (TxConnectionManager) just logs just once a generic message:
Prepare called on a local tx. Use of local transactions on a jta transaction with more than one branch may result in inconsistent data in some cases of failure.
We need more information about the resource and a stack trace for identifying the malicious code.
--
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
16 years, 1 month
[JBoss JIRA] Created: (JGRP-805) Message getHeaders not protected from concurrent modification
by Michal Frajt (JIRA)
Message getHeaders not protected from concurrent modification
-------------------------------------------------------------
Key: JGRP-805
URL: https://jira.jboss.org/jira/browse/JGRP-805
Project: JGroups
Issue Type: Bug
Affects Versions: 2.6.3
Environment: 2.6.3.GA
Reporter: Michal Frajt
Assignee: Bela Ban
We have just downloaded the latest JGroups 2.6.3.GA version for some initial multicast testing. There is no expirience with the API on our side. The initial review of the Message class shows us huge memory requirements of each message instance. The HashMap for headers and the ReentrantReadWriteLock for headers access seems to be a bit to much overhead for messages with the data (buf) lenght of few bytes.
Despite using the heavy RRWLock there is an unprotected read access to the headers map possible. The method getHeaders returns the headers as unmodifiableMap instead of a copy created within the read lock. An iteration over the returned unmodifiableMap might throw ConcurrentModificationException as the same headers map object might be modified using the putHeader method.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 1 month