[jira] [Commented] (COCOON-2340) XMLByteStreamCompiler in not thread-safe
[ https://issues.apache.org/jira/browse/COCOON-2340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13834764#comment-13834764 ] Ivan Lagunov commented on COCOON-2340: -- Hi Javier, I would like to try Cocoon 2.2.1 first but could you say where it's located? I suppose it must be under trunk here http://svn.apache.org/repos/asf/cocoon/trunk/ ? Is it stable enough for Production usage? I mean it's written here that SNAPSHOTS are not tested and not guaranteed to even build cleanly: https://cocoon.apache.org/mirror.cgi Ivan XMLByteStreamCompiler in not thread-safe Key: COCOON-2340 URL: https://issues.apache.org/jira/browse/COCOON-2340 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2 Reporter: Ivan Lagunov I'm periodically getting the following exceptions in different places: Caused by: java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(Native Method) at org.apache.cocoon.components.sax.XMLByteStreamCompiler.getSAXFragment(XMLByteStreamCompiler.java:61) at org.apache.cocoon.components.pipeline.impl.ExpiresCachingProcessingPipeline.processXMLPipeline(ExpiresCachingProcessingPipeline.java:152) After debugging I've found the root cause. It happens due to multi-threading when one thread allocates newbuf array, then another thread increments bufCount in write method and then the first thread fails on System.arraycopy invocation. I suggest making getSAXFragment and write methods synchronized. It should resolve the issue. If it helps, I'll provide a patch later. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Comment Edited] (COCOON-2340) XMLByteStreamCompiler in not thread-safe
[ https://issues.apache.org/jira/browse/COCOON-2340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13834764#comment-13834764 ] Ivan Lagunov edited comment on COCOON-2340 at 11/28/13 12:15 PM: - Hi Javier, I would like to try Cocoon 2.2.1 first but could you say where it's located? I suppose it must be under trunk here http://svn.apache.org/repos/asf/cocoon/trunk/ ? Is it stable enough for Production usage? It's written here that SNAPSHOTS are not tested and not guaranteed to even build cleanly: https://cocoon.apache.org/mirror.cgi Regarding singleton components in the pipeline. I'm using standard Cocoon components, you can see the exception is coming from ExpiresCachingProcessingPipeline. Did you mean that some Cocoon 2.2 components are declared as singletons? Because I don't think I can fix it in my code. Ivan was (Author: lagivan): Hi Javier, I would like to try Cocoon 2.2.1 first but could you say where it's located? I suppose it must be under trunk here http://svn.apache.org/repos/asf/cocoon/trunk/ ? Is it stable enough for Production usage? I mean it's written here that SNAPSHOTS are not tested and not guaranteed to even build cleanly: https://cocoon.apache.org/mirror.cgi Ivan XMLByteStreamCompiler in not thread-safe Key: COCOON-2340 URL: https://issues.apache.org/jira/browse/COCOON-2340 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2 Reporter: Ivan Lagunov I'm periodically getting the following exceptions in different places: Caused by: java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(Native Method) at org.apache.cocoon.components.sax.XMLByteStreamCompiler.getSAXFragment(XMLByteStreamCompiler.java:61) at org.apache.cocoon.components.pipeline.impl.ExpiresCachingProcessingPipeline.processXMLPipeline(ExpiresCachingProcessingPipeline.java:152) After debugging I've found the root cause. It happens due to multi-threading when one thread allocates newbuf array, then another thread increments bufCount in write method and then the first thread fails on System.arraycopy invocation. I suggest making getSAXFragment and write methods synchronized. It should resolve the issue. If it helps, I'll provide a patch later. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (COCOON-2340) XMLByteStreamCompiler in not thread-safe
Ivan Lagunov created COCOON-2340: Summary: XMLByteStreamCompiler in not thread-safe Key: COCOON-2340 URL: https://issues.apache.org/jira/browse/COCOON-2340 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2 Reporter: Ivan Lagunov I'm periodically getting the following exceptions in different places: Caused by: java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(Native Method) at org.apache.cocoon.components.sax.XMLByteStreamCompiler.getSAXFragment(XMLByteStreamCompiler.java:61) at org.apache.cocoon.components.pipeline.impl.ExpiresCachingProcessingPipeline.processXMLPipeline(ExpiresCachingProcessingPipeline.java:152) After debugging I've found the root cause. It happens due to multi-threading when one thread allocates newbuf array, then another thread increments bufCount in write method and then the first thread fails on System.arraycopy invocation. I suggest making getSAXFragment and write methods synchronized. It should resolve the issue. If it helps, I'll provide a patch later. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (COCOON-2340) XMLByteStreamCompiler in not thread-safe
[ https://issues.apache.org/jira/browse/COCOON-2340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13833877#comment-13833877 ] Ivan Lagunov commented on COCOON-2340: -- Synchronization helped to avoid the Exception although now the resource seems to be loaded partially. So the root cause is on the upper level. Perhaps, all writes to this.buf must be done before getSAXFragment invocation because all the data written to this.buf afterwards seems to be ignored. XMLByteStreamCompiler in not thread-safe Key: COCOON-2340 URL: https://issues.apache.org/jira/browse/COCOON-2340 Project: Cocoon Issue Type: Bug Components: * Cocoon Core Affects Versions: 2.2 Reporter: Ivan Lagunov I'm periodically getting the following exceptions in different places: Caused by: java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(Native Method) at org.apache.cocoon.components.sax.XMLByteStreamCompiler.getSAXFragment(XMLByteStreamCompiler.java:61) at org.apache.cocoon.components.pipeline.impl.ExpiresCachingProcessingPipeline.processXMLPipeline(ExpiresCachingProcessingPipeline.java:152) After debugging I've found the root cause. It happens due to multi-threading when one thread allocates newbuf array, then another thread increments bufCount in write method and then the first thread fails on System.arraycopy invocation. I suggest making getSAXFragment and write methods synchronized. It should resolve the issue. If it helps, I'll provide a patch later. -- This message was sent by Atlassian JIRA (v6.1#6144)
Getting Exception.getMessage in map:handle-errors
Hello, Is it possible to access fields of the thrown Exception inside map:handle-errors? I want to do something like this: map:handle-errors map:select type=exception map:when test=processing map:generate src=page/exception.jx type=jx map:parameter name=errorMessage value=want to extract Exception.getMessage() here/ /map:generate map:serialize type=xhtml/ /map:when /map:select /map:handle-errors Where selector is defined as following: map:selector name=exception src=org.apache.cocoon.selection.ExceptionSelector exception name=processing class=org.apache.cocoon.ProcessingException/ /map:selector Any ideas how to achieve this? Best regards, Ivan Lagunov
NPE during source validity check for ValidatingTransformer
Hi, I've caught the following NullPointerException: org.apache.excalibur.source.impl.validity.AggregatedValidity.isValid(AggregatedValidity.java:45) org.apache.cocoon.components.validation.impl.CachingValidator.getSchema(CachingValidator.java:129) org.apache.cocoon.components.validation.impl.AbstractValidator.getValidationHandler(AbstractValidator.java:330) org.apache.cocoon.components.validation.impl.AbstractValidator.getValidationHandler(AbstractValidator.java:244) org.apache.cocoon.transformation.ValidatingTransformer.setup(ValidatingTransformer.java:135) So what is happening? It appeared that AggregatedValidity.m_list array list held null element. The null element was added to m_list in ValidationResolver. resolveSource method: /* Record the current source in the validities to return */ this.sourceValidity.add(source.getValidity()); The javadoc for Source.getValidity() says: Get the Validity object. This can either wrap the last modification date or some expiry information or anything else describing this object's validity. If it is currently not possible to calculate such an information, null is returned. The fact is that my Source is being loaded from XML DB by custom generator and it seems to be correct that validity is null. I suppose it's a bug and it can be fixed in the following way: /* Record the current source in the validities to return */ If (source.getValidity() != null) this.sourceValidity.add(source.getValidity()); This worked for me. I suggest this as an official commit. Best regards, Ivan Lagunov
Problem running maven jetty:run for cocoon block module
Hi, Just want to share my workaround for the following issue. I have a cocoon web app being run under tomcat with jdk6. After some changes (including maven 2 - maven 3 migration and some code changes) I keep getting this error while executing maven jetty:run goal: Error DOMSource cannot be processed: check that saxon8-dom.jar is on the classpath Dec 14, 2011 11:27:41 AM com.sun.xml.internal.messaging.saaj.soap.MessageImpl saveChanges SEVERE: SAAJ0539: Unable to get header stream in saveChanges Dec 14, 2011 11:27:42 AM com.sun.xml.internal.messaging.saaj.soap.MessageImpl saveChanges SEVERE: SAAJ0540: Error during saving a multipart message Having searched in the web, I've come across this thread: http://forum.springsource.org/archive/index.php/t-41774.html Indeed, cocoon-core and some other cocoon components (e.g. cocoon-sitemap-impl, cocoon-fop-ng-impl) have xerces, xalan and xml-apis transitive dependencies. Thus, I've tried different ways and ended up with excluding these dependencies for cocoon-core like this: dependency groupIdorg.apache.cocoon/groupId artifactIdcocoon-core/artifactId version2.2.0/version exclusions exclusion groupIdxalan/groupId artifactIdxalan/artifactId /exclusion exclusion groupIdxerces/groupId artifactIdxercesImpl/artifactId /exclusion exclusion groupIdxml-apis/groupId artifactIdxml-apis/artifactId /exclusion /exclusions /dependency It solved the issue and jetty:run works fine now. However, I'm not totally sure why this way works as the same dependencies exist in other places as well (moreover, the final application build didn't change at all with my modifications). So the only guess I have is it may be related to the loading order of libraries in the classpath. If anybody has a better understanding on this, please share your ideas. Best regards, Ivan Lagunov
Re: Nullpointer in ZipSerializer (cocoon 2.2)
Robby Pelssers Robby.Pelssers at nxp.com writes:
Hi guys,
Just wanted to know if the issue in below thread has ever been fixed.
http://web.archiveorange.com/archive/v/uRmkWnxszXP6g7Xuw33H
To shortly describe the use case:
http://cocoon.apache.org/2.1/userdocs/ziparchive-serializer.html
The zipserializer only allows either:
- You specify a at src pointing to some cocoon pipeline using
cocoon:// (Ideally it would also support the servlet: protocol as now I have
to provide a façade in the calling cocoon block)
- You specify inline content and the at serializer
In a ideal world you should be able to use at src in combination with the
at serializer because now I have to first include the content from a pipeline
by using cinclude before calling
map:serialize type=”zip”/
I actually created some nice generic functionality to work around some issues:
FLOWSCRIPT ***
function downloadImdsZip() {
var entries = [];
new
Collection(cocoon.request.getParameterValues(id)).forEach(function(id){
var entry = {name: id + .xml, source:
cocoon://chemicalcontent/imds/ + id + .xml, serializer: upload};
print('Adding entry [name=' + entry.name + ', source=' +
entry.source + '] to ZIP archive.');
entries.push(entry);
});
var response = cocoon.response;
response.setHeader(
Content-Disposition,
attachment; filename=imds.zip
);
cocoon.sendPage(zipArchive, {entries: entries});
}
*
?xml version=1.0 encoding=UTF-8?
jx:template
xmlns:jx=http://apache.org/cocoon/templates/jx/1.0;
xmlns:zip=http://apache.org/cocoon/zip-archive/1.0;
xmlns:cinclude=http://apache.org/cocoon/include/1.0;
!--
This jx expects an array called 'entries' containing objects with
following
properties:
* name (mandatory)
* source (mandatory)
* serializer (optional)
*
* If both source and serializer are provided, we assume that we want to
include the content inline so we can specify the serializer
--
zip:archive
jx:forEach var=entry items=${entries}
zip:entry name=${entry.name}
jx:choose
jx:when test=${entry.serializer != null}
jx:attribute name=serializer value=${entry.serializer}/
cinclude:include src=${entry.source}/
/jx:when
jx:otherwise
jx:attribute name=src value=${entry.source}/
/jx:otherwise
/jx:choose
/zip:entry
/jx:forEach
/zip:archive
/jx:template
*
map:match pattern=zipArchive
map:generate src=jx/zipArchive.jx type=jx/
map:transform type=cinclude/
map:serialize type=zip/
/map:match
*
But I now am facing the same nullpointer exception as in the link above.
Anyone some usefull input on this matter?
Cheers,
Robby Pelssers
Hi Robby,
Just want to share my fix with the community. The NullPointerException was
caused by ZipArchiveSerializer (improper usage of a setter method). If you read
javadocs, they'll tell you that you shouldn't provide null to setConsumer
method. You can use the specific method to deinitialize consumer. Here is the
patch:
Index: src/main/java/org/apache/cocoon/serialization/ZipArchiveSerializer.java
===
--- src/main/java/org/apache/cocoon/serialization/ZipArchiveSerializer.java
(revision 1208405)
+++ src/main/java/org/apache/cocoon/serialization/ZipArchiveSerializer.java
(revision )
@@ -369,7 +369,7 @@
throw this.exception = new SAXException(ioe);
}
-super.setConsumer(null);
+super.recycle();
this.selector.release(this.serializer);
this.serializer = null;
Best regards,
Ivan Lagunov
