Re: [Poll] Naming style for acronyms
[ ]: All capital [X]: Only the initial letter should be capital I don't like special cases and / or picking the SHIFT key longer than for one letter ;) Regards Michael
Virtual Blocking Channels for Mina Socket Pipe
The code of IoHandler:
public void messageReceived(IoSession session, Object in) throws Exception
{
ChannelMessage response = (ChannelMessage) in;
Factory.getChannelManager().getChannel(response.getChannelId())
.performCallback(response);
}
Re: MDCInjectionFilterTest fails occasionally.
On 9/17/07, Trustin Lee [EMAIL PROTECTED] wrote: On 9/17/07, Maarten Bosteels [EMAIL PROTECTED] wrote: Hi Trustin, On 9/17/07, Trustin Lee [EMAIL PROTECTED] wrote: Hi Maaretn, On 9/17/07, Maarten Bosteels [EMAIL PROTECTED] wrote: I fixed a possible ConcurrentModificationException in the test-case. I hope that was the failure you saw ? I didn't actually check the cause. :) I have run the test-case several times both on linux and Windows XP, and it always succeeded. It passes very well now, but why does this test case take up a lot of CPU and take more than 10 seconds to run? Somewhat odd... On my 2.3 Ghz dual core Windows box it only takes 6,655 seconds :-) And on a 3Ghz single-core Xeon linux box, it takes 12 seconds. Didn't know dual core would make such a difference. Yes, it's one of the slowest tests in mina, I don't really know why. Each of the 6 test-methods starts a SocketAcceptor and makes 2 connections. Although the filter itself is pretty simple, I wanted to test this filter with a real SocketAcceptor and a real ExecutorFilter etc. If you have any suggestions to make it speedier, please let me know. I'll be glad to fix it. Maybe I could re-use the acceptor for all test-methods and just replace the filter-chain but that seems a bit messy. BTW, do we have to manually set the svn properties for every file we add to subversion ? Can't we use default properties on all .java files ? You mean keyword substitution? The following article might be helpful: http://blog.gleamynode.net/2006/12/setting-svnkeyword-property.html Yes, I keep forgetting that this is a client-side setting. I wish it was a repository setting because I have only one ~/.subversion/config file and at work we decided not to enable auto-props. I could create a separate user for MINA development, but that has other disadvantages of course. But thanks for the pointer. Maarten
Re: New name for ByteBuffer?
Rob Butler wrote: No one likes IoBuffer eh.. Honestly it seems like the best name to me. Surely, if you're renaming, it would make sense for this choice to be IOBuffer, unless it's pertaining to the moon of Jupiter, the king of the gods, or one of the other more valid uses ? I'm all for valid naming (personally, I don't have a problem with ByteBuffer - packages are designed for clearing abiguities), but when a word is an Acronym or an Initialism, the letters should always remain capitalised. Michael.
Re: [Poll] Naming style for acronyms
[ ]: All capital [X]: Only the initial letter should be capital I think using all capitals reduces readability. Consider the methods exportHTMLSource() and exportHtmlSource(). It's a lot easier and quicker for the brain to make out the last word in the second method name. Or maybe it's just my brain? ;-) -- Niklas Therning www.spamdrain.net
Re: [Poll] Naming style for acronyms
[X]: All capital [ ]: Only the initial letter should be capital It's English, and that's how english is written. It's how existing classes within the Java API are written, and it's how the vast majority of names were written before framework developers became lazy when implementing autowiring of properties. If you wan't something that's not all upper-case, find a different word that isn't an acronym. Michael.
Re: [Poll] Naming style for acronyms
I agree. But this is something were nobody will think the same indeed. Rodrigo On 9/19/07, Michael Kearns [EMAIL PROTECTED] wrote: [X]: All capital [ ]: Only the initial letter should be capital It's English, and that's how english is written. It's how existing classes within the Java API are written, and it's how the vast majority of names were written before framework developers became lazy when implementing autowiring of properties. If you wan't something that's not all upper-case, find a different word that isn't an acronym. Michael.
Re: [Poll] Naming style for acronyms
Michael Kearns wrote: [X]: All capital [ ]: Only the initial letter should be capital It's English, and that's how english is written. It's how existing classes within the Java API are written, and it's how the vast majority of names were written before framework developers became lazy when implementing autowiring of properties. WellIAmQuiteSureEnglishIsNotNormallyWrittenUsingCamelCase. :-P In fact Sun isn't as consistent in their naming as one may think: Java SE (5.0): java.beans.XMLDecoder java.net.HttpRetryException javax.net.ssl.HttpsURLConnection java.net.HttpURLConnection javax.print.attribute.standard.PrinterURI javax.print.attribute.standard.ReferenceUriSchemesSupported (these are my favourite ones ;-) ) javax.sql.rowset.spi.XmlWriter.writeXML(...) javax.sql.rowset.spi.XmlReader.readXML(...) Java EE (1.4): javax.enterprise.deploy.model.J2eeApplicationObject javax.servlet.jsp.JspContext javax.servlet.jsp.JspWriter So they don't seem to be able to decide whether it should be Xml or XML, URI or Uri. They always seem to use HTML, Http and Jsp. :-) -- Niklas Therning www.spamdrain.net
Re: [Poll] Naming style for acronyms
Niklas Therning wrote: Michael Kearns wrote: [X]: All capital [ ]: Only the initial letter should be capital It's English, and that's how english is written. It's how existing classes within the Java API are written, and it's how the vast majority of names were written before framework developers became lazy when implementing autowiring of properties. WellIAmQuiteSureEnglishIsNotNormallyWrittenUsingCamelCase. :-P That's because whitespace is more important in full English prose ;) In fact Sun isn't as consistent in their naming as one may think: Java SE (5.0): java.beans.XMLDecoder java.net.HttpRetryException javax.net.ssl.HttpsURLConnection java.net.HttpURLConnection javax.print.attribute.standard.PrinterURI javax.print.attribute.standard.ReferenceUriSchemesSupported (these are my favourite ones ;-) ) javax.sql.rowset.spi.XmlWriter.writeXML(...) javax.sql.rowset.spi.XmlReader.readXML(...) Java EE (1.4): javax.enterprise.deploy.model.J2eeApplicationObject javax.servlet.jsp.JspContext javax.servlet.jsp.JspWriter So they don't seem to be able to decide whether it should be Xml or XML, URI or Uri. They always seem to use HTML, Http and Jsp. :-) Oh, I agree, even if in general it's the later extensions (javax.) that break the naming conventions more, but that's down to Sun getting more lax in enforcing naming standards - A good testcase is actually the java.net.HttpURLConnection This is a very tricky situation, because HTTPURLConnection is very unreadable. However a far simpler solution is to make the class URLConnection in an http sub-package (and before you start, package standards of all lower case should definitely override Acronym 'upper-case-ness'). Because naming is so inconsistent across software, I think it's easier to stick to Acronyms being consistent with their native language structure, so it's obvious what they are. Their most recognised form is their upper case presentation. If it's causing problems with the classname, just think of a more appropriate classname. Most style guides recommend avoiding Acronyms wherever possible for this very reason. Whichever decision is taken, does it mean the entire source codebase is going to be refactored to the new standard ? Consistency is far more important than which approach is taken. Michael.
Re: [Poll] Naming style for acronyms
About SUN (Sun ? :) inconstistant naming, just remember that as they are porviding APIs (Apis ? :), it's impossinle for them to rename a wrong class/metod as soon as it has made its way to the public. Remember the Hashtable class ... -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: New name for ByteBuffer?
Well... we already made sure most people prefer IoBuffer to IOBuffer. This thread is about what word should come before 'Buffer'. Trustin On 9/19/07, Michael Kearns [EMAIL PROTECTED] wrote: Rob Butler wrote: No one likes IoBuffer eh.. Honestly it seems like the best name to me. Surely, if you're renaming, it would make sense for this choice to be IOBuffer, unless it's pertaining to the moon of Jupiter, the king of the gods, or one of the other more valid uses ? I'm all for valid naming (personally, I don't have a problem with ByteBuffer - packages are designed for clearing abiguities), but when a word is an Acronym or an Initialism, the letters should always remain capitalised. Michael. -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: New name for ByteBuffer?
s/but if this turn out/but if this doesn't turn out/ On 9/19/07, Rodrigo Madera [EMAIL PROTECTED] wrote: I don't mean to be a show stopper but if this turn out into an official poll this will go on and on forever. The faster the code is updated the better. Also an immediate release afterwards would be a great idea. Yours, Rodrigo On 9/19/07, Michael Kearns [EMAIL PROTECTED] wrote: Yes, apologies Trustin - I found the Acronym poll after I posted. I don't think you need to rename the class at all, as the packages will distinguish any ambiguity, and the current name describes exactly what it is: A buffer of bytes. Prepending Io (IO) is redundant in my eyes, as you don't use a buffer for anything else other than input or output (not necessarily comms scope of course). The only other name that I could think of was ExpandableByteBuffer as it does auto-grow if necessary, but even this seems a bit of overkill. I tend to look at class names to describe exactly what they are, and for package names to describe the scope or context. If you do change ByteBuffer, will you also be changing AbstractByteBuffer ? HTH, Michael. Trustin Lee wrote: Well... we already made sure most people prefer IoBuffer to IOBuffer. This thread is about what word should come before 'Buffer'. Trustin On 9/19/07, Michael Kearns [EMAIL PROTECTED] wrote: Rob Butler wrote: No one likes IoBuffer eh.. Honestly it seems like the best name to me. Surely, if you're renaming, it would make sense for this choice to be IOBuffer, unless it's pertaining to the moon of Jupiter, the king of the gods, or one of the other more valid uses ? I'm all for valid naming (personally, I don't have a problem with ByteBuffer - packages are designed for clearing abiguities), but when a word is an Acronym or an Initialism, the letters should always remain capitalised. Michael.
Re: New name for ByteBuffer?
I don't mean to be a show stopper but if this turn out into an official poll this will go on and on forever. The faster the code is updated the better. Also an immediate release afterwards would be a great idea. Yours, Rodrigo On 9/19/07, Michael Kearns [EMAIL PROTECTED] wrote: Yes, apologies Trustin - I found the Acronym poll after I posted. I don't think you need to rename the class at all, as the packages will distinguish any ambiguity, and the current name describes exactly what it is: A buffer of bytes. Prepending Io (IO) is redundant in my eyes, as you don't use a buffer for anything else other than input or output (not necessarily comms scope of course). The only other name that I could think of was ExpandableByteBuffer as it does auto-grow if necessary, but even this seems a bit of overkill. I tend to look at class names to describe exactly what they are, and for package names to describe the scope or context. If you do change ByteBuffer, will you also be changing AbstractByteBuffer ? HTH, Michael. Trustin Lee wrote: Well... we already made sure most people prefer IoBuffer to IOBuffer. This thread is about what word should come before 'Buffer'. Trustin On 9/19/07, Michael Kearns [EMAIL PROTECTED] wrote: Rob Butler wrote: No one likes IoBuffer eh.. Honestly it seems like the best name to me. Surely, if you're renaming, it would make sense for this choice to be IOBuffer, unless it's pertaining to the moon of Jupiter, the king of the gods, or one of the other more valid uses ? I'm all for valid naming (personally, I don't have a problem with ByteBuffer - packages are designed for clearing abiguities), but when a word is an Acronym or an Initialism, the letters should always remain capitalised. Michael.
Re: New name for ByteBuffer?
I will fire the vote soon. I just can't right now because I'm pretty busy preparing for a trip. Please don't stop brain-storming until then! :D Trustin On 9/19/07, Rodrigo Madera [EMAIL PROTECTED] wrote: I don't mean to be a show stopper but if this turn out into an official poll this will go on and on forever. The faster the code is updated the better. Also an immediate release afterwards would be a great idea. Yours, Rodrigo On 9/19/07, Michael Kearns [EMAIL PROTECTED] wrote: Yes, apologies Trustin - I found the Acronym poll after I posted. I don't think you need to rename the class at all, as the packages will distinguish any ambiguity, and the current name describes exactly what it is: A buffer of bytes. Prepending Io (IO) is redundant in my eyes, as you don't use a buffer for anything else other than input or output (not necessarily comms scope of course). The only other name that I could think of was ExpandableByteBuffer as it does auto-grow if necessary, but even this seems a bit of overkill. I tend to look at class names to describe exactly what they are, and for package names to describe the scope or context. If you do change ByteBuffer, will you also be changing AbstractByteBuffer ? HTH, Michael. Trustin Lee wrote: Well... we already made sure most people prefer IoBuffer to IOBuffer. This thread is about what word should come before 'Buffer'. Trustin On 9/19/07, Michael Kearns [EMAIL PROTECTED] wrote: Rob Butler wrote: No one likes IoBuffer eh.. Honestly it seems like the best name to me. Surely, if you're renaming, it would make sense for this choice to be IOBuffer, unless it's pertaining to the moon of Jupiter, the king of the gods, or one of the other more valid uses ? I'm all for valid naming (personally, I don't have a problem with ByteBuffer - packages are designed for clearing abiguities), but when a word is an Acronym or an Initialism, the letters should always remain capitalised. Michael. -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: http server for Mina today.
Hi Jason The JIRA is https://issues.apache.org/jira/browse/DIRMINA-353 The last comment is waiting Apache members to fill the IP clearance form directly into the incubator web site and import the source code... On 9/13/07, Mark [EMAIL PROTECTED] wrote: ASyncWeb has not been migrated in yet. There is a JIRA entry however. -- ..Cheers Mark On 9/13/07, Jason Ish [EMAIL PROTECTED] wrote: Hello.. We have a server application built on Mina and are in need of an embedded web server to provide a basic debugging UI as well as a web based API (rest like today, soap is in our future). What are the options today? I know we can embed Tomcat, Jetty, etc. in our app (and have done so for experimentation), but that seems like overkill. Is asyncweb ready? If so, which version of Mina should we be using? We are currently using 1.1.2, but since our app isn't in production yet, moving to trunk would not be a big problem. Thanks for any info. -- Hez
Re: New name for ByteBuffer?
Do I have to change my current source code using ByteBuffer? On 9/19/07, Trustin Lee [EMAIL PROTECTED] wrote: I will fire the vote soon. I just can't right now because I'm pretty busy preparing for a trip. Please don't stop brain-storming until then! :D Trustin On 9/19/07, Rodrigo Madera [EMAIL PROTECTED] wrote: I don't mean to be a show stopper but if this turn out into an official poll this will go on and on forever. The faster the code is updated the better. Also an immediate release afterwards would be a great idea. Yours, Rodrigo On 9/19/07, Michael Kearns [EMAIL PROTECTED] wrote: Yes, apologies Trustin - I found the Acronym poll after I posted. I don't think you need to rename the class at all, as the packages will distinguish any ambiguity, and the current name describes exactly what it is: A buffer of bytes. Prepending Io (IO) is redundant in my eyes, as you don't use a buffer for anything else other than input or output (not necessarily comms scope of course). The only other name that I could think of was ExpandableByteBuffer as it does auto-grow if necessary, but even this seems a bit of overkill. I tend to look at class names to describe exactly what they are, and for package names to describe the scope or context. If you do change ByteBuffer, will you also be changing AbstractByteBuffer ? HTH, Michael. Trustin Lee wrote: Well... we already made sure most people prefer IoBuffer to IOBuffer. This thread is about what word should come before 'Buffer'. Trustin On 9/19/07, Michael Kearns [EMAIL PROTECTED] wrote: Rob Butler wrote: No one likes IoBuffer eh.. Honestly it seems like the best name to me. Surely, if you're renaming, it would make sense for this choice to be IOBuffer, unless it's pertaining to the moon of Jupiter, the king of the gods, or one of the other more valid uses ? I'm all for valid naming (personally, I don't have a problem with ByteBuffer - packages are designed for clearing abiguities), but when a word is an Acronym or an Initialism, the letters should always remain capitalised. Michael. -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
multiple handlers per IoService
Can this be done with MINA now? I would like to put together a framework that will have one Acceptor and register multiple IoHandlerApapters each processing different types of data. -- ..Cheers Mark
Re: MINA for HTTP
If you are using the trunk, check out the protocol-http-server and filter-codec-http subprojects. -- ..Cheers Mark On 9/19/07, Deepak J [EMAIL PROTECTED] wrote: Hi, I am trying to run a MINA HTTP server using the encoder/decoder provided in src/main/java/org/apache/mina/example/httpserver/codec . I noticed that some HTTP POSTs are causing the connection to hang. This never happens when content is just text but happens for many image/jpegs. Subsequently I noticed package.html which says A HTTP server implemented with protocol codec (needs more work). Is the problem I am facing expected? Should I consider using ASyncWeb? -- View this message in context: http://www.nabble.com/MINA-for-HTTP-tf4481259s16868.html#a12778286 Sent from the Apache MINA Support Forum mailing list archive at Nabble.com .
Re: New name for ByteBuffer?
+1 IoBuffer Based on that I agree IoBuffer does make the most sense. I saw this shortly before my last post and it didn't have enough time to sink in, but it has grown on me and would fit with the naming scheme much better than DataBuffer. And if some feel that IoBuffer isn't descriptive enough we could always make it IoDataBuffer and get the best of both. Rich Cameron Taggart wrote: I like IoBuffer. Look at the documentation... http://mina.apache.org/documentation.html The basic constructs are: * ByteBuffer * IoService * IoHandler * IoFilter * IoFuture Which one doesn't fit? Cameron On 9/18/07, Rob Butler [EMAIL PROTECTED] wrote: No one likes IoBuffer eh.. Honestly it seems like the best name to me. - Original Message From: Jeroen Brattinga [EMAIL PROTECTED] To: dev@mina.apache.org Sent: Tuesday, September 18, 2007 12:04:14 PM Subject: Re: New name for ByteBuffer? What about IoDataBuffer? Jeroen Brattinga Richard Wallace wrote: +0 DataBuffer I also agree with the argument against using ByteBuffer in the name, unless we actually change it to subclass the Java ByteBuffer. My vote is slightly in favor of DataBuffer, but it still doesn't sound/feel quite right to me. But I can't think of anything else at the moment and I think it's the best of what's been suggested so far. Rich Rodrigo Madera wrote: I agree with the comment of not suffixing with ByteBuffer since it incorrectly suggests that it's a subclass of the Java standard. I don't think just Buffer would be good because of the single word, which would normally describe an interface. So that's why I voted to something simple as xxxBuffer, which in this case was DataBuffer as Trustin suggested. Regards, Rodrigo On 9/18/07, Niklas Therning [EMAIL PROTECTED] wrote: Trustin Lee wrote: Hi folks, It is often confusing to discriminate MINA ByteBuffer and NIO ByteBuffer. Do we need renaming? I didn't have much difficulties actually because most Java code doesn't use both types at the same time. There was an opinion about renaming it to MinaByteBuffer, but I don't think it's the best name available for us. I think DataBuffer, ExtendedByteBuffer, ExtendedBuffer or just Buffer might also be a candidate. There's Buffer in NIO, too, but nobody uses that class directly. I'd like to find the best name; short and not confusing one. Please don't hesitate to respond to this message with your idea so we can find out the best alternative. Trustin Since MINA's ByteBuffer doesn't inherit from java.nio.ByteBuffer I think the names ending in ByteBuffer (especially ExtendedByteBuffer) could be confusing. I think I prefer just calling it Buffer. Or maybe OctetBuffer? According to Wikipedia (http://en.wikipedia.org/wiki/Octet_%28computing%29): Octet, with the only exception noted below, always refers to an entity having exactly eight bits. As such, it is often used where the term byte might be ambiguous. For that reason, computer networking standards almost exclusively use octet. Also In France, French Canada and Romania, the word octet usually means byte This would make all the French and Romainian MINA users happy! :-) -- Niklas Therning www.spamdrain.net Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online. http://smallbusiness.yahoo.com/webhosting
Re: slightly OT: how to write an NIO provider
Hi, I just committed it, it's compiling, a bit working, but it's not really for production usage (or any usage actually :D).Trustin is going to refactor AbstractIoProcessor The APR goal is to be portable on Unix and non Unix OSes, so there is no Unix Domain socket :( Perhaps a great idea whould be a to produce IOPrcessor working with a homemade library using epoll for achieving great perfs on linux for TCP, UDP, files, serial, Unix Domain Socket, Audio, pipes , whatever I/O using a file descriptor :) Or if APR perfs are goods, adding Unix Domain support to APR. Julien On Wed, 19 Sep 2007 10:51:31 -0400 Mark [EMAIL PROTECTED] wrote: Julien, I just saw that the APR code you wrote is in the trunk. Let me know if you want to try and get it to support Unix Domain Sockets if it does not already. Thanks. On 9/14/07, Julien Vermillard [EMAIL PROTECTED] wrote: On Thu, 13 Sep 2007 13:02:25 -0400 Mark [EMAIL PROTECTED] wrote: I am looking to write a provider that performs NIO on a Unix Domain Socket. This would be used to communicate between JVMs on the same box and do it in a way that is faster than TCP. Hi Mark, My APR based connector is starting purring. TCP UDP are supported (I think SCTP too but I made no test). Perhaps I can force/modify APR for supporting Unix domain socket. Unix socket can be very usefull too for communication between a C prog and a Java one, but I'm not sure nowadays loopback UDP is really slower than Unix sockets. Julien
Re: slightly OT: how to write an NIO provider
sounds great! I will keep my eye on this project for future updates and will revisit this soon. -- ..Cheers Mark On 9/19/07, Julien Vermillard [EMAIL PROTECTED] wrote: Hi, I just committed it, it's compiling, a bit working, but it's not really for production usage (or any usage actually :D).Trustin is going to refactor AbstractIoProcessor The APR goal is to be portable on Unix and non Unix OSes, so there is no Unix Domain socket :( Perhaps a great idea whould be a to produce IOPrcessor working with a homemade library using epoll for achieving great perfs on linux for TCP, UDP, files, serial, Unix Domain Socket, Audio, pipes , whatever I/O using a file descriptor :) Or if APR perfs are goods, adding Unix Domain support to APR. Julien On Wed, 19 Sep 2007 10:51:31 -0400 Mark [EMAIL PROTECTED] wrote: Julien, I just saw that the APR code you wrote is in the trunk. Let me know if you want to try and get it to support Unix Domain Sockets if it does not already. Thanks. On 9/14/07, Julien Vermillard [EMAIL PROTECTED] wrote: On Thu, 13 Sep 2007 13:02:25 -0400 Mark [EMAIL PROTECTED] wrote: I am looking to write a provider that performs NIO on a Unix Domain Socket. This would be used to communicate between JVMs on the same box and do it in a way that is faster than TCP. Hi Mark, My APR based connector is starting purring. TCP UDP are supported (I think SCTP too but I made no test). Perhaps I can force/modify APR for supporting Unix domain socket. Unix socket can be very usefull too for communication between a C prog and a Java one, but I'm not sure nowadays loopback UDP is really slower than Unix sockets. Julien
Re: New name for ByteBuffer?
No, your code will automatically notice this by reading Google and change itself accordingly =o) Just kidding. Yes, you will need to update it. Regards, Rodrigo On 9/19/07, mat [EMAIL PROTECTED] wrote: Do I have to change my current source code using ByteBuffer? On 9/19/07, Trustin Lee [EMAIL PROTECTED] wrote: I will fire the vote soon. I just can't right now because I'm pretty busy preparing for a trip. Please don't stop brain-storming until then! :D Trustin On 9/19/07, Rodrigo Madera [EMAIL PROTECTED] wrote: I don't mean to be a show stopper but if this turn out into an official poll this will go on and on forever. The faster the code is updated the better. Also an immediate release afterwards would be a great idea. Yours, Rodrigo On 9/19/07, Michael Kearns [EMAIL PROTECTED] wrote: Yes, apologies Trustin - I found the Acronym poll after I posted. I don't think you need to rename the class at all, as the packages will distinguish any ambiguity, and the current name describes exactly what it is: A buffer of bytes. Prepending Io (IO) is redundant in my eyes, as you don't use a buffer for anything else other than input or output (not necessarily comms scope of course). The only other name that I could think of was ExpandableByteBuffer as it does auto-grow if necessary, but even this seems a bit of overkill. I tend to look at class names to describe exactly what they are, and for package names to describe the scope or context. If you do change ByteBuffer, will you also be changing AbstractByteBuffer ? HTH, Michael. Trustin Lee wrote: Well... we already made sure most people prefer IoBuffer to IOBuffer. This thread is about what word should come before 'Buffer'. Trustin On 9/19/07, Michael Kearns [EMAIL PROTECTED] wrote: Rob Butler wrote: No one likes IoBuffer eh.. Honestly it seems like the best name to me. Surely, if you're renaming, it would make sense for this choice to be IOBuffer, unless it's pertaining to the moon of Jupiter, the king of the gods, or one of the other more valid uses ? I'm all for valid naming (personally, I don't have a problem with ByteBuffer - packages are designed for clearing abiguities), but when a word is an Acronym or an Initialism, the letters should always remain capitalised. Michael. -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: New name for ByteBuffer?
mat wrote: Do I have to change my current source code using ByteBuffer? This name change will only affect MINA 2.0 (MINA trunk in subversion). So you would have to change your code if you move to MINA 2.0. The MINA 1.x APIs won't change. -Mike
[jira] Created: (DIRMINA-441) SocketConnection cannot be manually closed (for v1.1.2)
SocketConnection cannot be manually closed (for v1.1.2) --- Key: DIRMINA-441 URL: https://issues.apache.org/jira/browse/DIRMINA-441 Project: MINA Issue Type: Bug Components: Core Affects Versions: 1.1.2 Reporter: Jeff Genender Fix For: 1.1.3 The SocketConnection cannot be closed. Currently it will wait a certain amount of timeout as specified by the worker timeout to shut down the connection. This can result in OOM and hanging clients until thee timeouts occur. Mina should allow the SocketConnection to be closed manually if the connection is known to be completed. Patch is attached. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Test failures on trunk?
I noticed the following today: Failed tests: testSuspendResumeReadWrite(org.apache.mina.transport.socket.nio.DatagramTrafficControlTest) Does anyone know when that may get fixed? Thanks, Jeff
Re: multiple handlers per IoService
It would also be nice if we had some way of sharing thread pools and selectors between Acceptors and Connectors. It would take quite a bit of refactoring but it may be nice feature to have for those of us building proxies that have multiple acceptors and multiple connectors working in conjunction. -Mike Mark wrote: Just to clarify this further, because I don't think I described what I wanted to properly. 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. So for each port, you will have an associated handler but this will all go through a common Selector. The goal here is to keep the number of threads at a minimum. I am building a system that may be listening on many different ports and each port will get different types of data. The number of ports could be over 20. Taking a quick look at the current SocketAcceptor, this would be alot of work.
[jira] Updated: (DIRMINA-441) SocketConnection cannot be manually closed (for v1.1.2)
[ https://issues.apache.org/jira/browse/DIRMINA-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Genender updated DIRMINA-441: -- Attachment: DIRMINA-441-jgenender.patch SocketConnection cannot be manually closed (for v1.1.2) --- Key: DIRMINA-441 URL: https://issues.apache.org/jira/browse/DIRMINA-441 Project: MINA Issue Type: Bug Components: Core Affects Versions: 1.1.2 Reporter: Jeff Genender Fix For: 1.1.3 Attachments: DIRMINA-441-jgenender.patch The SocketConnection cannot be closed. Currently it will wait a certain amount of timeout as specified by the worker timeout to shut down the connection. This can result in OOM and hanging clients until thee timeouts occur. Mina should allow the SocketConnection to be closed manually if the connection is known to be completed. Patch is attached. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-441) SocketConnection cannot be manually closed (for v1.1.2)
[ https://issues.apache.org/jira/browse/DIRMINA-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Genender updated DIRMINA-441: -- Attachment: DIRMINA-441-jgenender.patch This patch is better and its thread safe. SocketConnection cannot be manually closed (for v1.1.2) --- Key: DIRMINA-441 URL: https://issues.apache.org/jira/browse/DIRMINA-441 Project: MINA Issue Type: Bug Components: Core Affects Versions: 1.1.2 Reporter: Jeff Genender Fix For: 1.1.3 Attachments: DIRMINA-441-jgenender.patch, DIRMINA-441-jgenender.patch The SocketConnection cannot be closed. Currently it will wait a certain amount of timeout as specified by the worker timeout to shut down the connection. This can result in OOM and hanging clients until thee timeouts occur. Mina should allow the SocketConnection to be closed manually if the connection is known to be completed. Patch is attached. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
1 more reveive packet
Hello. I'm using MINA 1.1.2.
I use TextLineCodecFactory like this.
cfg.getFilterChain().addLast( codec, new ProtocolCodecFilter( new
TextLineCodecFactory( Charset.forName( EUC-KR ) ) ) );
and messageReceived() in SessionHandler is like this.
public void messageReceived(IoSession session, Object message) throws
Exception {
logger.debug( Suprema message received );
// blah blah code
}
and client's send routine is like this.
char sBufSend[ 512 ] = ;
sprintf( sBufSend, S:REGUSER2:DONE:%d\n, r_user_idx );
if( send( scHost, sBufSend, strlen( sBufSend ), 0 ) 0 ) {
printf( Error (1)\n );
return BS_ERR_UNKNOWN;
}
first packet from client is received well.
but server cannot reveive 2nd, 3rd, 4th... message.
what's wrong? client problem? I logged client sent message.
Re: Test failures on trunk?
I saw this too but I ran the tests again and they passed. It looks like testSuspendResumeReadWrite isn't deterministic and need to be looked at. Jeff Genender wrote: I noticed the following today: Failed tests: testSuspendResumeReadWrite(org.apache.mina.transport.socket.nio.DatagramTrafficControlTest) Does anyone know when that may get fixed? Thanks, Jeff
