Compile ambiguity fixed. Thanks Scott.
Any developers have opinions about 1.4?
I've seen file IO at native speeds, but you have to use the nio channel classes. You'd think they could push these improvements throughout the JDK, but guess not.
I'm all for it! Since the IL's and the PM's are pluggable... It would be a great project if some body created a NBIO version of the OIL IL and a NBIO version of the rollinglogged persistance manager.
It would fly and keep memory usage low.
Regarding jd 1.4 support. I'm having trouble using jdk1.4 beta3 for clients and jdk 1.3 for jboss when using JMS (but its probably more related to RMI).
JBoss is unable to send JMS messages to jdk 1.4 clients. (Running jboss with 1.4beta-3 works perfectly but that is not an option in this case as Cocoon has trouble with 1.4 (probably solvable though) and for other reasons)
[OILClientIL] ConnectionReceiverOILClient is connecting to: 127.0.0.1:1405
[ClientConsumer:ID4] Could not send messages to a receiver.
java.rmi.RemoteException: Cannot connect to the ConnectionReceiver/Server
[JMSServer] The connection to client ID4 failed.
Jboss, Sun? Who is to blame? :)
The OIL client/server is supposed to run over sockets without RMI. The RMI client/server is for that. From the stack trace it looks like this is a socket problem and I'm guessing that the rmi.RemoteException is used to indicate a remote problem (gota use some exception and I'm guessing RemoteException fit the bill).
So... I don't think that RMI is to blame here. Now I'm willing to be proven wrong, but I think there's probably some issue connecting to 127.0.0.1:1405. It probably got a connection refused error for some reason.
> I'm all for it! Since the IL's and the PM's are
> pluggable... It would be a great project if some
> body created a NBIO version of the OIL IL and a NBIO
> version of the rollinglogged persistance manager.
> It would fly and keep memory usage low.
I made it for SwiftMQ (we have already a NBIO version and switched it to java.nio). The network layer running with java.nio instead of normal java blocking I/O is much slower, although we use direct buffers and do the work very efficient. When we have a throughput of 1000 msgs/s with normal I/O, we got ~700 with java.nio. IMO the buffer stuff in java.nio isn't implemented efficient enough. If you write or read a whole buffer, it is done internally with for-loops and get/put per single byte. The select() has also some overhead. We have experience with NBIO from Matt Welsh. This is also slower when you compare it with a few connections on java blocking I/O, but it is more scalable and you need only a few threads. NBIO is your friend if you have to handle > 500 connections. We haven't made scalability tests with java.nio yet, because there is a known bug in the selector impl. You cannot register more than 63 channels.
Another big backdraw is that you cannot use socket factories to obtain a socket, hence, you cannot use JSSE. java.nio itself hasn't support for SSL channels.
The other stuff with file I/O isn't more efficient either. Allocating direct buffers takes time. So when you have a rolling logfile, you haven't any advantages because you mostly write to it and read it only on recovery which isn't time critical. The advantage comes if you read from that buffers and the file size is somewhat fixed. But as long as you have to extend the file, you have to create a new MappedByteBuffer each time you extend the file (you cannot extend the buffer). That's very slow. SwiftMQ has a page-oriented cache and swaps into RandomAccesFiles. That's much faster and doesn't consume that memory you will need for all the native buffers.
So don't expect too much from the new I/O classes.
Yes, agreed. Still it had something to do with JDK 1.4 in some way (works perfectly with 1.3), and I have a hard time blaming RMI of course for the reason you stated :). Still I'm more concerned with cocoon being unable to run with 1.4 (several bugs reported on that issue).
My initial thought was that there was a problem in the EJB replying to the message (of course). No such things.
(Not?) Surprisingly the exact same system can switch between 1.3 and 1.4 on another system with the exact (obvisouly not) setup and code and similar OS etc. So disregard this I guess. Thanks for your reply anyway!