CRJAZ0040I error in logPublisher Ant task
Hello,
I am using JBE on Linux to run an Ant build that starts an external job. After the job is done, I attach the job log file to the current build result with the Jazz logPublisher Ant task:
From time to time, the logPublisher fails with the following error
com.ibm.team.repository.common.TeamRepositoryException:
CRJAZ0040I I/O error preprocessing the stream: Input length = 1
The job log file is a large (28 MB) text file that contains some UTF-8 chars and has very long lines. It's generated on Linux. Command "file" tells me:
joblog.txt: UTF-8 Unicode English text, with very long lines.
The questions are: Is the logPublisher failing because of the UTF-8 characters? If so, how do avoid that problem? Should I instead use the filePublisher task?
I am running RTC 2.0.0.2.
I am using JBE on Linux to run an Ant build that starts an external job. After the job is done, I attach the job log file to the current build result with the Jazz logPublisher Ant task:
< logPublisher
buildResultUUID="${buildResultUUID}"
repositoryAddress="${repositoryAddress}"
userId="rtcuser"
passwordFile="path/to/pwd/file"
label="Job log for xxxx"
filePath="/path/to/joblog.txt"
/>
From time to time, the logPublisher fails with the following error
com.ibm.team.repository.common.TeamRepositoryException:
CRJAZ0040I I/O error preprocessing the stream: Input length = 1
The job log file is a large (28 MB) text file that contains some UTF-8 chars and has very long lines. It's generated on Linux. Command "file" tells me:
joblog.txt: UTF-8 Unicode English text, with very long lines.
The questions are: Is the logPublisher failing because of the UTF-8 characters? If so, how do avoid that problem? Should I instead use the filePublisher task?
I am running RTC 2.0.0.2.
Accepted answer
Yes, your hypothesis is correct: the character encoding is ignored when you specify a content type that doesn't start with "text".
You may get different behavior when trying to view those files from within the Eclipse client. It uses a mix of file extension and content type to determine which editor to use.
You may get different behavior when trying to view those files from within the Eclipse client. It uses a mix of file extension and content type to determine which editor to use.
2 other answers
Try adding characterEncoding="UTF-8". Also verbose="true" will show the full stack trace of the failure, letting us look into it further.
I tried this. The stack trace show that this is indeed a charset problem:
com.ibm.team.repository.common.TeamRepositoryException: CRJAZ0040I I/O error preprocessing the stream: Input length = 1
at com.ibm.team.repository.client.internal.ContentManager$StreamLengthUtility.run(ContentManager.java:261)
at com.ibm.team.repository.client.internal.ContentManager.storeContent(ContentManager.java:401)
at com.ibm.team.repository.client.internal.ContentManager.storeText(ContentManager.java:535)
at com.ibm.team.build.internal.publishing.ContentPublisher.storeTextContent(ContentPublisher.java:155)
at com.ibm.team.build.internal.publishing.ContentPublisher.getFileContent(ContentPublisher.java:82)
at com.ibm.team.build.internal.publishing.AbstractFilePublisher.initializeContribution(AbstractFilePublisher.java:49)
at com.ibm.team.build.internal.publishing.AbstractContributionPublisher.publish(AbstractContributionPublisher.java:120)
at com.ibm.team.build.internal.ant.AbstractContentPublisherTask.updateBuildResult(AbstractContentPublisherTask.java:174)
at com.ibm.team.build.ant.task.AbstractPublisherTask.doExecute(AbstractPublisherTask.java:107)
at com.ibm.team.build.ant.task.AbstractTeamBuildTask.execute(AbstractTeamBuildTask.java:433)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
[8><snip><8]
Caused by: java.nio.charset.MalformedInputException: Input length = 1
at java.nio.charset.CoderResult.throwException(CoderResult.java:260)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:319)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158)
at java.io.InputStreamReader.read(InputStreamReader.java:167)
at java.io.Reader.read(Reader.java:83)
at com.ibm.team.repository.client.internal.EncodingConvertingInputStream.ensureByteNonEmpty(EncodingConvertingInputStream.java:56)
at com.ibm.team.repository.client.internal.EncodingConvertingInputStream.read(EncodingConvertingInputStream.java:119)
at java.io.FilterInputStream.read(FilterInputStream.java:116)
at com.ibm.team.repository.common.utils.HashComputingInputStream.read(HashComputingInputStream.java:40)
at java.io.FilterInputStream.read(FilterInputStream.java:90)
at com.ibm.team.repository.client.internal.ContentManager$StreamLengthUtility.run(ContentManager.java:231)
... 25 more
This points to the com.ibm.team.repository.client.internal.EncodingConvertingInputStream as the culprit. It seems to attempt a charset conversion and choke.
Adding characterEncoding="UTF-8" solves the problem ONLY when I am attaching a UTF-8 log. When I attempt to attach a log containing ISO-8859-1 chars, I get the same CRJAZ0040I error.
I found out by trial and error that you can leave the characterEncoding to default and add contentType="application/unknown". This works for all my test cases (including log files with "strange" non-UTF8 characters), so my hypothesis is that this contentType apparently prevents parsing the log as text and ignores the characternEcoding.
Is this hypothesis correct? If not, what's the recommended way to attach log files as binary, without going through the com.ibm.team.repository.client.internal.EncodingConvertingInputStream method?
--Fred Mora