this is default jdk behavior... you can override parsers per jar file by including these files with a reference to other xml implementations. Nothing to do with jBPM
Twice 'yes' and once 'no'.
Yes, I can see that too that it is default behaviour of the xerces lib (not really the JVM as you said).
Yes, it is not jBPM code that causes this. Not directly at least.
But also no, because in the end it is jBPM code that (albeit indirectly) causes these stat() calls. So the causal link is very much there, I'm sorry.
I think jBPM is great stuff. But as you can see from my original post the sys. admin. is very picky about the behaviour of the code that goes online on a production machine. I was just hoping one of the jBPM gurus would, with a sleight of hand, point me toward a solution for this problem. Maybe at the same time pointing at this minor problem at the same so everyone can benefit from the solution. Well, I'm still hoping a guru may lay eyes on this post.
The usual reason for this is code that creates a new parserFactory every place one is needed, instead of reusing one (or more).
This can add ~100ms or so to the time for each parse, so (if as I suspect) it may be worth fixing for performance as well.
I haven't looked at the jBPM code to see whether this theory fits. (sorry, never enough time)
Johan, so your problem is not that it tries to open the none-existing files, but that number of times it tries that.... I did not interpret your 'constantly' as to often and certainly not that it was mainly jBPM.
Still afaik it is a specification of java that you can override parsers this way and yes in most cases it is xerces doing it since it is one of the most used ones...
As Ed states, the solution is kind of obvious and could indeed lead to performance gains... We'd appreciate it if you could help out on this one, since we have lots of other things to do. File a jira issue and assign it to yourself so it does not get lost.
Hi Ed and Ronald,
Thanks for your respective replies. I'll give it a shot and report my progress (if any here).
no progress may also be reported ;-)
How do I go about submitting my patch? Or will this all becoming clear when I'll open the issues in JIRA?
you can attach them to the jira issue. Tom will review them (I´ll notify him)
I'll try it out tonight... thanks
In the meanwhile I had a chance to try the code too. It works but does not solve the problem :(
So I resumed my quest and found the real source of the many SAXParserFactory instantiations: JbpmContext.getSession (see below).
Hmmm, I see a solution in caching the configuration in the DbPersistenceServiceFactory class. Since it can't be the idea that you can change the resource.hibernate.properties file or resource.hibernate.cfg.xml file at runtime caching the configuration at this point seems reasonable to me. This would be a simple patch to the getConfiguration method.
Gurus, any objection to this?