You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Gary Gregory <ga...@gmail.com> on 2016/02/21 07:28:39 UTC
[compress] BZip2 block size is invalid
Hi [compress]:
[cross-posting log4j dev and commons dev]
Any thoughts on:
org.apache.commons.compress.compressors.CompressorException: Could not
create CompressorInputStream.
at org.apache.commons.compress.compressors.CompressorStreamFactory.createCompressorInputStream(CompressorStreamFactory.java:319)
at org.apache.logging.log4j.core.appender.rolling.RollingAppenderSizeTest.testAppender(RollingAppenderSizeTest.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.apache.logging.log4j.junit.LoggerContextRule$1.evaluate(LoggerContextRule.java:94)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83)
at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75)
at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:161)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
Caused by: java.io.IOException: BZip2 block size is invalid
at org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.init(BZip2CompressorInputStream.java:251)
at org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.<init>(BZip2CompressorInputStream.java:133)
at org.apache.commons.compress.compressors.CompressorStreamFactory.createCompressorInputStream(CompressorStreamFactory.java:287)
... 47 more
from:
https://builds.apache.org/job/Log4j%202.x/1700/org.apache.logging.log4j$log4j-core/testReport/org.apache.logging.log4j.core.appender.rolling/RollingAppenderSizeTest/testAppender_log4j_rolling_bzip2_xml____bz2_/
?
Thank you,
Gary
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [compress] BZip2 block size is invalid
Posted by Remko Popma <re...@gmail.com>.
Yes, I think you're right.
This ticket may have the same underlying cause: LOG4J2-1266
<https://issues.apache.org/jira/browse/LOG4J2-1266>
Perhaps the compress action needs a countdown latch to force it to wait
until the rename action has completed.
On Mon, Feb 22, 2016 at 1:36 AM, Ralph Goers <ra...@dslextreme.com>
wrote:
> I am wondering if this isn’t a multi-threading problem. When a rollover
> occurs the compression action is delegated to a separate thread so the main
> thread can get back to logging. It may simply be that the test case is
> trying to check the compressed file before it has actually finished being
> created.
>
> Ralph
>
> > On Feb 21, 2016, at 6:14 AM, Stefan Bodewig <bo...@apache.org> wrote:
> >
> > Hi Remko
> >
> > On 2016-02-21, Remko Popma wrote:
> >
> >> The funny/funky thing about this issue is that it only happens on our
> (Ubuntu) Jenkins continuous integration server, not when we build locally.
> (System info: https://builds.apache.org/computer/ubuntu-4/systemInfo)
> >
> >> To make it extra fun it's sporadic and transient: It doesn't always
> happen, and it often goes away without us making any changes...
> >
> >> Any tips on how we can debug this?
> >
> > First of all we need to figure out whether this is a bug on the reading
> > or the writing side. For this we really need to take a look at the file
> > that cannot be read. My best advice is to immediatly download the file
> > in question from the Jenkins workspace when it happens the next time.
> >
> > The bzip2 format is a block based compression algorithm with a block
> > size that's a multiple of 100kB and one of the first bytes of the
> > compressed file indicates the block size as a number between 1 and 9
> > inclusive - for the allowed block sizes of 100k up to 900k. The file in
> > question seems to contain a different value, at least that's what the
> > exception says.
> >
> > I don't know what you do in order to create the file. Faced with
> > sporadic failures like this I'd suspect a race condition somewhere,
> > which the single-threaded BZip2CompressorInputStream is less likely to
> > face.
> >
> > Stefan
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
Re: [compress] BZip2 block size is invalid
Posted by Ralph Goers <ra...@dslextreme.com>.
I am wondering if this isn’t a multi-threading problem. When a rollover occurs the compression action is delegated to a separate thread so the main thread can get back to logging. It may simply be that the test case is trying to check the compressed file before it has actually finished being created.
Ralph
> On Feb 21, 2016, at 6:14 AM, Stefan Bodewig <bo...@apache.org> wrote:
>
> Hi Remko
>
> On 2016-02-21, Remko Popma wrote:
>
>> The funny/funky thing about this issue is that it only happens on our (Ubuntu) Jenkins continuous integration server, not when we build locally. (System info: https://builds.apache.org/computer/ubuntu-4/systemInfo)
>
>> To make it extra fun it's sporadic and transient: It doesn't always happen, and it often goes away without us making any changes...
>
>> Any tips on how we can debug this?
>
> First of all we need to figure out whether this is a bug on the reading
> or the writing side. For this we really need to take a look at the file
> that cannot be read. My best advice is to immediatly download the file
> in question from the Jenkins workspace when it happens the next time.
>
> The bzip2 format is a block based compression algorithm with a block
> size that's a multiple of 100kB and one of the first bytes of the
> compressed file indicates the block size as a number between 1 and 9
> inclusive - for the allowed block sizes of 100k up to 900k. The file in
> question seems to contain a different value, at least that's what the
> exception says.
>
> I don't know what you do in order to create the file. Faced with
> sporadic failures like this I'd suspect a race condition somewhere,
> which the single-threaded BZip2CompressorInputStream is less likely to
> face.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [compress] BZip2 block size is invalid
Posted by Stefan Bodewig <bo...@apache.org>.
Hi Remko
On 2016-02-21, Remko Popma wrote:
> The funny/funky thing about this issue is that it only happens on our (Ubuntu) Jenkins continuous integration server, not when we build locally. (System info: https://builds.apache.org/computer/ubuntu-4/systemInfo)
> To make it extra fun it's sporadic and transient: It doesn't always happen, and it often goes away without us making any changes...
> Any tips on how we can debug this?
First of all we need to figure out whether this is a bug on the reading
or the writing side. For this we really need to take a look at the file
that cannot be read. My best advice is to immediatly download the file
in question from the Jenkins workspace when it happens the next time.
The bzip2 format is a block based compression algorithm with a block
size that's a multiple of 100kB and one of the first bytes of the
compressed file indicates the block size as a number between 1 and 9
inclusive - for the allowed block sizes of 100k up to 900k. The file in
question seems to contain a different value, at least that's what the
exception says.
I don't know what you do in order to create the file. Faced with
sporadic failures like this I'd suspect a race condition somewhere,
which the single-threaded BZip2CompressorInputStream is less likely to
face.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [compress] BZip2 block size is invalid
Posted by Remko Popma <re...@gmail.com>.
Hi Stefan, thanks for getting back to us!
The funny/funky thing about this issue is that it only happens on our (Ubuntu) Jenkins continuous integration server, not when we build locally. (System info: https://builds.apache.org/computer/ubuntu-4/systemInfo)
To make it extra fun it's sporadic and transient: It doesn't always happen, and it often goes away without us making any changes...
Any tips on how we can debug this?
Remko
Sent from my iPhone
> On 2016/02/21, at 18:11, Stefan Bodewig <bo...@apache.org> wrote:
>
>> On 2016-02-21, Gary Gregory wrote:
>>
>> Caused by: java.io.IOException: BZip2 block size is invalid
>> at
>> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.init(BZip2CompressorInputStream.java:251)
>
> Are you sure this is a valid bzip2 file - i.e. can command line bzip2
> uncompress it?
>
> If so, please open a JIRA ticket and attach the file in question (or
> directly create a unit test from it :-)
>
> Cheers
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
Re: [compress] BZip2 block size is invalid
Posted by Stefan Bodewig <bo...@apache.org>.
On 2016-02-21, Gary Gregory wrote:
> Caused by: java.io.IOException: BZip2 block size is invalid
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.init(BZip2CompressorInputStream.java:251)
Are you sure this is a valid bzip2 file - i.e. can command line bzip2
uncompress it?
If so, please open a JIRA ticket and attach the file in question (or
directly create a unit test from it :-)
Cheers
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [compress] BZip2 block size is invalid
Posted by Stefan Bodewig <bo...@apache.org>.
On 2016-02-21, Gary Gregory wrote:
> Caused by: java.io.IOException: BZip2 block size is invalid
> at
> org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.init(BZip2CompressorInputStream.java:251)
Are you sure this is a valid bzip2 file - i.e. can command line bzip2
uncompress it?
If so, please open a JIRA ticket and attach the file in question (or
directly create a unit test from it :-)
Cheers
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org