Google Groups | Marcelo Oikawa | 8 months ago
Click on the to mark the solution that helps you, Samebug will learn from it.
As a community member, you’ll be rewarded for you help.
  1. 0

    Hadoop indexer path issue

    Google Groups | 12 months ago | Unknown author
  2. 0

    Exceptions after hadoop batch ingestion finished with success

    Google Groups | 8 months ago | Marcelo Oikawa
  3. 0

    ExecutorLifecycle stop not idempotent

    GitHub | 1 year ago | drcrallen
  4. Speed up your debug routine!

    Automated exception search integrated into your IDE

  5. 0

    Hey, I've seen that this error has been around for some time and I hope that this description is complete and will be helpful in reproducing and fixing. System: a logback.xml with a file appender with prudent=true. the log path should be to a volume with little available space. Scenario: start writing to the log file. as soon as the space is depleted, errors start happening: 15:44:40,595 |-ERROR in c.q.l.c.recovery.ResilientFileOutputStream@1944673755 - IO failure while writing to file [/Volumes/TESTVOL/logs/my-log.2015-02-01.log] No space left on device at No space left on device at at Method) at at at at at at at at ch.qos.logback.core.recovery.ResilientOutputStreamBase.flush( [...] 15:44:51,064 |-INFO in c.q.l.c.recovery.ResilientFileOutputStream@1944673755 - Attempting to recover from IO failure on file [/Volumes/TESTVOL/logs/my-log.2015-02-01.log] 15:44:51,064 |-INFO in c.q.l.c.recovery.ResilientFileOutputStream@1944673755 - Recovered from IO failure on file [/Volumes/TESTVOL/logs/my-log.2015-02-01.log] 15:44:51,064 |-ERROR in ch.qos.logback.core.rolling.RollingFileAppender[MY_LOG] - IO failure in appender java.nio.channels.ClosedChannelException at java.nio.channels.ClosedChannelException at at and then: 15:44:51,069 |-WARN in ch.qos.logback.core.rolling.RollingFileAppender[MY_LOG] - Attempted to append to non started appender [MY_LOG]. Debugging: i have investigated this issue and found the culprit to be line 204 in FileAppender: finally { if (fileLock != null) { ---> fileLock.release(); } [...] the problem is that when the original IOException was thrown, the channel was closed as part of the attemptRecovery method in ResilientOutputStreamBase. the release will throw a ClosedChannelException if the file channel is closed. the appender is then set to started=false in OutputStreamAppender subAppend Method and stays this way until restarted. Fix suggestion: the easy fix here is changing the guard of the release: finally { if (fileLock != null && fileChannel.isOpen()) { fileLock.release(); } [...] this prevents the release from throwing the exception. for now, an easy mitigation (if possible) is to set prudent=false. hope this helps and the bug will be fixed. JIRA | 2 years ago | Nadav Wexler
  6. 0

    I ran a build in debug mode ({{mvn -X}}) and noticed the following bug (repeatedly): {noformat} [DEBUG] Error releasing shared lock for resolution tracking file: C:\Users\awhitford\.m2\repository\org\apache\maven\plugins\maven-war-plugin\ java.nio.channels.ClosedChannelException at at at org.apache.maven.repository.legacy.DefaultUpdateCheckManager.readLastUpdated( at org.apache.maven.repository.legacy.DefaultUpdateCheckManager.readLastUpdated( at org.apache.maven.repository.legacy.DefaultUpdateCheckManager.isUpdateRequired( at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.resolve( at org.apache.maven.project.artifact.MavenMetadataSource.retrieveAvailableVersions( at org.apache.maven.project.artifact.MavenMetadataSource.retrieveAvailableVersions( at org.codehaus.mojo.versions.api.DefaultVersionsHelper.lookupArtifactVersions( at org.codehaus.mojo.versions.api.DefaultVersionsHelper.lookupPluginUpdates( at org.codehaus.mojo.versions.api.DefaultVersionsHelper.lookupPluginsUpdates( at org.codehaus.mojo.versions.PluginUpdatesReport.doGenerateReport( at org.codehaus.mojo.versions.AbstractVersionsReport.executeReport( at org.apache.maven.reporting.AbstractMavenReport.generate( at at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule( at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render( at at at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo( at org.apache.maven.lifecycle.internal.MojoExecutor.execute( at org.apache.maven.lifecycle.internal.MojoExecutor.execute( at org.apache.maven.lifecycle.internal.MojoExecutor.execute( at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject( at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject( at at org.apache.maven.lifecycle.internal.LifecycleStarter.execute( at org.apache.maven.DefaultMaven.doExecute( at org.apache.maven.DefaultMaven.execute( at org.apache.maven.cli.MavenCli.execute( at org.apache.maven.cli.MavenCli.doMain( at org.apache.maven.cli.MavenCli.main( at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke( at sun.reflect.DelegatingMethodAccessorImpl.invoke( at java.lang.reflect.Method.invoke( at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced( at org.codehaus.plexus.classworlds.launcher.Launcher.launch( at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode( at org.codehaus.plexus.classworlds.launcher.Launcher.main( {noformat} I traced the bug to the {{}} method. [Line 396|] is releasing a FileLock, but the {{FileInputStream}} has already been closed by [Line 381|].

    Apache's JIRA Issue Tracker | 3 years ago | Anthony Whitford

  1. Adarro 3 times, last 8 months ago
Not finding the right solution?
Take a tour to get the most out of Samebug.

Tired of useless tips?

Automated exception search integrated into your IDE

Root Cause Analysis

  1. java.nio.channels.ClosedChannelException

    No message provided

  2. Java RT
    1 frame
  3. Druid Indexing
    1. io.druid.indexing.worker.executor.ExecutorLifecycle.stop([druid-indexing-service-0.8.3.jar:0.8.3]
    1 frame
  4. Java RT
    1. sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[?:1.8.0_91]
    2. sun.reflect.NativeMethodAccessorImpl.invoke([?:1.8.0_91]
    3. sun.reflect.DelegatingMethodAccessorImpl.invoke([?:1.8.0_91]
    4. java.lang.reflect.Method.invoke([?:1.8.0_91]
    4 frames
  5. java-util
    1. com.metamx.common.lifecycle.Lifecycle$AnnotationBasedHandler.stop([java-util-0.27.4.jar:?]
    2. com.metamx.common.lifecycle.Lifecycle.stop([java-util-0.27.4.jar:?]
    2 frames
  6. Druid
    1. io.druid.cli.CliPeon$[druid-services-0.8.3.jar:0.8.3]
    1 frame
  7. Java RT
    1 frame