-
1. Re: Missing (config) files starters kit?
kukeltje Feb 19, 2007 1:01 PM (in response to johan.parent)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
-
2. Re: Missing (config) files starters kit?
johan.parent Feb 20, 2007 5:12 AM (in response to johan.parent)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.
Best regards,
Johan -
3. Re: Missing (config) files starters kit?
estaub Feb 21, 2007 8:07 AM (in response to johan.parent)Johan,
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)
-Ed Staub -
4. Re: Missing (config) files starters kit?
kukeltje Feb 21, 2007 10:40 AM (in response to johan.parent)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. -
5. Re: Missing (config) files starters kit?
johan.parent Feb 22, 2007 10:32 AM (in response to johan.parent)Hi Ed and Ronald,
Thanks for your respective replies. I'll give it a shot and report my progress (if any here).
Best regards,
Johan -
6. Re: Missing (config) files starters kit?
kukeltje Feb 22, 2007 10:52 AM (in response to johan.parent)no progress may also be reported ;-)
-
7. Re: Missing (config) files starters kit?
johan.parent Mar 1, 2007 8:13 AM (in response to johan.parent)@Ronald:
How do I go about submitting my patch? Or will this all becoming clear when I'll open the issues in JIRA?
Regards,
Johan -
8. Re: Missing (config) files starters kit?
kukeltje Mar 1, 2007 8:16 AM (in response to johan.parent)you can attach them to the jira issue. Tom will review them (I´ll notify him)
-
9. Re: Missing (config) files starters kit?
johan.parent Mar 1, 2007 9:34 AM (in response to johan.parent)Ok, it's done
http://jira.jboss.com/jira/browse/JBPM-858
I don't know how to make a build so I could not test the code but it should do the job.
Johan -
10. Re: Missing (config) files starters kit?
kukeltje Mar 1, 2007 10:36 AM (in response to johan.parent)I'll try it out tonight... thanks
-
11. Re: Missing (config) files starters kit?
johan.parent Mar 2, 2007 6:40 AM (in response to johan.parent)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?
Regards,
Johan
newInstance():87, SAXParserFactory.java
createXMLReader():46, JAXPHelper.java
createXMLReaderViaJAXP():125, SAXHelper.java
createXMLReader():75, SAXHelper.java
createXMLReader():894, SAXReader.java
getXMLReader():714, SAXReader.java
read():435, SAXReader.java
doConfigure():1343, Configuration.java
configure():1286, Configuration.java
createConfiguration():84, HibernateHelper.java
getConfiguration():60, DbPersistenceServiceFactory.java
getSessionFactory():83, DbPersistenceServiceFactory.java
getSessionFactory():76, DbPersistenceService.java
getSession():80, DbPersistenceService.java
getSession():464, JbpmContext.java