[jcifs] Possible jCIFS<->JDK1.4.2 problem

[barry.roberts at xactsites.com]

Duh, I deleted all the bad files yesterday.  I can tell you that the plain xml files had things like this:

valu"XT_WHATEVER"

instead of 

value="XT_WHATEVER"

And generally the corruption in the xml file seemed to only happen in one spot and was the same in every xml file for a particular occurence.  Ok, what I'm trying to say is, once the app server went bad, it wrote every xml file bad, but in exactly the same way.  The next time it went bad it might be different corruption, but every xml file for that occurance would have the same corruption.

The other thing I saw (in a different run) was a whole bunch of (what emacs showed as) ^@ inserted.

The .zip files got CRC errors, and the files extracted were usually too short and garbage toward the end.

My Jmeter script simulates one user per thread.  My application should never have more than one thread accessing the file.  But that would be a good test.  I'll reconfigure to 1.4.2 and try it again soon.

I usually would only have to have 100-200 login/test/logout cycles with 1.4.2 to get the app server into the state where all the files it wrote were corrupt.  I did 3,000 cycles with 1.4.0_01 with no corruption.

Again, I don't know if this has anything to do with jCIFS.  It might be just 1.4.2.  Since I have a deadline and a workaround it will probably be several days before I can try anything.   I was just hoping all the io changes with 1.4.2 would ring a bell with somebody and there would be an easy answer.

Thanks,
Barry Roberts

-----Original Message-----
From:	Allen, Michael B (RSCH) [mailto:Michael_B_Allen at ml.com]
Sent:	Thu 8/14/2003 10:44 PM
To:	Barry Roberts; jcifs at lists.samba.org
Cc:	
Subject:	RE: [jcifs] Possible jCIFS<->JDK1.4.2 problem

I am not aware of any bad interaction of Java 1.4.2 with jCIFS. As far as I know jCIFS is
extreemly stable right now.

How long does it take you to get this corruption you're seeing? It would be very interesting if
you could get a packet capture of this happening.

Keep in mind that it is perfectly legitimate to open and write to the same file using multiple
threads. Unless the actions of these threads were closely coordinated this would certainly
lead to file corruption. You might try opening the file with a share access parameter of
FILE_SHARE_NONE. This will cause additional threads attempting to open a file for the
second time to get the "being accessed by another process" Exception.

If you can get a packet capture of the transition from no corruption to getting corruption I
might be able to determine if it's a problem with jCIFS or it's usage.

Also perhaps you can send me one of these corrupted files if it's not too big (e.g. 500K)?

Mike

> -----Original Message-----
> From:	barry.roberts at xactsites.com [SMTP:barry.roberts at xactsites.com]
> Sent:	Thursday, August 14, 2003 3:21 PM
> To:	jcifs at lists.samba.org
> Subject:	[jcifs] Possible jCIFS<->JDK1.4.2 problem
> 
> I'll admit I'm fishing here, but I'm having a problem with data corruption int a Tomcat app.  The app writes xml files and zip files to Samba server using jCIFS 0.7.11.  With JDK1.4.2 (Solaris 8) I
> can pretty consistently get corrupted files using a JMeter script with 6-10 threads.
> 
> Once it starts EVERY file written is corrupt until I re-start Tomcat.  Using JDK1.4.0, I can't re-produce the problem.
> 
> Are there any known problems with jCIFS and 1.4.2? 
> 



-------------- next part --------------
HTML attachment scrubbed and removed