Java io and Java nio, which is faster to binary io?

Anybody can advise me about java io and java nio ?
I want to write the faster code to read and write binary files.
I'm going to read/write
- individual elements (int, double, etc)
- arraylists
- objects
Also I'm going (or I'd want) to use seek functions.
Thanks

Anybody can advise me about java io and java nio ?
I want to write the faster code to read and write binary files.Which is "faster" depends on exactly how you're using them. For example, a MappedByteBuffer is usually faster for random access than a RandomAccessFile, unless your files are so large (and your accesses so random) than you're constantly loading from disk. And it's not at all faster for linear uni-directional access than a simple FileInputStream.
So, rather than expecting some random stranger telling you that one is faster than the other without knowing your project, perhaps you should tell us exactly how you plan to use IO, and why you think that one approach may be faster than the other.

Similar Messages

Sun C++ Vs Sun JAVA - Future - Which is faster

Hi,
Sometimes I am perplexed with Sun's approach. They ship SunC++12 and market for JAVA. I work on both C++ and JAVA. I started career as a JAVA developer and then shifted as a C++ developer for SUN platform. Now I work on both.
Many of Sun's article praise about JAVA and says it is faster than C++. Does that list include Sun C++ compiler too?
Can't Sun C++ developers develop an app better and faster than a Sun java App?
If for Sun everything is JAVA why they invest on C++ compilers?
Now C++ is changing and after couple of years you get C++ - 0X.
Will Sun upgrade the compiler to support thesame?
Jayaram

Dear Friend,
This excersise is absolutely pointless. It can prove nothing.
It proved C++ is powerful. You can close your eyes against truth and live in your fantacy world.
By changing int -> double you went into a muddy ground of a floating point calculations.
By moving your "toggle" objects from heap onto stack you stepped away from java semantics possibilities. No wonder C++ can win here.
Here the constructor is called only one time. Stack and heap are irrelevent. By the way margin was of couple of seconds. No C++ guy will think of JAVA semantics when programming in C++. Do you think of pointers when you program in JAVA?
Both are primitive types. Reason for moving I have specified.
Btw, its likely that compiler managed to figure out those virtual calls and inline them altogether.
I used babys of same mother. SUN. SUN CC compiler and SUN JAVA 1.6.
Its hard to say what happened in your case as you did not tell which compiler flags did you use.
Nothing hard or special in my case. It is truth. C++ WON. You can try yourself.
Its funny that you used register/inline stuff because it can hardly make any real difference in this test.
For particular C++ compiler on particular platform and compilation flags it might have an effect, but thats a third order effect of compiler bugs and inefficiencies.
Being a battle started by the benchmark person, I have the freedom to use all weapons in C++. Use whatever you have. May be you can ask SUN to put a bug in their CC compiler to prove your point. Then I will test with MSVC++ compiler.
Please not I didn't change the end output or logic. Pointers where not required So removed. I was in the office work when I did this. I am not a full time evangelist.
Compiler option. If you understand JVM then it uses onthe fly profiling, compiler optimization etc.. So I used compiler Compiler switch is very much reasonable.
Anyway, the bottom point is that different languages are suitable for different purposes.
Creatively tweaking your programming environment you can make any given combination of particular language/compiler/program to win a race.
First point is right. C++ is a general purpose language. For each specific purpose use only those parts. JAVA is a simple language suitable for normal brains.
Whats ever you tweak for JAVA it is an interpreted language. Additional layer of JVM is there. So native languages may be even pascal and Basic will win JAVA in many bench marks.
Using that car analogy - sport car on a muddy track will hardly compete with an unloaded truck. Though it doesnt mean that sport car is slower.
Again your are risking. The track is not muddy. No only increment operation is done. No floating point multiplication or division. Even if it is there you don't have eany voice to complain. It is primitive type. If still you cribb I can't help.
Java reached the point when performance is not a biggest concern. For majority of applications you win a great deal more by choosing proper algorithms than by rewriting your application on some "faster" language.
Again you are mistaken. Our MAX CPUs clock speed is getting saturated. We are going for multicore architectures. All apps are not parallel. So single core performance is important. So if you can loose the fat in your language always it is better.
Algorithems don't assure that they won't use floating point opration. And the choice of an algorithm is not propritary right of JAVA. Any language can use it.
So the point is don't compare performance of JAVA withh C++ and get patents for the same. It won't take much time for a person like me to break the patents and prove you are wrong.
If you see the url I am given, go three levels up. The test case is the one in the benchmark which had the highest margin of JAVA Win. So Your best result is ruined in a couple of hours!!!!.
Ok letme come back to the point. Why is the C++ team of Sun silent?
I feel they are not funded properly for development or they were told to keep their mouth shut.
I would like to hear from the C++ team of Sun if any one reads this belong to that team.
Reagrds,
Jayaram Ganapathy

J2ME and java.nio

I'm not sure which forum this should go in so applogies if I got it wrong.
I would like to use the java.nio package from JDK1.4 with the J2ME. Is this possible in any way?
cheers
Andrew

I'm not sure which forum this should go in so
applogies if I got it wrong.
I would like to use the java.nio package from JDK1.4
with the J2ME. Is this possible in any way?this topic should be post at
CLDC and MIDP
http://forum.java.sun.com/forum.jsp?forum=76
or
K Virtual Machine (KVM)
http://forum.java.sun.com/forum.jsp?forum=50
CLDC 1.0 and MIDP 1.0 doesn't include java.nio
please go to
http://java.sun.com/j2me/docs/
two documents will be useful
CLDC Specification, V1.0
MIDP 1.0 Specification, Final (JSR 37)

Design Problem : How to design/code a java client which is deployed to all the machines in a cluster and make sure that only one of the java client is active

          hi ,
          I have to design a java client (which is basically a JMS message listener)which
          is deplloyed to all the servers in the cluster. But as these are message listeners,
          i want only one of the instance to be active at a time.
          If the server on which the client is active goes down , I want the second server
          to start listening to messages.
          How do i design this ? Also is there a public api for multicasting that we can
          use ?
          Anybody has an idea on how to go about this..
          Thanks
          nisha


Hi Nisha,
          Failover message listeners? Sounds like you want MDBs, which are deployed on all nodes in a
          cluster. If your JMS destination is a queue, then only one MDB will pick up the message. And just
          like any other ejb service, MDBs failover.
          Gene
          "Nisha" <[email protected]> wrote in message news:[email protected]..
          hi ,
          I have to design a java client (which is basically a JMS message listener)which
          is deplloyed to all the servers in the cluster. But as these are message listeners,
          i want only one of the instance to be active at a time.
          If the server on which the client is active goes down , I want the second server
          to start listening to messages.
          How do i design this ? Also is there a public api for multicasting that we can
          use ?
          Anybody has an idea on how to go about this..
          Thanks
          nisha

Java NIO locking and NTFS network resources

Hi all - just ran into a really nasty situation and I was wondering if anyone else has hit it and might have some suggestions.
Platform: JRE 1.4_02 on a Win XP machine
The following test code locks a file, then copies it to another location using NIO.
When I run it with source path on my local drives (C), it works fine. If I run it with source path on a network shared resource, it fails with an IOException with description 'Error performing inpage operation'.
If I disable the lock immediately before the copy operation, it works fine.
My conclusion is that there is something about the NIO locking implementation that prevents it from working properly with NTFS volumes on other hosts. Can this be right? I've found the following bug report:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4774175
but this seems like a huge problem that would prevent folks from using NIO in many, many applications. Maybe I'm wrong on something here...
Anyway, here's the test code:
import java.io.File;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.RandomAccessFile;
import java.nio.channels.FileChannel;
import java.nio.channels.FileLock;
* Created on May 28, 2004
* (c) 2004 Trumpet, Inc.
* @author kevin
public class test {
     private void createFile(File f) throws IOException{
          FileOutputStream os = new FileOutputStream(f);
          for(int i = 0; i < 10; i++){
               os.write(i);
          os.close();
     public test() {
          boolean testWithReleasingLockPriorToCopy = false;
          final File f1= new File("w:/temp/test2.lok");
          final File f2 = new File("w:/temp/test.lok");
          f1.delete();
          f2.delete();
          try {
               createFile(f1);
               RandomAccessFile raf1 = new RandomAccessFile(f1, "rw");
               RandomAccessFile raf2 = new RandomAccessFile(f1, "rw");
               FileChannel ch1 = raf1.getChannel();
               FileChannel ch2 = raf2.getChannel();
               FileLock flock1 = ch1.lock();
              if (!f2.getParentFile().exists() && !f2.getParentFile().mkdirs())
                   throw new IOException("Unable to create directories for destination file '" + f2 + "'");
              if (testWithReleasingLockPriorToCopy)
                   flock1.release();
               ch1.transferTo(0, raf1.length(), ch2);
               raf1.close();
               raf2.close();
          } catch (Exception e) {
               // TODO Auto-generated catch block
               e.printStackTrace();
     public static void main(String[] args) {
          test t = new test();
}Does anyone have any pointers here? I need to be able to exclusively lock a file on a network drive (preventing any other applications from opening it), then make a copy of it. I can't use regular stream operations, because the lock prevents them from working properly (it appears that, once you grab a file lock using NIO, the only way your application can use the file is via the NIO operations - using stream operations fails...).
Thanks in advance for any help!
- Kevin

i've run into the same problem recently, channels working fine for local file locking, but when you turn to the network, they fail to accurately handle locks.
i ended up writing a jni utility to ship with my java application that locks files using native windows calls.
my .c file ends up looking something like this:
JNIEXPORT jint JNICALL Java_Mapper_NativeUtils_LockFile
(JNIEnv *env, jobject obj, jstring filename)
const char* ntvFilename = (*env)->GetStringUTFChars(env, filename, 0);
int retVal = (int)CreateFile
ntvFilename
, GENERIC_WRITE
, FILE_SHARE_READ
, 0
, OPEN_EXISTING
, FILE_FLAG_SEQUENTIAL_SCAN
, 0
//add code to throw java exceptions based on retVal
if (retVal == (int)INVALID_HANDLE_VALUE)
return retVal;
(*env)->ReleaseStringUTFChars(env, filename, ntvFilename);
return retVal;
JNIEXPORT jboolean JNICALL Java_Mapper_NativeUtils_UnlockFile
(JNIEnv *env, jobject obj, jint handle)
     CloseHandle((void *)handle);
return 1;
it's a little shy on the error checking side, but it provides support for network file locking that java seems to lack.

Java NIO, ByteBuffers and Linksys router

I have a client server app/game that uses NIO for communication sending ByteBuffers. On a LAN with 5-8 users it runs great. On the internet, through a Linksys router, with one user, it has a blip. I get all my data transmissions except for one buffer. Whenever I chat the buffer contains a size, an int typeID and the encoded string for chat. This particular buffer never makes it to the client on the outside of the router. I have a port forwarded and regular tcp/ip java io sockets stuff works fine. As does al lof the other NIO buffer traffic for locational data, login in and out, etc... ANy thoughts??

But not sure what would be the performance of those clients?? when compared to Java NIO performance....Telnet isn't a high-performance protocol anyway. Don't worry about it. Use existing code. Get it working. Measure. If you have a performance issue, then worry, while at least you have something you can deploy. It won't be a problem. The router is there to route, not to talk high-speed telnet.

Java.nio and databases

Please, need help.
I'm using java.nio to get large files contents (txt) and need to put these data into MSSQL SERVER 2000 database tables. NIO have capabilityies to get data and transfer directly to the tables? If so, how can i do it?
Thanks a lot
Aloisio

ChuckBing, i'm connected with database trough JDBC yet and i can retrieve data meaning my connection is OK.
I'm able to read data from a txt file (250mb large) trough MappedByteBuffer and write into another with the same size and content. It's working fine.
My question is if i can read the txt file and, instead write the data into another txt file, put these data into a table.
Thanks for your reply

Java NIO and sockets in 1.4.1FCS

Hi,
I have built a client server system using the new 1.4 java.nio packages. In 1.4 everything worked fine, yet in 1.4.1 FCS it definitely does not. The process is as follows.
Everything work in non-blocking mode:
- Server receives connection and accepts it, the new SocketChannel is put in non-blocking mode and registered with the same selector as the server.
- New SocketChannel waits for data from the client so it waits for OP_READ from the selector. All it gets is OP_WRITE, OP_CONNECT. With 1.4 it received OP_READ, OP_WRITE.
I tried adding a call to finishConnect, but that didn't help.
Anyone have any thoughts about this?
Thanks,
Mike.

The code in the bug report is incorrect. The key will of course always be writable if you do not write anything to the socket! And since it is writable the readable part of the code will never be executed (its in an else-statement). When you are not interested in the OP_WRITE, change the ops on the selection key.

Troubles with timeout using java.nio.channels and non-blocking sockets

Hello.
I have a server application that employs java.nio.channels with non-blocking sockets.
The server waits for connections. The client should connect and be first in sending data.
Timeouts are significant! If client exceeds the allowed time to send data, the server should break the connection.
The huge trouble I've discovered that I cannot control the timeout when client connects but remains silent.
My code looks as follows:
<pre>
Selector oSel;
SocketChannel oSockChan;
Socket oSock;
SelectionKey oSelKey;
Iterator<SelectionKey> oItSelKeys;
int iCurrState, iMask, iCount;
iCurrState = INT_SERVER_WORKING;
iMask = SelectionKey.OP_ACCEPT | SelectionKey.OP_CONNECT | SelectionKey.OP_READ | SelectionKey.OP_WRITE;
while ( iCurrState == INT_SERVER_WORKING )
try
*// retrieving next action*
iCount = oSel.select();
if ( iCount > 0 )
oItSelKeys = oSel.selectedKeys().iterator();
while ( oItSelKeys.hasNext() )
oSelKey = oItSelKeys.next();
oItSelKeys.remove();
if ( oSelKey.isValid() )
switch ( oSelKey.readyOps() & iMask ) {
case SelectionKey.OP_ACCEPT :
oSockChan = oSSockChan.accept();
oSockChan.configureBlocking(false);
oSock = oSockChan.socket();
oSock.setKeepAlive(true);
oSockChan.register(oSel,SelectionKey.OP_READ,new MyPacket(oSock.getInetAddress(),oSock.getPort()));
break;
case SelectionKey.OP_READ :
oSelKey.interestOps(0);
((MyPacket) oSelKey.attachment()).inRequest(); *// preparing request*
this.getReader().add(oSelKey); *// sending key to reading thread*
break;
case SelectionKey.OP_WRITE :
oSelKey.interestOps(0);
((MyRequest) oSelKey.attachment()).inResponse(); *// preparing response*
this.getWriter().add(oSelKey); *// sending key to writing thread*
break;
case SelectionKey.OP_CONNECT :
default :
*// nothing to do*
catch ( IOException oExcept )
*// do some actions*
</pre>
Timeouts are easily controlled by reading and writing threads (see OP_READ and OP_WRITE ).
But when a client just connects without consequent data send, the state of this connection remains as OP_ACCEPT. The connection remains open for arbitrarily large time and I cannot control it!
Please help with idea how can I terminate such connections!

How can I process the keys that weren't selected at the bottom of the loop? Should I use the method keys() ?Yes. Form a new set from keys() and removeAll(selectedKeys()). Do that before you process selectedKeys().
And the second moment: as I understood a single key may contain several operations simultaneously? Thus I should use several if's (but not if/else 'cause it's the equivalent of switch ... case ).If there is anything unclear about 'your switch statement is invalid. You need an if/else chain' I fail to see what it is. Try reading it again. And if several ifs were really the equivalent of "switch ... case", there wouldn't be a problem in the first place. They're not, and there is.

Selecting between java.io and java.nio

Hi,
I'm a bit confused between java.io and java.nio. What sre the major differences between these two?
In areas are these best applicable?

The java.nio package improves on the basic Java I/O that was available prior to JDK 1.4.
It is designed to interoperate more natively with the underlying file handles (sockets, open files etc) to achieve better performance.
The improvements include true non-blocking I/O, better buffer management, character-set support, channels (similar to Occam's channels) and selectors, and some other ancillery stuff. Most of these classes are designed to be inherently threadsafe.
There are some examples here:
http://java.sun.com/j2se/1.4.2/docs/guide/nio/example/index.html
However, if you are still a beginner with file or network I/O, its better if you start with the simple I/O first. You'll appreciate the NIO improvements better afterwards.

Java NIO Vs Normal IO

hi ppl...i want to know when v should prefer nio over normal io. I read somewhere that only if you have to deal with a lot of connections simultaneously you should consider using NIO. as an example it said that a web spider which needs to process a few million connections simultaneously NIO should be preferred. Now in my project i need to have around 750 simultaneous connections. Should i use NIO or traditional IO ?

There is not enough information given about the
specifics of this situation to be making such broad
claim that it will help.I got enougth information. NIO was introduced because traditional Java I/O was found lacking. Traditional I/O is good for reading and writing a few files but that's not what the OP will be attempting. From the NIO proposal documentation:
2.3 What needs of the Java community will be addressed by the proposed specification?
* The proposed specification will satisfy several long-standing needs of the Java community.
* The scalable I/O API will make it easier to write production-quality web and application servers that scale well to thousands of open connections and can easily take advantage of multiple processors;
* The fast buffered binary I/O API will make it easier to write high-performance, I/O-intensive programs that manipulate streams or files of binary data;
* The fast buffered character I/O API will simplify the efficient handling of character streams and files; it will also bring regular expressions and a compact notation for formatted output to the Java platform, putting it on a par with other popular platforms such as Perl;
* The character-set converter API will give developers direct access the platform's built-in character-set converters and will also provide for the easy "plugging in" of new converters;
* The new set of I/O exceptions will make it easier to write programs that recover from different types of I/O failures in different ways, and to write user interfaces that behave consistently on different platforms when I/O failures occur; and
* The new filesystem interface will work more consistently across platforms, will make it easier to write programs that gracefully handle the failure of filesystem operations, will provide more efficient access to a larger set of file attributes, will allow developers of sophisticated applications to take advantage of platform-specific features when absolutely necessary, and will allow support for non-native filesystems, such as network filesystems, to be "plugged in" to the platform.
2.4 Why aren't these needs met by existing specifications?
Some of the above needs can be met by using existing APIs together with a significant amount of custom code. It is possible, for example, to write a class that implements the DataInput interface and runs about eight times faster than the built-in DataInputStream class. The Java community would be better served if the Java platform made this sort of work unnecessary.
Some of the above needs can be met by using existing APIs in fragile, implementation-specific ways. To recover from specific types of I/O errors, for example, developers sometimes write code that dissects the message strings of generic IOException objects. This technique may work with a particular implementation of Java on a particular operating system, but it is not very portable. A different implementation on a different operating system may, in a given situation, throw an IOException object with a completely different message string.
Finally, most of the above needs cannot be met simply because the required functionality is not provided by the current I/O APIs.
In summary. If you're doing serious I/O (like 1000 open connections) go for NIO. It's also easier to start with NIO right away to get used to it than it is to first use traditional I/O only to find you need to upgrade later on.

Java NIO client

I need to make the server is able to hold about 500 connections and operates on a single thread. The server itself should make all the connections. Where can I find examples of finished implementations?

I have an example, but it does not work
import java.io.IOException;
import java.net.InetAddress;
import java.net.InetSocketAddress;
import java.net.Socket;
import java.nio.ByteBuffer;
import java.nio.channels.SelectionKey;
import java.nio.channels.Selector;
import java.nio.channels.SocketChannel;
import java.nio.channels.spi.SelectorProvider;
import java.util.*;
public class NioClient implements Runnable {
     // The host:port combination to connect to
     private InetAddress hostAddress;
     private String host;
     private int port;
     // The selector we'll be monitoring
     private Selector selector;
     // The buffer into which we'll read data when it's available
     private ByteBuffer readBuffer = ByteBuffer.allocate(8192);
     // A list of PendingChange instances
     private List pendingChanges = new LinkedList();
     // Maps a SocketChannel to a list of ByteBuffer instances
     private Map pendingData = new HashMap();
     // Maps a SocketChannel to a RspHandler
     private Map rspHandlers = Collections.synchronizedMap(new HashMap());
     public NioClient() {
          try {this.selector = this.initSelector();} catch(IOException e){}
     public void connect(String host, int port, RspHandler handler) throws IOException {
          this.hostAddress = hostAddress;
          this.host = host;
          this.port = port;
          this.send("$Hello |".getBytes(), handler);
     public void send(byte[] data, RspHandler handler) throws IOException {
          // Start a new connection
          SocketChannel socket = this.initiateConnection();
          // Register the response handler
          this.rspHandlers.put(socket, handler);
          // And queue the data we want written
          synchronized (this.pendingData) {
               List queue = (List) this.pendingData.get(socket);
               if (queue == null) {
                    queue = new ArrayList();
                    this.pendingData.put(socket, queue);
               queue.add(ByteBuffer.wrap(data));
          // Finally, wake up our selecting thread so it can make the required changes
          this.selector.wakeup();
          handler.waitForResponse();
     public void run() {
          while (true) {
               try {
                    // Process any pending changes
                    synchronized (this.pendingChanges) {
                         Iterator changes = this.pendingChanges.iterator();
                         while (changes.hasNext()) {
                              ChangeRequest change = (ChangeRequest) changes.next();
                              switch (change.type) {
                              case ChangeRequest.CHANGEOPS:
                                   SelectionKey key = change.socket.keyFor(this.selector);
                                   key.interestOps(change.ops);
                                   break;
                              case ChangeRequest.REGISTER:
                                   change.socket.register(this.selector, change.ops);
                                   break;
                         this.pendingChanges.clear();
                    // Wait for an event one of the registered channels
                    this.selector.select();
                    // Iterate over the set of keys for which events are available
                    Iterator selectedKeys = this.selector.selectedKeys().iterator();
                    while (selectedKeys.hasNext()) {
                         SelectionKey key = (SelectionKey) selectedKeys.next();
                         selectedKeys.remove();
                         if (!key.isValid()) {
                              continue;
                         // Check what event is available and deal with it
                         if (key.isConnectable()) {
                              this.finishConnection(key);
                         } else if (key.isReadable()) {
                              this.read(key);
                         } else if (key.isWritable()) {
                              this.write(key);
               } catch (Exception e) {
                    e.printStackTrace();
     private void read(SelectionKey key) throws IOException {
          SocketChannel socketChannel = (SocketChannel) key.channel();
          // Clear out our read buffer so it's ready for new data
          this.readBuffer.clear();
          // Attempt to read off the channel
          int numRead;
          try {
               numRead = socketChannel.read(this.readBuffer);
          } catch (IOException e) {
               // The remote forcibly closed the connection, cancel
               // the selection key and close the channel.
               key.cancel();
               socketChannel.close();
               return;
          System.out.println("READ");
          if (numRead == -1) {
               // Remote entity shut the socket down cleanly. Do the
               // same from our end and cancel the channel.
               key.channel().close();
               key.cancel();
               return;
          // Handle the response
          this.handleResponse(socketChannel, this.readBuffer.array(), numRead);
     private void handleResponse(SocketChannel socketChannel, byte[] data, int numRead) throws IOException {
          // Make a correctly sized copy of the data before handing it
          // to the client
          byte[] rspData = new byte[numRead];
          System.arraycopy(data, 0, rspData, 0, numRead);
          // Look up the handler for this channel
          RspHandler handler = (RspHandler) this.rspHandlers.get(socketChannel);
          // And pass the response to it
          if (handler.handleResponse(rspData)) {
               // The handler has seen enough, close the connection
               socketChannel.close();
               socketChannel.keyFor(this.selector).cancel();
     private void write(SelectionKey key) throws IOException {
          SocketChannel socketChannel = (SocketChannel) key.channel();
          synchronized (this.pendingData) {
               List queue = (List) this.pendingData.get(socketChannel);
               // Write until there's not more data ...
               while (!queue.isEmpty()) {
                    ByteBuffer buf = (ByteBuffer) queue.get(0);
                    socketChannel.write(buf);
                    if (buf.remaining() > 0) {
                         // ... or the socket's buffer fills up
                         break;
                    queue.remove(0);
               if (queue.isEmpty()) {
                    // We wrote away all data, so we're no longer interested
                    // in writing on this socket. Switch back to waiting for
                    // data.
                    key.interestOps(SelectionKey.OP_READ);
     private void finishConnection(SelectionKey key) throws IOException {
          SocketChannel socketChannel = (SocketChannel) key.channel();
          // Finish the connection. If the connection operation failed
          // this will raise an IOException.
          try {
               socketChannel.finishConnect();
          } catch (IOException e) {
               // Cancel the channel's registration with our selector
               System.out.println(e);
               key.cancel();
               return;
          // Register an interest in writing on this channel
          key.interestOps(SelectionKey.OP_WRITE);
     private SocketChannel initiateConnection() throws IOException {
          // Create a non-blocking socket channel
          SocketChannel socketChannel = SocketChannel.open();
          socketChannel.configureBlocking(false);
          // Kick off connection establishment
          socketChannel.connect(new InetSocketAddress(this.host, this.port));
          // Queue a channel registration since the caller is not the
          // selecting thread. As part of the registration we'll register
          // an interest in connection events. These are raised when a channel
          // is ready to complete connection establishment.
          synchronized(this.pendingChanges) {
               this.pendingChanges.add(new ChangeRequest(socketChannel, ChangeRequest.REGISTER, SelectionKey.OP_CONNECT));
          return socketChannel;
     private Selector initSelector() throws IOException {
          // Create a new selector
          return SelectorProvider.provider().openSelector();
public class RspHandler {
     private byte[] rsp = null;
     public synchronized boolean handleResponse(byte[] rsp) {
          this.rsp = rsp;
          this.notify();
          return true;
     public synchronized void waitForResponse() {
          while(this.rsp == null) {
               try {
                    this.wait();
               } catch (InterruptedException e) {
          System.out.println(new String(this.rsp));
}          NioClient NioClient = new NioClient();
          Thread t = new Thread(NioClient);
          t.setDaemon(true);
          t.start();
          RspHandler handler = new RspHandler();
          NioClient.connect("69.28.156.250", 27040, handler);
          NioClient.connect("72.165.61.188", 27040, handler);
          NioClient.connect("208.111.133.84", 27011, handler);
          NioClient.connect("72.165.61.136", 27012, handler);
Edited by: 915967 on 01.08.2012 7:07

String.getBytes() & String(byte[]) - java.nio.BufferOverflowException

The application in question uses JNI for legacy integration and I suspect the legacy code is corrupting the stack causing the above error. However, the error does not occur in Java 1.3, only Java 1.4.
Is there some way to suppress 1.4's use of the native IO API when encoding and decoding byte streams? This would at least provide a workaround in the meantime.
Thanks.

This is beginning to make a little sense. The problem is that you got a String and you don't want one. A String wraps an array of chars, which your app needs, right? Specifically they're chars because you need 16-bit char sets.
Presumably the getBytes() method call is used to get an array of bytes for some data transfer operation. java.nio was probably added in 1.4 as it has some very efficient ways of handling buffers as simultaneously of two or more types. It's trying to use the underlying char array as a byte array and there's a straight up bug someplace.
Workaround is strange to contemplate, but I'm pretty sure it will work: use String.getChars() to get an array of chars, and then use java.nio yourself to create your byte array! If you've never been there, it's not very hard. I use nio all the time and it's never been a problem.

Thread blocking on java.nio.charset.CoderResult

Hello all,
I have a multi-threaded app which does some fairly intestive string operations (basically extracts text from documents for indexing a search system).
I am seeing a massive bottleneck around the java.nio.charset.CoderResult class. When profiling, I see a whole stack of threads blocking on (waiting for) a monitor on this java.nio.charset.CoderResult class. Seems to be a result of string encoding/decoding (I am often encoding strings as UTF-8).
Anyone know why the JVM would want my threads to sync on this class? It's creating a huge performance issue for my app. Approximately 15% of ALL the processing time is spent waiting for this class.
Help!

I would guess that you're using some of the static methods in the CoderResult class. The static methods CoderResult.unmappableCache(), CoderResult.malformedForLength() and CoderResult.malformedCache all use a static inner class called Cache. Its get() method is synchronized on Cache.class. Since the Cache inner-class is static, any part of your multi-threaded application that goes through the Cache.get() method is going to be waiting for the lock on Cache.class.
Could you create a CoderResult instance for each thread? That would mean that there would be a different static Cache class for each thread, reducing the number of threads competing for the Cache.class lock.
I'd have to see some of your code to give a better answer.
Brian

Java.nio package

Is there a good tutorial somewhere which explain in depth the new I/O package in JDK 1.4 java.nio?

And there is the JavaWorld article at:
http://www.javaworld.com/javaworld/jw-09-2001/jw-0907-merlin.html
but the example code they give is a little broken, and
the article is also a little confusing. But it can help a little.
I have also started some threads on these forums about the bugs in that article.

Java io and Java nio, which is faster to binary io?

Similar Messages

Maybe you are looking for