Re: Writing Large Files
On Thu, 2007-07-12 at 14:11 +0900, Trustin Lee wrote: On 7/12/07, Mike Heath [EMAIL PROTECTED] wrote: I've been thinking about this specific issue for a while now for a project I've got coming down the pipe-line. I'll try to add support for writeFile to IoSession in MINA trunk per DIRMINA-218. I should have time this weekend to work on it. Should we provide this operation to all transports? I guess we can't because Serial port communication doesn't work in the same manner. We could make the method available only in SocketSession. We may not be able to provide FileChannel.transferTo support for Serial port communication but it might be a nice convenience method to have anyway. It would be trivial to implement something that sent the contents of a file directly to the Serial port. (Am I assuming too much? I haven't even looked at the Serial port code.) Besides, there's not really any need for zero copy I/O with serial port communications. The fastest serial ports are orders of magnitude slower than the slowest NICs. -Mike
Re: Writing Large Files
On 7/12/07, Mike Heath [EMAIL PROTECTED] wrote: On Thu, 2007-07-12 at 14:11 +0900, Trustin Lee wrote: On 7/12/07, Mike Heath [EMAIL PROTECTED] wrote: I've been thinking about this specific issue for a while now for a project I've got coming down the pipe-line. I'll try to add support for writeFile to IoSession in MINA trunk per DIRMINA-218. I should have time this weekend to work on it. Should we provide this operation to all transports? I guess we can't because Serial port communication doesn't work in the same manner. We could make the method available only in SocketSession. We may not be able to provide FileChannel.transferTo support for Serial port communication but it might be a nice convenience method to have anyway. It would be trivial to implement something that sent the contents of a file directly to the Serial port. (Am I assuming too much? I haven't even looked at the Serial port code.) At least we need to think about possible new transports such as group communication, other JNI-based implementation, and many more. Of course, providing an emulation will be very convenient, but such an emulation can be implemented as a filter like we did for InputStream (i.e. StreamWriteFilter), so I think file transfer method should exist only in SocketSession. Besides, there's not really any need for zero copy I/O with serial port communications. The fastest serial ports are orders of magnitude slower than the slowest NICs. Right! :D Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
suspend/resume sessionOpen
Hi all, I wrote some prototype for streaming mp3 (tcp) to a BARIX device. All works well so far :-) Now I want to get sure that only one stream is send to the device at once. So I thought about pause the new connection if it comes from the same ip and resume it after the old connection was closed. Is it possible todo something like this ? Or should i better use IoSession.setTrafficMask(..) to suspend / resume write to the device ? Any help is welcome. bye Norman
Re: [VOTE] Release Apache MINA 1.0.4 1.1.1
[X]: +1 Release 1.0.4 and 1.1.1 [ ]: 0 Abstain [ ]: -1 Don't release 1.0.4 and 1.1.1 Kaju
Re : [VOTE] Release Apache MINA 1.0.4 1.1.1
[X]: +1 Release 1.0.4 and 1.1.1 [ ]: 0 Abstain [ ]: -1 Don't release 1.0.4 and 1.1.1 TeD - Message d'origine De : Tan Ka Ju [EMAIL PROTECTED] À : dev@mina.apache.org Envoyé le : Jeudi, 12 Juillet 2007, 11h26mn 27s Objet : Re: [VOTE] Release Apache MINA 1.0.4 1.1.1 [X]: +1 Release 1.0.4 and 1.1.1 [ ]: 0 Abstain [ ]: -1 Don't release 1.0.4 and 1.1.1 Kaju ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
RE: [VOTE] Release Apache MINA 1.0.4 1.1.1
[X]: +1 Release 1.0.4 and 1.1.1 [ ]: 0 Abstain [ ]: -1 Don't release 1.0.4 and 1.1.1 L -Eredeti üzenet- Feladó: Dupont jean [mailto:[EMAIL PROTECTED] Küldve: 2007. július 12. 11:56 Címzett: dev@mina.apache.org Tárgy: Re : [VOTE] Release Apache MINA 1.0.4 1.1.1 [X]: +1 Release 1.0.4 and 1.1.1 [ ]: 0 Abstain [ ]: -1 Don't release 1.0.4 and 1.1.1 TeD - Message d'origine De : Tan Ka Ju [EMAIL PROTECTED] À : dev@mina.apache.org Envoyé le : Jeudi, 12 Juillet 2007, 11h26mn 27s Objet : Re: [VOTE] Release Apache MINA 1.0.4 1.1.1 [X]: +1 Release 1.0.4 and 1.1.1 [ ]: 0 Abstain [ ]: -1 Don't release 1.0.4 and 1.1.1 Kaju ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
Re: [VOTE] Release Apache MINA 1.0.4 1.1.1
[X]: +1 Release 1.0.4 and 1.1.1 On 7/12/07, Trustin Lee [EMAIL PROTECTED] wrote: Hi community, Apache MINA project team fixed more than 10 bugs since its last release (1.0.3 and 1.1.0). I'd like to fire a vote for releasing the new version for those who are waiting for more stable releases. This vote is about releasing *two* versions. We usually fire one vote per release, but these two releases have almost identical changelog: http://tinyurl.com/35cm88 Two additional issues were resolved in 1.1 branch: https://issues.apache.org/jira/browse/DIRMINA-384 https://issues.apache.org/jira/browse/DIRMINA-392 DIRMINA-384 is about reverting back the changes made in 1.1 branch to the original code in 1.0 branch, and DIRMINA-392 is too trivial to mention. The snapshot for the release candidates are located here: http://people.apache.org/~trustin/snapshot/ Please feel free to give it a try and cast -1 without hesitation if any problem is found. [ ]: +1 Release 1.0.4 and 1.1.1 [ ]: 0 Abstain [ ]: -1 Don't release 1.0.4 and 1.1.1 Thanks, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6 -- Ersin Er R.A. and Ph.D Student at the Dept. of Computer Eng. in Hacettepe University http://www.cs.hacettepe.edu.tr Committer and PMC Member of The Apache Directory Project http://directory.apache.org
AW: [VOTE] Release Apache MINA 1.0.4 1.1.1
[X]: +1 Release 1.0.4 and 1.1.1 [ ]: 0 Abstain [ ]: -1 Don't release 1.0.4 and 1.1.1 Nikolaus Schlemm Senior Software Developer cellity AG | Stahltwiete 23 | D-22761 Hamburg Vorstand: Nils Weitemeyer (Vorstandsvorsitzender), Sarik Weber Aufsichtsrat: Dr. Sven Claussen (Aufsichtsratsvorsitzender) Handelsregistereintrag: HRB 99023, Amtsgericht Hamburg Umsatzsteuer-Identnummer: DE251404018 BRANDNEU: Mit cellity freeSMS kostenlos SMS versenden! Hier ausprobieren http://www.cellity.com/freesms Oder sofort per Handy runterladen: Sende cellity an 86000
Re: [VOTE] Release Apache MINA 1.0.4 1.1.1
[ X ]: +1 Release 1.0.4 and 1.1.1 [ ]: 0 Abstain [ ]: -1 Don't release 1.0.4 and 1.1.1
[jira] Commented: (DIRMINA-385) SSLFilter starts writing to session before filter chain is complete
[ https://issues.apache.org/jira/browse/DIRMINA-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512149 ] Chris Audley commented on DIRMINA-385: -- Its not like this is a particularly intractable issue. The code could easily be adapted to heed the appropriate events from the session to determine when to start the SSL session. The problem is the filter may be added to the chain after it has processed the sessionOpened event. In this case, there isn't sufficient information for the filter to determine whether or when to start the SSL session. The current approach, just assume the programmer wants the session started immediately, is flawed. It works when the assumption is correct, but it is absolutely not always correct, and you can't possibly state with any credibility how often it will be correct. The better approach is to allow the developer using the filter to explicitly indicate when to start the session. The means is already there, the startSSL(IoSession) method. If the user wants to add the filter late, thats what they should be doing. If it makes you fell better, add a constructor that allows the developer to turn immediate session negotiation on as a convenience, but don't make it a requirement. Your suggestion that I can just add the SSLFilter later doesn't work. As I indicated before, not everyone is using MINA directly. If MINA is hidden from the developer behind another library interface, you can't just assume there will be an opportunity to add additional filters whenever necessary. Please fix this code, it isn't that hard. SSLFilter starts writing to session before filter chain is complete --- Key: DIRMINA-385 URL: https://issues.apache.org/jira/browse/DIRMINA-385 Project: MINA Issue Type: Bug Components: Filter Affects Versions: 1.0.3, 1.1.0 Reporter: Chris Audley Assignee: Trustin Lee Attachments: SSLFilter-1.1.0.patch, SSLFilter-HEAD.patch The SSLFilter starts to write packets to the session as soon as it is added to the filter chain (in onPostAdd). However, this can result in errors if a filter exists or is added before SSLFilter in the processing order. Writing to the session in onPostAdd should be considered breaking the contract between filters and the session. If a filter is added in the processing order before the SSLFilter, but after the SSLFilter has been added, SSLFilter will have already sent some messages that the newly added filter will never have the opportunity to process. Any subsequent SSLFilter messages *will* be processed by the newly added filter, potentially creating inconsistencies. Even if the filter before the SSLFilter in processing order is added before the SSLFilter is added, having SSLFilter send messages in onPostAdd ignores the possibility that the other filter needs to send and/or receive messages before the connection is considered open by later filters in the chain. The specific circumstances of my problem is a web proxy traversal filter that needs to be placed in front of the SSLFilter in order to function correctly. This filter is responsible for sending the CONNECT message to the proxy to open an outside connection before the SSL session is negotiated. With the current behavior of SSLFilter, this is simply not possible. I have created a patch for SSLFilter that moves the code for initiated the handshake to sessionOpened. This works correctly in my situation, but breaks the case where an SSLFilter is added to the chain after the connection is opened. I try to address this by adding a conditional handshake initiation to onPostAdd only if the session is already connected. Unfortunately, the IoSession.isConnected() method only indicates if the session hasn't been closed. What SSLFilter.onPostAdd() needs is a way to determine if the sessionOpened event for the session has been fired. My patches disable the code in onPostAdd() until isConnected or another method is able to provide the necessary information. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DIRMINA-399) Add getter/putter methods for medium ints (24-bit ints)
[ https://issues.apache.org/jira/browse/DIRMINA-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Heath resolved DIRMINA-399. Resolution: Fixed Add getter/putter methods for medium ints (24-bit ints) --- Key: DIRMINA-399 URL: https://issues.apache.org/jira/browse/DIRMINA-399 Project: MINA Issue Type: New Feature Components: Core Affects Versions: 2.0.0-M1 Reporter: Mike Heath Assignee: Mike Heath Priority: Minor Fix For: 2.0.0-M1 Add support for being able to get/put 24-bit ints. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DIRMINA-399) Add getter/putter methods for medium ints (24-bit ints)
Add getter/putter methods for medium ints (24-bit ints) --- Key: DIRMINA-399 URL: https://issues.apache.org/jira/browse/DIRMINA-399 Project: MINA Issue Type: New Feature Components: Core Affects Versions: 2.0.0-M1 Reporter: Mike Heath Assignee: Mike Heath Priority: Minor Fix For: 2.0.0-M1 Add support for being able to get/put 24-bit ints. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
A Couple of Newbie Questions
First let me say that I've ported some parts of my application to Mina so I could perform some tests and I'm quite impressed with the performance! Now I could use some design guidance. In my IoHandler I need to perform a possibly long task (taking seconds to run). My assumption is that I'd want to run this task in a separate thread to avoid blocking the IoProcessor thread. So my question is, how should I run this task? Can I simply callback to the IoHandler and write the response from the callback handler? I would appreciate whatever insight anyone might have. Thanks, -geoff
[jira] Commented: (DIRMINA-385) SSLFilter starts writing to session before filter chain is complete
[ https://issues.apache.org/jira/browse/DIRMINA-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512307 ] Trustin Lee commented on DIRMINA-385: - Then what do you think about adding an option that disables autostart of SSL handshake? Would it resolve your issue? SSLFilter starts writing to session before filter chain is complete --- Key: DIRMINA-385 URL: https://issues.apache.org/jira/browse/DIRMINA-385 Project: MINA Issue Type: Bug Components: Filter Affects Versions: 1.0.3, 1.1.0 Reporter: Chris Audley Assignee: Trustin Lee Attachments: SSLFilter-1.1.0.patch, SSLFilter-HEAD.patch The SSLFilter starts to write packets to the session as soon as it is added to the filter chain (in onPostAdd). However, this can result in errors if a filter exists or is added before SSLFilter in the processing order. Writing to the session in onPostAdd should be considered breaking the contract between filters and the session. If a filter is added in the processing order before the SSLFilter, but after the SSLFilter has been added, SSLFilter will have already sent some messages that the newly added filter will never have the opportunity to process. Any subsequent SSLFilter messages *will* be processed by the newly added filter, potentially creating inconsistencies. Even if the filter before the SSLFilter in processing order is added before the SSLFilter is added, having SSLFilter send messages in onPostAdd ignores the possibility that the other filter needs to send and/or receive messages before the connection is considered open by later filters in the chain. The specific circumstances of my problem is a web proxy traversal filter that needs to be placed in front of the SSLFilter in order to function correctly. This filter is responsible for sending the CONNECT message to the proxy to open an outside connection before the SSL session is negotiated. With the current behavior of SSLFilter, this is simply not possible. I have created a patch for SSLFilter that moves the code for initiated the handshake to sessionOpened. This works correctly in my situation, but breaks the case where an SSLFilter is added to the chain after the connection is opened. I try to address this by adding a conditional handshake initiation to onPostAdd only if the session is already connected. Unfortunately, the IoSession.isConnected() method only indicates if the session hasn't been closed. What SSLFilter.onPostAdd() needs is a way to determine if the sessionOpened event for the session has been fired. My patches disable the code in onPostAdd() until isConnected or another method is able to provide the necessary information. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: MINA Performance and Scalability
That's about 1000 messages per second and well within what we've seen MINA do. Personally, I think MINA will give you no problems but I wouldn't trust MySQL that much (I know, others love it but I've never worked on a project where it performed as well as all the hype suggests). With Hibernate and such, I think your biggest issue will be all the CPU usage. I'd probably go for at least a dual processor, dual core box with 4 gigs of RAM (2g should be allocated to the VM). You might need more CPU with Hibernate in the mix though. As for OS and VM, we've had significantly better performance out of Linux running Java 1.6. Just make sure you increase the file descriptor limit on the box. Good luck! Mike - Original Message - From: Ahmed Al-Obaidy [EMAIL PROTECTED] To: dev@mina.apache.org Sent: Thursday, July 12, 2007 7:05 PM Subject: MINA Performance and Scalability Hi guys... I'm using MINA to build a very loaded GPRS gatway... The server should handle 10K RTU... each will have about 6 TCP messages per minute... every message is about 100 byte The gateway will access MySQL database using Hibernate... Is that too much for MINA... how can I determine my hardware requirements... what is the performance tips ... both for the programming and the configuration... what is the preferred OS and VM for such server? - Don't be flakey. Get Yahoo! Mail for Mobile and always stay connected to friends.
Re: [VOTE] Release Apache MINA 1.0.4 1.1.1
[X ]: +1 Release 1.0.4 and 1.1.1 [ ]: 0 Abstain [ ]: -1 Don't release 1.0.4 and 1.1.1 Thanks. -Adam
Re: A Couple of Newbie Questions
Please read the tutorial first and it is pretty good. http://mina.apache.org/documentation.html#Documentation-Tutorials On 7/13/07, Geoff Cadien [EMAIL PROTECTED] wrote: First let me say that I've ported some parts of my application to Mina so I could perform some tests and I'm quite impressed with the performance! Now I could use some design guidance. In my IoHandler I need to perform a possibly long task (taking seconds to run). My assumption is that I'd want to run this task in a separate thread to avoid blocking the IoProcessor thread. So my question is, how should I run this task? Can I simply callback to the IoHandler and write the response from the callback handler? I would appreciate whatever insight anyone might have. Thanks, -geoff
Re: Tutorial on ProtocolCodecFilter, state and threads
Anyone else have thoughts on this issue? It still seems like a key part of
understanding MINA, and I do think the Maarten's overall excellent and very
helpful tutorial is misleading as it stands on this point.
-Adam
On 6/23/07, Maarten Bosteels [EMAIL PROTECTED] wrote:
On 6/23/07, Adam Fisk [EMAIL PROTECTED] wrote:
Hi Maarten-
Thanks for the link to that discussion thread. It seems like there's
quite
a bit of confusion on this point, though. The thread really didn't
reach
a
common consensus in my reading of it.
Indeed, I want thread-2 to see the changes made by thread-1.
But without synchronization, there is no such guarantee.
Right, but the tutorial snippet says MINA ensures that there will never
be
more than one thread simultaneously executing the decode() function for
the
same IoSession. For that to be true, there's gotta be some
synchronization
somewhere. I decided to dig into the code a little bit for the
1.1.0branch, and indeed ProtocolCodecFilter has the following:
try
{
synchronized( decoderLock )
{
decoder.decode( session, in, decoderOut );
}
}
With the code above, the changes made by thread-1 on the decoder *are
guaranteed to be seen by thread-2*.
Indeed.
Now, I realize this is an
implementation detail of 1.1.0, but the tutorial description above seems
to
be relying on that detail.
The fact that no two threads will execute decode() for the same
IoSession
is not an implementation detail, it's a guarantee of the framework.
The use of syncronized(decoderLock) is an implementation detail, but I
can't
immediately find
an alternative implementation that would cause visibility problems in your
decoder but still
guarantee that no two threads will execute decode() for the same
IoSession
so maybe that paragraph in the tutorial is not totally accurate.
Mina experts, what do you think about it ?
Still, I think it's worth reminding people about the danger of the
visibility problem in general.
So it seems like it should be totally fine to
have a ProtocolCodecFactory that returns a new decoder on each
getDecoder
call (effectively one decoder per session). I still don't see the
disadvantage of doing this.
I guess you're right.
But the difference between one decoder per session or one decoderState per
session is small in my eyes.
It certainly seems less complicated that way!
Thanks again for your patience Maarten. Seems like a key point we
should
all be clear on, so that's why I'm trying to dig a little deeper here.
Right. Let's see what the rest thinks about it.
Maarten
-Adam
help: about the handler
I want to use IBM MQ in my Mina app and I don't know how to use it with Mina handlers. Can anyone help me,thanks. -- View this message in context: http://www.nabble.com/help%3A-about-the-handler-tf4072036.html#a11572574 Sent from the mina dev mailing list archive at Nabble.com.
[jira] Resolved: (DIRMINA-361) Event type and EventType enum
[ https://issues.apache.org/jira/browse/DIRMINA-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trustin Lee resolved DIRMINA-361. - Resolution: Fixed Assignee: Trustin Lee IoEventType, IoEvent, IoFilterEvent were added to trunk. Event type and EventType enum - Key: DIRMINA-361 URL: https://issues.apache.org/jira/browse/DIRMINA-361 Project: MINA Issue Type: New Feature Components: Core Reporter: Trustin Lee Assignee: Trustin Lee Priority: Trivial Fix For: 2.0.0-M1 Filters which queues received events into a collection needs to convert a method invocation into an event object. ExecutorFilter and SSLFilter are good examples, and we might have more than that in the near future. It would be great to extract Event and EventType types from ExecutorFilter and to provide them as a utility. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DIRMINA-400) Selective event processing in ExecutorFilter
Selective event processing in ExecutorFilter Key: DIRMINA-400 URL: https://issues.apache.org/jira/browse/DIRMINA-400 Project: MINA Issue Type: New Feature Components: Filter Reporter: Trustin Lee Assignee: Trustin Lee Fix For: 2.0.0-M1 Previous implementation of ExecutorFilter forwarded only sessionOpened, sessionIdle, sessionClosed, messageReceived and messageSent events to the executor. It often becomes a cause of resource contention for other I/O events such as filterWrite. If we can provide a set of event types that has to be forwarded to the executor, we will be able to apply more sophisticated thread model. The following is a typical usage example: chain.addLast(executor1, new ExecutorFilter()); // Default behavior of ExecutorFilter will be retained. chain.addLast(codec, new ProtocolCodecFilter(...)); chain.addLast(logger, new LoggingFilter()); chain.addLast(executor2, new ExecutorFilter(IoEventType.WRITE, IoEventType.CLOSE)); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DIRMINA-400) Selective event processing in ExecutorFilter
[ https://issues.apache.org/jira/browse/DIRMINA-400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trustin Lee resolved DIRMINA-400. - Resolution: Fixed Done. Please review. Selective event processing in ExecutorFilter Key: DIRMINA-400 URL: https://issues.apache.org/jira/browse/DIRMINA-400 Project: MINA Issue Type: New Feature Components: Filter Reporter: Trustin Lee Assignee: Trustin Lee Fix For: 2.0.0-M1 Previous implementation of ExecutorFilter forwarded only sessionOpened, sessionIdle, sessionClosed, messageReceived and messageSent events to the executor. It often becomes a cause of resource contention for other I/O events such as filterWrite. If we can provide a set of event types that has to be forwarded to the executor, we will be able to apply more sophisticated thread model. The following is a typical usage example: chain.addLast(executor1, new ExecutorFilter()); // Default behavior of ExecutorFilter will be retained. chain.addLast(codec, new ProtocolCodecFilter(...)); chain.addLast(logger, new LoggingFilter()); chain.addLast(executor2, new ExecutorFilter(IoEventType.WRITE, IoEventType.CLOSE)); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Apache MINA 1.0.4 1.1.1
+1 On Thu, 2007-07-12 at 13:54 +0900, Trustin Lee wrote: Hi community, Apache MINA project team fixed more than 10 bugs since its last release (1.0.3 and 1.1.0). I'd like to fire a vote for releasing the new version for those who are waiting for more stable releases. This vote is about releasing *two* versions. We usually fire one vote per release, but these two releases have almost identical changelog: http://tinyurl.com/35cm88 Two additional issues were resolved in 1.1 branch: https://issues.apache.org/jira/browse/DIRMINA-384 https://issues.apache.org/jira/browse/DIRMINA-392 DIRMINA-384 is about reverting back the changes made in 1.1 branch to the original code in 1.0 branch, and DIRMINA-392 is too trivial to mention. The snapshot for the release candidates are located here: http://people.apache.org/~trustin/snapshot/ Please feel free to give it a try and cast -1 without hesitation if any problem is found. [ ]: +1 Release 1.0.4 and 1.1.1 [ ]: 0 Abstain [ ]: -1 Don't release 1.0.4 and 1.1.1 Thanks, Trustin
Re: [VOTE] Release Apache MINA 1.0.4 1.1.1
+1 -- 向秦贤
