You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Christophe Fondacci <ch...@nextep-softwares.com> on 2009/06/11 10:26:05 UTC
IncludeTransformer: 2 parallel threads only ?
Hello all,
I am currently working with the parallel inclusion through the IncludeTransformer. Our website is based on Cocoon 2.1.11.
It works fine and we truly like this feature, but I notice some strange behaviour :
a.. I have a XSP page with 4 "i:include" inclusions. We configured the include transformer in the sitemap to enable parallelism.
b.. I placed breakpoints on every included page to see how cocoon processes the inclusions.
c.. When I try to generate this page, it seems like inclusions are made 2 by 2. I see 2 of my breakpoints being reached, the others being reached only after completion of these first inclusions. The weird thing is that the order seem to change randomly : sometime i got inclusion 1 and 4 first, sometime 1 and 2, etc. I would have expected to see my 4 breakpoints being reached in 4 distinct threads...
Could someone explain to me if it is possible to include these 4 elements in 4 parallel threads or whether there are some limitations or restrictions on the parallelism ?
The other thing (less important since i found a workaround) is that parallelism seem to only work when referencing local elements through the cocoon protocol (URI like "cocoon:/"). As soon as we reference inclusions through "external" URLs (URI like "http://"), every inclusion seem to be processed sequentially.
Could you confirm this is the expected behaviour ? If someone can explain me why it is working this way I would be very interested.
Thank your very much for your help / time
& keep up the good work !
Christophe.
RE: Cocoon 2.1.11- XSP compiled in Java 1.3 when running Cocoon with a 1.6 JVM and using the Eclipse compiler
Posted by Laurent Medioni <lm...@odyssey-group.com>.
Should we also replace, in Cocoon 2.1.x, JDT 3.1 with 3.5 ?
As 3.1 does not know about 1.6 and 3.5 still support Java 1.1 ;)
We use 3.5 since a few weeks and have not detected any issue...
Laurent
-----Original Message-----
From: Antonio Gallardo [mailto:agallardo@agssa.net]
Sent: lundi, 31. août 2009 22:45
To: users@cocoon.apache.org
Subject: Re: Cocoon 2.1.11- XSP compiled in Java 1.3 when running Cocoon with a 1.6 JVM and using the Eclipse compiler
El 31/08/09 04:54, Laurent Medioni escribió:
> Anyway I think that EclipseJavaCompiler should be modified to properly handle 1.6 without reverting to 1.3 by default (even if the 2 additional jdt properties look more cosmetic than critical for the generated code).
>
+1 Would you provide a patch. I think it should not be too dificult.
BTW, The java 1.3 was set to default value, due historical reasons.
Perhaps it is time to switch that too. :)
Best Regards,
Antonio Gallardo.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
____________________________________________________________
� This email and any files transmitted with it are CONFIDENTIAL and intended
solely for the use of the individual or entity to which they are addressed.
� Any unauthorized copying, disclosure, or distribution of the material within
this email is strictly forbidden.
� Any views or opinions presented within this e-mail are solely those of the
author and do not necessarily represent those of Odyssey Financial
Technologies SA unless otherwise specifically stated.
� An electronic message is not binding on its sender. Any message referring to
a binding engagement must be confirmed in writing and duly signed.
� If you have received this email in error, please notify the sender immediately
and delete the original.
RE: Cocoon 2.1.11- XSP compiled in Java 1.3 when running Cocoon with a 1.6 JVM and using the Eclipse compiler
Posted by Laurent Medioni <lm...@odyssey-group.com>.
Should we also replace, in Cocoon 2.1.x, JDT 3.1 with 3.5 ?
As 3.1 does not know about 1.6 and 3.5 still support Java 1.1 ;)
We use 3.5 since a few weeks and have not detected any issue...
Laurent
-----Original Message-----
From: Antonio Gallardo [mailto:agallardo@agssa.net]
Sent: lundi, 31. août 2009 22:45
To: users@cocoon.apache.org
Subject: Re: Cocoon 2.1.11- XSP compiled in Java 1.3 when running Cocoon with a 1.6 JVM and using the Eclipse compiler
El 31/08/09 04:54, Laurent Medioni escribió:
> Anyway I think that EclipseJavaCompiler should be modified to properly handle 1.6 without reverting to 1.3 by default (even if the 2 additional jdt properties look more cosmetic than critical for the generated code).
>
+1 Would you provide a patch. I think it should not be too dificult.
BTW, The java 1.3 was set to default value, due historical reasons.
Perhaps it is time to switch that too. :)
Best Regards,
Antonio Gallardo.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
____________________________________________________________
� This email and any files transmitted with it are CONFIDENTIAL and intended
solely for the use of the individual or entity to which they are addressed.
� Any unauthorized copying, disclosure, or distribution of the material within
this email is strictly forbidden.
� Any views or opinions presented within this e-mail are solely those of the
author and do not necessarily represent those of Odyssey Financial
Technologies SA unless otherwise specifically stated.
� An electronic message is not binding on its sender. Any message referring to
a binding engagement must be confirmed in writing and duly signed.
� If you have received this email in error, please notify the sender immediately
and delete the original.
Re: Cocoon 2.1.11- XSP compiled in Java 1.3 when running Cocoon with
a 1.6 JVM and using the Eclipse compiler
Posted by Antonio Gallardo <ag...@agssa.net>.
El 31/08/09 04:54, Laurent Medioni escribió:
> Anyway I think that EclipseJavaCompiler should be modified to properly handle 1.6 without reverting to 1.3 by default (even if the 2 additional jdt properties look more cosmetic than critical for the generated code).
>
+1 Would you provide a patch. I think it should not be too dificult.
BTW, The java 1.3 was set to default value, due historical reasons.
Perhaps it is time to switch that too. :)
Best Regards,
Antonio Gallardo.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Cocoon 2.1.11- XSP compiled in Java 1.3 when running Cocoon with a 1.6 JVM and using the Eclipse compiler
Posted by Laurent Medioni <lm...@odyssey-group.com>.
Hi Antonio,
I am just trying to understand what is done in EclipseJavaCompiler ;)
Original code: if we have the compiler-compliance-level parameter set to 1.5, then the JDT options org.eclipse.jdt.core.compiler.compliance and org.eclipse.jdt.core.compiler.source are set to 1.5. Then SystemUtils.JAVA_VERSION_INT is used to set the JDT option org.eclipse.jdt.core.compiler.codegen.targetPlatform.
So if I use a 1.6 JVM and if I set compiler-compliance-level to 1.5 (maximum handled by JDT 3.1) then I end up with the following combination out of EclipseJavaCompiler:
- compliance = 1.5
- source = 1.5
- targetPlatform = 1.3
It is true that this combination is discouraged in the Eclipse Preferences panel. It requires that Source compatibility <= Classfile compatibility (targetPlatform) <= Compliance level.
But with my "wrong" configuration I get no errors from JDT and XSPs are compiled and are running correctly (which is "understandable" because my target platform is a 1.6, so the minimum level of 1.3 is respected).
Anyway I think that EclipseJavaCompiler should be modified to properly handle 1.6 without reverting to 1.3 by default (even if the 2 additional jdt properties look more cosmetic than critical for the generated code).
Laurent
-----Original Message-----
From: Antonio Gallardo [mailto:agallardo@agssa.net]
Sent: vendredi, 28. août 2009 17:51
To: users@cocoon.apache.org
Subject: Re: Cocoon 2.1.11- XSP compiled in Java 1.3 when running Cocoon with a 1.6 JVM and using the Eclipse compiler
Hi Laurent,
Hmm. I am wondering about your message, because IIRC, the compliance
level almost define the target java version for compiled class. I mean
if I select compliance level 1.5, the generated class cannot be compiled
for java 1.3 because 1.3 JVM cannot handle some of the new features
introduced in java 1.5. I can be wrong be I can recall it is not
possible to set that way in eclipse. I mean a higher compliance level
(ie: 1.5) and a lower compilation level (ie: 1.3). It simply does not work.
Best Regards,
Antonio Gallardo.
____________________________________________________________
� This email and any files transmitted with it are CONFIDENTIAL and intended
solely for the use of the individual or entity to which they are addressed.
� Any unauthorized copying, disclosure, or distribution of the material within
this email is strictly forbidden.
� Any views or opinions presented within this e-mail are solely those of the
author and do not necessarily represent those of Odyssey Financial
Technologies SA unless otherwise specifically stated.
� An electronic message is not binding on its sender. Any message referring to
a binding engagement must be confirmed in writing and duly signed.
� If you have received this email in error, please notify the sender immediately
and delete the original.
Re: Cocoon 2.1.11- XSP compiled in Java 1.3 when running Cocoon with
a 1.6 JVM and using the Eclipse compiler
Posted by Antonio Gallardo <ag...@agssa.net>.
Hi Laurent,
Hmm. I am wondering about your message, because IIRC, the compliance
level almost define the target java version for compiled class. I mean
if I select compliance level 1.5, the generated class cannot be compiled
for java 1.3 because 1.3 JVM cannot handle some of the new features
introduced in java 1.5. I can be wrong be I can recall it is not
possible to set that way in eclipse. I mean a higher compliance level
(ie: 1.5) and a lower compilation level (ie: 1.3). It simply does not work.
Best Regards,
Antonio Gallardo.
El 28/08/09 01:27, Laurent Medioni escribió:
> Hi,
> Yes I used it, but it only affects the compliance level, not the generated class file compatibility, which is directly taken from the version of the running JVM... And the default of the switch/case is 1.3...
> So I had to replace the 2 switch/cases in EclipseJavaCompiler (1 for the source code version and 1 for the target version) with new ones defaulting to 1.5 if the version is greater than 1.5.
> So using JDT 3.1 and running a 1.6 JVM produces 1.5 code (which is the limit of JDT 3.1).
>
> My second try has been to use JDT 3.5 and modifying again EclipseJavaCompiler to properly manage 1.6. And everything seems to work fine.
>
> Laurent
>
> ________________________________________
> From: Antonio Gallardo [mailto:agallardo@agssa.net]
> Sent: jeudi, 27. août 2009 23:37
> To: users@cocoon.apache.org
> Subject: Re: Cocoon 2.1.11- XSP compiled in Java 1.3 when running Cocoon with a 1.6 JVM and using the Eclipse compiler
>
> Hi Laurent,
>
> Please look into the cocoon.xconf for the configuration of eclipse compiler and set the value to "1.5" instead of "auto". Here is the code:
> <!--+
> 55 :
>
>
> | Specifies the java code source version used to compile the XSP code.
> 56 :
>
>
> |
> 57 :
>
>
> | Posible values:
> 58 :
>
>
> | 1.3 = Java version 1.3
> 59 :
>
>
> | 1.4 = Java version 1.4
> 60 :
>
>
> | 1.5 = Java version 1.5
> 61 :
>
>
> | auto = The version of the JVM where cocoon is running. (Default value).
> 62 :
>
>
> |
> 63 :
>
>
> | NOTE: The parameter is optional to keep backward compatibility.
> 64 :
> anathaniel
> 555089
> | The parameter works with Sun Javac compiler and the Eclipse compiler.
> 65 :
> antonio
> 124779
> | The pizza compiler does not support java 1.5.
> 66 :
>
>
> +-->
> 67 :
>
>
> <!--<parameter name="compiler-compliance-level" value="auto"/> -->
>
> Best Regards,
>
> Antonio Gallardo
>
>
>
> ____________________________________________________________
>
> � This email and any files transmitted with it are CONFIDENTIAL and intended
> solely for the use of the individual or entity to which they are addressed.
> � Any unauthorized copying, disclosure, or distribution of the material within
> this email is strictly forbidden.
> � Any views or opinions presented within this e-mail are solely those of the
> author and do not necessarily represent those of Odyssey Financial
> Technologies SA unless otherwise specifically stated.
> � An electronic message is not binding on its sender. Any message referring to
> a binding engagement must be confirmed in writing and duly signed.
> � If you have received this email in error, please notify the sender immediately
> and delete the original.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Cocoon 2.1.11- XSP compiled in Java 1.3 when running Cocoon with a 1.6 JVM and using the Eclipse compiler
Posted by Laurent Medioni <lm...@odyssey-group.com>.
Hi,
Yes I used it, but it only affects the compliance level, not the generated class file compatibility, which is directly taken from the version of the running JVM... And the default of the switch/case is 1.3...
So I had to replace the 2 switch/cases in EclipseJavaCompiler (1 for the source code version and 1 for the target version) with new ones defaulting to 1.5 if the version is greater than 1.5.
So using JDT 3.1 and running a 1.6 JVM produces 1.5 code (which is the limit of JDT 3.1).
My second try has been to use JDT 3.5 and modifying again EclipseJavaCompiler to properly manage 1.6. And everything seems to work fine.
Laurent
________________________________________
From: Antonio Gallardo [mailto:agallardo@agssa.net]
Sent: jeudi, 27. août 2009 23:37
To: users@cocoon.apache.org
Subject: Re: Cocoon 2.1.11- XSP compiled in Java 1.3 when running Cocoon with a 1.6 JVM and using the Eclipse compiler
Hi Laurent,
Please look into the cocoon.xconf for the configuration of eclipse compiler and set the value to "1.5" instead of "auto". Here is the code:
<!--+
55 :
| Specifies the java code source version used to compile the XSP code.
56 :
|
57 :
| Posible values:
58 :
| 1.3 = Java version 1.3
59 :
| 1.4 = Java version 1.4
60 :
| 1.5 = Java version 1.5
61 :
| auto = The version of the JVM where cocoon is running. (Default value).
62 :
|
63 :
| NOTE: The parameter is optional to keep backward compatibility.
64 :
anathaniel
555089
| The parameter works with Sun Javac compiler and the Eclipse compiler.
65 :
antonio
124779
| The pizza compiler does not support java 1.5.
66 :
+-->
67 :
<!-- <parameter name="compiler-compliance-level" value="auto"/> -->
Best Regards,
Antonio Gallardo
____________________________________________________________
� This email and any files transmitted with it are CONFIDENTIAL and intended
solely for the use of the individual or entity to which they are addressed.
� Any unauthorized copying, disclosure, or distribution of the material within
this email is strictly forbidden.
� Any views or opinions presented within this e-mail are solely those of the
author and do not necessarily represent those of Odyssey Financial
Technologies SA unless otherwise specifically stated.
� An electronic message is not binding on its sender. Any message referring to
a binding engagement must be confirmed in writing and duly signed.
� If you have received this email in error, please notify the sender immediately
and delete the original.
Re: Cocoon 2.1.11- XSP compiled in Java 1.3 when running Cocoon with
a 1.6 JVM and using the Eclipse compiler
Posted by Antonio Gallardo <ag...@agssa.net>.
Hi Laurent,
Please look into the cocoon.xconf for the configuration of eclipse
compiler and set the value to "1.5" instead of "auto". Here is the code:
<!--+
55 : | Specifies the java code source version used to compile the XSP
code.
56 : |
57 : | Posible values:
58 : | 1.3 = Java version 1.3
59 : | 1.4 = Java version 1.4
60 : | 1.5 = Java version 1.5
61 : | auto = The version of the JVM where cocoon is running.
(Default value).
62 : |
63 : | NOTE: The parameter is optional to keep backward compatibility.
64 : anathaniel 555089
<http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/blocks/xsp/conf/xsp-program-language.xconf?view=diff&pathrev=555089&r1=555088&r2=555089>
| The parameter works with Sun Javac compiler and the Eclipse compiler.
65 : antonio 124779
<http://svn.apache.org/viewvc/cocoon/branches/BRANCH_2_1_X/src/blocks/xsp/conf/xsp-program-language.xconf?view=diff&pathrev=555089&r1=124778&r2=124779>
| The pizza compiler does not support java 1.5.
66 : +-->
67 : <!-- <parameter name="compiler-compliance-level" value="auto"/> -->
Best Regards,
Antonio Gallardo
El 21/08/09 09:27, Laurent Medioni escribió:
> Hello,
> Still with our Cocoon 2.1.11 on a 1.6 JVM series...
> Just noticed that org.apache.cocoon.components.language.programming.java.EclipseJavaCompiler does not know anything about 1.6 (nothing wrong with this as it uses JDT 3.1) but in this case defaults to... 1.3, which is quite a big step back from 1.4 ;).
> It is possible to force the compliance level to 1.5 through the xconf parameter compiler-compliance-level but no configuration is possible for the generated class file compatibility, which does not obey to the same parameter...
>
> I tried to replace JDT 3.1 by the latest 3.5 and locally patched EclipseJavaCompiler to manage a 1.6 value... For the moment it works well...
>
> Cheers,
> Laurent
>
> ____________________________________________________________
>
> � This email and any files transmitted with it are CONFIDENTIAL and intended
> solely for the use of the individual or entity to which they are addressed.
> � Any unauthorized copying, disclosure, or distribution of the material within
> this email is strictly forbidden.
> � Any views or opinions presented within this e-mail are solely those of the
> author and do not necessarily represent those of Odyssey Financial
> Technologies SA unless otherwise specifically stated.
> � An electronic message is not binding on its sender. Any message referring to
> a binding engagement must be confirmed in writing and duly signed.
> � If you have received this email in error, please notify the sender immediately
> and delete the original.
>
Cocoon 2.1.11- XSP compiled in Java 1.3 when running Cocoon with a 1.6 JVM and using the Eclipse compiler
Posted by Laurent Medioni <lm...@odyssey-group.com>.
Hello,
Still with our Cocoon 2.1.11 on a 1.6 JVM series...
Just noticed that org.apache.cocoon.components.language.programming.java.EclipseJavaCompiler does not know anything about 1.6 (nothing wrong with this as it uses JDT 3.1) but in this case defaults to... 1.3, which is quite a big step back from 1.4 ;).
It is possible to force the compliance level to 1.5 through the xconf parameter compiler-compliance-level but no configuration is possible for the generated class file compatibility, which does not obey to the same parameter...
I tried to replace JDT 3.1 by the latest 3.5 and locally patched EclipseJavaCompiler to manage a 1.6 value... For the moment it works well...
Cheers,
Laurent
____________________________________________________________
� This email and any files transmitted with it are CONFIDENTIAL and intended
solely for the use of the individual or entity to which they are addressed.
� Any unauthorized copying, disclosure, or distribution of the material within
this email is strictly forbidden.
� Any views or opinions presented within this e-mail are solely those of the
author and do not necessarily represent those of Odyssey Financial
Technologies SA unless otherwise specifically stated.
� An electronic message is not binding on its sender. Any message referring to
a binding engagement must be confirmed in writing and duly signed.
� If you have received this email in error, please notify the sender immediately
and delete the original.
Cocoon 2.1.11- XSP compiled in Java 1.3 when running Cocoon with a 1.6 JVM and using the Eclipse compiler
Posted by Laurent Medioni <lm...@odyssey-group.com>.
Hello,
Still with our Cocoon 2.1.11 on a 1.6 JVM series...
Just noticed that org.apache.cocoon.components.language.programming.java.EclipseJavaCompiler does not know anything about 1.6 (nothing wrong with this as it uses JDT 3.1) but in this case defaults to... 1.3, which is quite a big step back from 1.4 ;).
It is possible to force the compliance level to 1.5 through the xconf parameter compiler-compliance-level but no configuration is possible for the generated class file compatibility, which does not obey to the same parameter...
I tried to replace JDT 3.1 by the latest 3.5 and locally patched EclipseJavaCompiler to manage a 1.6 value... For the moment it works well...
Cheers,
Laurent
____________________________________________________________
� This email and any files transmitted with it are CONFIDENTIAL and intended
solely for the use of the individual or entity to which they are addressed.
� Any unauthorized copying, disclosure, or distribution of the material within
this email is strictly forbidden.
� Any views or opinions presented within this e-mail are solely those of the
author and do not necessarily represent those of Odyssey Financial
Technologies SA unless otherwise specifically stated.
� An electronic message is not binding on its sender. Any message referring to
a binding engagement must be confirmed in writing and duly signed.
� If you have received this email in error, please notify the sender immediately
and delete the original.
RE: Cocoon 2.1.11- Avalon issue using IBM java 6 jvm
Posted by Laurent Medioni <lm...@odyssey-group.com>.
Fix now promised for IBM Java Runtimes 6.0 SR6.
-----Original Message-----
From: Laurent Medioni [mailto:lmedioni@odyssey-group.com]
Sent: lundi, 15. juin 2009 15:41
To: users@cocoon.apache.org
Cc: dev@cocoon.apache.org
Subject: Cocoon 2.1.11- Avalon issue using IBM java 6 jvm
Hello,
On a Websphere 7 server we noticed in the logs many occurrences of:
"WARN ... [core.manager] ... WebContainer : 4/ExcaliburComponentSelector: Attempted to release a $Proxy32 but its handler could not be located."
We have been able to debug the case: ExcaliburComponentSelector is not able to find back a Component proxy in the Component mapping map, and after some investigations the culprit is... the "new" IBM implementation of HashMap.get.
The java 4 IBM jvm does (like the Sun or BEA ones), to compare keys, ((x == y) || (x.equals(y))), == is OK for the proxy, so it works.
The java 6 one skips the == test and ends up directly calling .equals on the proxy, which correctly relays to the proxified item, but still passing a proxy in parameter to the equals, so NOK.
This, at least, leads to leaks in the components maps (components are never released then recreated, ...), and whatever else we have not noticed yet...
We posted this issue to IBM and are waiting for an answer: http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14261744
This issue does not appear when running a Sun or BEA jvm (java 4 or 6) or an IBM java 4 jvm.
Just wanted to let you know...
Thanks.
____________________________________________________________
� This email and any files transmitted with it are CONFIDENTIAL and intended
solely for the use of the individual or entity to which they are addressed.
� Any unauthorized copying, disclosure, or distribution of the material within
this email is strictly forbidden.
� Any views or opinions presented within this e-mail are solely those of the
author and do not necessarily represent those of Odyssey Financial
Technologies SA unless otherwise specifically stated.
� An electronic message is not binding on its sender. Any message referring to
a binding engagement must be confirmed in writing and duly signed.
� If you have received this email in error, please notify the sender immediately
and delete the original.
RE: Cocoon 2.1.11- Avalon issue using IBM java 6 jvm
Posted by Laurent Medioni <lm...@odyssey-group.com>.
Fix now promised for IBM Java Runtimes 6.0 SR6.
-----Original Message-----
From: Laurent Medioni [mailto:lmedioni@odyssey-group.com]
Sent: lundi, 15. juin 2009 15:41
To: users@cocoon.apache.org
Cc: dev@cocoon.apache.org
Subject: Cocoon 2.1.11- Avalon issue using IBM java 6 jvm
Hello,
On a Websphere 7 server we noticed in the logs many occurrences of:
"WARN ... [core.manager] ... WebContainer : 4/ExcaliburComponentSelector: Attempted to release a $Proxy32 but its handler could not be located."
We have been able to debug the case: ExcaliburComponentSelector is not able to find back a Component proxy in the Component mapping map, and after some investigations the culprit is... the "new" IBM implementation of HashMap.get.
The java 4 IBM jvm does (like the Sun or BEA ones), to compare keys, ((x == y) || (x.equals(y))), == is OK for the proxy, so it works.
The java 6 one skips the == test and ends up directly calling .equals on the proxy, which correctly relays to the proxified item, but still passing a proxy in parameter to the equals, so NOK.
This, at least, leads to leaks in the components maps (components are never released then recreated, ...), and whatever else we have not noticed yet...
We posted this issue to IBM and are waiting for an answer: http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14261744
This issue does not appear when running a Sun or BEA jvm (java 4 or 6) or an IBM java 4 jvm.
Just wanted to let you know...
Thanks.
____________________________________________________________
� This email and any files transmitted with it are CONFIDENTIAL and intended
solely for the use of the individual or entity to which they are addressed.
� Any unauthorized copying, disclosure, or distribution of the material within
this email is strictly forbidden.
� Any views or opinions presented within this e-mail are solely those of the
author and do not necessarily represent those of Odyssey Financial
Technologies SA unless otherwise specifically stated.
� An electronic message is not binding on its sender. Any message referring to
a binding engagement must be confirmed in writing and duly signed.
� If you have received this email in error, please notify the sender immediately
and delete the original.
Cocoon 2.1.11- Avalon issue using IBM java 6 jvm
Posted by Laurent Medioni <lm...@odyssey-group.com>.
Hello,
On a Websphere 7 server we noticed in the logs many occurrences of:
"WARN ... [core.manager] ... WebContainer : 4/ExcaliburComponentSelector: Attempted to release a $Proxy32 but its handler could not be located."
We have been able to debug the case: ExcaliburComponentSelector is not able to find back a Component proxy in the Component mapping map, and after some investigations the culprit is... the "new" IBM implementation of HashMap.get.
The java 4 IBM jvm does (like the Sun or BEA ones), to compare keys, ((x == y) || (x.equals(y))), == is OK for the proxy, so it works.
The java 6 one skips the == test and ends up directly calling .equals on the proxy, which correctly relays to the proxified item, but still passing a proxy in parameter to the equals, so NOK.
This, at least, leads to leaks in the components maps (components are never released then recreated, ...), and whatever else we have not noticed yet...
We posted this issue to IBM and are waiting for an answer: http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14261744
This issue does not appear when running a Sun or BEA jvm (java 4 or 6) or an IBM java 4 jvm.
Just wanted to let you know...
Thanks.
____________________________________________________________
� This email and any files transmitted with it are CONFIDENTIAL and intended
solely for the use of the individual or entity to which they are addressed.
� Any unauthorized copying, disclosure, or distribution of the material within
this email is strictly forbidden.
� Any views or opinions presented within this e-mail are solely those of the
author and do not necessarily represent those of Odyssey Financial
Technologies SA unless otherwise specifically stated.
� An electronic message is not binding on its sender. Any message referring to
a binding engagement must be confirmed in writing and duly signed.
� If you have received this email in error, please notify the sender immediately
and delete the original.
Cocoon 2.1.11- Avalon issue using IBM java 6 jvm
Posted by Laurent Medioni <lm...@odyssey-group.com>.
Hello,
On a Websphere 7 server we noticed in the logs many occurrences of:
"WARN ... [core.manager] ... WebContainer : 4/ExcaliburComponentSelector: Attempted to release a $Proxy32 but its handler could not be located."
We have been able to debug the case: ExcaliburComponentSelector is not able to find back a Component proxy in the Component mapping map, and after some investigations the culprit is... the "new" IBM implementation of HashMap.get.
The java 4 IBM jvm does (like the Sun or BEA ones), to compare keys, ((x == y) || (x.equals(y))), == is OK for the proxy, so it works.
The java 6 one skips the == test and ends up directly calling .equals on the proxy, which correctly relays to the proxified item, but still passing a proxy in parameter to the equals, so NOK.
This, at least, leads to leaks in the components maps (components are never released then recreated, ...), and whatever else we have not noticed yet...
We posted this issue to IBM and are waiting for an answer: http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14261744
This issue does not appear when running a Sun or BEA jvm (java 4 or 6) or an IBM java 4 jvm.
Just wanted to let you know...
Thanks.
____________________________________________________________
� This email and any files transmitted with it are CONFIDENTIAL and intended
solely for the use of the individual or entity to which they are addressed.
� Any unauthorized copying, disclosure, or distribution of the material within
this email is strictly forbidden.
� Any views or opinions presented within this e-mail are solely those of the
author and do not necessarily represent those of Odyssey Financial
Technologies SA unless otherwise specifically stated.
� An electronic message is not binding on its sender. Any message referring to
a binding engagement must be confirmed in writing and duly signed.
� If you have received this email in error, please notify the sender immediately
and delete the original.
Re: IncludeTransformer: 2 parallel threads only ?
Posted by Christophe Fondacci <ch...@nextep-softwares.com>.
Hello all,
Digged a little further to find out why external URLs inclusion cannot be done in parallel.
It seems like the problem is located in the org.apache.cocoon.transformation.IncludeTransformer line 563 (Cocoon 2.1.11) :
synchronized (validity) {
validity.addSource(source);
}
The second "external" inclusion processed by the IncludeTransformer is waiting for synch on the addSource method call.
When working with sitemap inclusions (cocoon://), the source.getValidity performed by the addSource method returns immediately without really invoking the URL. There is no synchronization issue here.
When working with external URL inclusions (http://), the source.getValidity makes the remote call and waits for the element to be generated, thus creating synchronization issues preventing the use of parallel inclusion of external URL. Each inclusion will wait on the synchronize until the previous call returns.
Is there a way to workaround this ?
Thank you,
Christophe
From: Christophe Fondacci
Sent: Thursday, June 11, 2009 11:03 AM
To: users@cocoon.apache.org
Subject: Re: IncludeTransformer: 2 parallel threads only ?
Update :
Default parallel inclusion seems to work fine with any number of threads.
To workaround the last point of my previous email (parallel inclusion of "external" URLs), I made a XSP wrapper which is a XSP to include locally (through "cocoon:/"), though enabling parallelism, which simply includes external URL.
When I use this XSP to wrap all my external inclusions, parallelism do work but limits the parallelism to 2 threads.
Here is an extract of the content of this wrapper XSP :
<content>
<xsp:logic>
final String myURL = <util:get-sitemap-parameter name="my_url"/>;
final String xspRef = request.getParameter(CocoonURLUtils.PARAM_XSP_REF);
final String urlQuery = CocoonURLUtils.getURLQuery(request);
<i:include>
<xsp:attribute name="src"><xsp:expr>myURL</xsp:expr>/<xsp:expr>xspRef</xsp:expr><xsp:expr>urlQuery</xsp:expr></xsp:attribute>
</i:include>
</xsp:logic>
</content>
Thanks to anyone who could explain me why do i have this behaviour.
Christophe.
From: Christophe Fondacci
Sent: Thursday, June 11, 2009 10:26 AM
To: users@cocoon.apache.org
Subject: IncludeTransformer: 2 parallel threads only ?
Hello all,
I am currently working with the parallel inclusion through the IncludeTransformer. Our website is based on Cocoon 2.1.11.
It works fine and we truly like this feature, but I notice some strange behaviour :
a.. I have a XSP page with 4 "i:include" inclusions. We configured the include transformer in the sitemap to enable parallelism.
b.. I placed breakpoints on every included page to see how cocoon processes the inclusions.
c.. When I try to generate this page, it seems like inclusions are made 2 by 2. I see 2 of my breakpoints being reached, the others being reached only after completion of these first inclusions. The weird thing is that the order seem to change randomly : sometime i got inclusion 1 and 4 first, sometime 1 and 2, etc. I would have expected to see my 4 breakpoints being reached in 4 distinct threads...
Could someone explain to me if it is possible to include these 4 elements in 4 parallel threads or whether there are some limitations or restrictions on the parallelism ?
The other thing (less important since i found a workaround) is that parallelism seem to only work when referencing local elements through the cocoon protocol (URI like "cocoon:/"). As soon as we reference inclusions through "external" URLs (URI like "http://"), every inclusion seem to be processed sequentially.
Could you confirm this is the expected behaviour ? If someone can explain me why it is working this way I would be very interested.
Thank your very much for your help / time
& keep up the good work !
Christophe.
Re: IncludeTransformer: 2 parallel threads only ?
Posted by Christophe Fondacci <ch...@nextep-softwares.com>.
Update :
Default parallel inclusion seems to work fine with any number of threads.
To workaround the last point of my previous email (parallel inclusion of "external" URLs), I made a XSP wrapper which is a XSP to include locally (through "cocoon:/"), though enabling parallelism, which simply includes external URL.
When I use this XSP to wrap all my external inclusions, parallelism do work but limits the parallelism to 2 threads.
Here is an extract of the content of this wrapper XSP :
<content>
<xsp:logic>
final String myURL = <util:get-sitemap-parameter name="my_url"/>;
final String xspRef = request.getParameter(CocoonURLUtils.PARAM_XSP_REF);
final String urlQuery = CocoonURLUtils.getURLQuery(request);
<i:include>
<xsp:attribute name="src"><xsp:expr>myURL</xsp:expr>/<xsp:expr>xspRef</xsp:expr><xsp:expr>urlQuery</xsp:expr></xsp:attribute>
</i:include>
</xsp:logic>
</content>
Thanks to anyone who could explain me why do i have this behaviour.
Christophe.
From: Christophe Fondacci
Sent: Thursday, June 11, 2009 10:26 AM
To: users@cocoon.apache.org
Subject: IncludeTransformer: 2 parallel threads only ?
Hello all,
I am currently working with the parallel inclusion through the IncludeTransformer. Our website is based on Cocoon 2.1.11.
It works fine and we truly like this feature, but I notice some strange behaviour :
a.. I have a XSP page with 4 "i:include" inclusions. We configured the include transformer in the sitemap to enable parallelism.
b.. I placed breakpoints on every included page to see how cocoon processes the inclusions.
c.. When I try to generate this page, it seems like inclusions are made 2 by 2. I see 2 of my breakpoints being reached, the others being reached only after completion of these first inclusions. The weird thing is that the order seem to change randomly : sometime i got inclusion 1 and 4 first, sometime 1 and 2, etc. I would have expected to see my 4 breakpoints being reached in 4 distinct threads...
Could someone explain to me if it is possible to include these 4 elements in 4 parallel threads or whether there are some limitations or restrictions on the parallelism ?
The other thing (less important since i found a workaround) is that parallelism seem to only work when referencing local elements through the cocoon protocol (URI like "cocoon:/"). As soon as we reference inclusions through "external" URLs (URI like "http://"), every inclusion seem to be processed sequentially.
Could you confirm this is the expected behaviour ? If someone can explain me why it is working this way I would be very interested.
Thank your very much for your help / time
& keep up the good work !
Christophe.