Re: Asynchronous timeout/sleep/delay/etc.
It requires another thread. jgenender wrote: > > How is the ScheduledExecutorService a blocking mechanism? > > Jeff > > yz wrote: >> I just started playing around with Mina, and I tried searching the >> archives >> for a discussion about this, but I noticed a glaring lack of any >> asynchronous scheduling of callbacks. I.e., we can't schedule a >> timeout/sleep/delay within this framework. Is this accurate? Is there >> some >> reason why this relatively straightforward and standard feature is not >> available in this framework? >> >> As a workaround, it seems that we must resort to synchronous, blocking >> timeout mechanisms (e.g. ScheduledExecutorService). Is the general >> approach >> here to simply save the IoSession (while inside one of the IoHandler >> callbacks) and use it (a) from other threads (b) at any time in the >> future? >> If this is the case, meaning the IoSession never changes across the >> IoHandler callbacks, then why is IoSession continually passed back into >> those callbacks? >> >> IoSession says it's thread-safe (I assume this implies the thread-safety >> of >> the reactor core as well) but the Filters may not be. How do I tell if a >> particular filter is thread-safe? In particular, I'm interested in >> LoggingFilter and ProtocolCodecFilter with ObjectSerializationCodec, but >> for >> these there's no mention in the docs regarding their thread-safety. >> >> Thanks in advance for your answers. > > -- View this message in context: http://www.nabble.com/Asynchronous-timeout-sleep-delay-etc.-tf4519900s16868.html#a12893885 Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.
Re: Asynchronous timeout/sleep/delay/etc.
How is the ScheduledExecutorService a blocking mechanism? Jeff yz wrote: > I just started playing around with Mina, and I tried searching the archives > for a discussion about this, but I noticed a glaring lack of any > asynchronous scheduling of callbacks. I.e., we can't schedule a > timeout/sleep/delay within this framework. Is this accurate? Is there some > reason why this relatively straightforward and standard feature is not > available in this framework? > > As a workaround, it seems that we must resort to synchronous, blocking > timeout mechanisms (e.g. ScheduledExecutorService). Is the general approach > here to simply save the IoSession (while inside one of the IoHandler > callbacks) and use it (a) from other threads (b) at any time in the future? > If this is the case, meaning the IoSession never changes across the > IoHandler callbacks, then why is IoSession continually passed back into > those callbacks? > > IoSession says it's thread-safe (I assume this implies the thread-safety of > the reactor core as well) but the Filters may not be. How do I tell if a > particular filter is thread-safe? In particular, I'm interested in > LoggingFilter and ProtocolCodecFilter with ObjectSerializationCodec, but for > these there's no mention in the docs regarding their thread-safety. > > Thanks in advance for your answers.
Asynchronous timeout/sleep/delay/etc.
I just started playing around with Mina, and I tried searching the archives for a discussion about this, but I noticed a glaring lack of any asynchronous scheduling of callbacks. I.e., we can't schedule a timeout/sleep/delay within this framework. Is this accurate? Is there some reason why this relatively straightforward and standard feature is not available in this framework? As a workaround, it seems that we must resort to synchronous, blocking timeout mechanisms (e.g. ScheduledExecutorService). Is the general approach here to simply save the IoSession (while inside one of the IoHandler callbacks) and use it (a) from other threads (b) at any time in the future? If this is the case, meaning the IoSession never changes across the IoHandler callbacks, then why is IoSession continually passed back into those callbacks? IoSession says it's thread-safe (I assume this implies the thread-safety of the reactor core as well) but the Filters may not be. How do I tell if a particular filter is thread-safe? In particular, I'm interested in LoggingFilter and ProtocolCodecFilter with ObjectSerializationCodec, but for these there's no mention in the docs regarding their thread-safety. Thanks in advance for your answers. -- View this message in context: http://www.nabble.com/Asynchronous-timeout-sleep-delay-etc.-tf4519900s16868.html#a12893472 Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.
Re: multiple handlers per IoService
No, not yet. It's must to have in 2.0 though. :) Cheers, Trustin On 9/25/07, Mark <[EMAIL PROTECTED]> wrote: > As long as the size of the pool could = 1. > > Has any work been done on this? > > Thanks Trustin. > > -- > ..Cheers > Mark > > On 9/25/07, Trustin Lee <[EMAIL PROTECTED]> wrote: > > > > On 9/25/07, Mark <[EMAIL PROTECTED]> wrote: > > > Wouldn't it make sense to multiplex a Selector across multiple channels > > in > > > order to efficiently manage threads since you can have multiple channels > > > being monitored by one selector. You could have 10 channels, 1 selector > > in > > > the main thread and 1 I/O thread. Currently, 10 channels would mean 10 > > > selectors each in their own thread. > > > > Yes, that's what I am saying. By managing a global pool of selectors > > and I/O processors, we could optimize thread usage. > > > > Cheers, > > Trustin > > -- > > what we call human nature is actually human habit > > -- > > http://gleamynode.net/ > > -- > > PGP Key ID: 0x0255ECA6 > > > -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
What is a best way of decoding variable size records?
Hi, I am new to this forum. I have some code that converts COBOL copybook records, which can have variable length, into Java objects. For some reasons the byte length of the record cannot be passed up front. So my existing code uses blocking I/O (buffered InputStream) and it works pretty well. I have a server around it that was built on top of Apache Phoenix code. The Phoenix project is no longer supported so I've decided to move to Apache MINA which looks pretty cool too. However, I am not sure what is the best way of integrating my code into it. As far as I can see, there are two ways: 1) Implement a subclass of StreamIoHandler and get back to good old blocking I/O. But I can see that experts here recommend not doing so unless absolutely necessary. Also, why Handler and not Filter? 2) Implement a subclass of CumulativeProtocolDecoder that will try to decode message and if there is not enough bytes available yet, return false so that MINA comes back with more data. Well, that seems highly ineffective, especially when working with large records - you have to throw away all the work and redo it again when more data becomes available. Suggestions? Thanks, Andrei -- View this message in context: http://www.nabble.com/What-is-a-best-way-of-decoding-variable-size-records--tf4518931s16868.html#a12890468 Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.
setting up packet forwarding
hi all
I have a need help on the following problem
I have a server application that is sending out UDP packets on a
pre-determined port.
These are to be read and re-transmited on different port
I managed to do this using threads and good old datagram sockets part of
the code is below
How would this mechanism be achieved using MINA .
thanks
private void handlePackets() {
byte[] buffer = new byte[1024];
DatagramPacket readPacket = new DatagramPacket(buffer, buffer.length);
DatagramPacket sendPacket = new DatagramPacket(buffer, buffer.length);
///Message message = new Message();
try {
recieve.receive(readPacket);
sendPacket.setAddress(InetAddress.getByName( "localhost" ) ); //
machine ip
sendPacket.setPort( DESTINATION_PORT ); // machine port
sendPacket.setData(readPacket.getData()); // data to machine ...
recieve.send(sendPacket);
counter++;
System.out.println(">> forwarded "+counter);
} catch (IOException io) {
io.printStackTrace();
}
}
private boolean _flag_ = true;
public void run() {
while( _flag_ ){
handlePackets();
}
}
Re: Problem with slf4j and log4j
http://www.slf4j.org/manual.html On 9/25/07, kwtan <[EMAIL PROTECTED]> wrote: > > I have a big problem using slf4j with log4j! I am not sure which jar to use > in the classpath. How do I log it into a file using log4j properties file. > how do I load the properties file? many questions, I can't find a good > documentation to solve my problem! Mina is lack of documentation! Can > somebody help me, where to find the resources? a simple sample is > appriciated, Thank you. > -- > View this message in context: > http://www.nabble.com/Problem-with-slf4j-and-log4j-tf4517137s16868.html#a12884970 > Sent from the Apache MINA Support Forum mailing list archive at Nabble.com. > > -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Problem with slf4j and log4j
I have a big problem using slf4j with log4j! I am not sure which jar to use in the classpath. How do I log it into a file using log4j properties file. how do I load the properties file? many questions, I can't find a good documentation to solve my problem! Mina is lack of documentation! Can somebody help me, where to find the resources? a simple sample is appriciated, Thank you. -- View this message in context: http://www.nabble.com/Problem-with-slf4j-and-log4j-tf4517137s16868.html#a12884970 Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.
Re: multiple handlers per IoService
As long as the size of the pool could = 1. Has any work been done on this? Thanks Trustin. -- ..Cheers Mark On 9/25/07, Trustin Lee <[EMAIL PROTECTED]> wrote: > > On 9/25/07, Mark <[EMAIL PROTECTED]> wrote: > > Wouldn't it make sense to multiplex a Selector across multiple channels > in > > order to efficiently manage threads since you can have multiple channels > > being monitored by one selector. You could have 10 channels, 1 selector > in > > the main thread and 1 I/O thread. Currently, 10 channels would mean 10 > > selectors each in their own thread. > > Yes, that's what I am saying. By managing a global pool of selectors > and I/O processors, we could optimize thread usage. > > Cheers, > Trustin > -- > what we call human nature is actually human habit > -- > http://gleamynode.net/ > -- > PGP Key ID: 0x0255ECA6 >
Re: multiple handlers per IoService
On 9/25/07, Mark <[EMAIL PROTECTED]> wrote: > Wouldn't it make sense to multiplex a Selector across multiple channels in > order to efficiently manage threads since you can have multiple channels > being monitored by one selector. You could have 10 channels, 1 selector in > the main thread and 1 I/O thread. Currently, 10 channels would mean 10 > selectors each in their own thread. Yes, that's what I am saying. By managing a global pool of selectors and I/O processors, we could optimize thread usage. Cheers, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: multiple handlers per IoService
Wouldn't it make sense to multiplex a Selector across multiple channels in order to efficiently manage threads since you can have multiple channels being monitored by one selector. You could have 10 channels, 1 selector in the main thread and 1 I/O thread. Currently, 10 channels would mean 10 selectors each in their own thread. -- ..Cheers Mark On 9/20/07, Trustin Lee <[EMAIL PROTECTED]> wrote: > > On 9/21/07, Gary Helmling <[EMAIL PROTECTED]> wrote: > > > > > > Mark Webb wrote: > > > > > > I am interested in having one IoAcceptor listen on multiple > ports. This > > > acceptor will have one Selector and based on the incoming > connection/data, > > > the proper handler will be triggered. > > > > This would be pretty useful for me as well. I have a server that will > be > > handling essentially the same data over 2 different protocols on 2 > different > > ports. For each protocol the handling would be slightly different, so a > > separate IoHandlerAdapter on each port would be useful. > > > > This capability seemed to be present in the 1.1.x releases with the: > > SocketAcceptor.bind(SocketAddress, IoHandler, IoServiceConfig) > > > > method (don't know if it worked the way I expected with multiple calls). > > Was this causing problems that were fixed with the current restructuring > in > > the trunk? > > Yes, we redesigned the API for more simplicity. IIRC, we didn't like > the way how threads are managed in MINA (e.g. assumption that one > SocketAcceptor means one acceptor thread). In 2.0, we will introduce > much more efficient thread management built-in, as Mike mentioned > already. No matter how many acceptor or connector instances are > created, the number of I/O threads will be maintained in an optimal > number. > > HTH, > Trustin > -- > what we call human nature is actually human habit > -- > http://gleamynode.net/ > -- > PGP Key ID: 0x0255ECA6 >
