[Design of JCA on JBoss] - [JBAS-5095] Race condition between connection.close() and tr
by jesper.pedersen
I have been looking at subject for both 5.0.CR2 and 4.2.4.GA.
As Adrian states there is a race condition between connection.close() and an asynchronous transaction completion (e.g. transaction timeout) that can lead to a leaked connection permit with eventual pool exhaustion when using track-connection-by-tx (i.e. all local resources).
The fix (has he states) is to check that the number of handles are zero and the connection no longer is track-by-tx in an atomic way.
I have introduced a reentrant lock that is used when isManagedConnectionFree() is used in combination with returnManagedConnection(). The lock is defined as an instance variable in TxConnectionManager - and the code is guarded using the lock() / unlock() methods.
The overhead of the reentraant lock is minimal when operating with track-by-tx == false and the lock only comes into play in afterCompletion() when track-by-tx is true.
The patch have been attached to the JIRA issue for review.
Any feedback is welcomed !
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166381#4166381
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166381
17 years, 8 months
[Design the new POJO MicroContainer] - Re: JBoss with spaces in the directory name
by alesj
"adrian(a)jboss.org" wrote :
| I'd guess the fix invloves adding a
| URLDecoder.decode(uri, "UTF-8");
| to FileSystemContext.getFile(URI)
| but there might be other places that need this fix?
Shouldn't the URI and File take care of those %20 'chars'?
I'm trying to put together a test that would fail,
but so far no luck. :-)
I've added this
| public void testPathWithSpaces() throws Throwable
| {
| String path = "/test/pckg with spaces/somefile.txt";
| VirtualFile vf = testPath(path);
| assertNotNull(vf);
| URI uri = getResource("/vfs").toURI();
| String uriPath = uri.getPath();
| URI fileURI = vf.toURI();
| String fileURIPath = fileURI.getPath();
| assertEquals(uriPath + path, fileURIPath);
| }
|
but all is ok. :-)
Since your case fails when looking up child,
perhaps a proper fix would be to fix the path
in VirtualFile::getChild.
| public static String fixName(String name)
| {
| if (name == null)
| throw new IllegalArgumentException("Null name");
|
| int length = name.length();
| if (length <= 1)
| return name;
| if (name.charAt(length-1) == '/')
| return name.substring(0, length-1);
|
| return decode(name);
| }
|
| /**
| * Decode the path with UTF-8 encoding..
| *
| * @param path the path to decode
| * @return decoded path
| */
| public static String decode(String path)
| {
| return decode(path, DEFAULT_ENCODING);
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166377#4166377
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166377
17 years, 8 months
[Design of AOP on JBoss (Aspects/JBoss)] - Re: AOPConstructorJoinpoint and methodHasSubInstanceMetaData
by kabir.khan＠jboss.com
"adrian(a)jboss.org" wrote : "kabir.khan(a)jboss.com" wrote :
| | So it would seem that when creating the properties for the bean, it uses the MetaData for the bean, which does not contain the methods for the properties. Maybe we need to call MetaDataStack.mask() as part of ConfigureAction.setAttributes()?
| |
|
| Is that the cause or are you guessing?
|
| Do you know where the wrong ConstructorInfo is coming from.
I believe it is the cause, but I am not so familiar with that part of MC. Let's call it an educated guess :-) Looking at EndpointRecordProcessorDeploymentAspect, it does contain a List property called "processors". Setting a breakpoint again, different class this time, it fails for a bean of type org.jboss.ejb3.cache.CacheFactoryRegistry. This contains a property
| public class CacheFactoryRegistry
| {
| // Instance Members
| private Map<String, Class<? extends Ejb3CacheFactory>> factories;
|
| // Accessors / Mutators
|
| public Map<String, Class<? extends Ejb3CacheFactory>> getFactories()
| {
| return factories;
| }
|
| public void setFactories(Map<String, Class<? extends Ejb3CacheFactory>> factories)
| {
| this.factories = factories;
| }
| ...
| }
|
The stack trace this time is
| AnnotatedElementMetaDataLoader.getComponentMetaDataRetrieval(Signature) line: 150
| AbstractMetaDataContext.getComponentMetaDataRetrieval(Signature) line: 276
| MetaDataRetrievalToMetaDataBridge.getComponentMetaData(Signature) line: 160
| AOPConstructorJoinpoint.methodHasSubInstanceMetaData(MetaData, MethodInfo) line: 171
| AOPConstructorJoinpoint.rootHasMethodWithSubInstanceMetaData(MetaData) line: 149
| AOPConstructorJoinpoint.rootHasSubInstanceMetaData(MetaData) line: 129
| AOPConstructorJoinpoint.dispatch() line: 92
| AbstractMapMetaData(AbstractTypeMetaData).createInstance(TypeInfo, ClassLoader, Class<T>, boolean) line: 251
| AbstractMapMetaData(AbstractTypeMetaData).getTypeInstance(TypeInfo, ClassLoader, Class<T>, boolean) line: 292
| AbstractMapMetaData(AbstractTypeMetaData).getTypeInstance(TypeInfo, ClassLoader, Class<T>) line: 271
| AbstractMapMetaData.getValue(TypeInfo, ClassLoader) line: 117
| PropertyDispatchWrapper.execute() line: 87
| PropertyDispatchWrapper(ExecutionWrapper).execute(AccessControlContext) line: 47
| KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContext, ExecutionWrapper) line: 109
| ConfigureAction.dispatchSetProperty(KernelControllerContext, PropertyMetaData, boolean, BeanInfo, Object, ClassLoader) line: 109
| ConfigureAction.setAttributes(KernelControllerContext, Object, BeanInfo, BeanMetaData, boolean) line: 87
| ConfigureAction.installActionInternal(KernelControllerContext) line: 44
| ConfigureAction(InstallsAwareAction).installAction(KernelControllerContext) line: 54
| ConfigureAction(InstallsAwareAction).installAction(ControllerContext) line: 42
| ConfigureAction(SimpleControllerContextAction<T>).simpleInstallAction(T) line: 62
| ConfigureAction(AccessControllerContextAction<S,T>).install(ControllerContext) line: 71
| KernelControllerContextActions(AbstractControllerContextActions).install(ControllerContext, ControllerState, ControllerState) line: 51
| AbstractKernelControllerContext(AbstractControllerContext).install(ControllerState, ControllerState) line: 348
|
The KCC in AbstractKernelControllerContext has the name EJB3CacheFactoryRegistry, and it is of type org.jboss.ejb3.cache.CacheFactoryRegistry.
Looking at ConfigureAction.setAttributes() it iterates over the properties, and is currently on
| AbstractPropertyMetaData@f4561{name=factories value=AbstractMapMetaData@4b5a7b{value=null type=java.util.HashMap}}
|
This then calls dispatchSetProperty() which ends up in AOPConstructorJoinPoint(0 to create the HashMap value to be configured. So it is not a "wrong" ConstructorInfo, the CacheFactoryRegistry was already created properly. It happens when creating the properties.
Convinced?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166375#4166375
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166375
17 years, 8 months
[Design of AOP on JBoss (Aspects/JBoss)] - Re: AOPConstructorJoinpoint and methodHasSubInstanceMetaData
by kabir.khan＠jboss.com
BTW looking at ReflectionUtils.findMethod() it relies on exceptions:
| public static Method findMethod(Class<?> clazz, String name, Class<?>... parameterTypes)
| {
| if (clazz == null)
| return null;
|
| try
| {
| return clazz.getDeclaredMethod(name, parameterTypes);
| }
| catch(Exception ignored)
| {
| }
| return findMethod(clazz.getSuperclass(), name, parameterTypes);
| }
|
Since exceptions are expensive to create, I threw together a small benchmark
| public class TestFindMethods
| {
|
| public static void main(String[] args)
| {
| Class<?> clazz = ArrayList.class;
| //Use the name of one of the last methods from the base class, but with non-matching params
| //(The method is called java.util.AbstractCollection.retainAll(Collection<?>))
| String name = "retainAll";
| Class<?>[] params = new Class<?>[] {Integer.class};
|
| long get = 0;
| long iterate = 0;
| for (int i = 0 ; i < 10000000 ; i++)
| {
| long start1 = System.currentTimeMillis();
| Method m1 = getDeclaredMethod(clazz, name, params);
| get += (System.currentTimeMillis() - start1);
|
| long start2 = System.currentTimeMillis();
| Method m2 = iterateDeclaredMethods(clazz, name, params);
| iterate += (System.currentTimeMillis() - start2);
| }
|
| System.out.println("Get took " + get);
| System.out.println("Iterate took " + iterate);
| }
|
| private static Method getDeclaredMethod(Class clazz, String name, Class<?>[] params)
| {
| try
| {
| return clazz.getDeclaredMethod(name, params);
| }
| catch(Exception e)
| {
|
| }
| clazz = clazz.getSuperclass();
| if (clazz != null)
| {
| return getDeclaredMethod(clazz, name, params);
| }
| return null;
| }
|
| private static Method iterateDeclaredMethods(Class<?> clazz, String name, Class<?>[] params)
| {
| Method[] methods = clazz.getDeclaredMethods();
| for (int i = 0 ; i < methods.length ; i++)
| {
| if (name.equals(methods.getName()))
| {
| Class<?>[] myparams = methods.getParameterTypes();
| if (myparams.length == params.length)
| {
| for (int j = 0 ; j < myparams.length ; j++)
| {
| if (params[j] != myparams[j])
| {
| break;
| }
| return methods;
| }
| }
| }
| }
| clazz = clazz.getSuperclass();
| if (clazz != null)
| {
| return iterateDeclaredMethods(clazz, name, params);
| }
| return null;
| }
| }
|
Running it I get:
| Get took 179658
| Iterate took 112402
|
Of course if we get rid of the cause of not finding these methods then this becomes less relevant.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166373#4166373
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166373
17 years, 8 months
[Design the new POJO MicroContainer] - Re: VFS Performance
by adrian＠jboss.org
"adrian(a)jboss.org" wrote :
| Reading byte code from zip files
|
| | java.util.zip.Inflater.inflateBytes(Inflater.java:Unknown line)
| | java.util.zip.Inflater.inflate(Inflater.java:215)
| | java.util.zip.InflaterInputStream.read(InflaterInputStream.java:128)
| | java.io.FilterInputStream.read(FilterInputStream.java:90)
| | org.jboss.virtual.plugins.context.zip.ZipEntryInputStream.read(ZipEntryInputStream.java:112)
| | org.jboss.classloader.plugins.ClassLoaderUtils.loadByteCode(ClassLoaderUtils.java:150)
| | org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:475)
| | org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:464)
| | java.security.AccessController.doPrivileged(AccessController.java:Unknown line)
| | org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:462)
| |
|
| This one might improve if we wrap the VFS stream in a BufferedInputStream
| in ClassLoaderUtils?
| This looks inefficient, it is listing a parent directory when we do getChild
|
|
| | java.io.UnixFileSystem.checkAccess(UnixFileSystem.java:Unknown line)
| | java.io.File.canRead(File.java:660)
| | org.jboss.virtual.plugins.context.file.FileHandler.getChildren(FileHandler.java:161)
| | org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:337)
| | org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:256)
| | org.jboss.virtual.plugins.context.file.FileHandler.createChildHandler(FileHandler.java:224)
| | org.jboss.virtual.plugins.context.AbstractVirtualFileHandler.structuredFindChild(AbstractVirtualFileHandler.java:509)
| | org.jboss.virtual.plugins.context.file.FileHandler.getChild(FileHandler.java:233)
| | org.jboss.virtual.VirtualFile.getChild(VirtualFile.java:427)
| | org.jboss.classloading.spi.vfs.policy.VFSClassLoaderPolicy.findVirtualFileInfo(VFSClassLoaderPolicy.java:488)
| |
|
| Modified checking
|
|
| | java.io.UnixFileSystem.getLastModifiedTime(UnixFileSystem.java:Unknown line)
| | java.io.File.lastModified(File.java:795)
| | org.jboss.virtual.plugins.context.zip.ZipFileWrapper.getLastModified(ZipFileWrapper.java:140)
| | org.jboss.virtual.plugins.context.zip.ZipEntryContext.getLastModified(ZipEntryContext.java:682)
| | org.jboss.virtual.plugins.context.zip.ZipEntryHandler.getLastModified(ZipEntryHandler.java:92)
| | org.jboss.virtual.plugins.context.DelegatingHandler.getLastModified(DelegatingHandler.java:107)
| | org.jboss.virtual.plugins.context.AbstractVirtualFileHandler.hasBeenModified(AbstractVirtualFileHandler.java:181)
| | org.jboss.virtual.plugins.context.file.FileHandler.getChildren(FileHandler.java:183)
| | org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:337)
| | org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:256)
| |
|
| I keep seeing this, not checked if it is a real inefficiency
|
|
| | org.jboss.virtual.plugins.context.AbstractVirtualFileHandler.getLocalPathName(AbstractVirtualFileHandler.java:230)
| | org.jboss.virtual.plugins.context.zip.ZipEntryContext.isLeaf(ZipEntryContext.java:751)
| | org.jboss.virtual.plugins.context.zip.ZipEntryHandler.isLeaf(ZipEntryHandler.java:110)
| | org.jboss.virtual.plugins.context.AbstractVirtualFileHandler.structuredFindChild(AbstractVirtualFileHandler.java:502)
| | org.jboss.virtual.plugins.context.zip.ZipEntryHandler.getChild(ZipEntryHandler.java:139)
| | org.jboss.virtual.plugins.context.DelegatingHandler.getChild(DelegatingHandler.java:93)
| | org.jboss.virtual.VirtualFile.getChild(VirtualFile.java:427)
| | org.jboss.classloading.spi.vfs.policy.VFSClassLoaderPolicy.findVirtualFileInfo(VFSClassLoaderPolicy.java:488)
| | org.jboss.classloading.spi.vfs.policy.VFSClassLoaderPolicy.findChild(VFSClassLoaderPolicy.java:452)
| | org.jboss.classloading.spi.vfs.policy.VFSClassLoaderPolicy.getResource(VFSClassLoaderPolicy.java:385)
| |
|
| Similarly this
|
|
| | java.util.concurrent.ConcurrentHashMap$Segment.get(ConcurrentHashMap.java:334)
| | java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:731)
| | org.jboss.virtual.plugins.context.zip.ZipEntryContext.getRoot(ZipEntryContext.java:606)
| | org.jboss.virtual.plugins.context.AbstractVirtualFileHandler.getLocalPathName(AbstractVirtualFileHandler.java:230)
| | org.jboss.virtual.plugins.context.zip.ZipEntryContext.isLeaf(ZipEntryContext.java:751)
| | org.jboss.virtual.plugins.context.zip.ZipEntryHandler.isLeaf(ZipEntryHandler.java:110)
| | org.jboss.virtual.plugins.context.AbstractVirtualFileHandler.structuredFindChild(AbstractVirtualFileHandler.java:502)
| | org.jboss.virtual.plugins.context.zip.ZipEntryHandler.getChild(ZipEntryHandler.java:139)
| | org.jboss.virtual.plugins.context.DelegatingHandler.getChild(DelegatingHandler.java:93)
| | org.jboss.virtual.VirtualFile.getChild(VirtualFile.java:427)
| |
|
| I'm still seeing the PathTokenizer showing up
|
|
| | org.jboss.virtual.plugins.vfs.helpers.PathTokenizer.getTokens(PathTokenizer.java:97)
| | org.jboss.virtual.plugins.context.AbstractVirtualFileHandler.structuredFindChild(AbstractVirtualFileHandler.java:475)
| | org.jboss.virtual.plugins.context.zip.ZipEntryHandler.getChild(ZipEntryHandler.java:139)
| | org.jboss.virtual.plugins.context.DelegatingHandler.getChild(DelegatingHandler.java:93)
| | org.jboss.virtual.VirtualFile.getChild(VirtualFile.java:427)
| | org.jboss.classloading.spi.vfs.policy.VFSClassLoaderPolicy.findVirtualFileInfo(VFSClassLoaderPolicy.java:488)
| | org.jboss.classloading.spi.vfs.policy.VFSClassLoaderPolicy.findChild(VFSClassLoaderPolicy.java:452)
| | org.jboss.classloading.spi.vfs.policy.VFSClassLoaderPolicy.getResource(VFSClassLoaderPolicy.java:385)
| | org.jboss.classloader.spi.base.BaseClassLoader$3.run(BaseClassLoader.java:567)
| | org.jboss.classloader.spi.base.BaseClassLoader$3.run(BaseClassLoader.java:564)
| |
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166370#4166370
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166370
17 years, 8 months