nbserver-devel Mailing List for Non-blocking servers in Java made easy
Status: Beta
Brought to you by:
szegedia
Menu
▾
▴
nbserver-devel — List for nbserver development discussion
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
(10) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
|---|
|
From: Attila S. <sze...@fr...> - 2002-09-08 21:04:51
|
Hi, sorry for being slow to follow-up, but I was on a vacation with only a sporadic Internet access. I'll try to review the tests this week with whatever 1.4.1 beta is freshest at this time. This project is in back of my mind all the time, but it is true I had no time to work on it lately, altough I'd like to get back to it more intensively in the future. In the meantime, feel free toexperiment. If you like it - I think the code base is quite clear and is easy to develop against it - and you want to take a part in it, I'll be happy to process whatever patches you send. Also, feel free to ask - I'm back home now, so answer latency should be lower now :-) Cheers, Attila. ----- Original Message ----- From: "Alex Dron" <av...@in...> To: <nbs...@li...> Sent: Thursday, August 29, 2002 11:08 PM Subject: [Nbserver-devel] JDK 1.4 > Hi Atilla, > > Which JDK you have used in the February, when you ran test suite? > I'm using 1.4.1-rc-b19, and "ant test" reports failure on TestNioServer: > ===================================================================== > Testsuite: org.szegedi.nioserver.TestNioServer > Tests run: 5, Failures: 4, Errors: 0, Time elapsed: 8.122 sec > > Testcase: testIsHalfDuplex took 2.784 sec > Testcase: testClosingSingleChannel took 2.194 sec > FAILED > expected:<0> but was:<1> > junit.framework.AssertionFailedError: expected:<0> but was:<1> > at > org.szegedi.nioserver.TestNioServer.assertIdleServer(TestNioServer.java:187) > at > org.szegedi.nioserver.TestNioServer.testClosingSingleChannel(TestNioServer.j > ava:106) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 > ) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl > .java:25) > > Testcase: testClosingSingleChannelTestcase: testClosingTwoChannels took > 1.031 sec > FAILED > ===================================================================== > > And I haven't succeeded with your HttpProtocolHandler either. For some > reason, > AbstractPipedProtocolHandler.tryToRead() never got executed. > But I'm able to use basic handler, as you described in the "GettingStarted". > So I believe something changed in Java Runtime since then... > > Also, what is the current status of this project? > Do you plan to work on it somewhere in the future? > > Regards, > Alex > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Nbserver-devel mailing list > Nbs...@li... > https://lists.sourceforge.net/lists/listinfo/nbserver-devel > > > |
|
From: Alex D. <av...@in...> - 2002-08-29 21:10:53
|
Hi Atilla, Which JDK you have used in the February, when you ran test suite? I'm using 1.4.1-rc-b19, and "ant test" reports failure on TestNioServer: ===================================================================== Testsuite: org.szegedi.nioserver.TestNioServer Tests run: 5, Failures: 4, Errors: 0, Time elapsed: 8.122 sec Testcase: testIsHalfDuplex took 2.784 sec Testcase: testClosingSingleChannel took 2.194 sec FAILED expected:<0> but was:<1> junit.framework.AssertionFailedError: expected:<0> but was:<1> at org.szegedi.nioserver.TestNioServer.assertIdleServer(TestNioServer.java:187) at org.szegedi.nioserver.TestNioServer.testClosingSingleChannel(TestNioServer.j ava:106) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) Testcase: testClosingSingleChannelTestcase: testClosingTwoChannels took 1.031 sec FAILED ===================================================================== And I haven't succeeded with your HttpProtocolHandler either. For some reason, AbstractPipedProtocolHandler.tryToRead() never got executed. But I'm able to use basic handler, as you described in the "GettingStarted". So I believe something changed in Java Runtime since then... Also, what is the current status of this project? Do you plan to work on it somewhere in the future? Regards, Alex |
|
From: Attila S. <sze...@fr...> - 2002-04-23 11:48:56
|
the pipe's "auto-transfer" feature is useful when you want to have th=
e pipe
attempt writing to its associated auto-write channel whenever you wri=
te to
the pipe. If you want to transfer a file that is readily available (i=
.e. it
resides on a hard drive instead of being dinamically generated conten=
t)
you'd be better off by writing a protocol handler that opens a channe=
l to
the file, and whenever your protocol handler's "tryToWrite" method is
called, call fileChannel.transferTo(socketChannel, offset, length),
adjusting the offset along the way.
A minimalistic protocol handler that - after a client connects - send=
s over
a file would look like the code below. Note that you needn't use the
nonblocking pipe - this is because nonblocking pipe is for situations=
where
your code generates the data. When the data is readily available in a=
file,
you can send it over more efficiently.
public class FileSendProtocolHandler
implements
ProtocolHandler
{
private final FileChannel fileChannel;
private final SocketChannel socketChannel
private long offset =3D 0;
private final long length;
public FileSendProtocolHandler(File file, SocketChannel socketCha=
nnel)
throws
IOException
{
length =3D file.length();
fileChannel =3D new FileInputStream(file).getChannel();
this.socketChannel =3D socketChannel;
}
public int validOps()
{
return SelectionKey.OP_WRITE;
}
public boolean tryToRead()
throws
IOException
{
return true;
}
public boolean tryToWrite()
throws
IOException
{
boolean endWrite =3D false;
try
{
while(offset < length)
{
int written =3D fileChannel.transferTo(offset, 4096,
socketChannel);
if(written =3D=3D 0) break;
offset +=3D written;
}
endWrite =3D offset =3D=3D length;
}
catch(IOException e)
{
endWrite =3D true;
e.printStackTrace();
throw e;
}
finally
{
if(endWrite)
{
fileChannel.close();
}
}
return endWrite;
}
--
Attila Szegedi
home: http://www.szegedi.org
----- Original Message -----
=46rom: ivanwang
To: sze...@us...
Sent: 2002. =E1prilis 22. 18:05
Subject: question
hi,szegedia
I have study the code of nbserver, but i have some questions about it=
.
I want to send a huge file and I have done as the following:
1) create a GlobalByteBufferPool object--pool
2)according to MEMORY_BLOCKSIZE,separate the huge file into blocks, a=
nd call
pool.putbuffer to be a ByteBuffer list.
3) create a NonblockingPipe object pipe=3D NonblockingPipe(pool)
4)call pipe.setAutoWriteChannel() and pipe.autoTransferTo() to send o=
ut the
huge file.
Is it okay? would you please give me some ideas?
Thank you very much!
ivan
|
|
From: Zombi <zo...@ma...> - 2002-02-27 23:41:29
|
I have used NBIO for a long time, and i'm very satisfied with it, and i've already checked SEDA too. Well.. it's not simple, but i dont think that it's too complex, if it's performs well:-) That architecture allows for the specific program to ignore/reject commands/requests when it's overloaded, and i'm really convinced, that this is the key feature for a scalable server, and when the architecture and not the the protocol implementation have to consider this view point, it's the better. > P.S.: Are you aware that SourceForge mailing lists are set up so that > "Reply" sends a reply to the poster, not to the list? I'm asking since your > letter came to me privately, not through the list. well ... sorry ... i wanted to send to the list, but i didn't take care to check the address ... :) and i just sitting, and wondering why my reply don't come back from the list ... :-) bye Zsombor |
|
From: Attila S. <sze...@fr...> - 2002-02-27 22:36:32
|
----- Original Message ----- From: "Zombi" <zo...@ma...> To: "Attila Szegedi" <sze...@fr...> Sent: Wednesday, February 27, 2002 10:50 PM Subject: Re[2]: [Nbserver-devel] NBServer for "client" side ... > > > Take a look and tell me how do you like it. Note that in the current > > scenario the user has to create the socket channel, but it is OK - he might > > want to set different TCP options on the socket (linger, timeout, nodelay, > > etc.) and I don't want to take away that flexibility. > > Well... your code is much simpler, and easier to use, so I like it :-) > Thx for the credits :-) > Anyway ... what's your future plans about the whole package ? to > create a small and simple web server? or an adapter for > Tomcat/Catalina? Well, it started as my learning ground for non-blocking I/O in Java... I thought it'd be a good idea to write an in-depth "best practices" style article on the topic, so I needed to familiarize myself with it. There really is a generic HTTP handler in the source tree, and with various Adapter implementations, it can be fitted onto Tomcat, or serve as a base for a standalone HTTP server, so there is a goal of creating a non-blocking frontend to Tomcat, indeed. The more I think of it, the more I realize that it has to be refactored heavily. First, selector threads should not run protocol handler code. Instead, they should queue OP_whatever events (in a LinkedList, say) and a separate pool of worker threads should get events from the queue and process them one by one. This decoupling of a connection and worker thread would provide for better work balance between threads, and in the end better throughput (right now, if some protocol handler takes a long time to complete, all other protocol handlers registered with the same selector thread are waiting). Next, there should be some other entity, a thread manager that increases/decreases the number of worker threads as the queue latency grows/decreases. The concept could be expanded toward generic event queues and a thread manager that dynamically allocates event processing threads from faster queues to slower queues. With my thoughts going in that direction, we're starting to suspiciously look like Matt Welsh's SEDA, whose complexity I was trying to avoid... In the end, maybe the guy was right and that's the minimum complexity required for a truly performant NBIO server? I'm devoting some more thinking to it; we'll see. Cheers, Attila. P.S.: Are you aware that SourceForge mailing lists are set up so that "Reply" sends a reply to the poster, not to the list? I'm asking since your letter came to me privately, not through the list. > > bye > Zsombor > > > > |
|
From: Attila S. <sze...@fr...> - 2002-02-26 16:09:32
|
Frankly, I dislike the design. The concept of factories is required for a
server-side of a protocol since the server does not control when a
connection is made - the client establishes the connection, thus the client
determines its creation time. The server is notified of the fact through the
"accept" event, and has to create a protocol handler at that time; thus the
need for a protocol handler factory. On the other hand, the client side
completely controls when is the connection established - it
follows from the program logic. Therefore, client side can directly create
protocol handlers and need not be burdened with complexity of dealing with
factories and connect callbacks. In this spirit, client connecting code
should not be piggybacked on Service.
My proposal instead is to create a NioServer.registerClient method. The
client code would then do something like:
SocketChannel ch = socket.getChannel();
ProtocolHandler handler = new MyProtocolHandler(ch);
server.registerClient(ch, handler);
registerClientProtocolHandler would handle the details of calling connect(),
finishConnect() and friends. Errors could be handler solely within NioServer
code, however there would be need for the protocol handler to get a
notificiation of a
successful connect (i.e. to initialize state that should be only initialized
in case of successful connect). Therefore I propose a new interface:
public interface ClientProtocolHandler
extends
ProtocolHandler
{
public void afterConnect();
}
and in the NioServer:
public void registerClient(SocketAddress addr, SocketChannel channel,
ClientProtocolHandler handler);
The initial changes are already committed to CVS; while this does not
resemble much your original idea, I've credited you as the author on
relevant classes since I've borrowed many ideas (as well as the correct
connect()/finishConnect() method call order). It's not in a new release yet.
Take a look and tell me how do you like it. Note that in the current
scenario the user has to create the socket channel, but it is OK - he might
want to set different TCP options on the socket (linger, timeout, nodelay,
etc.) and I don't want to take away that flexibility.
Cheers,
Attila.
--
Attila Szegedi
home: http://www.szegedi.org
----- Original Message -----
From: "Zombi" <zo...@ma...>
To: <nbs...@li...>
Sent: 2002. február 22. 1:30
Subject: [Nbserver-devel] NBServer for "client" side ...
>
> Hi !
>
> I wrote some code, which helps to use nbserver protocol abstraction,
> from the "client" side, when our program initiate the communication to
> a remote address.
> To use it,we just call :
> service.doConnect( SocketAddress address )
> and (as i hope:-) the NioServer opens a SocketChannel to the address,
> register selectionkey to the NioServer.connectingSelectors, which
> delivers OP_CONNECT message back to Service.connected(SocketChannel)
> which finally call the ProtocolHandlerFactory.createProtocolHandler()
> method, and register the ProtocolHandler with the NioServer ... :-)
> I hope it's works, but i can't test it now ... :-( at least, i'm sure,
> i didn't brake any existing code :-)
> I include the 2 modified source (NioServer.java, Service.java) the
> new ConnectingSelectorLoop.java, and an output of a 'cvs-diff'
> command ...
>
> good bye
> Zsombor
>
|
|
From: G Z. <zo...@ma...> - 2002-02-25 15:06:50
|
ugh ... sorry about my "nearly unreadable" email ...
>This looks promising. I've thought about providing support for
> client-side operations (mostly since lots of servers can have "client"
> behavior as well - just think of proxy servers),
> but haven't yet got around to doing
> it. I'll review the code soon and either incorporate it, or raise
> questions :-)
>
> To somewhat assure yourself that you haven't broken anything, run "ant
> test".
I know, i know :-) i just want to say, that i didn't make any test case
...:-)
One thing, that i forget ... it would be simpler,
if there is a ExtendedProtocolHandlerFactory interface which contains
just one method:
public ProtocolHandler createProtocolHandler (
SocketChannel channel,Object attachment);
and the Service.doConnect become :
public void doConnect( SocketAddress address, Object attachment )
and the 'attachment' object passed through the system, so the
ExtendedProtocolHandlerFactory can associate the SocketChannel with some
user/client specific data.
I think, in the implementation:
Service.java:
private final ProtocolHandlerFactory factory;
Service(...ProtocolHandlerFactory factory ...) {
=09this.factory =3D factory;
should become :
private final ExtendedProtocolHandlerFactory factory;
Service(...ExtendedProtocolHandlerFactory factory ... ) {
this.factory =3D factory;
...
Service(...ProtocolHandlerFactory factory ... ) {
this.factory =3D new ProtocolHandlerWrapper( factory );
where ProtocolHandlerWrapper.java:
class ProtocolHandlerWrapper implements ExtendedProtocolHandler {
=09ProtocolHandler ph;
=09public ProtocolHandler createProtocolHandler(SocketChannel
channel,Object attachment) {
=09=09return ph.createProtocolHandler(channel);
=09}
}
and so on ...
:-) bye Zsombor
--------------------------------------------------
http://www.mailbox.hu - Mert levelezni kell...
|
|
From: G Z. <zo...@ma...> - 2002-02-25 14:51:33
|
Id=E9zet Attila Szegedi level=E9b=F5l >This looks promising. I've thought
about
providing support for > client-side > operations (mostly since lots of
servers
can have "client" behavior as > well - just think of proxy servers),
but
haven't yet got around to doing > it. > I'll review the code soon and
either
incorporate it, or raise questions > :-) > > To somewhat assure yourself
that
you haven't broken anything, run "ant > test". > I know, i know :-) i
just want
to say, that i didn't make any test case ...:-) One thing, that i
forget ... it
would be simpler, if there is a ExtendedProtocolHandlerFactory interface
which
contains just one method: public ProtocolHandler createProtocolHandler
(SocketChannel channel,Object attachment); and the Service.doConnect
become :
public void doConnect( SocketAddress address, Object attachment ) and the
'attachment' object passed through the system, so the
ExtendedProtocolHandlerFactory can associate the SocketChannel with some
user/
client specific data. I think, in the implementation: Service.java:
private
final ProtocolHandlerFactory factory; Service(...ProtocolHandlerFactory
factory
...) { this.factory =3D factory; should become : private final
ExtendedProtocolHandlerFactory factory; Service
(...ExtendedProtocolHandlerFactory factory ... ) { this.factory =3D
factory; ...
Service(...ProtocolHandlerFactory factory ... ) { this.factory =3D new
ProtocolHandlerWrapper( factory ); where ProtocolHandlerWrapper.java:
class
ProtocolHandlerWrapper implement ExtendedProtocolHandler {
ProtocolHandler ph;
public ProtocolHandler createProtocolHandler(SocketChannel channel,Object
attachment) { return ph.createProtocolHandler(channel); } } and that so
on ...
:-) bye Zsombor
--------------------------------------------------
http://www.mailbox.hu - Mert levelezni kell...
|
|
From: Attila S. <sze...@fr...> - 2002-02-25 12:41:20
|
The support for OP_CONNECT can make some great testing code... Just create two server instances (to separate thread pools), then register several thousands of client-side echo protocol handlers with one server and bomb the other with requests. This ought to be fun! -- Attila Szegedi home: http://www.szegedi.org ----- Original Message ----- From: "Zombi" <zo...@ma...> To: <> Sent: 2002. február 22. 1:30 Subject: [Nbserver-devel] NBServer for "client" side ... > > Hi ! > > I wrote some code, which helps to use nbserver protocol abstraction, > from the "client" side, when our program initiate the communication to > a remote address. > To use it,we just call : > service.doConnect( SocketAddress address ) > and (as i hope:-) the NioServer opens a SocketChannel to the address, > register selectionkey to the NioServer.connectingSelectors, which > delivers OP_CONNECT message back to Service.connected(SocketChannel) > which finally call the ProtocolHandlerFactory.createProtocolHandler() > method, and register the ProtocolHandler with the NioServer ... :-) > I hope it's works, but i can't test it now ... :-( at least, i'm sure, > i didn't brake any existing code :-) > I include the 2 modified source (NioServer.java, Service.java) the > new ConnectingSelectorLoop.java, and an output of a 'cvs-diff' > command ... > > good bye > Zsombor > |
|
From: Attila S. <sze...@fr...> - 2002-02-25 08:38:00
|
This looks promising. I've thought about providing support for client-side operations (mostly since lots of servers can have "client" behavior as well - just think of proxy servers), but haven't yet got around to doing it. I'll review the code soon and either incorporate it, or raise questions :-) To somewhat assure yourself that you haven't broken anything, run "ant test". Cheers, Attila. -- Attila Szegedi home: http://www.szegedi.org ----- Original Message ----- From: "Zombi" <zo...@ma...> To: <nbs...@li...> Sent: 2002. február 22. 1:30 Subject: [Nbserver-devel] NBServer for "client" side ... > > Hi ! > > I wrote some code, which helps to use nbserver protocol abstraction, > from the "client" side, when our program initiate the communication to > a remote address. > To use it,we just call : > service.doConnect( SocketAddress address ) > and (as i hope:-) the NioServer opens a SocketChannel to the address, > register selectionkey to the NioServer.connectingSelectors, which > delivers OP_CONNECT message back to Service.connected(SocketChannel) > which finally call the ProtocolHandlerFactory.createProtocolHandler() > method, and register the ProtocolHandler with the NioServer ... :-) > I hope it's works, but i can't test it now ... :-( at least, i'm sure, > i didn't brake any existing code :-) > I include the 2 modified source (NioServer.java, Service.java) the > new ConnectingSelectorLoop.java, and an output of a 'cvs-diff' > command ... > > good bye > Zsombor > |
|
From: Zombi <zo...@ma...> - 2002-02-22 00:30:52
|
Hi !
I wrote some code, which helps to use nbserver protocol abstraction,
from the "client" side, when our program initiate the communication to
a remote address.
To use it,we just call :
service.doConnect( SocketAddress address )
and (as i hope:-) the NioServer opens a SocketChannel to the address,
register selectionkey to the NioServer.connectingSelectors, which
delivers OP_CONNECT message back to Service.connected(SocketChannel)
which finally call the ProtocolHandlerFactory.createProtocolHandler()
method, and register the ProtocolHandler with the NioServer ... :-)
I hope it's works, but i can't test it now ... :-( at least, i'm sure,
i didn't brake any existing code :-)
I include the 2 modified source (NioServer.java, Service.java) the
new ConnectingSelectorLoop.java, and an output of a 'cvs-diff'
command ...
good bye
Zsombor
|
|
From: Attila S. <sze...@fr...> - 2002-02-21 08:09:46
|
Thanks! AFAIK, you're the first poster so it doesn't make much difference that you wrote in Hungarian, since the only other person currently on the list (that is, me) understands it :-) I'd like to see all list traffic happen in English, as this way it and its archives are of most value to community. Much thanks for the log4j adapter, I'll review it and commit it to the CVS as soon as I get some time (presumably on Monday) And yes, you're definitely right - NioServer needs a setLog method. Will add that too. Cheers, Attila. -- Attila Szegedi home: http://www.szegedi.org ----- Original Message ----- From: "Zombi" <zo...@ma...> To: <nbs...@li...> Sent: 2002. február 20. 22:42 Subject: [Nbserver-devel] loging ... Üdv ! Egy minimális észrevétel: kéne a NioServer -be egy public void setLogger(Log log) { this.log = log; } metódus,mellékelten küldök egy wrapper class-t a log4j-hez... tudom, nem túl produktiv megjegyzések ... :) üdv Zsombor ui. nem tudom, hogy hányan vannak a listán, akik nem tudnak magyarul... most könnyebb volt igy :) |
|
From: Zombi <zo...@ma...> - 2002-02-20 21:42:59
|
=DCdv !
Egy minim=E1lis =E9szrev=E9tel: k=E9ne a NioServer -be egy
public void setLogger(Log log) {
this.log =3D log;
}
met=F3dus,mell=E9kelten k=FCld=F6k egy wrapper class-t a log4j-hez...
tudom, nem t=FAl produktiv megjegyz=E9sek ... :)
=FCdv
Zsombor
ui. nem tudom, hogy h=E1nyan vannak a list=E1n, akik nem tudnak
magyarul... most k=F6nnyebb volt igy :)
|