Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Trivial Trivial
    • Resolution: Fixed
    • Affects Version/s: 2.8.0.M1
    • Fix Version/s: 3.2.0.M2
    • Component/s: SUPPORT
    • Labels:
      None

      Description

      I raised this bug as 'trivial' because the exceptions don't get logged or otherwise visible to users. However, they are mighty annoying when debugging anything in STS.

      I like to have a NPE triggered breakpoint, because, usually, NPEs are bugs that should be fixed, and browsing around their execution context is mighty useful. But since the introduction of UAA it has become very annoying that my NPE breakpoint is constantly being hammered by a UAA thread.

      Stacktrace:

      Daemon Thread [Reporting Thread-1 (Spring UAA/1.0.2)] (Suspended (exception java.lang.NullPointerException))	
      	org.springframework.uaa.client.util.Base64$OutputStream(java.io.FilterOutputStream).flush() line: 123 [local variables unavailable]	
      	org.springframework.uaa.client.util.Base64$OutputStream(java.io.FilterOutputStream).close() line: 140	
      	org.springframework.uaa.client.util.Base64$OutputStream.close() line: 2027	
      	org.springframework.uaa.client.util.Base64.encodeBytesToBytes(byte[], int, int, int) line: 929	
      	org.springframework.uaa.client.util.Base64.encodeBytes(byte[], int, int, int) line: 831	
      	org.springframework.uaa.client.util.Base64.encodeBytes(byte[], int) line: 760	
      	org.springframework.ide.eclipse.internal.uaa.client.QueueingUaaServiceExtension(org.springframework.uaa.client.internal.UaaServiceImpl).saveProductUse(org.springframework.uaa.client.protobuf.UaaClient$ProductUse$Builder) line: 550	
      	org.springframework.ide.eclipse.internal.uaa.client.QueueingUaaServiceExtension(org.springframework.uaa.client.internal.UaaServiceImpl).registerProductUsage(org.springframework.uaa.client.protobuf.UaaClient$Product, byte[], java.lang.String, boolean, boolean) line: 672	
      	org.springframework.ide.eclipse.internal.uaa.client.QueueingUaaServiceExtension(org.springframework.uaa.client.internal.UaaServiceImpl).registerInfrastructureProducts() line: 595	
      	org.springframework.ide.eclipse.internal.uaa.client.QueueingUaaServiceExtension(org.springframework.uaa.client.internal.UaaServiceImpl).rebuildPersistedDetails(boolean) line: 309	
      	org.springframework.ide.eclipse.internal.uaa.client.QueueingUaaServiceExtension(org.springframework.uaa.client.internal.UaaServiceImpl).getFeatureUseData(org.springframework.uaa.client.protobuf.UaaClient$Product, org.springframework.uaa.client.protobuf.UaaClient$FeatureUse) line: 193	
      	org.springframework.ide.eclipse.internal.uaa.client.QueueingUaaServiceExtension.getFeatureUseData(org.springframework.uaa.client.protobuf.UaaClient$Product, org.springframework.uaa.client.protobuf.UaaClient$FeatureUse) line: 95	
      	org.springframework.ide.eclipse.internal.uaa.UaaManager$ExtensionProductDescriptor(org.springframework.ide.eclipse.internal.uaa.UaaManager$ProductDescriptor).registerFeature(java.lang.String, java.util.Map<java.lang.String,java.lang.String>) line: 901	
      	org.springframework.ide.eclipse.internal.uaa.UaaManager$ExtensionProductDescriptor(org.springframework.ide.eclipse.internal.uaa.UaaManager$ProductDescriptor).registerFeatureUseIfMatch(java.lang.String, java.util.Map<java.lang.String,java.lang.String>) line: 822	
      	org.springframework.ide.eclipse.internal.uaa.UaaManager$2.run() line: 187	
      	java.util.concurrent.ThreadPoolExecutor$Worker.runTask(java.lang.Runnable) line: 886	
      	java.util.concurrent.ThreadPoolExecutor$Worker.run() line: 908	
      	java.lang.Thread.run() line: 662	
      

        Activity

        Kris De Volder (c) made changes -
        Field Original Value New Value
        Description I raised this bug as 'trivial' because the exceptions don't get logged or otherwise visible to users. However, they are mighty annoying when debugging anything in STS.

        I like to have a NPE triggered breakpoint, because, usually, NPEs are bugs that should be fixed, and browsing around their execution context is mighty useful. But since the introduction of UAA it has become very annoying that my NPE breakpoint is constantly being hammered by a UAA thread.

        Stacktrace:
        Daemon Thread [Reporting Thread-1 (Spring UAA/1.0.2)] (Suspended (exception NullPointerException))
        Base64$OutputStream(FilterOutputStream).flush() line: 123 [local variables unavailable]
        Base64$OutputStream(FilterOutputStream).close() line: 140
        Base64$OutputStream.close() line: 2027
        Base64.encodeBytesToBytes(byte[], int, int, int) line: 929
        Base64.encodeBytes(byte[], int, int, int) line: 831
        Base64.encodeBytes(byte[], int) line: 760
        QueueingUaaServiceExtension(UaaServiceImpl).saveProductUse(UaaClient$ProductUse$Builder) line: 550
        QueueingUaaServiceExtension(UaaServiceImpl).registerProductUsage(UaaClient$Product, byte[], String, boolean, boolean) line: 672
        QueueingUaaServiceExtension(UaaServiceImpl).registerInfrastructureProducts() line: 595
        QueueingUaaServiceExtension(UaaServiceImpl).rebuildPersistedDetails(boolean) line: 309
        QueueingUaaServiceExtension(UaaServiceImpl).getFeatureUseData(UaaClient$Product, UaaClient$FeatureUse) line: 193
        QueueingUaaServiceExtension.getFeatureUseData(UaaClient$Product, UaaClient$FeatureUse) line: 95
        UaaManager$ExtensionProductDescriptor(UaaManager$ProductDescriptor).registerFeature(String, Map<String,String>) line: 901
        UaaManager$ExtensionProductDescriptor(UaaManager$ProductDescriptor).registerFeatureUseIfMatch(String, Map<String,String>) line: 822
        UaaManager$2.run() line: 187
        ThreadPoolExecutor$Worker.runTask(Runnable) line: 886
        ThreadPoolExecutor$Worker.run() line: 908
        Thread.run() line: 662
        I raised this bug as 'trivial' because the exceptions don't get logged or otherwise visible to users. However, they are mighty annoying when debugging anything in STS.

        I like to have a NPE triggered breakpoint, because, usually, NPEs are bugs that should be fixed, and browsing around their execution context is mighty useful. But since the introduction of UAA it has become very annoying that my NPE breakpoint is constantly being hammered by a UAA thread.

        Stacktrace:
        {noformat}
        Daemon Thread [Reporting Thread-1 (Spring UAA/1.0.2)] (Suspended (exception java.lang.NullPointerException))
        org.springframework.uaa.client.util.Base64$OutputStream(java.io.FilterOutputStream).flush() line: 123 [local variables unavailable]
        org.springframework.uaa.client.util.Base64$OutputStream(java.io.FilterOutputStream).close() line: 140
        org.springframework.uaa.client.util.Base64$OutputStream.close() line: 2027
        org.springframework.uaa.client.util.Base64.encodeBytesToBytes(byte[], int, int, int) line: 929
        org.springframework.uaa.client.util.Base64.encodeBytes(byte[], int, int, int) line: 831
        org.springframework.uaa.client.util.Base64.encodeBytes(byte[], int) line: 760
        org.springframework.ide.eclipse.internal.uaa.client.QueueingUaaServiceExtension(org.springframework.uaa.client.internal.UaaServiceImpl).saveProductUse(org.springframework.uaa.client.protobuf.UaaClient$ProductUse$Builder) line: 550
        org.springframework.ide.eclipse.internal.uaa.client.QueueingUaaServiceExtension(org.springframework.uaa.client.internal.UaaServiceImpl).registerProductUsage(org.springframework.uaa.client.protobuf.UaaClient$Product, byte[], java.lang.String, boolean, boolean) line: 672
        org.springframework.ide.eclipse.internal.uaa.client.QueueingUaaServiceExtension(org.springframework.uaa.client.internal.UaaServiceImpl).registerInfrastructureProducts() line: 595
        org.springframework.ide.eclipse.internal.uaa.client.QueueingUaaServiceExtension(org.springframework.uaa.client.internal.UaaServiceImpl).rebuildPersistedDetails(boolean) line: 309
        org.springframework.ide.eclipse.internal.uaa.client.QueueingUaaServiceExtension(org.springframework.uaa.client.internal.UaaServiceImpl).getFeatureUseData(org.springframework.uaa.client.protobuf.UaaClient$Product, org.springframework.uaa.client.protobuf.UaaClient$FeatureUse) line: 193
        org.springframework.ide.eclipse.internal.uaa.client.QueueingUaaServiceExtension.getFeatureUseData(org.springframework.uaa.client.protobuf.UaaClient$Product, org.springframework.uaa.client.protobuf.UaaClient$FeatureUse) line: 95
        org.springframework.ide.eclipse.internal.uaa.UaaManager$ExtensionProductDescriptor(org.springframework.ide.eclipse.internal.uaa.UaaManager$ProductDescriptor).registerFeature(java.lang.String, java.util.Map<java.lang.String,java.lang.String>) line: 901
        org.springframework.ide.eclipse.internal.uaa.UaaManager$ExtensionProductDescriptor(org.springframework.ide.eclipse.internal.uaa.UaaManager$ProductDescriptor).registerFeatureUseIfMatch(java.lang.String, java.util.Map<java.lang.String,java.lang.String>) line: 822
        org.springframework.ide.eclipse.internal.uaa.UaaManager$2.run() line: 187
        java.util.concurrent.ThreadPoolExecutor$Worker.runTask(java.lang.Runnable) line: 886
        java.util.concurrent.ThreadPoolExecutor$Worker.run() line: 908
        java.lang.Thread.run() line: 662
        {noformat}
        Hide
        Tomasz Zarna added a comment -

        Kris, have you tried disabling UAA in your runtime STS instance? Also, do you think it's a bug in STS or is it more an issue with UAA client (org.springframework.uaa.client) itself?

        Show
        Tomasz Zarna added a comment - Kris, have you tried disabling UAA in your runtime STS instance? Also, do you think it's a bug in STS or is it more an issue with UAA client (org.springframework.uaa.client) itself?
        Hide
        Kris De Volder (c) added a comment -

        1) Yes UAA is disabled.

        2) Not sure, but from the stacktrace I'd say it is the uaa client trying to close something that's not actually there.

        Show
        Kris De Volder (c) added a comment - 1) Yes UAA is disabled. 2) Not sure, but from the stacktrace I'd say it is the uaa client trying to close something that's not actually there.
        Hide
        Tomasz Zarna added a comment - - edited

        It's a bug in UAA client, below is snippet from org.springframework.uaa.client.util.Base64:

                    try {
                        // GZip -> Base64 -> ByteArray
                        baos = new java.io.ByteArrayOutputStream();
                        b64os = new Base64.OutputStream( baos, ENCODE | options );
                        gzos  = new java.util.zip.GZIPOutputStream( b64os );
        
                        gzos.write( source, off, len );
                        gzos.close();
                    }   // end try
                    catch( java.io.IOException e ) {
                        // Catch it and then throw it immediately so that
                        // the finally{} block is called for cleanup.
                        throw e;
                    }   // end catch
                    finally {
                        try{ gzos.close();  } catch( Exception e ){}
                        try{ b64os.close(); } catch( Exception e ){}
                        try{ baos.close();  } catch( Exception e ){}
                    }   // end finally
        

        As you can see gzos is a wrapper around b64os, which in turn wraps baos. The thing is that when gzos.close() is called for the first time (last line in the try clause) it nulls b64os's out field. Next, in the finally block we close each stream. gzos is safe as it checks if it's already closed before proceeding, mind the closed flag:

            public void close() throws IOException {
                if (!closed) {
                    finish();
                    if (usesDefaultDeflater)
                        def.end();
                    out.close();
                    closed = true;
                }
            }
        

        b64os fails as it calls super.close() (java.io.FilterOutputStream.close()) which tries to flush the stream first, but the stream is already null. Bang! You have your NPE.

        Show
        Tomasz Zarna added a comment - - edited It's a bug in UAA client, below is snippet from org.springframework.uaa.client.util.Base64 : try { // GZip -> Base64 -> ByteArray baos = new java.io.ByteArrayOutputStream(); b64os = new Base64.OutputStream( baos, ENCODE | options ); gzos = new java.util.zip.GZIPOutputStream( b64os ); gzos.write( source, off, len ); gzos.close(); } // end try catch ( java.io.IOException e ) { // Catch it and then throw it immediately so that // the finally {} block is called for cleanup. throw e; } // end catch finally { try { gzos.close(); } catch ( Exception e ){} try { b64os.close(); } catch ( Exception e ){} try { baos.close(); } catch ( Exception e ){} } // end finally As you can see gzos is a wrapper around b64os , which in turn wraps baos . The thing is that when gzos.close() is called for the first time (last line in the try clause) it nulls b64os 's out field. Next, in the finally block we close each stream. gzos is safe as it checks if it's already closed before proceeding, mind the closed flag: public void close() throws IOException { if (!closed) { finish(); if (usesDefaultDeflater) def.end(); out.close(); closed = true ; } } b64os fails as it calls super.close() ( java.io.FilterOutputStream.close() ) which tries to flush the stream first, but the stream is already null . Bang! You have your NPE.
        Hide
        Christian Dupuis added a comment -

        I fixed this bug in the UAA client lib and sent the jar to Martin for inclusion with STS.

        Christian

        Show
        Christian Dupuis added a comment - I fixed this bug in the UAA client lib and sent the jar to Martin for inclusion with STS. Christian
        Hide
        Christian Dupuis added a comment -

        Over to you Martin for inclusion in STS/Spring IDE.

        Show
        Christian Dupuis added a comment - Over to you Martin for inclusion in STS/Spring IDE.
        Christian Dupuis made changes -
        Assignee Martin Lippert [ mlippert ]
        Hide
        Martin Lippert (c) added a comment -

        Awesome, thanks!!! Can you send me the source bundle as well?

        Show
        Martin Lippert (c) added a comment - Awesome, thanks!!! Can you send me the source bundle as well?
        Hide
        Martin Lippert (c) added a comment -

        Updated the UAA client lib to the new 1.0.3 release version.

        Show
        Martin Lippert (c) added a comment - Updated the UAA client lib to the new 1.0.3 release version.
        Martin Lippert (c) made changes -
        Fix Version/s 3.2.0.M2 [ 12884 ]
        Resolution Fixed [ 8 ]
        Status Open [ 1 ] Resolved [ 5 ]
        Trevor Marshall (c) made changes -
        Workflow jira [ 35174 ] jira with Pivotal Tracker [ 67200 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        482d 4h 22m 1 Martin Lippert (c) 13/Dec/12 2:20 PM

          People

          • Assignee:
            Martin Lippert (c)
            Reporter:
            Kris De Volder (c)
          • Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              First Response Date: