Re: Nasty flowscript issue - nailed
Hi, On 7 Jul 2004, at 17:17, Gianugo Rabellino wrote: On Jul 7, 2004, at 8:03 AM, Sylvain Wallez wrote: Giaunugo, I committed the unique ID fix (using an instance counter). Can you please crosscheck? Thanks so much Sylvain! I'm out of the office for the next two days, but I'll get back to you ASAP if Andrew/Jerm don't beat me at it... Ok, I've tried it out and it seems to do the trick. Thanks very much for your help, Sylvain! Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
Re: Nasty flowscript issue - nailed
On Jul 7, 2004, at 8:03 AM, Sylvain Wallez wrote: Giaunugo, I committed the unique ID fix (using an instance counter). Can you please crosscheck? Thanks so much Sylvain! I'm out of the office for the next two days, but I'll get back to you ASAP if Andrew/Jerm don't beat me at it... Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com
Re: Nasty flowscript issue - nailed
Vadim Gritsenko wrote: Sylvain Wallez wrote: The interpreter is looked up by the sitemap engine (see FlowNode.java), so in that case SingleThreaded means a different instance for each sitemap, which handles all requests for that sitemap. A bit hacky, but that's how it is since the origin to ensure proper isolation of flowscripts between different sitemaps. So the unique ID attached to an interpreter instance is therefore also unique per sitemap, which is what we want to achieve here. Got you. Hope it's mentioned somewhere in the comments / javadocs :-) Well, now it is :-) Giaunugo, I committed the unique ID fix (using an instance counter). Can you please crosscheck? Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Nasty flowscript issue - nailed
Sylvain Wallez wrote: Vadim Gritsenko wrote: Sylvain Wallez wrote: JavaScriptInterpreter should have an id attribute intialized once, whose value is used instead of getSitemapPath(), e.g. private String interpreterID = IDGenerator.getNewID(); System.identityHashCode(this) is much simpler than suggested before IDgenerator. Mmmh... The javadoc states that uniqueness cannot be guaranteed, although most JVMs implement it by returning the object pointer. That's why using an ID generator looks safer to me. Thinking further, we actually don't need a time-based ID (I copy/pasted this from some code I have here): a simple counter is enough to do the job. Exactly :-) But, it was mentioned that some component is single threaded - this means, for second (parallel) request, another component will get created, with different ID - and different scope will be obtained, breaking the flow again. The interpreter is looked up by the sitemap engine (see FlowNode.java), so in that case SingleThreaded means a different instance for each sitemap, which handles all requests for that sitemap. A bit hacky, but that's how it is since the origin to ensure proper isolation of flowscripts between different sitemaps. So the unique ID attached to an interpreter instance is therefore also unique per sitemap, which is what we want to achieve here. Got you. Hope it's mentioned somewhere in the comments / javadocs :-) Vadim
Re: Nasty flowscript issue - nailed
Vadim Gritsenko wrote: Sylvain Wallez wrote: Gianugo Rabellino wrote: On Jul 6, 2004, at 12:26 PM, Sylvain Wallez wrote: There is a solution, though: there's a different FlowIntepreter for each Processor instance (they are SingleThreaded), and so each interpreter instance could produce a unique identifier and use it as the result of getSitemapPath (which should therefore be renamed). Any suggestions for a good unique identifier? Thanks so much, Since ID uniqueness doesn't have to survive JVM restart, a date-based generator like this should do the job (sorry, no time to commit it myself): Uhm, I might be missing something here. I understood that scope should be reused (resurrected?) when inside the same sitemap: in this case, your IDGenerator would yield a different result every time, hence a new scope. Is this what is needed? If that's the case, well, fair enough. :-) Sorry, I wasn't clear in my explanation (I was hungry and ready to run for lunch, which isn't good for clarity ;-) JavaScriptInterpreter should have an id attribute intialized once, whose value is used instead of getSitemapPath(), e.g. private String interpreterID = IDGenerator.getNewID(); System.identityHashCode(this) is much simpler than suggested before IDgenerator. Mmmh... The javadoc states that uniqueness cannot be guaranteed, although most JVMs implement it by returning the object pointer. That's why using an ID generator looks safer to me. Thinking further, we actually don't need a time-based ID (I copy/pasted this from some code I have here): a simple counter is enough to do the job. But, it was mentioned that some component is single threaded - this means, for second (parallel) request, another component will get created, with different ID - and different scope will be obtained, breaking the flow again. The interpreter is looked up by the sitemap engine (see FlowNode.java), so in that case SingleThreaded means a different instance for each sitemap, which handles all requests for that sitemap. A bit hacky, but that's how it is since the origin to ensure proper isolation of flowscripts between different sitemaps. So the unique ID attached to an interpreter instance is therefore also unique per sitemap, which is what we want to achieve here. Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Nasty flowscript issue - nailed
Sylvain Wallez wrote: Gianugo Rabellino wrote: On Jul 6, 2004, at 12:26 PM, Sylvain Wallez wrote: There is a solution, though: there's a different FlowIntepreter for each Processor instance (they are SingleThreaded), and so each interpreter instance could produce a unique identifier and use it as the result of getSitemapPath (which should therefore be renamed). Any suggestions for a good unique identifier? Thanks so much, Since ID uniqueness doesn't have to survive JVM restart, a date-based generator like this should do the job (sorry, no time to commit it myself): Uhm, I might be missing something here. I understood that scope should be reused (resurrected?) when inside the same sitemap: in this case, your IDGenerator would yield a different result every time, hence a new scope. Is this what is needed? If that's the case, well, fair enough. :-) Sorry, I wasn't clear in my explanation (I was hungry and ready to run for lunch, which isn't good for clarity ;-) JavaScriptInterpreter should have an id attribute intialized once, whose value is used instead of getSitemapPath(), e.g. private String interpreterID = IDGenerator.getNewID(); System.identityHashCode(this) is much simpler than suggested before IDgenerator. But, it was mentioned that some component is single threaded - this means, for second (parallel) request, another component will get created, with different ID - and different scope will be obtained, breaking the flow again. Vadim and scope = (ThreadScope)userScopes.get(getSitemapPath()); becomes scope = (ThreadScope)userScopes.get(this.interpreterID); Hope this is clearer. Sylvain
Re: Nasty flowscript issue - nailed
Gianugo Rabellino wrote: On Jul 6, 2004, at 12:26 PM, Sylvain Wallez wrote: There is a solution, though: there's a different FlowIntepreter for each Processor instance (they are SingleThreaded), and so each interpreter instance could produce a unique identifier and use it as the result of getSitemapPath (which should therefore be renamed). Any suggestions for a good unique identifier? Thanks so much, Since ID uniqueness doesn't have to survive JVM restart, a date-based generator like this should do the job (sorry, no time to commit it myself): Uhm, I might be missing something here. I understood that scope should be reused (resurrected?) when inside the same sitemap: in this case, your IDGenerator would yield a different result every time, hence a new scope. Is this what is needed? If that's the case, well, fair enough. :-) Sorry, I wasn't clear in my explanation (I was hungry and ready to run for lunch, which isn't good for clarity ;-) JavaScriptInterpreter should have an id attribute intialized once, whose value is used instead of getSitemapPath(), e.g. private String interpreterID = IDGenerator.getNewID(); and scope = (ThreadScope)userScopes.get(getSitemapPath()); becomes scope = (ThreadScope)userScopes.get(this.interpreterID); Hope this is clearer. Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Nasty flowscript issue - nailed
On Jul 6, 2004, at 12:26 PM, Sylvain Wallez wrote: There is a solution, though: there's a different FlowIntepreter for each Processor instance (they are SingleThreaded), and so each interpreter instance could produce a unique identifier and use it as the result of getSitemapPath (which should therefore be renamed). Any suggestions for a good unique identifier? Thanks so much, Since ID uniqueness doesn't have to survive JVM restart, a date-based generator like this should do the job (sorry, no time to commit it myself): Uhm, I might be missing something here. I understood that scope should be reused (resurrected?) when inside the same sitemap: in this case, your IDGenerator would yield a different result every time, hence a new scope. Is this what is needed? If that's the case, well, fair enough. :-) Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com
Re: Nasty flowscript issue - nailed
Gianugo Rabellino wrote: On Jul 6, 2004, at 11:35 AM, Sylvain Wallez wrote: I changed that to private String getSitemapPath() throws Exception { return ObjectModelHelper.getRequest( EnvironmentHelper.getCurrentEnvironment().getObjectModel()).getSitemap UR I(); } Aargh! You should absolutely avoid to use the very-internal-and-private EnvironmentHelper class! ContextHelper is your friend ;-) Good to know, even though this very class is very-internal-and-private as well. :-) Forgot to say: although maybe not well-known, ContextHelper is part of Cocoon's public API and can therefore be used without fearing compatibility issues with newer versions. This isn't the case with EnvironmentHelper: it's new in HEAD, and can change without notice! Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Nasty flowscript issue - nailed
Gianugo Rabellino wrote: On Jul 6, 2004, at 11:35 AM, Sylvain Wallez wrote: I changed that to private String getSitemapPath() throws Exception { return ObjectModelHelper.getRequest( EnvironmentHelper.getCurrentEnvironment().getObjectModel()).getSitemap UR I(); } Aargh! You should absolutely avoid to use the very-internal-and-private EnvironmentHelper class! ContextHelper is your friend ;-) Good to know, even though this very class is very-internal-and-private as well. :-) but being a freshman on Cocoon flow internals, I'm afraid this is going to introduce a nasty set of regressions. Can anyone more knowleadgeable verify the problem and possibly provide a more clever solution? There is a solution, though: there's a different FlowIntepreter for each Processor instance (they are SingleThreaded), and so each interpreter instance could produce a unique identifier and use it as the result of getSitemapPath (which should therefore be renamed). Any suggestions for a good unique identifier? Thanks so much, Since ID uniqueness doesn't have to survive JVM restart, a date-based generator like this should do the job (sorry, no time to commit it myself): public class IDGenerator { private static long lastKey = 0; public static String getNewID() { long result; synchronized(IDGenerator.class) { while ((result = System.currentTimeMillis()) <= lastKey) { Thread.yeld(); // wait a bit } lastKey = result; } return String.valueOf(result); } } Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Nasty flowscript issue - nailed
On Jul 6, 2004, at 11:35 AM, Sylvain Wallez wrote: I changed that to private String getSitemapPath() throws Exception { return ObjectModelHelper.getRequest( EnvironmentHelper.getCurrentEnvironment().getObjectModel()).getSitemap UR I(); } Aargh! You should absolutely avoid to use the very-internal-and-private EnvironmentHelper class! ContextHelper is your friend ;-) Good to know, even though this very class is very-internal-and-private as well. :-) but being a freshman on Cocoon flow internals, I'm afraid this is going to introduce a nasty set of regressions. Can anyone more knowleadgeable verify the problem and possibly provide a more clever solution? There is a solution, though: there's a different FlowIntepreter for each Processor instance (they are SingleThreaded), and so each interpreter instance could produce a unique identifier and use it as the result of getSitemapPath (which should therefore be renamed). Any suggestions for a good unique identifier? Thanks so much, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com
Re: Nasty flowscript issue - nailed
Gianugo Rabellino wrote: We had an interesting night here, dealing with a really nasty flowscript issue (http://marc.theaimsgroup.com/?t=10879848851&r=1&w=2). Thanks to the precious help of Jerm, Andrew and Paul Russell, our small hackaton seemed to be successful in at least nailing the issue. So, there you go: you have different sitemaps, dealing with different flowscripts each BUT all residing in the same directory and mounted using uri-prefix as follows: BTW, this is "check-reload" (singular), but as it defaults to true, you can safely remove it everywhere ;-) (BTW, we discussed this already, I really consider this a useless feature). In that case, FOM_JavaScriptInterpreter screws up because of scope handling: scopes are kept in memory and indexed using a string coming from the internal getSitemapPath() function call which, a bit naively, is as follows: private String getSitemapPath() throws Exception { Source src = this.sourceresolver.resolveURI("."); try { return src.getURI(); } finally { this.sourceresolver.release(src); } } Now, whether you ask for /url /something/url or /else/url, that method will always return file://$COCOON_HOME/build/webapp/. This means that the list of available functions will always point to the first set of scripts being evaluated, and on your subsequent requests to seemingly different URLs you get a nice function not found error. I changed that to private String getSitemapPath() throws Exception { return ObjectModelHelper.getRequest( EnvironmentHelper.getCurrentEnvironment().getObjectModel()).getSitemapUR I(); } Aargh! You should absolutely avoid to use the very-internal-and-private EnvironmentHelper class! ContextHelper is your friend ;-) but being a freshman on Cocoon flow internals, I'm afraid this is going to introduce a nasty set of regressions. Can anyone more knowleadgeable verify the problem and possibly provide a more clever solution? That won't solve the problem since getSitemapURI will return a different result for different request URIs within the same sitemap. This means you will loose the scope between requests to different URIs. This is a tricky problem as the scope should actually be attached to the Processor instance, since you have here several Processors attached to the same URI prefix. There is a solution, though: there's a different FlowIntepreter for each Processor instance (they are SingleThreaded), and so each interpreter instance could produce a unique identifier and use it as the result of getSitemapPath (which should therefore be renamed). Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Nasty flowscript issue - nailed
On 6 Jul 2004, at 10:04, Andrew Savory wrote: Hi, On 5 Jul 2004, at 22:16, Gianugo Rabellino wrote: I changed that to private String getSitemapPath() throws Exception { return ObjectModelHelper.getRequest( EnvironmentHelper.getCurrentEnvironment().getObjectModel()).getSitemap URI(); } but being a freshman on Cocoon flow internals, I'm afraid this is going to introduce a nasty set of regressions. Can anyone more knowleadgeable verify the problem and possibly provide a more clever solution? Sadly this doesn't appear to have cured the problem (though it reduces the frequency). I'm loath for us to have to create subdirectories for all our sitemaps ... anyone else got any ideas? Unfortunately, we are also finding that placing sitemaps in their own folders does not guarantee that the problem goes away. I am still checking in Eclipse, but it appears that we sometimes get the wrong scope (we get a scope with a different pipeline's flowscript functions in it). Should there be a completely different scope (set of functions) available to each pipeline, or are the functions 'accumulated' into one scope? If the answer is 'accumulation' then we need to find out why functions are not added sometimes, if the pipelines should have different scopes, then I need to find out why we get the wrong one. regards Jeremy If email from this address is not signed IT IS NOT FROM ME Always check the label, folks ! smime.p7s Description: S/MIME cryptographic signature
Re: Nasty flowscript issue - nailed
Hi, On 5 Jul 2004, at 22:16, Gianugo Rabellino wrote: I changed that to private String getSitemapPath() throws Exception { return ObjectModelHelper.getRequest( EnvironmentHelper.getCurrentEnvironment().getObjectModel()).getSitemapU RI(); } but being a freshman on Cocoon flow internals, I'm afraid this is going to introduce a nasty set of regressions. Can anyone more knowleadgeable verify the problem and possibly provide a more clever solution? Sadly this doesn't appear to have cured the problem (though it reduces the frequency). I'm loath for us to have to create subdirectories for all our sitemaps ... anyone else got any ideas? Cheers, Andrew. -- Andrew Savory, Managing Director, Luminas Limited Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.luminas.co.uk/ Orixo alliance: http://www.orixo.com/
Nasty flowscript issue - nailed
We had an interesting night here, dealing with a really nasty flowscript issue (http://marc.theaimsgroup.com/?t=10879848851&r=1&w=2). Thanks to the precious help of Jerm, Andrew and Paul Russell, our small hackaton seemed to be successful in at least nailing the issue. So, there you go: you have different sitemaps, dealing with different flowscripts each BUT all residing in the same directory and mounted using uri-prefix as follows: In that case, FOM_JavaScriptInterpreter screws up because of scope handling: scopes are kept in memory and indexed using a string coming from the internal getSitemapPath() function call which, a bit naively, is as follows: private String getSitemapPath() throws Exception { Source src = this.sourceresolver.resolveURI("."); try { return src.getURI(); } finally { this.sourceresolver.release(src); } } Now, whether you ask for /url /something/url or /else/url, that method will always return file://$COCOON_HOME/build/webapp/. This means that the list of available functions will always point to the first set of scripts being evaluated, and on your subsequent requests to seemingly different URLs you get a nice function not found error. I changed that to private String getSitemapPath() throws Exception { return ObjectModelHelper.getRequest( EnvironmentHelper.getCurrentEnvironment().getObjectModel()).getSitemapUR I(); } but being a freshman on Cocoon flow internals, I'm afraid this is going to introduce a nasty set of regressions. Can anyone more knowleadgeable verify the problem and possibly provide a more clever solution? TIA, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com