We Keep Coding

Which is a better way of serving files (for downloads) via Tomcat?

If a file is available to me a byte-array, which method would be better to enable the users to download the file?
A: Write the byte-array directly to response stream using Apache IOUtils. In this case, what will happen if the client stops the download and/or is disconnected? I want to keep the JVM's memory utilization to a minimum.
B: Write the byte-array to a file in some temporary location. Then get a FileInputSteam and write that to the response. In this case I would need to write code to manage the saved files on the disk and ensure periodic cleanup. The cleanup algorithm would need to ensure that it does not try to delete a file which is currently being served to the client.

This is a typical case where I think there's no one-size-fits-all:
What size are all your byte-arrays? (average, min/max)
Do you read them from disk anyways?
How long does a byte-array typically survive in memory once you have it
How often do you observe connection interruptions compared to successful and full downloads? On which file sizes?
Did you measure what happens when you just stream the bytes that you have anyways?
Do many users download the same content at the same time?
As you state you have the files in byte-arrays anyway, I'd not expect it to be prohibitive to serve exactly that byte-array. However, you'll need to be aware of the encoding of the byte-array (assuming that it's textual content, you'll need to send an encoding header with the response)
Without measuring what your situation is, there's hardly any reasonable recommendation for what you should do.
Edit, Replying to your comment: Whenever a request has been handled - e.g. when the file has been fully transmitted or when a "broken pipe" exception was thrown, I'd assume that your memory will be freed, unless you explicitly save it in the webapp's session or in any other datastructure that survives for longer. But you probably won't do that explicitly, right?
The sizes and nature of your downloads don't seem like you have really high demand on either I/O or memory. My advice: Don't worry. However, what you should do is: Measure. Check if memory consumption is indeed a problem. I doubt that it is. If it's not broken: Don't fix it.
You have the byte array anyway - you might as well use it to stream it to the client and only then forget about it. It doesn't look like this would take prohibitively long.

Java File IO performance?

I am using RandomAccesFile and writing data in chunks of 10MB at a time. Following is source. Here it is writing 10MB data in write call. It's taking ~700ms. Is there any way to improve this using file channel or some other means. FileSystem is NFS.
RandomAccessFile randomAccessFile = new RandomAccessFile(file, "rw");
OutputStream output = Channels.newOutputStream(randomAccessFile.getChannel());
randomAccessFile.seek(offset);
output.write(data, 0, dataLength);//10MB
output.flush();

NFS is, by definition, nonlocal so you're pretty much limited to your network bandwidth - being able to write 10MiB in 700ms is equal to having a bandwidth of 14,28 MiB/s - that'd be about 119Mbit so im guessing you were actually talking about MB/s in which case you still had 114Mbit .... well, i will assume you're on Gigabit-LAN.
In that case, you indeed would have some performance issues because gbit-LAN can do much more than that. There are several steps to find the root cause :
check if another application is running
check if your NIC has some faulty settings (reset to factory default if possible)
check if another application is able to transfer data faster than that
and finally (if the problem persists):
switch to Java NIO and see if it makes your situation better, here are a few examples : https://docs.oracle.com/javase/8/docs/technotes/guides/io/example/

Efficient bulk data transfer through I/O in Java

Is there an efficient mechanism in Java for transferring large amounts of data (~10 GB) back and forth between the disk and the network on a low-end machine? Low-end machine meaning a machine with much less than 10 GB of main memory. I want to efficiently transfer ~10GB portions of a file from one machine to another.

The most efficient means of I/O in Java is the NIO libraries. If your data is appropriate applying a compression stream filter would help as well.

I think you need to just copy an InputStream to an OutputStream. I'd start off with using somebody else's implementation commons-io:IOUtils.copyLarge(InputStream,OutputStream)
InputStream is = null;
OutputStream os = null;
try{
InputStream is = new FileInputStream("yourfile.bin");
OutputStream os = remoteSocket.getOutputStream();
IOUtils.copyLarge(is,os);
}finally{
IOUtils.closeQuietly(is);
IOUtils.closeQuietly(out);
}
This should be a good starter for ten. If you need higher through put, you can start my putting the read and write actions in separate threads, this in theory should ensure you completely saturate the slowest of the links, but it may be a better choice to use the FileChannel#transferTo method if using traditional stuff just isn't enough.

FYI, transferTo() only is only optimized between files, not file-socket, in java 6

traditional socket and file io would be fine.
in java 6, there is no direct file-socket io optimization as far as I know.
even if there is, as rumored in java 7, it won't improve performance very much. your code would be either disk bound or network bound. mem copy shouldn't matter.

Finding server internet bandwidth thru java for streaming

Following this thread.
Streaming large files in a java servlet.
Is it possible to find the total internet bandwidth available in current machine thru java?
what i am trying to do is while streaming large files thru servlet, based on the number of parallel request and the total band width i am trying to reduce the BUFFER_SIZE of the stream for each request. make sense?
Is there any pure java way? (without JNI)

Maybe you can time how long the app need to send one package (the buffer). And if that is larger than x milliseconds, then make your buffer smaller. You can use other values for the original bufferSize and if (stop - start > 700).
This is based on the thread you noticed:
ServletOutputStream out = response.getOutputStream();
InputStream in = [ code to get source input stream ];
String mimeType = [ code to get mimetype of data to be served ];
int bufferSize = 1024 * 4;
byte[] bytes = new byte[bufferSize];
int bytesRead;
response.setContentType(mimeType);
while ((bytesRead = in.read(bytes)) != -1) {
long start = System.currentTimeMillis();
out.write(bytes, 0, bytesRead);
long stop = System.currentTimeMillis();
if (stop - start > 700)
{
bufferSize /= 2;
bytes = new byte[bufferSize];
}
}
// do the following in a finally block:
in.close();
out.close();

The only way to find available bandwidth is to monitor / measure it. On windows you have access to Net.exe and can get the throughput on each NIC.

If you're serving the content through a servlet, then you could calculate how fast each servlet output stream is going. Collect that data for all streams for a user/session, and you could determine at least what the current bandwidth usage is.
A possible way to calculate the rate could be instead of writing the large files through the servlet output stream, write to a new FilterOutputStream that would keep track of your download rates.

The concept of "total internet bandwidth available in current machine" is really hard to define. However, tweaking the local buffer size will not affect how much data you can push through to an individual client.
The rate at which a given client can take data from your server will vary with the client, and with time. For any given connection, you might be limited by your local upstream connection to the Internet (e.g., server on DSL) or you might be limited somewhere in the core (unlikely) or the remote end (e.g., server in a data center, client on a dialup line). When you have many connections, each individual connection may have a different bottleneck. Measuring this available bandwidth is a hard problem; see for example this list of research and tools on the subject.
In general, TCP will handle using all the available bandwidth fairly for any given connection (though sometimes it may react to changes in available bandwidth slower than you like). If the client can't handle more data, the write call will block.
You should only need to tweak the buffersize in the linked question if you find that you are seeing low bandwidth and the cause of that is insufficient data buffered to write to the network. Another reason you might tweak the buffer size is if you have so many active connections that you are running low on memory.
In any case, the real answer may be to not buffer at all but instead put your static files on a separate server and use something like thttpd to serve them (using a system call like sendfile) instead of a servlet. This helps ensure that the bottleneck is not on your server, but somewhere out in the Internet, beyond your control.

EDIT: Re-reading this, it's a little muddled because it's late here. Basically, you shouldn't have to do this from scratch; use one of the existing highly scalable java servers, since they'll do it better and easier.
You're not going to like this, but it actually doesn't make sense, and here's why:
Total bandwidth is independent of the number of connections (though there is some small overhead), so messing with buffer sizes won't help much
Your chunks of data are being broken into variable-sized packets anyway. Your network card and protocol will deal with this better than your servlet can
Resizing buffers regularly is expensive -- far better to re-use constant buffers from a fixed-size pool and have all connections queue up for I/O rights
There are a billion and a half libraries that assist with this sort of server
Were this me, I would start looking at multiplexed I/O using NIO. You can almost certainly find a library to do this for you. The IBM article here may be a useful starting point.
I think the smart money gives you one network I/O thread, and one disk I/O thread, with multiplexing. Each connection requests a buffer from a pool, fills it with data (from a shared network or disk Stream or Channel), processes it, then returns the buffer to the pool for re-use. No re-sizing of buffers, just a bit of a wait for each chunk of data. If you want latency to stay short, then limit how many transfers can be active at a time, and queue up the others.

How to allocate the memory from OS instead of increasing the JVM’s heap size?

I need to detect whether the file I am attaching to an email is exceeding the server limit. I am not allowed to increase the JVM heap size to do this since it is going to affect the application performance.
If I don’t increase the JVM heap size, I will run into OutOfMemoryError directly.
I would like to know how do allocate the memory from OS instead of increasing the JVM’s heap size?
Thanks a lot!

Are you really trying to read the entire file to determine its size to check if it is less than some configured value (your question is not too easy to understand)? If so, why are you not using File#length() instead?

If you need to stream the file to the server in order to find out whether it's too big, you still don't need to read the whole file into memory.
Instead, read maybe 10-100k into memory. Fill the buffer, send it to the server. Repeat until the file is done or the server complains. Then you don't need enough memory for the whole file.

If you write your own stream handling code, you could create your own counter to track the number of bytes transmitted. I'd be surprised if there wasn't already some sort of Filter class that does this for you. Sun has a page about this. Search for 'CountReader'.

You could allocate the memory natively via native code and JNI. However that sounds a painful way to do this.
Instead can't you give the JVM suitable memory configurations (via -Xmx) ? If the document you're mailing is so big that you can't easily handle it, then I'm not sure email is the correct medium to transfer it, and you should instead host it and send a link to it, or perhaps FTP it.

If all the other solutions turn out to be unusable (and I would encourage you to find a better way than requiring the entire file to fit in memory!) you could consider using a direct ByteBuffer. It has the option of using mmap() or other system calls to map a file into your memory without actually reading / allocating space in the heap. You can do this by calling map() on a FileChannel -- API documentation. Note that this is potentially expensive and/or not supported on some platforms, so it should be considered suboptimal compared to any solution which does not require the entire file to be in memory.

Socket s = /* go get your socket to the server */
InputStream is = new FileInputStream("foo.txt");
OutputStream os = s.getOutputStream();
byte[] buf = new byte[4096];
for(int len=-1;(len=is.read(buf))!=-1;) os.write(buf,0,len);
os.close();
is.close();
Of course handle your Exceptions.

If you're not allowed to increase the heap size because of memory constaints, doing an "under the table" memory allocation would cause the same problems. It sounds like you're looking for a loophole in the rules. Like, "My doctor says to cut down on how much I eat at each meal, so I'm eating more between meals to make up for it."
The only way I know of to allocate memory without using the Java heap would be to write JNDI calls to malloc the memory with C. But then how would you use this memory? You'd have to write more JNDI calls to interact with it. I think you'd end up basically re-inventing Java.
If the goal here is to send a large file, just use buffered streams and read/write it one byte at a time. A buffered stream, as the name implies, will take care of buffering for you so you're not really hitting the hard drive one byte at a time. It will really read, I think the default is 8k at a time, and then pass these bytes to you as you ask for them. Likewise, on the write side it will save up a few kb and and send them all in chunks.
So all you should have to do is open a BufferedInputStream and a BufferedOutputStream. Then write a loop that reads one byte from the input stream and writes it to the output stream until you hit end-of-file.
Something like:
OutputStream os=... however you're getting your socket ...
BufferedInputStream bis=new BufferedInputStream(new FileInputStream(fileObject));
BufferedOutputStream bos=new BufferedOutputStream(os);
int b;
while ((b=bis.read())!=-1)
bos.write(b);
bis.close();
bos.close();
No need to make life complicated for yourself by re-inventing buffering.
while (