Tomcat Writing to NFS

[Kevin Daly (kedaly)]

Hi,
 
I have a Web Application running on Tomcat that writes to NFS. the code
doing the write is:
String transcriptPath  = ...

StringBuffer buffer = 

BufferedWriter buffWriter = new BufferedWriter(new
FileWriter(transcriptPath));

buffWriter.write(buffer.toString());

buffWriter.close(); 

I am noticing that the longer the transcriptPath, the longer the file
write takes.

So for example creating the same 1.5K file takes

14 msecs to /nfshome/transcripts/tmp.xml  

19 msecs to /nfshome/transcripts/dialogid/tmp.xml

28 msecs to /nfshome/transcripts/sessionid/dialogid/tmp.xml

37 msecs to /nfshome/transcripts/sessionid/dialogid/day/tmp.xml

Reason I am posting to tomcat mailer is when I try the above from a
standalone Java App, I don't see this behaviour - all file writes take
about 14 msecs. I am running Tomcat Version 5.5.17 - Linux platform. Any
ideas why the above might be happening. 

- Kevin.

 

 

 

 

 

 

 

 

 

Kevin Daly
Software Engineer
IP Communications Business Unit

[EMAIL PROTECTED]
Phone :+35391384651



Block 10
Parkmore
Galway
Ireland
Ireland
www.cisco.com/



This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.   
 


 

RE: Tomcat Writing to NFS

[Kevin Daly (kedaly)]

Chris,

You were right in the pathlength has nothing to do with the problem.

When I put the code in the execute method of a servlet it works with the
expect response times.

The logic to create the file is running as a JMS client within Tomcat,
so basically there is a JMS MessageListener (on a separate thread)
within tomcat, making the I/O calls. You mentioned thread scheduling in
your response mail, how could thread scheduling affect a file write
(within Tomcat).

- Kevin



 

-Original Message-
From: Christopher Schultz [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, July 23, 2008 4:32 PM
To: Tomcat Users List
Subject: Re: Tomcat Writing to NFS

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Kevin,

Kevin Daly (kedaly) wrote:
| I have a Web Application running on Tomcat that writes to NFS.

Since the same JVM and same standard classes are being used to write to
the file, there should be no difference between your webapp and a
standalone Java app.

| So for example creating the same 1.5K file takes
|
| 14 msecs to /nfshome/transcripts/tmp.xml
|
| 19 msecs to /nfshome/transcripts/dialogid/tmp.xml
|
| 28 msecs to /nfshome/transcripts/sessionid/dialogid/tmp.xml
|
| 37 msecs to /nfshome/transcripts/sessionid/dialogid/day/tmp.xml

1.5k isn't very big. What if you try writing, say, 1MiB to the same
file. Does the entire file write scale linearly with path length, or
does this just look like noise in your timing data?

| Reason I am posting to tomcat mailer is when I try the above from a 
| standalone Java App, I don't see this behaviour - all file writes take

| about 14 msecs. I am running Tomcat Version 5.5.17 - Linux platform.
| Any ideas why the above might be happening.

Something else you might try is putting this code into a
ServletContextListener's contextInitialized() method -- one that will
run before any requests are handled. If the timing is similar to your
standalone Java app, then the problem is likely to be simple thread
scheduling and just a fluke that the timings appear to be related to the
path length.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiHTtsACgkQ9CaO5/Lv0PC3agCgi5Ka1pZA8dtawz5y0tOGv8fE
yNQAn0eOuFvlzLq6i7XATTeDh4SI0qlU
=JBdv
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe,
e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]