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
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
snip/
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
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
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/
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
Gianugo Rabellino wrote:
We had an interesting night here, dealing with a really nasty
flowscript issue
(http://marc.theaimsgroup.com/?t=10879848851r=1w=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:
map:mount src=something.xmap uri-prefix=something
check-reloads=true/
map:mount src=else.xmap uri-prefix=else check-reloads=true/
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 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:
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
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
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 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
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
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: 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
Nasty flowscript issue - nailed
We had an interesting night here, dealing with a really nasty
flowscript issue
(http://marc.theaimsgroup.com/?t=10879848851r=1w=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:
map:mount src=something.xmap uri-prefix=something
check-reloads=true/
map:mount src=else.xmap uri-prefix=else check-reloads=true/
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
