java.lang.Exception: Someone tried to close the stream System.err

Atlassian JIRA | Igor Ristic | 10 years ago
  1. 0

    Quoting the error description: {quote} I can confirm that the cvs components of JIRA do indirectly attempt close the logs, resulting in a close of System.err, which, due to tomcat invocation redirection, is the same as stdout. I have attached a wrapping Stream to stderr that dumps a stacktrace whenever someone attempts to close it. Here is it's output (there are plenty of those at JIRA startup): {noformat} java.lang.Exception: Someone tried to close the stream System.err at be.rmi.intranet.tomcat.IOGuardianListener$GuardedStream.close(IOGuardianListener.java:95) at org.apache.jasper.util.SystemLogHandler.close(SystemLogHandler.java:123) at org.apache.jasper.util.SystemLogHandler.close(SystemLogHandler.java:123) at org.apache.jasper.util.SystemLogHandler.close(SystemLogHandler.java:123) at com.jcraft.jsch.IO.close(Unknown Source) at com.jcraft.jsch.Channel.disconnect(Unknown Source) at org.netbeans.lib.cvsclient.connection.ExtConnection.close(Unknown Source) at com.atlassian.jira.vcs.cvsimpl.CvsRepositoryUtilImpl.updateCvs(CvsRepositoryUtilImpl.java:427) at com.atlassian.jira.vcs.cvsimpl.CvsRepository.updateCvs(CvsRepository.java:232) at com.atlassian.jira.vcs.cvsimpl.CvsRepository.updateRepository(CvsRepository.java:287) at com.atlassian.jira.vcs.DefaultRepositoryManager.updateRepository(DefaultRepositoryManager.java:547) at com.atlassian.jira.vcs.DefaultRepositoryManager.updateRepositories(DefaultRepositoryManager.java:500) at com.atlassian.jira.service.services.vcs.VcsService.run(VcsService.java:54) at com.atlassian.jira.service.JiraServiceContainerImpl.run(JiraServiceContainerImpl.java:67) at com.atlassian.jira.service.ServiceRunner.execute(ServiceRunner.java:48) at org.quartz.core.JobRunShell.run(JobRunShell.java:191) at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:516) {noformat} Here is, basically, the code used to 'guard' System.err stream: {noformat} PrintStream err = System.err; err.flush(); System.setErr(new GuardedStream(err,"System.err")); {noformat} GuardedStream follows simply the delegation pattern, except for close() where it refuses the close() operation and dumps a stacktrace to stdout. {quote}

    Atlassian JIRA | 10 years ago | Igor Ristic
    java.lang.Exception: Someone tried to close the stream System.err
  2. 0

    Quoting the error description: {quote} I can confirm that the cvs components of JIRA do indirectly attempt close the logs, resulting in a close of System.err, which, due to tomcat invocation redirection, is the same as stdout. I have attached a wrapping Stream to stderr that dumps a stacktrace whenever someone attempts to close it. Here is it's output (there are plenty of those at JIRA startup): {noformat} java.lang.Exception: Someone tried to close the stream System.err at be.rmi.intranet.tomcat.IOGuardianListener$GuardedStream.close(IOGuardianListener.java:95) at org.apache.jasper.util.SystemLogHandler.close(SystemLogHandler.java:123) at org.apache.jasper.util.SystemLogHandler.close(SystemLogHandler.java:123) at org.apache.jasper.util.SystemLogHandler.close(SystemLogHandler.java:123) at com.jcraft.jsch.IO.close(Unknown Source) at com.jcraft.jsch.Channel.disconnect(Unknown Source) at org.netbeans.lib.cvsclient.connection.ExtConnection.close(Unknown Source) at com.atlassian.jira.vcs.cvsimpl.CvsRepositoryUtilImpl.updateCvs(CvsRepositoryUtilImpl.java:427) at com.atlassian.jira.vcs.cvsimpl.CvsRepository.updateCvs(CvsRepository.java:232) at com.atlassian.jira.vcs.cvsimpl.CvsRepository.updateRepository(CvsRepository.java:287) at com.atlassian.jira.vcs.DefaultRepositoryManager.updateRepository(DefaultRepositoryManager.java:547) at com.atlassian.jira.vcs.DefaultRepositoryManager.updateRepositories(DefaultRepositoryManager.java:500) at com.atlassian.jira.service.services.vcs.VcsService.run(VcsService.java:54) at com.atlassian.jira.service.JiraServiceContainerImpl.run(JiraServiceContainerImpl.java:67) at com.atlassian.jira.service.ServiceRunner.execute(ServiceRunner.java:48) at org.quartz.core.JobRunShell.run(JobRunShell.java:191) at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:516) {noformat} Here is, basically, the code used to 'guard' System.err stream: {noformat} PrintStream err = System.err; err.flush(); System.setErr(new GuardedStream(err,"System.err")); {noformat} GuardedStream follows simply the delegation pattern, except for close() where it refuses the close() operation and dumps a stacktrace to stdout. {quote}

    Atlassian JIRA | 10 years ago | Igor Ristic
    java.lang.Exception: Someone tried to close the stream System.err
  3. 0

    (17839156) stuck in xdf file creation and couldn’t proceed further

    Oracle Community | 2 years ago | Twila Chavez-Oracle
    java.lang.Exception: Unable to close the database connection using schema username/password. The exception message is No more data to read from socket
  4. Speed up your debug routine!

    Automated exception search integrated into your IDE

  5. 0

    Problem with multiple params in URL

    Icesoft | 7 years ago | Fanka_DE
    java.lang.Exception: javax.faces.FacesException: Can't parse stream for /mypage.jspx The reference to entity "param2" must end with the ';' delimiter.
  6. 0

    HikariCP detects connectionleak even though all of my code has a call to close method

    Stack Overflow | 2 months ago | JRojo
    java.lang.Exception: Apparent connection leak detected I already checked and made sure all my sql codes has a call to close method. Here's my HikariConfig : private HikariConfig hikariConfig() { HikariConfig config = new HikariConfig(); config.setDriverClassName(CLASS_FOR_NAME); config.setJdbcUrl(HOST); config.setUsername(USER); config.setPassword(PASS); config.addDataSourceProperty("cachePrepStmts", "true"); config.addDataSourceProperty("prepStmtCacheSize", "250"); config.addDataSourceProperty("prepStmtCacheSqlLimit", "2048"); config.setLeakDetectionThreshold(TimeUnit.SECONDS.toMillis(30)); config.setValidationTimeout(TimeUnit.MINUTES.toMillis(1)); config.setMaximumPoolSize(40); config.setMinimumIdle(0); config.setMaxLifetime(TimeUnit.MINUTES.toMillis(2)); // 120 seconds max life time config.setIdleTimeout(TimeUnit.MINUTES.toMillis(1)); // minutes config.setConnectionTimeout(TimeUnit.MINUTES.toMillis(5)); // millis config.setConnectionTestQuery("/* ping */ SELECT 1"); return config; } here's how my queries look like : public ArrayList<LocationType> getLocationTypes() { ArrayList<LocationType> locationTypes = new ArrayList<>(); Connection connection = null; PreparedStatement pstmt = null; ResultSet resultSet = null; try { connection = DataSource.getInstance().getConnection(); pstmt = connection.prepareStatement("SELECT\n" + " location_type_id,\n" + " location_type_name\n" + "FROM tablename;"); resultSet = pstmt.executeQuery(); while (resultSet.next()) { locationTypes.add(new LocationType(resultSet.getInt("location_type_id"), resultSet.getString("location_type_name"))); } } catch (Exception e) { e.printStackTrace(); } finally { if (resultSet != null) try { resultSet.close(); } catch (SQLException e) { } if (pstmt != null) try { pstmt.close(); } catch (SQLException e) { } if (connection != null) try { connection.close(); } catch (SQLException e) { } } return locationTypes; } I've already tried increasing the connectionLeakDetection, max connection and minimum idle but none of that solved the issue. I have read that it could be caused by the machine(low resources) and connections being closed, I think however, none of these causes the issue. I noticed that some long queries in my code are now being detected as connection leak, even though I am not calling their methods. I hope you guys could help. This is the stack trace : at com..database.DataSource.getConnection(DataSource.java:148)

    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.lang.Exception

      Someone tried to close the stream System.err

      at be.rmi.intranet.tomcat.IOGuardianListener$GuardedStream.close()
    2. be.rmi.intranet
      IOGuardianListener$GuardedStream.close
      1. be.rmi.intranet.tomcat.IOGuardianListener$GuardedStream.close(IOGuardianListener.java:95)
      1 frame
    3. GWT dev
      SystemLogHandler.close
      1. org.apache.jasper.util.SystemLogHandler.close(SystemLogHandler.java:123)
      2. org.apache.jasper.util.SystemLogHandler.close(SystemLogHandler.java:123)
      3. org.apache.jasper.util.SystemLogHandler.close(SystemLogHandler.java:123)
      3 frames
    4. JSch
      Channel.disconnect
      1. com.jcraft.jsch.IO.close(Unknown Source)
      2. com.jcraft.jsch.Channel.disconnect(Unknown Source)
      2 frames
    5. org.netbeans.lib
      ExtConnection.close
      1. org.netbeans.lib.cvsclient.connection.ExtConnection.close(Unknown Source)
      1 frame
    6. com.atlassian.jira
      ServiceRunner.execute
      1. com.atlassian.jira.vcs.cvsimpl.CvsRepositoryUtilImpl.updateCvs(CvsRepositoryUtilImpl.java:427)
      2. com.atlassian.jira.vcs.cvsimpl.CvsRepository.updateCvs(CvsRepository.java:232)
      3. com.atlassian.jira.vcs.cvsimpl.CvsRepository.updateRepository(CvsRepository.java:287)
      4. com.atlassian.jira.vcs.DefaultRepositoryManager.updateRepository(DefaultRepositoryManager.java:547)
      5. com.atlassian.jira.vcs.DefaultRepositoryManager.updateRepositories(DefaultRepositoryManager.java:500)
      6. com.atlassian.jira.service.services.vcs.VcsService.run(VcsService.java:54)
      7. com.atlassian.jira.service.JiraServiceContainerImpl.run(JiraServiceContainerImpl.java:67)
      8. com.atlassian.jira.service.ServiceRunner.execute(ServiceRunner.java:48)
      8 frames
    7. quartz
      SimpleThreadPool$WorkerThread.run
      1. org.quartz.core.JobRunShell.run(JobRunShell.java:191)
      2. org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:516)
      2 frames