Non-blocking file selector?

Running W98/Labview 5.1.1, I have a DAQ application that collects data and
streams it to file. For this I would like to be able to change output
files without breaking the DAQ loop. For some reason, however the DAQ loop
occurence will time out the moment I open the file dialog, even though
the dialog runs in it's own while loop and even in it's own sub VI with
low priority. Any suggestions how I could get a non-blocking dialog box?
TIA,
Rudolf

Hi Rudolf,
take a look
http://zone.ni.com/devzone/devzoneweb.nsf/opendoc?openagent&75C636329327A87B862568690074800A&cat=8ABEC12D4C0AA4A3862567AC00583899
I hope it help you in many cases.
Mike
Rudolf Potucek wrote:
> Running W98/Labview 5.1.1, I have a DAQ application that collects data and
> streams it to file. For this I would like to be able to change output
> files without breaking the DAQ loop. For some reason, however the DAQ loop
> occurence will time out the moment I open the file dialog, even though
> the dialog runs in it's own while loop and even in it's own sub VI with
> low priority. Any suggestions how I could get a non-blocking dialog box?
>
> TIA,
>
> Rudolf

Similar Messages

Non-blocking file behaviour for Reader

Hi!
It will be really nice if Reader will not block files for writing. Assume someone is using TeX to create PDF and he need to
a) examine the results;
b) edit the source.
It becomes a nightmare with Reader. Compile TeX, open Reader, examine results, close Reader. And then from the beginning.
Auto reloading of a PDF file is also a nice feature!
So far I can see only one solution: one should use another viewer to get non-blocking behaviour.
Thanks!

OK, let us see. I use Windows XP Professional SP3, Reader version is 9.3.0. I made a simple test: openned a file in Reader, then openned this file in my favourite text editor and tried to change "%PDF-1.4" to "%PDF-1.3" and save. I received a "File sharing violation error". I can also try to do it in Ubuntu.
As for the open source viewers. That is what I am currently doing: I use additional viewer to view the files I create and I use Adobe Reader to view all other files. One can leave with such solution, but it is not the best.

Non-blocking file access?

1. Did I miss something: is there a way in java 1.5 (or even java 1.6) to read files and query file metadata (size, last modified, that kind of thing) in a non-blocking manner?
2. Is there a way to figure out where physical harddrive boundaries lie without resorting to tricks like running 'df' and parsing the output, which is rather un-portable? I obviously don't want to create a thread per file read (one aim is that the maximum number of threads is constant - even with a gazillion requests the amount of threads will never exceed a (low) constant.) but just 1 thread to perform all required reads would possibly end up wasting time if there are multiple harddrives and the CPU is idling anyway. I'd guess at this point that 1 thread per physical harddrive handling all file access is the best way to go, but how do I figure out those boundaries?
3. Is NIO2 (JSR 203) going to add features to work with files in a non-blocking way?
4. Is there a full-stack (templating, database access, writing web services, serving up the data) web server out there someplace that works entirely on a non-blocking methodology? I don't think so, but I might have missed something. JETTY tries something, but the servlet specs fundamentally do not work with non-blocking I/O, so it doesn't count.
background:
I'm writing a non-blocking webserver. KISS is the attitude - so far the basic system and any services (my take on the servlet spec, as the servlet spec doesn't play nice with NIO principles) on it all run inside a single thread, no thread pool.
So far it all works, and stress testing it with 1000 connections, 200 at the same time shows a process time of about half a millisecond per request, on a simple macbook, which is nice, because that beats apache even at serving up 404s.
So far I have only written very simple test apps that for example do calculations and the like, nothing that you'd actually do with web apps, like, say, serving (template-powered) data from files on a harddrive.
Because of the absolute requirement for each service NEVER to block while serving up bytes, manually working with files would be an unbelievable pain on the part of the web service developer. Hence I'm building templating and DB access into the system.
Unfortunately, I realized, reading NIO specs, that there doesn't seem to be any way to perform file operations in a non-blocking manner (not just reading them, but getting file size and last modified timestamps as well). I'll obviously have to use a lot of caching tactics, but before I can cache, I need to read files somehow.
The aim of this webserver is basically to survive massive spikes in traffic, be it from digg/slashdot, or from a DDOS attack, as best as possible, and where that isn't possible, to gracefully fall apart. That is, service as many requests as possible at a certain minimum bandwidth per request, prioritizing repeat visitors and site moderators, and deny the rest instantly, instead of just falling apart in shambles as happends in your usual LAMP or servlet design, not serving even 1 request right most of the time.
Thanks a lot for everyone's time!

ejp wrote:
BufferedInputStream will improve the performance by a factor of several thousand because it cuts down on system calls.Well, that might be true if you're reading individual bytes with a call to read(), or making many small read( buffer ) requests. But if you call read( buffer ) with a reasonably sized buffer (BufferedInputStream uses 8192 bytes as a default buffer size), then you're going to get performance equal to or possibly better than a BufferedInputStream.

FileInputStream.read() and non-blocking file i/o

According to the API, FileInputStream.read() is :
public native int read() throws IOException
Reads a byte of data from this input stream. This method blocks if no input is yet available.
Returns:
the next byte of data, or -1 if the end of the file is reached.In what instances does the read() blocks? Is there a danger that the call to read() would block forever?

thanks martian!
is the ff code right enough to prevent i/o blocking?
FileInputStream fis = new FileInputStream(src);
FileOutputStream fos = new FileOutputStream(sPersistorFolder+src.getName());
if(fis.available() > 0) {
    int c = -1;
    while((c=fis.read()) != -1) {
      fos.write(c);
fis.close();
fos.close();

Java.nio selector non-blocking IO question

Hi,
I am designing an interactive server where multiple clients can log on and communicate with the server. I designed a protocol that the client/server use to talk to each other. My server runs a Selector to monitor a ServerSocket, accepting connections and reading continuously from clients.
Now my question is, since read() on ServerChannel are non-blocking using selector, how can I be sure that my entire protocol message will be read each time selector wakes up? For example, a slow client sends me a 5kb message, in one write() command, can I be sure that I will be able to read the entire message in one non-blocking read() command as well? If not, then the design becomes much more complicated, as I have to pipe each client's input into a handler thread that performs blocking i/o to read a protocol message one at a time. If I do that, then I might as well not use select() at all.
I did some preliminary tests, and it seems that for my purpose (message of size <= 50kb), a read() command will always be able to read the entire message. But I can't find any documentation on this subject. My guess is that I cannot trust non-blocking I/O as well, which means it does not fit my purpose.
Any help will be much appreciated.
Thanks,
Frank

You can't be sure a read() will read in all the data from a client in one call.
For example, say your message from the client to the server is of the following format. <start>message here<end>, where <start> indicates the start of a message and <end> the end of the message. In one read() call you might get "<start>message he". Your server would recognize this is partially correct but it needs the rest of the message. The server would store this and on the second read() you might get "re<end>" for the complete message.
The purpose of non-blocking I/O is so you don't have to wait around for the second part of the message, you can process other client messages while the first client finishes sending their message. This way other clients aren't waiting around while you(the server) sit and wait for client 1 to finish sending it's data.
So basically there is no gaurantee you will get a whole message intact. Your protocol will have to deal with partial messages, recognize them, store the partial message in a buffer, and on subsequent reads get the rest of the message.
Nick

Are the experts wrong about non-blocking SocketChannels?

Everyone says to use the new SocketChannel and Selector for "highly scalable" server applications. So I ran a couple of tests using non-blocking (via Selector) and thread-per-connection SocketChannels.
The Selector version consumes 8x more cpu than the thread-per-connecton version!
Using JDK 1.4.1 FCS on Win2K, with 1000 socket connections each sending 1k bytes per second, the Selector version was consuming 40% cpu with 10 threads; the thread-per-connection version (using blocking SocketChannels) was only consuming about 5% cpu with 1009 threads.
So, are the experts wrong? Is there a performance problem when number of SocketChannels exceed a certain threshold?
For anyone interested, here's the source code:
Non-Blocking Server using Selector
import java.io.FileOutputStream;
import java.io.IOException;
import java.net.InetSocketAddress;
import java.net.ServerSocket;
import java.net.Socket;
import java.nio.ByteBuffer;
import java.nio.CharBuffer;
import java.nio.charset.Charset;
import java.nio.charset.CharsetDecoder;
import java.nio.charset.CharsetEncoder;
import java.nio.channels.FileChannel;
import java.nio.channels.SelectionKey;
import java.nio.channels.Selector;
import java.nio.channels.ServerSocketChannel;
import java.nio.channels.SocketChannel;
import java.util.Collections;
import java.util.Iterator;
import java.util.LinkedList;
import java.util.List;
import java.util.Set;
import java.util.logging.Level;
import java.util.logging.Logger;
public class Server4 implements Runnable
private static int port = 80;
public static void main(String args[]) throws Exception
Server4 server = new Server4();
Thread thread = new Thread(server);
thread.setDaemon(true);
thread.start();
thread.join();
public Server4() throws IOException
ServerSocketChannel server = ServerSocketChannel.open();
InetSocketAddress isa = new InetSocketAddress(port);
server.configureBlocking(false);
server.socket().bind(isa);
m_selector = Selector.open();
server.register(m_selector, SelectionKey.OP_ACCEPT);
Charset utf8 = Charset.forName("UTF-8");
m_decoder = utf8.newDecoder();
m_encoder = utf8.newEncoder();
public void run()
int count = 0;
try
ByteBuffer buffer = ByteBuffer.allocateDirect(2048);
//FileOutputStream fos = new FileOutputStream("server4.dat");
//FileChannel fc = fos.getChannel();
while (m_selector.select() > 0)
Set keys = m_selector.selectedKeys();
for (Iterator itr = keys.iterator(); itr.hasNext(); )
SelectionKey key = (SelectionKey) itr.next();
itr.remove();
if (key.isAcceptable())
System.out.println("accept: " + (++count));
ServerSocketChannel server
= (ServerSocketChannel) key.channel();
SocketChannel channel = server.accept();
channel.configureBlocking(false);
channel.register(m_selector, SelectionKey.OP_READ);
else
SocketChannel channel = null;
try
if (key.isReadable())
channel = (SocketChannel) key.channel();
int bytes = channel.read(buffer);
if (bytes <= 0) // Linux does not throw IOException
channel.close(); // will also cancel key
System.out.println("connection closed " + count);
else
buffer.flip();
//fc.write(buffer);
buffer.clear();
catch (IOException ioe) // connection closed by client
System.out.println("readable: " + ioe.getMessage());
sm_logger.log(Level.INFO, ioe.getMessage(), ioe);
Throwable cause = ioe.getCause();
if (cause != null)
System.out.println("cause: "
+ cause.getClass().getName()
+ ": " + cause.getMessage());
channel.close(); // will also cancel key
--count;
catch (IOException e)
System.out.println("run: " + e.getMessage());
sm_logger.log(Level.SEVERE, e.getMessage(), e);
catch (Exception e)
System.out.println("run: " + e.getMessage());
sm_logger.log(Level.SEVERE, e.getMessage(), e);
private Selector m_selector;
private CharsetDecoder m_decoder;
private CharsetEncoder m_encoder;
private static Logger sm_logger = Logger.getLogger("Server");
Thread-Per-Connection Server
import java.io.FileOutputStream;
import java.io.IOException;
import java.net.InetSocketAddress;
import java.net.ServerSocket;
import java.net.Socket;
import java.nio.ByteBuffer;
import java.nio.CharBuffer;
import java.nio.charset.Charset;
import java.nio.charset.CharsetDecoder;
import java.nio.charset.CharsetEncoder;
import java.nio.channels.FileChannel;
import java.nio.channels.SelectionKey;
import java.nio.channels.Selector;
import java.nio.channels.ServerSocketChannel;
import java.nio.channels.SocketChannel;
import java.util.Collections;
import java.util.Iterator;
import java.util.LinkedList;
import java.util.List;
import java.util.Set;
import java.util.logging.Level;
import java.util.logging.Logger;
public class MultiThreadServer implements Runnable
private static int port = 80;
public static void main(String[] args) throws Exception
ServerSocketChannel server = ServerSocketChannel.open();
InetSocketAddress isa = new InetSocketAddress(port);
server.socket().bind(isa);
int count = 0;
while (true)
SocketChannel channel = server.accept();
System.out.println("accept: " + (++count));
MultiThreadServer worker = new MultiThreadServer(channel);
Thread thread = new Thread(worker);
thread.setDaemon(true);
thread.start();
public MultiThreadServer(SocketChannel channel) throws IOException
m_channel = channel;
public void run()
ByteBuffer buffer = ByteBuffer.allocateDirect(2048);
int bytes = 0;
try
while ((bytes = m_channel.read(buffer)) > 0)
buffer.flip();
// process buffer
buffer.clear();
System.out.println("connection closed");
m_channel.close();
catch (IOException e)
System.out.println("run: " + e.getMessage());
sm_logger.log(Level.SEVERE, e.getMessage(), e);
catch (Exception e)
System.out.println("run: " + e.getMessage());
sm_logger.log(Level.SEVERE, e.getMessage(), e);
private SocketChannel m_channel;
private static Logger sm_logger = Logger.getLogger("MultiThreadServer");
Client
import java.io.*;
import java.net.*;
import java.nio.*;
import java.nio.channels.*;
import java.nio.charset.*;
import java.util.Arrays;
import java.util.Iterator;
import java.util.Set;
import java.util.logging.Level;
import java.util.logging.Logger;
public class MultiClient implements Runnable
public static void main(String[] args) throws Exception
if (args.length < 1)
System.out.println("usage: java MultiClient number [host]");
System.exit(1);
int number = Integer.parseInt(args[0]);
String host = (args.length == 2) ? args[1] : "localhost" ;
Thread[] threads = new Thread [number];
InetSocketAddress address = new InetSocketAddress(host, 80);
for (int i = 0; i < number; i++)
MultiClient client = new MultiClient(address, Integer.toString(i));
threads[i] = new Thread(client);
threads.setDaemon(true);
for (int i = 0; i < number; i++)
threads[i].start();
for (int i = 0; i < number; i++)
threads[i].join();
public MultiClient(InetSocketAddress address, String id)
throws InterruptedException, IOException
m_id = id;
Charset charset = Charset.forName("UTF-8");
m_decoder = charset.newDecoder();
m_encoder = charset.newEncoder();
m_channel = SocketChannel.open();
m_channel.connect(address);
if (id.equals("0"))
Socket socket = m_channel.socket();
System.out.println("SO_SNDBUF=" + socket.getSendBufferSize()
+ ",SO_TIMEOUT=" + socket.getSoTimeout()
+ ",SO_KEEPALIVE=" + socket.getKeepAlive());
byte[] buf = new byte [1024]; // bufsize = 1K
Arrays.fill(buf, (byte) m_id.charAt(0));
m_buffer = ByteBuffer.allocateDirect(1024);
m_buffer.put(buf);
m_buffer.flip();
Thread.currentThread().sleep(50L);
public void run()
System.out.print(m_id);
try
while (true)
m_channel.write(m_buffer);
m_buffer.rewind();
Thread.currentThread().sleep(1000L);
catch (IOException ioe)
ioe.printStackTrace();
catch (InterruptedException ie)
System.err.println(ie.toString());
private String m_id;
private CharsetEncoder m_encoder;
private CharsetDecoder m_decoder;
private SocketChannel m_channel;
private ByteBuffer m_buffer;

{This is a crosspost. I posted this earlier today at http://forum.java.sun.com/thread.jsp?forum=4&thread=319822 before I stumbled on a search phrase that located this older thread.
All follow-ups should be on haam's thread instead of mine. The important point below is that NIO select() behavior (vs. threading IO) is [b]worse under Windows but better under Solaris. This seems fundamentally broken. }
My company sells a scalable multi-user server platform built on Java 2.
It runs under Java 1.3.1 (and 1.4.0 windows) using multiple threads for communications, and 1.4.x (unix) using NIO. We were happy to see that 1.4.1 (windows) fixed the problem drastically limiting the number of selectable ports. :-)
The bad news is that whatever the VM is doing "under the sheets" to fix the problem seems to perform very poorly in terms of CPU:
I compared connecting 500 simulated users to a Solaris 8 and a Win2K box. These users were in 25 chat rooms, each sending a chat message every 30 seconds. (There was plenty of memory on each machine. There was no swapping in either case. Clock/CPU type doesn't matter as this isn't about comparing a machine to a machine, but different load characteristics -within- a machine environment.)
 Threaded IO NIO/Select
Solaris 1.4.1 20-30% 15- 20%
Windows 1.4.1 40-50% 95-100%Numbers are % of CPU as reported by 'top' and the Win2K task manager.
Both platforms showed the expected significant improvement in memory usage when moving from standard threaded IO to NIO.
Strangely, the Windows implementation of the VM showed a significant (and unexpected) degradation of NIO performance vs. the threaded model, whereas the Solaris VM behaved as expected: NIO outperformed threaded IO.
Our best guess is that the Selector fix in 1.4.1 is implemented in some cpu-intensive way; perhaps polling. As a result, we still can't use NIO for Wintel boxes running our server. :-( To us, Selector
is still broken.
Has anyone else seen results like this? Have we missed some configuration parameter that will fix this?
I thought the big upside of using select() was supposed to be performance. :-P
F. Randall Farmer
State Software, Inc.
http://www.statesoftware.com

Multiple non-blocking selectors in threads

About networking in java and sockets i read alot. I know about the 2 implementations witk thread per client and non-blocking IO (usage of select()). I ran a few tests of my own and i could't decide. So I wrote a server that uses them both. The Ideea is to have no more than 100 clients per each selector and each selector runs in a thread. so when you have 4000 clients you actualy have 40 threads running each 100 clients:D
However I'm stuck. I wrote this piece of code that has 2 objects one work thread with his own selector and a main thread with an accepting selector. The problem is that when I connect to it via telnet it only works when there is an even number of clients:(( when client nr 1 connects it blocks on channel.register(workSelector,SelectionKey.OP_READ);when client 2 gets connected it works:((
HELP!!!
here is the
import java.nio.*;
import java.nio.channels.*;
import java.nio.charset.*;
import java.io.*;
import java.net.*;
import java.util.*;
import java.util.concurrent.ConcurrentHashMap;
//work thread with own selector
class workThread implements Runnable{
 public int userCount=0;
 public int ID=0;
 private Charset charset;
 private CharsetEncoder encoder;
 private CharsetDecoder decoder;
 private ByteBuffer buffer;
 private ConcurrentHashMap userMap;
 public Selector workSelector = null;
 public void addClient(SelectableChannel channel, int ops) throws IOException{
 if (channel == null) return;
 //channel.configureBlocking(false);
 System.out.println("Channel was added in workSelector : "+channel);
 channel.register(workSelector,SelectionKey.OP_READ);
 System.out.println("Client was added in work selector : " + ID);
 userCount++;
 System.out.println("Client nr : "+userCount);
 public boolean find(String name){
 return true;
 public workThread() throws IOException{
 charset = Charset.forName("ISO-8859-1");
 encoder = charset.newEncoder();
 decoder = charset.newDecoder();
 buffer = ByteBuffer.allocate(256);
// System.out.println("S-a creat selectorul");
 workSelector = Selector.open();
 System.out.println("Selector open ");
 private void doRead(SelectionKey key) throws IOException{
 SocketChannel clientChannel = (SocketChannel)key.channel();
 buffer.clear();
 System.out.println("Speaking to client");
 if(clientChannel.read(buffer) == -1){
 key.cancel();
 clientChannel.close();
 }else{
 buffer.flip();
 String message = decoder.decode(buffer).toString();
 System.out.println(message);
 if(message.trim().equals(".")){
 clientChannel.write(encoder.encode(CharBuffer.wrap("BYE")));
 key.cancel();
 clientChannel.close();
 }else{
 buffer.flip();
 clientChannel.write(buffer);
 private void doWrite(SelectionKey key){
 System.out.println("WRITE!!!");
 public void run(){
 while(true){
 try{
 if(workSelector.select() > 0){
 Set keys1 = workSelector.selectedKeys();
 for(Iterator itr = keys1.iterator();itr.hasNext();){
 SelectionKey key = (SelectionKey)itr.next();
 itr.remove();
 if(key.isReadable()) {doRead(key);}
 // if(key.isWritable()) {doWrite(key);}
 }catch(IOException e){
 System.out.println("Error in workthread "+ID+" "+e);
//main thread
public class msselect implements Runnable{
 private ServerSocketChannel server;
 private ServerSocket sock;
 private Selector acceptSelector;
 private workThread wk;
 public static void main(String args[]){
 try{
 msselect x = new msselect("80.97.89.73",6500,5);
 new Thread(x).start();
 }catch(IOException ex){
 System.out.println("Probleme"+ex);
 msselect(String host, int port, int numT) throws IOException{
 server = ServerSocketChannel.open();
 sock = server.socket();
 sock.bind(new InetSocketAddress(port));
 server.configureBlocking(false);
 acceptSelector = Selector.open();
 server.register(acceptSelector, SelectionKey.OP_ACCEPT);
/* for(int i=0;i<numT;i++){
 wk[i] = new workThread();
 wk.ID = i;
 new Thread(wk[i]).start();
 wk = new workThread();
 wk.ID = 1;
 server.register(wk.workSelector, SelectionKey.OP_ACCEPT);
 new Thread(wk).start();
 public void run(){
 while(true){
 try{
 acceptSelector.select();
 Set keys = acceptSelector.selectedKeys();
 for(Iterator itr = keys.iterator();itr.hasNext();){
 SelectionKey key = (SelectionKey)itr.next();
 itr.remove();
 if(key.isAcceptable()){
 SocketChannel client = null;
 client = server.accept();
 client.configureBlocking(false);
 System.out.println("Accepted "+client);
 wk.addClient(client,SelectionKey.OP_READ);
 }catch(IOException e){
 System.out.println("Main Thread error"+e);

I compiled and ran your code.
The call channel.register(...) should block while selector is blocked in workSelector.select(). The fact that the registration succeeds is that you registered the server channel with both the work selector and the acceptor selector. The work selector is returning from select() because of a new client connection is accepted and is a matter of thread scheduling that the client.register() succeeeds (but only sometimes).
Possible solution:
- don't register the server channel with the work selector;
- probably call workSelector.wakeup() to make the client channel registration possible.

What is non blocking IO?

I have heard that 1.4 supports non blocking IO, and that this is greath for servers. What is it, how does it work and why is it so good?

I could be wrong - but if they have not yet done so
a good optimization would be to rearrange the
select list - such that the sockets that have
an event appears at the top of the list.
This way - when the select completes - it tells
you that there are - say 2 - active events - you
would then just read the first two channels on
the select list.From the API javadoc:
The selected-key set is the set of keys such that each key's channel was detected to be ready for at least one of the operations identified in the key's interest set during a prior selection operation. This set is returned by the selectedKeys method. The selected-key set is always a subset of the key set.
ie- select and iterate. No polling involved.
They just completed the java EventListener model
for the GUI. It would have been simple and clean
to implement a similar model for io. You have
the io channel - you would just attach an event
listener to it much like you would do for a control.
When an io finishes on a channel, you would be
told immediately the channel that the io completed
and what event occured - read, write etc.
Now you could have a million sockets
( if ever unix could support that many file
discriptors )
and you when an io completes no need to poll
a bunch of idle sockets.Question: What thread would this run in?
* Does it run in the network layer? How many concurrent event notifications can the network layer at any one time? Is it likely it would be an EventQueue-esque single thread?
* Does it spawn a new thread for each event? This would certainly yield worse results than spawning a new thread for each socket, since each socket would generate a vast number of events.
* Does it have a thread pool to deal with the events? Then you would be using exactly the same model as java.nio's Selector.
FYI: The windows NT asynchronous IO model uses
an event model - IO completion ports. It is far more
modern, advanced and efficient that the select / poll
model used in unix.Do you have any links for more information?
Sun could have incorporated the most modern / best
features into java and make it competitive. Instead
they went for least common denominator.Sun's nio package was (somewhat) based on a community project, and was integrated into Java on JSR-051
http://www.cs.berkeley.edu/~mdw/proj/java-nbio/
If there were such an initiative for NT-style asynchronous IO, and this was proven to be more efficient, then I imagine it will be much more likely to be integrated with the language.
If it isn't, you could still use the community-based implementation, as you could with the nbio package before 1.4 was released.
Just because Sun doesn't do something, doesn't mean you can't!

Writing Java Non-Blocking Socket Server for Winsock Client

Hi.
Im a newbie to Sockets. I need to write a Non-Blocking Socket server (using java.nio) that accepts connection and reads the data sent by WinSock clients, and write them to another winsock client. Its quite intriguing. How do I do that? Is it possible?
Thanks in advance
Arun

Well, in traditional 4.2 BSD sockets, you'd fill up a set of filedescriptors of connections (an array of bits usually), and push that in the read parameter of a call to 'select'. Select then blocks until at least one of the file descriptors become available for reading, or writing if you also made an fd_set full of file descriptors (but you can usually write freely to a socket, so there is not much use for that). Then you start finding out which of these file descriptors have actually become available for reading, and you pass those to a bunch of worker-threads. The advantage is that your set of worker-threads can be quite small, while your number of connections can still be quite large (unless, of course, everyone of your clients start talking all at once, but that is no different from the one-socket-one-thread-model that java.net.* forces upon you).
In java, the 'select' call is replaced by a call to java.nio.channels.Selector.select(); and then the fishing out of the selected stuff comes from java.nio.channels.Selector.selectedKeys().
To add a thingy to a selector, use (for example) java.nio.channel.ServerSocketChannel.register(Selector, ops, att);
whereby the ops parameter is the kind of action you'd like to select this channel for; SelectionKey.OP_READ etc..
The workerthread bit is also easy to write, but I leave that to you as an exercise.

FileChannel.transferTo() using non-blocking SocketChannel

I'm looking to use FileChannel.transfer(From/To) for performing file transfers over a network. On the uploading side I find that even though I set the SocketChannel to non-blocking mode, the loop manages to send files as large as 30MB in only a single transferTo() invocation. What I'm hoping for is to have a series of partial writes so that I might generate progress notifications, which does occur on the downloading side with transferFrom(). I don't think a file that large should be transferred in one pass so I'm thinking that this is caused by either some internal buffer allocation issue or a goof-up on my part.
Thanks in advance for any input and here's the uploading code:
public void upload( String fileName ) {
FileInputStream fileStrm = null;
FileChannel fileChan = null;
FileLock fileLock = null;
SocketChannel sockChan = null;
Selector selector = null;
try {
// Lock the source file.
file = new File( fileName );
fileStrm = new FileInputStream( file );
fileChan = fileStrm.getChannel();
fileLock = fileChan.lock( 0L, Long.MAX_VALUE, true );
// Open a server socket bound to an arbitrary port.
servChan = ServerSocketChannel.open();
servChan.socket().bind( new InetSocketAddress( 0 ) );
// Wait for a single connection and close the server socket.
sockChan = servChan.accept();
servChan.close();
sockChan.configureBlocking( false );
selector = Selector.open();
SelectionKey selectorKey = sockChan.register( selector, SelectionKey.OP_WRITE );
// Loop until transfer has completed.
int fileSize = ( int ) file.length();
int sizeLeft = fileSize;
while ( sizeLeft > 0 ) {
// Wait for data to read, then transfer it.
if ( selector.select() == 1 && selectorKey.isWritable() ) {
sizeLeft -= ( int ) fileChan.transferTo( fileSize - sizeLeft, sizeLeft, sockChan );
// Generate a progress notification here such as:
// monitor.bytesTransferred( fileSize - sizeLeft );
catch ( IOException ex ) {
ex.printStackTrace();
finally {
try {
// Cleanup.
if ( selector != null )
selector.close();
if ( sockChan != null )
sockChan.close();
if ( fileLock != null )
fileLock.release();
if ( fileChan != null )
fileChan.close();
if ( fileStrm != null )
fileStrm.close();
catch ( IOException ex ) {
ex.printStackTrace();
-Edwin

Actually, the sending process appears way ahead of the receiving one, where the send seems to finish in a blink while the receive takes several seconds to complete. In other words, the transferTo() completes in one loop, while the transferFrom() performs many with delays in between. I'd guess all that data is sitting in some large outbound buffer at the sender, which would explain why it seems to finish too quickly. If I split the send into smaller chunks, the two sides run quite nearly at the same pace as expected.
The receiver already sleeps by way of a select() against a non-blocking SocketChannel, so I'll try reducing the buffer sizes as you suggest.

Hyperlink to a non-pdf file

I have a number of pdf files as pages in an ASP.NET website. I want to include hyperlinks to other pages that are not pdf files. I get the message "Could not open the file <file name>" which means that acrobat tries to open the file and not to transfer the control. Is there a means to make Acrobat 9 pro Extended to return the control to the website? Thanks, Dinu

Thanks for the suggestion. Indeed AA9Ext offers Edit | Preferences | Trust Manager where I ticked "Allow opening of non-PDF file attachments with external applications". It doesn't work, apparently my problem is not related to "file attachments". I get "Security Block - Acrobat does not allow connection to: <url>"

Reading variable block file

Hi,
I have a variable block file which was transmitted from mainframe side.
When i browse the variable block file in mainframe i can see it as
!Line 1
!Line 2
!Line 3
but once we transmit the file in Unix box, the file contents appear as
!Line1!Line2!Line3
does java differentiate between variable block and fixed block files..
does java has separate API to read Variable block file

Ah. Then perhaps the file browser that you use in the mainframe is displaying the data in lines even though there are actually no new-line characters separating the records. For your convenience of course.
And perhaps there's an option in the mainframe FTP client that can insert those new-line characters if you need them. Although it's quite possible that you don't need them in the Unix system. If the only problem is that you don't see any, then just write your program assuming that there are none.

Non-Blocking Writing and Strings

Hello.
My question is simple, is it possible to write strings using a non-blocking method?
I was praying that there was a method in the NIO API that allowed me to, yet i can't find one.
If the answer is blatantly obvious please forgive me, i'm tired and hungry :)
Thank you for looking at this topic

Strings are written to files or sockets using a certain encoding. I usually use UTF-8, but your application might be different.
1. Get the SocketChannel from your non-blocking socket.
SocketChannel ch = mySocket.getChannel(); // mySocket is java.net.Socket2. Make a CharBuffer out of the String you want to send.
CharBuffer chars = CharBuffer.wrap(myString); // myString is your data3. Encode it so it becomes a ByteBuffer. I'll use the [UTF-8|http://www.joelonsoftware.com/articles/Unicode.html] Charset here.
ByteBuffer bytes = Charset.forName("UTF-8").encode(chars);4. Use the write(ByteBuffer) method in the SocketChannel from 1.
ch.write(bytes);Import declarations:
import java.nio.channels.SocketChannel;
import java.nio.CharBuffer;
import java.nio.ByteBuffer;
import java.nio.charset.Charset;s

Non-blocking SocketChannels

I'm trying to learn how to use non-blocking socket channles, but I haven't found much info (nor luck) so far.
To learn, I'm building a server and a client. The server accepts input from the clients and process it in only one thread. The clients should send Objects to the server, and the server process them and return the result also as an Object. For this, I'm trying to use ObjectOutputStream and ObjectInputStream.
The problem I don't know how to solve is that the SocketChannel is in non-bolcking mode, so I can't use their input/output streams (I get a IllegalBlockingModeException). In the server process loop I can reconfigure the SocketChannel to blocking mode to be able to read the Object, but I can't configure it to non-blocking mode again because I get a CancelledKeyException.
Does anyone know how to work with InputStreams and non-blocking channels? Or where to find more info about it?
Here are the relevant part of the server code:
Set ready = selector.selectedKeys();
Iterator i = ready.iterator();
while (i.hasNext()) {
 try {
 SelectionKey sk = i.next();
 i.remove();
 if (sk.isAcceptable()) {
 ServerSocketChannel ssc = (ServerSocketChannel)sk.channel();
 SocketChannel sc = ssc.accept();
 sc.configureBlocking(false);
 sc.register(selector, SelectionKey.OP_READ);
 } else if (sk.isReadable()) {
 SocketChannel sc = (SocketChannel)sk.channel();
 // PROBLEM: If the channel is in non-blocking mode
 // I cannot use InputStreams
 sk.cancel();
 sc.configureBlocking(true);
 // Read the object sent by the client
 ObjectInputStream in = new ObjectInputStream(Channels.newInputStream(sc));
 Object o = in.readObject();
 // PROBLEM: Can't put the channel back to non-blocking mode
 sc.configureBlocking(false);
 sc.register(selector, SelectionKey.OP_READ); // CancelledKeyException
 } catch (...){
}

In my client, this is working fine:
ObjectOutputStream oos = null;
ObjectInputStream ois = null;
for (int i = 0; i < 30000; i++) {
 oos = new ObjectOutputStream(sc.socket().getOutputStream());
 oos.writeObject(object);
 oos.flush();
 ois = new ObjectInputStream(sc.socket().getInputStream());
 Object o = ois.readObject();
}But trying to do it like this throws a StreamCorruptedException at the server side.
ObjectOutputStream oos = new ObjectOutputStream(sc.socket().getOutputStream());
ObjectInputStream ois = new ObjectInputStream(sc.socket().getInputStream());
for (int i = 0; i < 30000; i++) {
 oos.writeObject(object);
 oos.flush();
 Object o = ois.readObject();
}Do you know why?

Using non blocking connect() call for SCTP sockets in Solaris10

Hi,
I have a problem with non blocking connect call on SCTP socket.
I am using the sctp stack support in Solaris10.
When the connect is successful, I can get the pollout event on the socket.
But there is no event observed when the peer does not exist. In other words, I could not get the pollout event on connection failure. This logic works fine with TCP sockets on both Solaris and Suse10.
I am working with SCTP one-to-one style sockets.
Is there any way to handle this issue?
Do I need to load any patch to resolve this issue?
It will be great if I get a solution in this regard.
Thanks in advance.
Best Regards,
Bipin.

There are at least two problems here.
A. In the receiver you should test for -1 from the read() immediately, rather than continue with the loop and try to write -1 bytes to the file.
B. In the sender you are ignoring the return value of client.write(), which can be anything from 0 to the buffer length. If you get 0 you should wait for another OP_WRITE to trigger; if you get a 'short write' you need to retry it until you've got nothing left to write from the current buffer, before you read any more data. This is where the data is vanishing.

Non-blocking file selector?

Similar Messages

Maybe you are looking for