August 2009 - jboss-dev-forums - Jboss List Archives

[JBoss OSGi Development] - tests log4j.xml

by adrian＠jboss.org

I've removed this again. Having a default log4j.xml for tests is stupid because of the following reasons. 1) log4j.test.dir is not always set - e.g. impossible to run the tests under eclipse 2) you don't get the logging when you look the test reports in the target folder 3) turning off console logging means you have to hunt around for different information related to the test instead of searching in one place View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251481#4251481 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251481

17 years, 1 month

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] - Re: VFSClassLoaderPolicy backed jboss-cl performance issue

by jaikiran

Thanks Marko, for these details. I'll see if this can help out in some way to reduce the processing that we do. Probably the need to split the path on tokens might be eliminated if we get hold of the correct context and just call the entries.get(path) - ofcourse after ensuring the entries have been inited. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251470#4251470 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251470

17 years, 1 month

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] - Re: VFSClassLoaderPolicy backed jboss-cl performance issue

by mstruk

"jaikiran" wrote : A bit more on a higher level - Assuming we have a ZipEntryContext/Handler, does it know of the entries within that zip? I see a ZipEntryContext.entries Map in the code, but haven't yet figured out whether looking directly into this would indicate the presence/absence of a resource within the zip. | | So if a getChild(String path) is invoked, maybe looking into this "entries" would tell us whether it's present or not? | Yes, ZipEntryContext.entries contains relative path of the entry within a zip as the key and EntryInfo representing the entry as the value. It reflects the state of a zip archive in a specific point in time. Since entries is initialized in a lazy manner you need to make sure it was initialized first - before relying on direct entries.get(path). ensureEntries() is the method that does that and it is called from checkIfModified(). But you can call ensureEntries() directly of course - without going through checkIfModified(). There is initStatus field you can use to check that entries have been initialized: | if (initStatus == InitializationStatus.INITIALIZED) { | EntryInfo entry = entries.get(path); | } | But again, if you want to detect changes in the underlying zip file, you have to call checkIfModified which does the reinit of entries for you if it detects a change. - marko View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251468#4251468 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251468

17 years, 1 month

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Circular and self dependencies

by alesj

Where is this "fix", in AbstractController? Even if some context depends on itself, you shouldn't simply ignore it - in general state machine view. It should be simply reported as unresolved dependency as before, no special treatment required. I guess with classloading it could be different. But then it should be dealt in the classloading sub-project, not at the abstract state machine level. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251461#4251461 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251461

17 years, 1 month

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] - Re: VFSClassLoaderPolicy backed jboss-cl performance issue

by jaikiran

A bit more on a higher level - Assuming we have a ZipEntryContext/Handler, does it know of the entries within that zip? I see a ZipEntryContext.entries Map in the code, but haven't yet figured out whether looking directly into this would indicate the presence/absence of a resource within the zip. So if a getChild(String path) is invoked, maybe looking into this "entries" would tell us whether it's present or not? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251436#4251436 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251436

17 years, 1 month

1
0
0 / 0

[JBoss Microcontainer Development] - Circular and self dependencies

by thomas.diesler＠jboss.com

Folks, I am looking at https://jira.jboss.org/jira/browse/JBCL-24 which may be possible to fix in the classloading module alone. However I needed to make a trivial fix to the the Abstract controller in dependency | for (ControllerContext dependent : dependents) | { | boolean selfDependency = (dependent == context); | if (selfDependency == false && isBeforeState(dependent.getState(), whenRequired) == false) | uninstallContext(dependent, whenRequired, trace); | } | This should not change the existing behaviour. All tests still pass View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251433#4251433 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251433

17 years, 1 month

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] - Re: VFSClassLoaderPolicy backed jboss-cl performance issue

by jaikiran

"mstruk" wrote : | | I doubt you can improve performance simply by skipping a few tens of thousands of System.currentTimeMillis(). | | Nah, that's not going to improve performance :) I posted that as a question on why we check for modifications on each operation (from a functionality point rather than a performance point). View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251430#4251430 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251430

17 years, 1 month

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] - Re: VFSClassLoaderPolicy backed jboss-cl performance issue

by mstruk

"jaikiran" wrote : While doing this, internally the each of the file handlers are invoked which ultimately lead to AbstractVirtualFileHandler.structureFindChild(String classResourceName) first splits the resource path name into multiple tokens (through PathTokenizer). This in itself is expensive because of the various String operations involved: | Accross the whole VFS impl there is a lot of pathname parsing. One way to alleviate this would be to introduce a Path object that contains an already parsed path. This way all the methods taking a path in the form of a String could be rewritten to taking Path instead. Parsing would then happen only once for each path. "jaikiran" wrote : | i) ZipEntryHandler.getChild -> First gets the correct ZipEntryContext and then calls the getChild on the context. Any operations on the ZipEntryContext go through a isModified check which involves a call to System.currentTimeInMillis to get the current time and then comparing it with the earlier time. Do we need to do this modification check? | I doubt you can improve performance simply by skipping a few tens of thousands of System.currentTimeMillis(). For example - the following code executes in 50-60ms on my laptop: | import java.util.ArrayList; | | class Test { | | public static void main(String [] args) { | | long start = System.currentTimeMillis(); | ArrayList<Long> tstamps = new ArrayList<Long>(100000); | | for(int i=0; i<100000; i++) { | long now = System.currentTimeMillis(); | tstamps.add(now); | if (now - start > 1000) | throw new RuntimeException("Your comp is slow, man!"); | } | | System.out.println("Time elapsed for " + tstamps.size() + " iterations: " + (tstamps.get(tstamps.size()-1) - tstamps.get(0))); | } | } | isModified() check simply ensures that when you say getChild(name) you get the datastructure reflecting the actual state of the underlying file (someone may have dropped a modified ear in jboss deploy dir). The really expensive stuff only happens if the underlying file actually is changed. In this case reinit of children is triggered. Actually to make sure the datastructure reflects the current state of the file you would have to hit file's lastModified() method continuously which is pretty expensive. There's optimization in there that doesn't hit the file more often than once a second - see ZipWrapper . hasBeenModified(). In fact this should brobably be stated in the javadoc of this method which currently is not. This optimization is purposefully done as close to the file communication layer as possible to avoid introducing unexpected behaviour (read: vfs taking unusually long to pick up changes in the file). "jaikiran" wrote : | | ii) Within this flow, there's even an invocation to ZipEntryHandler.isLeaf(). Similar to the isModified call, this internally checks whether the zip context is closed. The isLeaf() implementation itself is a bit expensive since it's not a simple boolean check and instead does a .equals() on AbstractVirtualFileHandler: | | ZipEntryContext.isLeaf: | | | boolean isLeaf(ZipEntryHandler handler) | | { | | if (handler == null) | | throw new IllegalArgumentException("Null handler"); | | | | if (getRoot().equals(handler) == false) | | checkIfModified(); | | | | EntryInfo ei = entries.get(handler.getLocalPathName()); | | if (ei == null || ei.entry == null) | | return false; | | | | return ei.entry.isDirectory() == false; | | } | | | You can't just do a boolean check here because ZipEntryContext represents a mounted filesystem. What you're saying here is: 'Hey, you zip filesystem, check this file for me - is it a file, or is it a dir'. And filesystem goes: "Let's see what he passed to me. Ok .. it's not null. Is it a zip file - the one that I as a filesystem am taking care of? It's not. In that case before doing anything else - to reflect the current state of the file on the disk - let's check if maybe the file was modified and let's reinit ourselves before continuing to reflect the latest. Now let's see if we have a file entry for the pathname of the passed handler. Ok, we have an entry - let's see is it a file?" It looks kind of convoluted, but it's because it tries to be lazy on one hand, deferring the really slow stuff until really necessary, and tries to be current on the other, detecting file changes promptly. I don't see how you could reimplement AbstractVirtualFileHandler.equals() to stay semantically correct and take zero cycles to compute :) "jaikiran" wrote : | So overall, in order to find whether a zip (jar) file contains a given class resource (remember we already know it contains the package, we are just checking whether it contains the specific class) we do a lot of expensive operations. I haven't completely looked at the ZipEntryHandler/Context, but would it be possible to have some sort of a mapping which has the entries contained in that jar? I see that we are doing something similar in the initEntries() but not sure whether it can be used. | | So if we wanted to check if a given resource is available in the ZipEntryContext, maybe we could just do a entries.containsKey(resourcePath)? Would it be possible to simplify the zip entry handling? The code was originally written to support any usage scenario. That means that for some specific usage scenarios it could be optimized. If you know from the outside that the underlying file won't change, then all the code in vfszip that checks if the file was changed is redundant for your use-case. So you could for example introduce additional option UNCHANGABLE or something, and skip continous isModified checks when option is enabled. Cheers, - marko View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251421#4251421 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251421

17 years, 1 month

1
0
0 / 0

[jBPM Development] - Re: Java Activity not using Interface

by kukeltje

I was not saying it was no jbpm issue, it was not an issue for the jBPM DEV forum but for the jBPM USER forum. THe fact that you do not get a response there is no (valid) reason to try the dev forum. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251398#4251398 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251398

17 years, 1 month

1
0
0 / 0

[JBoss Identity Development] - ive post to wrong topic forum...can some one assist me with

by norazanita_adnan

http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251339#4251339 and also this http://www.jboss.org/index.html?module=bb&op=viewtopic&t=160328 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251393#4251393 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251393

17 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums August 2009