December 2007 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Re: NoCopyNestedJarHandler usage

by alesj

"scott.stark(a)jboss.org" wrote : | What is calling URL.openStream in this trace? | Usually it's some dynamic EL stuff: | http-127.0.0.1-8080-1 [RUNNABLE] | java.util.zip.ZipFile.getNextEntry(native method) | java.util.zip.ZipFile.access$700(ZipFile.java:35) | java.util.zip.ZipFile$3.nextElement(ZipFile.java:421) | java.util.zip.ZipFile$3.nextElement(ZipFile.java:415) | java.util.jar.JarFile$1.nextElement(JarFile.java:221) | java.util.jar.JarFile$1.nextElement(JarFile.java:220) | org.jboss.virtual.plugins.context.jar.AbstractStructuredJarHandler$JarEntryEnumeration.nextElement(AbstractStructuredJarHandler.java:347) | org.jboss.virtual.plugins.context.jar.AbstractStructuredJarHandler$JarEntryEnumeration.nextElement(AbstractStructuredJarHandler.java:329) | org.jboss.virtual.plugins.context.jar.AbstractStructuredJarHandler.initJarFile(AbstractStructuredJarHandler.java:133) | org.jboss.virtual.plugins.context.jar.AbstractStructuredJarHandler.initJarFile(AbstractStructuredJarHandler.java:107) | org.jboss.virtual.plugins.context.jar.JarHandler.<init>(JarHandler.java:79) | org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:182) | org.jboss.virtual.plugins.context.file.FileHandler.getChildren(FileHandler.java:177) | org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:242) | org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:189) | org.jboss.virtual.plugins.context.file.FileHandler.createChildHandler(FileHandler.java:214) | org.jboss.virtual.plugins.context.AbstractVirtualFileHandler.structuredFindChild(AbstractVirtualFileHandler.java:359) | org.jboss.virtual.plugins.context.file.FileHandler.findChild(FileHandler.java:197) | org.jboss.virtual.plugins.context.AbstractVFSContext.findChild(AbstractVFSContext.java:125) | org.jboss.virtual.VFS.findChild(VFS.java:208) | org.jboss.virtual.plugins.vfs.VirtualFileURLConnection.resolveVirtualFile(VirtualFileURLConnection.java:96) | org.jboss.virtual.plugins.vfs.VirtualFileURLConnection.getVirtualFile(VirtualFileURLConnection.java:109) | org.jboss.virtual.plugins.vfs.VirtualFileURLConnection.getInputStream(VirtualFileURLConnection.java:117) | java.net.URL.openStream(URL.java:1007) | sun.misc.URLClassPath$Loader.findResource(URLClassPath.java:472) | sun.misc.URLClassPath.findResource(URLClassPath.java:142) | java.net.URLClassLoader$2.run(URLClassLoader.java:362) | java.security.AccessController.doPrivileged(native method) | java.net.URLClassLoader.findResource(URLClassLoader.java:359) | java.lang.ClassLoader.getResource(ClassLoader.java:977) | org.jboss.mx.loading.RepositoryClassLoader.getResourceLocally(RepositoryClassLoader.java:265) | org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:265) | org.jboss.mx.loading.UnifiedClassLoader.loadClassImpl(UnifiedClassLoader.java:290) | org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:441) | java.lang.ClassLoader.loadClass(ClassLoader.java:251) | java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) | org.jboss.el.parser.ELParser.<init>(ELParser.java:1898) | org.jboss.el.lang.ExpressionBuilder.createNodeInternal(ExpressionBuilder.java:98) | org.jboss.el.lang.ExpressionBuilder.build(ExpressionBuilder.java:151) | org.jboss.el.lang.ExpressionBuilder.createValueExpression(ExpressionBuilder.java:195) | org.jboss.el.ExpressionFactoryImpl.createValueExpression(ExpressionFactoryImpl.java:68) | org.jboss.seam.el.SeamExpressionFactory.createValueExpression(SeamExpressionFactory.java:98) | com.sun.facelets.tag.TagAttribute.getValueExpression(TagAttribute.java:256) | com.sun.facelets.tag.jsf.ValueHolderRule$DynamicValueExpressionMetadata.applyMetadata(ValueHolderRule.java:101) | "scott.stark(a)jboss.org" wrote : | A VirtualFileURLConnection.getInputStream cache might be one cache to introduce. The AbstractURLHandler.openStream would be the other place. The main problem will be making sure these streams are closed to avoid leaks/locks. | How do you cache a stream? Wouldn't it be easier to somehow cache the 'url --> virtual file' mapping? Some timer fifo cache? An abstraction plugable into our JBoss Cache? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4116143#4116143 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4116143

16 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: NoCopyNestedJarHandler usage

by alesj

"scott.stark(a)jboss.org" wrote : Just a simple URLClassLoader based tests in the mc project should be fine to validate whether the resource can be loacated with a class loader with the same vfsurl in the classpath. | If it's a simple URL CL, then I'll add the test directly into VFS. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4116142#4116142 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4116142

16 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: NoCopyNestedJarHandler usage

by scott.stark＠jboss.org

"alesj" wrote : OK, NoCopy speeds things up. | But doing some more profiling, looks like our VirtualFileURLConnection is the cause of it all. :-) | | Creating new VirtualFile for every new connection. Meaning it builds the whole jar structure to get to a single resource. | | Scott, does your url-connection branch deal with this? | Or where/how to plug-in this sore of cache: url --> virtual file? The urlconn branch does not introduce extra caching, it just avoid relying on the URL details. What is calling URL.openStream in this trace? A VirtualFileURLConnection.getInputStream cache might be one cache to introduce. The AbstractURLHandler.openStream would be the other place. The main problem will be making sure these streams are closed to avoid leaks/locks. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4116137#4116137 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4116137

16 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: NoCopyNestedJarHandler usage

by scott.stark＠jboss.org

"alesj" wrote : | The classname is OK, it's just that classloader pushed to AnnotationMetaDataDeployer doesn't recognize it. | | ... | | Add a test for this type of usage. | Based on the exception, the problem is the class loader appears to have the class packaged index, but the class cannot be loaded. I have added some additional trace to see if this is just a resource loading problem, or the class does not actually exist for this class loader. Just a simple URLClassLoader based tests in the mc project should be fine to validate whether the resource can be loacated with a class loader with the same vfsurl in the classpath. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4116134#4116134 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4116134

16 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: NoCopyNestedJarHandler usage

by alesj

OK, NoCopy speeds things up. But doing some more profiling, looks like our VirtualFileURLConnection is the cause of it all. :-) Getting loads of this: | http-127.0.0.1-8080-3 [RUNNABLE] | java.util.zip.ZipFile.freeEntry(native method) | java.util.zip.ZipFile.access$1100(ZipFile.java:35) | java.util.zip.ZipFile$3.nextElement(ZipFile.java:438) | java.util.zip.ZipFile$3.nextElement(ZipFile.java:415) | java.util.jar.JarFile$1.nextElement(JarFile.java:221) | java.util.jar.JarFile$1.nextElement(JarFile.java:220) | org.jboss.virtual.plugins.context.jar.AbstractStructuredJarHandler$JarEntryEnumeration.nextElement(AbstractStructuredJarHandler.java:347) | org.jboss.virtual.plugins.context.jar.AbstractStructuredJarHandler$JarEntryEnumeration.nextElement(AbstractStructuredJarHandler.java:329) | org.jboss.virtual.plugins.context.jar.AbstractStructuredJarHandler.initJarFile(AbstractStructuredJarHandler.java:133) | org.jboss.virtual.plugins.context.jar.AbstractStructuredJarHandler.initJarFile(AbstractStructuredJarHandler.java:107) | org.jboss.virtual.plugins.context.jar.JarHandler.<init>(JarHandler.java:79) | org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:182) | org.jboss.virtual.plugins.context.file.FileHandler.getChildren(FileHandler.java:177) | org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:242) | org.jboss.virtual.plugins.context.file.FileSystemContext.createVirtualFileHandler(FileSystemContext.java:189) | org.jboss.virtual.plugins.context.file.FileHandler.createChildHandler(FileHandler.java:214) | org.jboss.virtual.plugins.context.AbstractVirtualFileHandler.structuredFindChild(AbstractVirtualFileHandler.java:359) | org.jboss.virtual.plugins.context.file.FileHandler.findChild(FileHandler.java:197) | org.jboss.virtual.plugins.context.AbstractVFSContext.findChild(AbstractVFSContext.java:125) | org.jboss.virtual.VFS.findChild(VFS.java:208) | org.jboss.virtual.plugins.vfs.VirtualFileURLConnection.resolveVirtualFile(VirtualFileURLConnection.java:96) | org.jboss.virtual.plugins.vfs.VirtualFileURLConnection.getVirtualFile(VirtualFileURLConnection.java:109) | org.jboss.virtual.plugins.vfs.VirtualFileURLConnection.getInputStream(VirtualFileURLConnection.java:117) | java.net.URL.openStream(URL.java:1007) | Creating new VirtualFile for every new connection. Meaning it builds the whole jar structure to get to a single resource. Scott, does your url-connection branch deal with this? Or where/how to plug-in this sore of cache: url --> virtual file? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4116124#4116124 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4116124

16 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Basic performance figures for MINA transport

by timfox

I would be very interesting in seeing some basic performance figures for the new transport. E.g. two machines on commodity hardware, connected by gigabit ethernet (direct or through switch). Test throughput for 1) One way invocations (both client-server and server-client) 2) Two way invocations With a few different values for payload: e.g. 256 byte, 1K, 10K, 100K View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4116087#4116087 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4116087

16 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JBM 2.0 JDBCPersistenceManager - volunteers?

by timfox

Hi Tyronne- Any more progress on this? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4116082#4116082 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4116082

16 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - A few more comments on new transport

by timfox

A few more comments 1. Client class should be interface - so it can be mocked out for clebert and others. 2. Correlation id should be counter? 3. Connector registry should be interface. 4. Packet dispatcher should be interface and have unit test. 5. Logging filter currently hardcoded to trace. 6. MINAService should be interface? 7. Why do we need PacketDispatcher.clent and .server? apart from invm case only one of these would be used? so instantianting unnecessary objects 8. Why not combine the codec class and the packet class - not sure why not separate classes 9. why register different codecs for each messsage type? why not just register one and lookup based on the message type? 10. We need to guarantee order per session - need to use the MINA OrderedThreadPoolExecutor? (otherwise messages might arrive out of order). 11. As mentioned before, need to test the actual contents of the byte buffer is what is expected in packettest - currently not being done. 12. MINA dependent classes should be in integration sub directory 13. core.remoting directory should only contain interfaces - currently contains implementations too View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4116081#4116081 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4116081

16 years, 10 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: New wireformat and client side remoting

by timfox

"jmesnil" wrote : | In the branch, I've added a version byte to all the packets of the new remote API to mimic the current behaviour of JBoss Remoting. I think we just just add the version byte on the create connection request. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4116080#4116080 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4116080

16 years, 10 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: NoCopyNestedJarHandler usage

by alesj

"scott.stark(a)jboss.org" wrote : We need tests that validate that the package scanning and resource checking done by the UCL class loader works with these urls. The location of this error indicates that taking the class name and making it a resource name, and calling getResource on the class loader is not working: | | | | String classRsrcName = classname.replace('.', '/') + ".class"; | | URL url = ucl.getResource(classRsrcName); | | | The classname is OK, it's just that classloader pushed to AnnotationMetaDataDeployer doesn't recognize it. "scott.stark(a)jboss.org" wrote : | Add a test for this type of usage. | In the AS5 testsuite? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4116040#4116040 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4116040

16 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums December 2007