Bug 33264 - Alpha AU server XML files truncated
Alpha AU server XML files truncated
Status: RESOLVED FIXED
Product: www
Classification: Unclassified
Component: Builds & Repositories
3.x
All All
: P1 (vote)
: 3.x
Assigned To: rbalada
nbbuild-issues@ide
:
Depends on:
Blocks: 33098
  Show dependency treegraph
 
Reported: 2003-04-27 08:37 UTC by _ mihmax
Modified: 2003-05-05 19:29 UTC (History)
0 users

See Also:
Issue Type: DEFECT
:


Attachments
Shortened ide.log (2.49 KB, text/plain)
2003-04-27 08:40 UTC, _ mihmax
Details
Patch for nbbuild/antsrc/org/netbeans/nbbuild/MakeUpdateDesc.java to flush streams (1023 bytes, patch)
2003-04-28 10:23 UTC, rbalada
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description _ mihmax 2003-04-27 08:37:39 UTC
Testing with NB 3.5 post-beta (clean English build
from trunk), clean userdir.

Tryed to connect to stable & beta AU servers - OK.
Trying to connect to alpha AU server - Error.

Shortened ide.log attached
Comment 1 _ mihmax 2003-04-27 08:40:04 UTC
Created attachment 10171 [details]
Shortened ide.log
Comment 2 _ mihmax 2003-04-27 08:40:48 UTC

*** This issue has been marked as a duplicate of 33097 ***
Comment 3 Jesse Glick 2003-04-27 17:23:14 UTC
Not a duplicate.
Comment 4 Jesse Glick 2003-04-27 17:29:03 UTC
Recently the alpha AU server files have been truncated. dev_1.6_.xml
is empty. 35_1.6_.xml ends suddenly halfway through. Guilty logs:

[35_1.6_.xml]
revision 1.10
date: 2003/04/26 03:06:12;  author: rbalada;  state: Exp;  lines:
+1041 -7393
Automatically updated during NetBeans release35 200304252350 build

[dev_1.6_.xml]
revision 1.8
date: 2003/04/26 04:10:47;  author: rbalada;  state: Exp;  lines: +0 -8478
Automatically updated during NetBeans dev 200304260100 build

Once again, I would suggest that issue #31961 be implemented - it
should be rather easy - as that would cause the build to signal an
immediate error in case bogus or ill-formed update server XML files
are being created, rather than waiting for someone to discover the
problem manually. Or for the short term (3.5), even without changes to
the task, it should be simple to run <validatexml> on the generated files.
Comment 5 rbalada 2003-04-28 09:22:43 UTC
This is my bug. I'm testing new infrastructure and it looks like
conflict between the infrastructures.

The very first investigation discovered, that 35_1.6_.xml file is
90112 bytes long, what is (64 + 24) * 1024. Maybe some
buffer/filestream is not properly flushed before close.
Comment 6 rbalada 2003-04-28 10:20:25 UTC
Related fix done in trunk.

nbcvs ci -m "Issue 33264. Added OutputStream and PrintWriter flush ()
right before their close()"
antsrc/org/netbeans/nbbuild/MakeUpdateDesc.java
Checking in antsrc/org/netbeans/nbbuild/MakeUpdateDesc.java;
/cvs/nbbuild/antsrc/org/netbeans/nbbuild/MakeUpdateDesc.java,v  <-- 
MakeUpdateDesc.java
new revision: 1.15; previous revision: 1.14
done
Processing log script arguments...
Mailing the commit message to cvs@nbbuild.netbeans.org (from
rbalada@netbeans.org)
Comment 7 rbalada 2003-04-28 10:23:20 UTC
Created attachment 10174 [details]
Patch for nbbuild/antsrc/org/netbeans/nbbuild/MakeUpdateDesc.java to flush streams
Comment 8 Jesse Glick 2003-04-28 13:49:34 UTC
pw.flush() is probably useless. Writer's generally are documented that
close() implies a flush() first, and in fact PW.close calls here
OutputStreamWriter.close, which ultimately calls OS.close, after
writing all remaining converted characters; and FileOutputStream.flush
according to JDK 1.4 sources does nothing (no buffering).

So calling os.flush is probably useless as well. The Javadoc for
OutputStream.close does not explicitly state that there is an implied
flush first (as Writer does), but I think that is the intent - e.g.
FilteredOutputStream's close (used also by BufferedOutputStream, which
*does* implement flush) does an automatic flush before closing.

Probably the calls to os.close() are gratuitous as well - just calling
pw.close() should suffice. Calling os.close() *afterwards* should be
harmless however.

So I am not sure the attached patch will do anything at all - the code
may have been correct without it. Were you able to reproduce the
creation of the truncated files and confirm that the patched
<makeupdatedesc> works correctly? If not, there may be some other problem.
Comment 9 Jesse Glick 2003-05-02 16:01:59 UTC
Currently looks like the 3.5 version is OK but the dev version is
still broken (empty). What is going on? Progress?
Comment 10 rbalada 2003-05-05 10:35:54 UTC
I'm sorry, I was on vacations last five days. Looking into that right now.
Comment 11 rbalada 2003-05-05 18:09:02 UTC
Fixed for trunk builds. The trunk builds are run on another build
infrastructure which was changed a little bit from the one used for
release35 build.

Results:
1) L10N modules have been put into separate module groups (folders)
   by language (no more "garbage" in the root)
2) dev_1.6_.xml is actually 435737 bytes long

I was able to successfully work with dev/release35 alpha update
centres on J2SDK 1.4.1, from NetBeans dev build 200305050100 and
release35 2003292350 (RC1).

Please verify.
Comment 12 Jesse Glick 2003-05-05 19:29:43 UTC
Dev server seems OK. Did not try the r35 server.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo