April 2008 - jboss-dev-forums - Jboss List Archives

[Design of Clustering on JBoss (Clusters/JBoss)] - Solution of JBREM-954 and ramifications into UnifiedInvokerH

by galder.zamarreno＠jboss.com

JBREM-954 First things firts, I believe that Remoting and AS as a whole, in the context of an EJB application, is a library and hence should not swallow the interruption request and instead rethrow it. I think everyone agrees on that. I've meaning to start a topic on this due to the ramifications it has on the UnifiedInvokerHAProxy. In principle, resolving JBREM-954 should be simple, i.e. rethrowing InterruptedException (or some form of it - IE for abbreviation) instead of CannotConnectException. Main issue here is that, from UnifiedInvokerHAProxy's point of view, it throws back an IE as it is. So, if UnifiedInvokerHAProxy did nothing about it and threw it back as it is, unless the EJB declared that it could throw an IE, the client would get a java.lang.reflect.UndeclaredThrowableException wrapping the IE. This is not nice and I don't think we can expect for all EJBs to declare IE. The cleanest solution I can think of is for either Remoting or the Unified invoker layer to rethrow an IE wrapped inside a RuntimeException and let the users deal with it appropiately. The unified invoker ha proxy does not differenciate between IE or RE, so we would be able to cope with both situations. Seeing that we already do some exception laundering in the Unified invoker HA proxy, I'd probably go for the laundering of IE into RE wrapping IE to happen there. Thoughts? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4145783#4145783 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4145783

16 years, 5 months

1
0
0 / 0

[Design of Clustering on JBoss (Clusters/JBoss)] - Re: JBAS-5233 - Logging synchronous cluster wide RPC calls a

by galder.zamarreno＠jboss.com

Thoughts anyone? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4145778#4145778 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4145778

16 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: File locking

by adrian＠jboss.org

"alesj" wrote : | See URLExistsUnitTestCase in JBossVFS. | What is the purpose of this test? It is testing the JDK rather than the VFS so why is it in the VFS testsuite? Surely this code: | conn = tmpURL.openConnection(); | lastModified = conn.getLastModified(); | should be changed to use the VFS to check the getLastModified works and assert the file can still be deleted? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4145771#4145771 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4145771

16 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: File locking

by adrian＠jboss.org

"alesj" wrote : | But in the case of jar file, see 2nd test in URLExistsUnitTestCase, I cannot do the same hack, since it complains about not specifying the entry: | | | java.io.IOException: no entry name specified | | at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:129) | | at org.jboss.test.virtual.test.URLExistsUnitTestCase.testJarURLs(URLExistsUnitTestCase.java:102) | | For the top level jar file you should be using the file: url not the jar: url A top level jar is a file :-) There used to be a HACK in the VFS JAR code that worked around this issue, i.e. it reworked the URL based on the parent but I don't see it in the current codebase? It probably got removed when the url handling was reworked? Also you need to be careful with JAR files and their URL connections. The JDK caches them internally and can even mmap them on some operating systems. So testing a jar entry has changed isn't the same thing as checking the top level file changed. Additionally, closing the top jar connection will close the cached version which can lead to strange errors. The internal caching is the source of the problems (e.g. locking on windows) and something Sun have consistently refused to fix. :-( View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4145769#4145769 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4145769

16 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: File locking

by alesj

"adrian(a)jboss.org" wrote : | I guess it would need something to explictly close() | the URLConnection or JarFile created in the JARHandler constructor | when it is unpacked and replaced? | How are you gonna do that? :-) Since URLConnection doesn't have anything useful to do a close. See below for more info. "adrian(a)jboss.org" wrote : | i.e. My guess is something is keeping a reference previous | packed VirtualFile and hence to the JarFile which means the | connection/file handle is kept open. | When we do lastModified, for HDScanning purposes, we mostly use URLConnection::getLastModified, which is probably the cause for open handle. See URLExistsUnitTestCase in JBossVFS. In the case of non-jar file, I was able to do this hacky thing: | InputStream in = conn.getInputStream(); | long lastModified; | try | { | lastModified = conn.getLastModified(); | System.out.println("lastModified, "+lastModified); | assertNotSame("lastModified", 0, lastModified); | } | finally | { | in.close(); | } | assertTrue(tmp.getAbsolutePath()+" deleted", tmp.delete()); | Open/close input stream, and was then allowed to delete the file. W/o this, you cannot delete the file. But in the case of jar file, see 2nd test in URLExistsUnitTestCase, I cannot do the same hack, since it complains about not specifying the entry: | java.io.IOException: no entry name specified | at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:129) | at org.jboss.test.virtual.test.URLExistsUnitTestCase.testJarURLs(URLExistsUnitTestCase.java:102) | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4145764#4145764 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4145764

16 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: File locking

by alesj

"adrian(a)jboss.org" wrote : | "alesj" wrote : | | Can someone try how we stand with this on Linux? | | | There's no locking issue on Linux. | It will however manifest itself as a "leaked" | open file. | | I guess it would need something to explictly close() | the URLConnection or JarFile created in the JARHandler constructor | when it is unpacked and replaced? | | i.e. My guess is something is keeping a reference previous | packed VirtualFile and hence to the JarFile which means the | connection/file handle is kept open. | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4145754#4145754 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4145754

16 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - File locking

by alesj

Moving file locking issue to the forum. I tried using the feature I recently added - explicit unpacking of archives - with top level .ear file. Adding this jboss-structure.xml to ear's META-INF directory does the trick of unpacking ear into tmp directory, but still doesn't allow the original ear file to be deleted. | <structure> | <context modification="Unpack"> | <path name=""/> | <metaDataPath> | <path name="META-INF"/> | </metaDataPath> | </context> | <context> | <path name="inner.war"/> | <metaDataPath> | <path name="WEB-INF"/> | </metaDataPath> | </context> | </structure> | I guess when you do any kind of reading inside file, in this case reading the contents of jboss-structure.xml, the file gets locked. I don't see how we can get past this w/o rewriting how URL(Connection)s are handled. Can someone try how we stand with this on Linux? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4145753#4145753 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4145753

16 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Annotation scanning

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : "alesj" wrote : | | To address Kabir'rs issue I'd suggest something like: | | | | | public interface ClassVisitor | | | { | | | void visit(URL classURL, String className, ClassLoader cl); | | | } | | | | | /quote] | | | | Actually I'd suggest | | | | | public interface ClassVisitor | | | { | | | void visit(ClassContext cc); | | | } | | | | | | | Then we can add new parameters and ease of use methods to ClassContext | | as required. e.g. | | ClassContext.getBytes(); | | which will do all the work to open the stream and read the bytes from it. | | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4145748#4145748 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4145748

16 years, 5 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Annotation scanning

by adrian＠jboss.org

"alesj" wrote : | So, what would be a good entry point into this in our classloading? | Part of ClassLoadingPolicy? | The entry point should be the module, which probably mean it delegates to the ClassLoadingPolicy (when the module is implemented by ClassLoadingPolicy :-) But this is only for the Class visitor. The rest of the annotation processing should be in the deployers project. To address Kabir'rs issue I'd suggest something like: | public interface ClassVisitor | { | void visit(URL classURL, String className, ClassLoader cl); | } | So you can do URL.openStream() and pass it to javassit. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4145745#4145745 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4145745

16 years, 5 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJB3 container for EJB2 beans

by alex.loubyansky＠jboss.com

The reason is Class.getInterfaces() doesn't return the interfaces inherited from the superclass. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4145730#4145730 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4145730

16 years, 5 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 April 2008