Re: messageSent on DemuxingIoHandler
Hi Trustin, I don't think splitting MessageHandler into the two interfaces makes more sense since, at least for me, it is simpler to write both sides in one class as some codes could be duplicated if I split them. So my question is (I could read the code but I feel like asking could be faster ;-) I suppose the one from MessageHandler is the one that would be executed, right ? Since we must defined messageSent function in MessageHandler (mandatory), second it is not mandatory to get it in DemuxingIoHandler, third as you said only one will be called (the one from MessageHandler ?), I would say that probably this function in DemuxingIoHandler is no more necessary and probably confusing with the one from MessageHandler. Except if one can use DemuxingIoHandler with something totally different from MessageHandler (?), I would suggest to remove this function (or mark it as deprecated and pointing to the one in MessageHandler). WDYT ? Frederic Selon Trustin Lee [EMAIL PROTECTED]: Hi Frédéric, On Nov 22, 2007 3:23 AM, Frédéric Brégier [EMAIL PROTECTED] wrote: Hy all, I am on the way to upgrade to last version of trunk... I have one question on DemuxingIoHandler in trunk version. I used DemuxingIoHandler which enables messageSent function to be overload (Invoked when a message written by IoSession.write(Object) is sent out.) I extend MessageHandler for my own message but now it implies the messageSent function (mandatory) too. (Invoked when the specific type of message is received from the specified session. Of course here the manual from API has en error since it is obviously is sent out and not is received) Thanks for pointing out the JavaDoc error. I've just fixed it. But why those two functions ? Is one call after the other or just one only (and if so, which one) ? It depends on situation but only one will be used and the other will be left as blank method for most cases. Thinking of why... well, I was somewhat crazy about creating more interfaces (i.e. replacing MessageHandler with ReceivedMessageHandler and SentMessageHandler). I'm not actually sure if it was a right decision. Please let me know if splitting MessageHandler into the two interfaces makes more sense. Thanks, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: APR Transport is ready to rock!
On Thu, 22 Nov 2007 13:14:47 +0900 Trustin Lee [EMAIL PROTECTED] wrote: On Nov 21, 2007 7:25 PM, Mladen Turk [EMAIL PROTECTED] wrote: Trustin Lee wrote: You might encounter segfault due to a bug of the current implementation because we are using tomcat-native bridge for APR 1.2. Any feed back is welcome! The problem is probably with shutting down the APR library. Tomcat-native is very thin JNI layer for APR, so some precautions must be taken, like implementing shutdown hooks. Yes, I found segfault happens when I try to close socket more than once. :) Right. All native 'objects' are long (actually pointers to the native memory), and the only check that is done is test for zero (NULL). It's the same as if you would call free() twice. The second call will probably core dump cause it references already deallocated memory. So, although harder to program correctly, it offers zero GC, cause no Java objects gets created. The same thing is done within core Java (rt.jar) where actual class implementation takes care of underlaying JNI safety. I was thinking to add the higher API over this thin layer that would allow Java programmers to use it more comfortably, but then extra Java objects would be created, and memory usage as well as GC would rise. So, when using tomcat-native, think as a C not as Java programmer ;) Yes, playing with APR reminded me of the old days. :D You probably mean the good old days ;) Next, the major problem is in threaded environment where you can call global Pool destroy (shutting down the Library) while there is still native call in progress. First thing I would add would be the unlock for Socket.accept (something each Acceptor, not only APR should have) and make sure that Socket.close for the acceptor socket is called even on the CTRL+C. After all native calls are exited, then you can safely call the Library.shutdown Doesn't OS release any resources allocated by a process when the process quits or dies? Do I really need to call Library.shutdown()? Am I missing something? Yes it's supposed to free it, but it's a good idea to unalloc everything when the process quit, it helps to track leaks. Thanks again for the feed back, Trustin Thanks you for revamping it :) Julien
Re: [jira] Created: (DIRMINA-477) Update page about differences between1.x and 2.x
Hi Trustin, Thank you and it is my pleasure if I can help... ;-) I am on the way to migrate so I will let you know, especially after new benchmarks... Frederic Selon Trustin Lee [EMAIL PROTECTED]: Hi Frédéric, On Nov 21, 2007 3:55 AM, Frédéric Brégier [EMAIL PROTECTED] wrote: Hi Trustin and all of you ! I come back to MINA since I feel that MINA 2 is on the way to get out. And I start to look what could be my effort to switch from beta 2 (trunk) from 6 months ago to the current status of trunk. I found some points that might be good to add on the page you started to write. Thanks for the feed back! Your suggestion will hopefully be applied before the first release candidate of 2.0 is released. :) Just a question I've just thinking about : Am I correct if I say Executors.newCachedThreadPool() will no more allows order as it is point in this page of transition in filter ? Of course, page in configuring thread model is no more correct for V2 (as far as I understand). Right. We need to update it. As always, Mina is going better and better... Just I feel like almost a new user to Mina after 6 months without coding Mina stuff, even If I read all the mailing list (great one !). I hope the changes were not too much to follow. How was your experience? Cheers, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: transferring files with Mina
Hi Trustin, (sorry for so much mails ;-) Bloking IO could be problematic so I will probably work on the second option (in fact my initial thoughts). My initial work was based on serialization but I fell like it could be no as efficient as needed, so I need to rethink about it and write a protocol from scratch which will include a MD5 check on each packet (security and check of file transport is the key of this project). Thank a lot Frederic Selon Trustin Lee [EMAIL PROTECTED]: On Nov 22, 2007 3:51 AM, Frédéric Brégier [EMAIL PROTECTED] wrote: Hi all, I feel that the question I post inside my long previous mail should be on a separate one, so here it is again. Sorry for the double post ! Just a question perhaps stupid : I have the idea to perhaps use StreamWriteFilter or StreamIoHandler to transfer some files but with a protocol exchange before and after the file transfer (to verify the access, the rules, to make some pre or post operations, probably making an MD5 check of the transfered file...). I have look at the mailing list but I didn't find a good example of what could be the best but also I didn't understand how to get the file on the other side. That is to say : I saw some code to send file (using StreamWF) but no on receiving this file? I'm surely missing something, obviously... For now.. you can: 1) Use StreamIoHandler, which is not recommended because it makes MINA work like a blocking I/O server. However, it's fine as long as you limit the usage of the StreamIoHandler. 2) Create a chunk message so your decoder generate multiple chunks with begin and end mark. Please let me know if you have any better idea to deal with big files. :) Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: APR Transport is ready to rock!
Trustin Lee wrote: First thing I would add would be the unlock for Socket.accept (something each Acceptor, not only APR should have) and make sure that Socket.close for the acceptor socket is called even on the CTRL+C. After all native calls are exited, then you can safely call the Library.shutdown Doesn't OS release any resources allocated by a process when the process quits or dies? Do I really need to call Library.shutdown()? Am I missing something? Sure OS will release resources. However APR has set of internal cleanup callbacks, so when you call Library.terminate or destroy an Pool, all the object will be gracefully closed by their corresponding callback. The hard close might leave temporary files not removed. Sockets are hard closed instead shutdown thus not sending FIN packets, etc... So, it's always better to do it gracefully rather then depending on the OS. Regards, Mladen
Applet not destroying cleanly
Hi
I am using mina 1.1.3 for communications between an applet and a server
process, using DemuxingProtocolCodecFactory and a DemuxingIoHandler my
implementation is based on the GraphicalCharGen example.
The Problem: Applet Not Destroying cleanly
From reading the forum it would appear that the Executor is not destroying
it threads but since I rely on the in built functionally I do not have a set
of Executors to clean up. Is that my problem? Should I have my own
Executors?
Many Thanks in Advance
Paul
The applet on destroy produces the following trace output.
DEBUG [AnonymousIoService-5] org.apache.mina.filter.executor.ExecutorFilter
- Exiting since queue is empty for /172.18.1.15:8082
Stop Applet
Destroy Applet
INFO [thread applet-com.bae.nads.gui.NADSApplet.class]
com.bae.nads.tcp.client.NadControlClient - [/172.18.1.15:8082] CLOSE
DEBUG [SocketConnectorIoProcessor-0.0]
org.apache.mina.filter.executor.ExecutorFilter - Launching thread for
/172.18.1.15:8082
Applet Destroyed
INFO [AnonymousIoService-6] com.bae.nads.tcp.client.NadControlClient -
[/172.18.1.15:8082] CLOSED
DEBUG [AnonymousIoService-6] com.bae.nads.tcp.client.NadControlClient -
[/172.18.1.15:8082] Session Closed
DEBUG [AnonymousIoService-6] org.apache.mina.filter.executor.ExecutorFilter
- Exiting since queue is empty for /172.18.1.15:8082
Exception in thread AnonymousIoService-1
java.lang.IllegalMonitorStateException
at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(Unknown
Source)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(Unknown
Source)
at java.util.concurrent.locks.ReentrantLock.unlock(Unknown Source)
at java.util.concurrent.LinkedBlockingQueue.take(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
And so on upto 20 repeatations of the same AnonymousIoService-n.
The socket creation code
public NadControlClient(String host, int port,NadsMessageListener
messageListener) {
this.host = host;
this.port = port;
this.messageListener = messageListener;
connector = new SocketConnector();
// Change the worker timeout to 1 second to make the I/O thread
quit soon
// when there's no connection to manage.
connector.setWorkerTimeout(1);
// Configure the service.
cfg = new SocketConnectorConfig();
cfg.setConnectTimeout(CONNECT_TIMEOUT);
cfg.getFilterChain().addLast(codec,
new ProtocolCodecFilter(new
NadsProtocolCodecFactory(false)));
cfg.getFilterChain().addLast(logger, new LoggingFilter());
this.addMessageHandler(SummaryMessage.class, new
SummaryMessageHandler(
this.messageListener));
this.addMessageHandler(AckMessage.class, new AckMessageHandler(
this.messageListener));
this.addMessageHandler(AlarmsMessage.class, new
AlarmsMessageHandler(
this.messageListener));
}
Socket Connection and Disconnection code snippets
public boolean connect() {
boolean result = false;
ConnectFuture connectFuture = connector.connect(new
InetSocketAddress(
host, port), this, cfg);
connectFuture.join(CONNECT_TIMEOUT);
try {
session = connectFuture.getSession();
if (session != null)
result = session.isConnected();
} catch (RuntimeIOException e) {
result = false;
}
return result;
}
public void disconnect() {
connector.setWorkerTimeout(0);
if (session != null) {
CloseFuture future = session.close();
// Wait until the connection is closed
future.join();
session = null;
}
}
--
View this message in context:
http://www.nabble.com/Applet-not-destroying-cleanly-tf4855371s16868.html#a13893939
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.
Re: Applet not destroying cleanly
Well I knew as soon as I posted to the forum I would fix it. (Been trying to
fix it for a day on and off)
For others here the fix is below in bold.
I think the problem is the demo's have not been updated to reflect various
changes in MINA
Trustin
If I get a couple hours I will knock up a simple multiple binary message
client / server example using DemuxingProtocolCodecFactory and a
DemuxingIoHandler.
cheers
Paul
public NadControlClient(String host, int port,
NadsMessageListener messageListener) {
this.host = host;
this.port = port;
this.messageListener = messageListener;
connector = new
SocketConnector(Runtime.getRuntime().availableProcessors()+1,Executors.newCachedThreadPool());
// Change the worker timeout to 1 second to make the I/O thread
quit soon
// when there's no connection to manage.
connector.setWorkerTimeout(1);
// Configure the service.
cfg = new SocketConnectorConfig();
cfg.setThreadModel(ThreadModel.MANUAL);
cfg.setConnectTimeout(CONNECT_TIMEOUT);
cfg.getFilterChain().addLast(codec,
new ProtocolCodecFilter(new
NadsProtocolCodecFactory(false)));
cfg.getFilterChain().addLast(logger, new LoggingFilter());
this.addMessageHandler(SummaryMessage.class, new
SummaryMessageHandler(
this.messageListener));
this.addMessageHandler(AckMessage.class, new AckMessageHandler(
this.messageListener));
this.addMessageHandler(AlarmsMessage.class, new
AlarmsMessageHandler(
this.messageListener));
}
--
View this message in context:
http://www.nabble.com/Applet-not-destroying-cleanly-tf4855371s16868.html#a13896088
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.
Re: transferring files with Mina
Thank you to pointing this discussion, but as I said, no example on client side ? Now about the MD5, I agree with you on compute MD5 locally globally on the file and comparing at the end. However, if I send by packet as Trustin suggested, I come back to my previous idea which was to compute MD5 on each packet, since it will bring some extra functionnalities that could be interesting on large files. For instance it allows to resend only the corrupted packet, restart a transmission from a synchronisation point (like some FTP servers do), ... As it takes some complexity to implement, I was looking at the new functionality of Mina to see if I can use a simpler way... I need to think about a clean way, perhaps something modular that can be reused easily... Frederic Selon Eero Nevalainen [EMAIL PROTECTED]: This discussion brought to mind an earlier one about sending large files http://www.nabble.com/Question-for-transfering-large-file-tf4222408s16868.html#a12011448 What about the option of calculating the MD5 locally and then sending the file and the checksum after that? -Eero Nevalainen [EMAIL PROTECTED] wrote: Hi Trustin, (sorry for so much mails ;-) Bloking IO could be problematic so I will probably work on the second option (in fact my initial thoughts). My initial work was based on serialization but I fell like it could be no as efficient as needed, so I need to rethink about it and write a protocol from scratch which will include a MD5 check on each packet (security and check of file transport is the key of this project). Thank a lot Frederic Selon Trustin Lee [EMAIL PROTECTED]: On Nov 22, 2007 3:51 AM, Frédéric Brégier [EMAIL PROTECTED] wrote: Hi all, I feel that the question I post inside my long previous mail should be on a separate one, so here it is again. Sorry for the double post ! Just a question perhaps stupid : I have the idea to perhaps use StreamWriteFilter or StreamIoHandler to transfer some files but with a protocol exchange before and after the file transfer (to verify the access, the rules, to make some pre or post operations, probably making an MD5 check of the transfered file...). I have look at the mailing list but I didn't find a good example of what could be the best but also I didn't understand how to get the file on the other side. That is to say : I saw some code to send file (using StreamWF) but no on receiving this file? I'm surely missing something, obviously... For now.. you can: 1) Use StreamIoHandler, which is not recommended because it makes MINA work like a blocking I/O server. However, it's fine as long as you limit the usage of the StreamIoHandler. 2) Create a chunk message so your decoder generate multiple chunks with begin and end mark. Please let me know if you have any better idea to deal with big files. :) Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: Problems handling multiple messages in HttpRequestDecoder
Hi Trustin - Thanks for the reply. I updated from trunk, and see all the new filter-codec-http stuff there - I'll use that, for sure. A couple things: 1. The problem that I had was only manifested when I slammed a bunch of GETs in a row - if I added even a tiny (like, 10ms) delay, then there was no problem. So I'm okay for now, and will upgrade to the trunk filter-codec-http stuff when I get a chance. 2. On the maven build from trunk (version 597419), I'm getting test failures - shown below - just in case it's useful. I'm building on Mac OS X. I am new to maven (pretty cool) so I'm just using 'mvn install'. Test failures, so I'm not getting any jars. Results : Failed tests: testSuspendResumeReadWrite(org.apache.mina.transport.socket.nio.SocketTrafficControlTest) testConnectFutureFailureTiming(org.apache.mina.transport.socket.nio.SocketConnectorTest) Tests in error: testExecutorFilterAtTheEnd(org.apache.mina.filter.logging.MdcInjectionFilterTest) testExecutorFilterAtBeginning(org.apache.mina.filter.logging.MdcInjectionFilterTest) testExecutorFilterBeforeProtocol(org.apache.mina.filter.logging.MdcInjectionFilterTest) testMultipleFilters(org.apache.mina.filter.logging.MdcInjectionFilterTest) testTwoExecutorFilters(org.apache.mina.filter.logging.MdcInjectionFilterTest) testOnlyRemoteAddress(org.apache.mina.filter.logging.MdcInjectionFilterTest) Tests run: 123, Failures: 2, Errors: 6, Skipped: 0 Thanks again - very much appreciated. Cheers, parki... --- x8 snip Trustin Lee wrote: On Nov 22, 2007 10:00 AM, parki [EMAIL PROTECTED] wrote: hello! I'm working on an async http server, transferring messages either way (ie. not necessarily request response). I'm basing the code on org.apache.mina.example.httpserver.codec. Everything works well, until I slam a bunch of messages to the server (simple GETs). After some digging around, it's clear that there can be more than one complete message in the IoBuffer when decodable/decode is called. I've tried to rework the HttpRequestDecoder to parse up a possible bunch of messages, but running into many twisty little tunnels - something is telling me I might be going down the rabbit hole. It's looking like the contents of the IoBuffer isn't, well, isn't exactly right, and I start to get off-by-one errors trying to find the location of the next message (if there is more than one) and then things go all to hell. Can anyone shed any light on this? I'd like to recommend you to try mina-filter-codec-http in our trunk instead... :) HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6 -- View this message in context: http://www.nabble.com/Problems-handling-multiple-messages-in-HttpRequestDecoder-tf4853729s16868.html#a13898039 Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.
Another question on transition
Hi Trustin and all ! In the past in trunk (6 month ago) we had : connector.setWorkerTimeout(1); But there is no more such a function now in trunk. Does it have a reason ? So far, it seems I almost finished (still without testing) rewriting my code, so at most 3 days. Thanks to all Frederic
Re: mina-protocol-http-client, AsyncWeb and Jakarta HttpComponents
Hello Trustin, re-inventing the wheel is never a good thing. To me, it sounds reasonable that HttpComponents and MINA cooperate on the client side, at least for the higher level functionality. There is of course some kind of competition on the lower levels, where HttpNIO and MINA address similar functionality. IIRC, Oleg had slightly different design goals for HttpNIO. At the same time, he made sure that MINA can be used to implement the HttpNIO API. So yes, I can see potential for joined efforts: higher-level client functionality like HttpAuth and HttpCookie, and also a low-level component HttpNIO-on-MINA. But since Java NIO is not within my sphere of interest, I have to leave it to others to figure this out (or not). cheers, Roland
Re: Another question on transition
Hello Frederic, try connector.dispose(); http://mina.apache.org/report/trunk/apidocs/org/apache/mina/common/IoService.html#dispose() Maarten On Nov 22, 2007 6:53 PM, Frédéric Brégier [EMAIL PROTECTED] wrote: Hi Trustin and all ! In the past in trunk (6 month ago) we had : connector.setWorkerTimeout(1); But there is no more such a function now in trunk. Does it have a reason ? So far, it seems I almost finished (still without testing) rewriting my code, so at most 3 days. Thanks to all Frederic
Re: Another question on transition
Hi Maarten, Correct me if I am missing something. dispose() seems to release all ressources from the IoService (or connector), so when you don't need anymore the connector. setWorkerTimeout() was intend to release one thread only inside the pool of threads after the specified timeout after no use. I read the code, specially from the 6 months ago trunk version and the current version. It seems that in previous version Mina tries to re-use thread during some time before returning them definitively to the pool (or to nothing since the default pool was NewThreadExecutor). In case of NewThreadExecutor, trying to reuse thread instead of created a new one everyone, I suppose it was the point. Am I correct if I say that, since the underlying pool of thread in the new trunk is a CachedPool, you don't need anymore this function as you rely on the pool management from CachedPool itself, such that Mina don't have to take care of this ? The more I read, the more I found myself (I hope not in wrong direction). It was just a quick question as some users from 1.x will probably ask the question too in a few weeks or so... So probably a new point in the Change from 1.x to 2 web page. Frederic - Original Message - From: Maarten Bosteels Hello Frederic, try connector.dispose(); http://mina.apache.org/report/trunk/apidocs/org/apache/mina/common/IoService.html#dispose() Maarten On Nov 22, 2007 6:53 PM, Frédéric Brégier [EMAIL PROTECTED] wrote: Hi Trustin and all ! In the past in trunk (6 month ago) we had : connector.setWorkerTimeout(1); But there is no more such a function now in trunk. Does it have a reason ? So far, it seems I almost finished (still without testing) rewriting my code, so at most 3 days. Thanks to all Frederic
Re: VMPIPE and IPC
Hi Trustin, What about performance (throughput)comparing VMPipe to Socket? On 11/22/07, Trustin Lee [EMAIL PROTECTED] wrote: Hi Angel, On Nov 20, 2007 9:07 PM, Angel.Figueroa [EMAIL PROTECTED] wrote: IF the two java process are executing on the same java virtual machine, it meaning that they can no establish communication or Only in the context of the same process executing on the same vm.? One Java virtual machine means one process. Do you mean two java application (or thread) in the same virtual machine? If I guessed correctly, yes you can exchange data without opening a socket with in-VM pipe transport. HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: Applet not destroying cleanly
On Nov 22, 2007 9:45 PM, paul bryant [EMAIL PROTECTED] wrote: Well I knew as soon as I posted to the forum I would fix it. (Been trying to fix it for a day on and off) For others here the fix is below in bold. I think the problem is the demo's have not been updated to reflect various changes in MINA Trustin If I get a couple hours I will knock up a simple multiple binary message client / server example using DemuxingProtocolCodecFactory and a DemuxingIoHandler. Great to hear that you fixed your problem before I answer. :) Let me look forward to your contribution then. Thanks, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: APR Transport is ready to rock!
Hi Mladen, On Nov 22, 2007 6:18 PM, Mladen Turk [EMAIL PROTECTED] wrote: Trustin Lee wrote: First thing I would add would be the unlock for Socket.accept (something each Acceptor, not only APR should have) and make sure that Socket.close for the acceptor socket is called even on the CTRL+C. After all native calls are exited, then you can safely call the Library.shutdown Doesn't OS release any resources allocated by a process when the process quits or dies? Do I really need to call Library.shutdown()? Am I missing something? Sure OS will release resources. However APR has set of internal cleanup callbacks, so when you call Library.terminate or destroy an Pool, all the object will be gracefully closed by their corresponding callback. The hard close might leave temporary files not removed. Sockets are hard closed instead shutdown thus not sending FIN packets, etc... So, it's always better to do it gracefully rather then depending on the OS. You are right. My concern is actually the case that user uses tomcat-native in a different module than MINA. Then things can get mixed up so making MINA to register the shutdown hook or call Library.terminate explicitly might be a bad decision. Is there any elegant way to take care of this case (i.e. multi APR-based applications in a container)? Thanks, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: Another question on transition
On Nov 23, 2007 3:06 PM, Trustin Lee [EMAIL PROTECTED] wrote: Hi Frédéric, On Nov 23, 2007 7:53 AM, Frédéric Brégier [EMAIL PROTECTED] wrote: Hi Maarten, Correct me if I am missing something. dispose() seems to release all ressources from the IoService (or connector), so when you don't need anymore the connector. setWorkerTimeout() was intend to release one thread only inside the pool of threads after the specified timeout after no use. I read the code, specially from the 6 months ago trunk version and the current version. It seems that in previous version Mina tries to re-use thread during some time before returning them definitively to the pool (or to nothing since the default pool was NewThreadExecutor). In case of NewThreadExecutor, trying to reuse thread instead of created a new one everyone, I suppose it was the point. Am I correct if I say that, since the underlying pool of thread in the new trunk is a CachedPool, you don't need anymore this function as you rely on the pool management from CachedPool itself, such that Mina don't have to take care of this ? 2.0 still uses NewThreadExecutor for acceptor connector threads, so there's some overhead of spawning a new thread. This becomes a problem when a user tries to request a bunch of connection with bad timing because threads will be spawned for each request. To avoid that situation, I programmed AbstractPollingIoConnector's Worker not to exit until dispose() is called. However, this is waste of thread if you explicitly specified a thread pool, as you pointed out. The solution could be not using NewThreadExecutor but using something different such as a cached thread pool executor. However, we are not able to share the cached thread pool executor among all acceptors and connectors because it means user have to call some global shutdown method to shut down the shared thread pool. Anyways, let me fix the problem by replacing NewThreadExecutor with Executors.newCachedThreadPool(). :) Done. It seems to work fine now. Thanks, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: Boardcast
On Nov 23, 2007 9:21 AM, mat [EMAIL PROTECTED] wrote: How can I implement boardcast in my application before Mina 2.0 releases? Any suggestion? Thanks. IIRC, it's not different from MINA 2.0. Just send some datagram to 255.255.255.255 after setting the broadcast property in session configuration. HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: VMPIPE and IPC
On Nov 23, 2007 9:19 AM, mat [EMAIL PROTECTED] wrote: Hi Trustin, What about performance (throughput)comparing VMPipe to Socket? You can drop ProtocolCodecFilter, which means you save a lot of CPU time. Therefore, the performance will be much better, but not better than the direct invocation. HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: Problems handling multiple messages in HttpRequestDecoder
I've just fixed the failing tests. Thanks for the information! Trustin On Nov 23, 2007 12:03 AM, parki [EMAIL PROTECTED] wrote: Hi Trustin - Thanks for the reply. I updated from trunk, and see all the new filter-codec-http stuff there - I'll use that, for sure. A couple things: 1. The problem that I had was only manifested when I slammed a bunch of GETs in a row - if I added even a tiny (like, 10ms) delay, then there was no problem. So I'm okay for now, and will upgrade to the trunk filter-codec-http stuff when I get a chance. 2. On the maven build from trunk (version 597419), I'm getting test failures - shown below - just in case it's useful. I'm building on Mac OS X. I am new to maven (pretty cool) so I'm just using 'mvn install'. Test failures, so I'm not getting any jars. Results : Failed tests: testSuspendResumeReadWrite(org.apache.mina.transport.socket.nio.SocketTrafficControlTest) testConnectFutureFailureTiming(org.apache.mina.transport.socket.nio.SocketConnectorTest) Tests in error: testExecutorFilterAtTheEnd(org.apache.mina.filter.logging.MdcInjectionFilterTest) testExecutorFilterAtBeginning(org.apache.mina.filter.logging.MdcInjectionFilterTest) testExecutorFilterBeforeProtocol(org.apache.mina.filter.logging.MdcInjectionFilterTest) testMultipleFilters(org.apache.mina.filter.logging.MdcInjectionFilterTest) testTwoExecutorFilters(org.apache.mina.filter.logging.MdcInjectionFilterTest) testOnlyRemoteAddress(org.apache.mina.filter.logging.MdcInjectionFilterTest) Tests run: 123, Failures: 2, Errors: 6, Skipped: 0 Thanks again - very much appreciated. Cheers, parki... --- x8 snip Trustin Lee wrote: On Nov 22, 2007 10:00 AM, parki [EMAIL PROTECTED] wrote: hello! I'm working on an async http server, transferring messages either way (ie. not necessarily request response). I'm basing the code on org.apache.mina.example.httpserver.codec. Everything works well, until I slam a bunch of messages to the server (simple GETs). After some digging around, it's clear that there can be more than one complete message in the IoBuffer when decodable/decode is called. I've tried to rework the HttpRequestDecoder to parse up a possible bunch of messages, but running into many twisty little tunnels - something is telling me I might be going down the rabbit hole. It's looking like the contents of the IoBuffer isn't, well, isn't exactly right, and I start to get off-by-one errors trying to find the location of the next message (if there is more than one) and then things go all to hell. Can anyone shed any light on this? I'd like to recommend you to try mina-filter-codec-http in our trunk instead... :) HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6 -- View this message in context: http://www.nabble.com/Problems-handling-multiple-messages-in-HttpRequestDecoder-tf4853729s16868.html#a13898039 Sent from the Apache MINA Support Forum mailing list archive at Nabble.com. -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: How can I build a polling server with Mina?
Hi Andi, On Nov 22, 2007 8:00 PM, superandi [EMAIL PROTECTED] wrote: Hi there Mina-Pros, before discovering Mina I did the following: I Started a Java ServerSocket to accept connections. I remembered the accepted connection and waited for a new one. At server start i spawned a number of Worker threads that: - checked if data was available FROM each of the sockets FOR my application logic. - checked if data was available FOR one of the sockets FROM my application logic. Thus i put the worker thread in charge of getting data from the socket-logic and vice versa. Then i discovered MINA and I'd like to use it since its tested and stable and works. But can I write a class (extending IoHandlerAdapter???) that not only calls messageReceived when data is available from the Socket but also periodically calls something like shouldIsendSomeMessage that can return an Object to be processed by my protocolFilter or null if nothing is to be sent out. Of course i could start some threads to do exactly this, but i think it might be wiser to use the worker threads that mina already provides for this task. Is this possible at all? Does it make sense? You might want to use sessionIdle event if the message is supposed to be sent only when the session is idle (i.e. no data transmission for a certain amount of time). Otherwise, I'd recommend you to use ScheduledExecutorService. HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: Memory leak in MINA 1.1.4
On Nov 22, 2007 3:08 PM, Matt Phillips [EMAIL PROTECTED] wrote: Trustin Lee wrote: I opened the hprof files you provided in YourKit profiler and it seems like the actual amount of memory the JVM is very small: http://www.nabble.com/file/p13891096/avis-profiler-report.zip avis-profiler-report.zip I often observe JVM increases its total heap size too much even when the application doesn't demand that much. Wouldn't it be such a case? OK, now I'm really confused. Am I reading the output of the jmap -histo output wrong? The output I cited in the original mail seemed to be saying there were 2,192,677 instances of java.util.concurrent.ConcurrentLinkedQueue$Node, taking up 35,082,832 bytes. And 8,285 byte arrays taking up 23,427,664 bytes. Which seems excessive for a server with just 20 connections, to put it mildly. But, as you say, the reports that YourKit generated don't bear this out (although that output is not from the exact same instance as the hprof's, it was taken earlier in my testing). Hmm.. I don't have much experience with jmap histogram. It might be including the objects to be GC'd or that has been GC'd so far. I'm not sure. Do you get OOM btw? Thanks for your help so far, No problem. Please keep up updated to find out any potential problem. :) Thanks, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: Boardcast
Actually I am talking about : broadcast public static List http://java.sun.com/j2se/1.5.0/docs/api/java/util/List.html?is-external=trueWriteFuture http://mina.apache.org/report/trunk/apidocs/org/apache/mina/common/WriteFuture.html *broadcast*(Object http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html?is-external=true message, Collection http://java.sun.com/j2se/1.5.0/docs/api/java/util/Collection.html?is-external=trueIoSession http://mina.apache.org/report/trunk/apidocs/org/apache/mina/common/IoSession.html sessions) in the trunk. On 11/23/07, Trustin Lee [EMAIL PROTECTED] wrote: On Nov 23, 2007 9:21 AM, mat [EMAIL PROTECTED] wrote: How can I implement boardcast in my application before Mina 2.0releases? Any suggestion? Thanks. IIRC, it's not different from MINA 2.0. Just send some datagram to 255.255.255.255 after setting the broadcast property in session configuration. HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Boardcast
How can I implement boardcast in my application before Mina 2.0 releases? Any suggestion? Thanks.
Re: mina-protocol-http-client, AsyncWeb and Jakarta HttpComponents
Hello Roland, Thanks for the response. Let's wait and see how people think about this issue. Probably Jeff will also have something to say. :) Cheers, Trustin On Nov 23, 2007 3:06 AM, Roland Weber [EMAIL PROTECTED] wrote: Hello Trustin, re-inventing the wheel is never a good thing. To me, it sounds reasonable that HttpComponents and MINA cooperate on the client side, at least for the higher level functionality. There is of course some kind of competition on the lower levels, where HttpNIO and MINA address similar functionality. IIRC, Oleg had slightly different design goals for HttpNIO. At the same time, he made sure that MINA can be used to implement the HttpNIO API. So yes, I can see potential for joined efforts: higher-level client functionality like HttpAuth and HttpCookie, and also a low-level component HttpNIO-on-MINA. But since Java NIO is not within my sphere of interest, I have to leave it to others to figure this out (or not). cheers, Roland -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
