WriteFuture.join() hangs when called in IoHandler.sessionOpened() in Datagram transport.
Hi there, I've just found a possible bug in MINA Datagram transport. In my handler class, I was trying to write some messages once the sessionOpened event is fired, while the program will hang if I get the writeFuture and call join() on it. If I call join with a timeout parameter, after the operation gets timeout, WriteFuture.isWritten returns false. (Same senario would go through if it's via SocketConnector transport, as showing in the sumup example.) However, if I don't place the write operation inside sessionOpened(); instead, I placed they after DatagramConnector.connect(), then writes will successfully go though. I'm using MINA 1.1.5 and JRE 1.6. Source code that demostrate the problem is attached. http://www.nabble.com/file/p14370126/BroadcastSender.java BroadcastSender.java -- View this message in context: http://www.nabble.com/WriteFuture.join%28%29-hangs-when-called-in-IoHandler.sessionOpened%28%29-in-Datagram-transport.-tp14370126s16868p14370126.html Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.
Re: HttpResponseEncoder and streaming data
On Dec 16, 2007 1:51 AM, Bogdan Ciprian Pistol <[EMAIL PROTECTED]> wrote: > Hi all, > > On Dec 13, 2007 7:50 PM, Trustin Lee <[EMAIL PROTECTED]> wrote: > > It seems like we now have some reasonable approaches on streaming > > large object now. I think all of them are valid, but I also would > > like you to think about receiving a large object. We need to resolve > > both encoding and decoding and the resolution should be symmetric so > > that it's easy to learn. Consequently, Dave's idea is providing some > > clue to improve the ideas of Tuure and Bogdan. It would be really > > exciting to see the best combination of the three ideas via > > cooperation. > > I wrote only the server part (the encoder), the server is accessed by > standard web browsers. :) > > This is how I see a client receiving chunked messages: > > The client receiving the chunked message can wait until the hole > chunked message is received (how the browsers are handling chunked > messages) > and then the decoder would pass the message as a normal HTTP message > to the application. > This assumes that for the application the message has a meaning as a > hole (all the chunked messages together), individual chunks are > meaningless. > > The client could also decode every chunked message as an individual > part of a stream of messages and the decoder will pass to the > application every chunked message. > This assumes that the application can handle every chunk individually > and every chunk has a meaning (it can be individually evaluated by the > application). > > The two ways of handling chunked messages should be configurable. An > application should manifest it's interest in a what way to handle the > received chunked messages. Makes a lot of sense. We need to make it configurable and retain the current behavior unless it's configured differently from the default. > Tuure, why standard HTTP messages cannot be used for streaming? Why > chunked messages are more appropriate? > If you send chunk after chunk in the same HTTP response or if you send > multiple standard HTTP responses it is almost the same (a standard > HTTP message has just some optional additional headers and that first > status line). We could make our current class hierarchy more granular like the following: * HttpMessage ** HttpRequest - no getContent() *** MergedHttpRequest - getContent() here *** ChunkedHttpRequest - once written, encoder expects HttpChunks, other HttpRequest or disconnection. ** HttpResponse - no getContent() *** MergedHttpResponse - getContent() here *** ChunkedHttpResponse - once written, encoder expects HttpChunks, other HttpResponse or disconnection. * HttpChunk - getContent() here Most users will be OK with MergedHttpRequest and MergedHttpResponse and some people who wants to stream a big message will use ChunkedHttpRequest, ChunkedResponse and HttpChunk. Additionally, we won't need END_TOKEN because the encoder implementation can determine the end of the chunks easily. For decoding, if the decoder is configured for chunking, the decoder will produce ChunkedHttpRequest and HttpChunks or ChunkedHttpResponse and HttpChunks. If not configured for chunking, then just MergedHttpRequest or MergedHttpResponse will be produced, which is the default behavior. I am not sure about the class name prefix 'Merged' though. Any better name suggestion is appreciated. What do you think about this solution? Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
MINA 2 migration guide
I have volunteered to lead an effort to put together a migration guide that shows how to 'port' a MINA 1.x based program to a MINA 2.x based program. Here are some thoughts I have: 1. Provide some programs written using MINA 1.x and the changes that are required to use 2.x. 2. List the bugs/features that have been closed as a result of 2.xdevelopment. 3. List the changes to the API, and the locations of the submodules/classes. Let me know if there are other ideas people have for this. Thanks Mark -- The adjuration to be "normal" seems shockingly repellent to me; I see neither hope nor comfort in sinking to that low level. I think it is ignorance that makes people think of abnormality only with horror and allows them to remain undismayed at the proximity of "normal" to average and mediocre. For surely anyone who achieves anything is, essentially, abnormal. Dr. Karl Menninger
Re: Maximum buffer
Hi Jeroen and pietry, TCP guarantees that the packets will be in the same order, that it will retransmit the lost packets and discard duplicates. You don't need to worry about all the above in your MINA based application because you are at a level above TCP, you are not implementing TCP, TCP does all this for you. You are too worried about how routing is done. You don't need to know this. TCP is a connection oriented protocol, if you are above the TCP layer then you deal with connections (sockets, etc), you shouldn't care what path a router chooses or other TCP guaranteed stuff. On Dec 16, 2007 6:03 PM, Jeroen Brattinga <[EMAIL PROTECTED]> wrote: > You have to take these (strange) situations in consideration, and decide > what action to take. It could be that you discard a previous session if > you receive conflicting information. > > Remember that the 'conversations' (= the protocol communications) you > have will not always be ideal. Sometimes you get corrupt information, > sometimes the connection is dropped without any warning (or exit > message!). In these situations you can easily get conflicting messages. > > An example: someone connects to a server. The server receives a connect > message and keeps track of the client. It expects a disconnect message > when the client disconnects. But what if the client is terminated before > it can send this message? How long is the server going to wait for the > client? What happens if the client tries to reconnect ... the old > session is still active on the server... > > Oh, and packet routing is totally independent of both clients. Every > router along the way decides what path each packet is going to take. > This means that you are never sure about the route of each packet. In a > LAN situation, this is of course much easier (since the routing choices > are limited), but on the internet it's a whole different matter. > > A connection between two peers is often simplified as a straight line. > In reality that is always never the case; if you would draw the routes > each packet takes, it would look more like a mesh than a line. > > > Jeroen Brattinga > > > On Sun, 2007-12-16 at 07:40 -0800, pietry wrote: > > I'm implementing the ADC protocol. > > http://dcplusplus.sf.net/ADC.html > > > > The info received by any client is what happens to other client, which is > > independent to current client. > > In other words, the client receives for example notifications when somebody > > enters or exits. > > If somebody reconnects and the package of connection arrives before the one > > of exiting, then the client receives like : "another client with the same > > name connected, how is that possible now i have two of them " > > If a connection between two peers is made once, why package X would be > > routed through China and Y through Africa... > > > > > > > > Jeroen Brattinga wrote: > > > > > > What you're talking about takes place at a lower level. As an example, > > > say you are sending a 5Kb payload (a couple of lines of text, for > > > instance). > > > > > > This 5Kb is split up in packets; each one gets the right header and > > > checksum and is sent to their destination. There the TCP layer assembles > > > the separate packets, puts them in the right order and eventually passes > > > the data to the application. In the end you'll see the 5Kb; nicely > > > assembled in the proper order. > > > > > > This has nothing to do with the level you're talking about: the protocol > > > level. You have to do the order and status housekeeping for your > > > protocol. You could adding a unique ID to each message to do that. If > > > you can't see how that's possible, try sharing some of the details of > > > your protocol, maybe someone on this list has an idea. > > > > > > By the way, it might be a good idea to read up on the OSI model > > > (http://en.wikipedia.org/wiki/OSI_model). What I'm talking about is the > > > difference between the transport layer (TCP) and the application layer > > > (where your protocol functions). > > > > > > > > -snip- > > > >> >> > > >> > > > >> > > > >> > > > >> > > > > > > > > > > > > >
Re: Many sockets over single socket
On Dec 11, 2007 11:51 AM, oscarcs <[EMAIL PROTECTED]> wrote: > > I must develop a system made of nodes in a tree layout. Each node (computer) > has many children and only one father. > > Each node sends TCP messages (using a propietary protocol) to the father, an > the father itself must send the messages to the grandfather and so on. > > I have been using MINA to solve many of the communications concerns, but now > i have some doubts. > > My questions are: > > 1. Is there a way to simulate at the lowest posible level, many sockets over > a single socket?. I mean, using a single socket to send to the grandfather > all the messages comming from the children, so i can reuse the procotol > logic in all the levels. Yes. MINA is all about an abstract API, so you can implement a meta-transport that does what you want. > 2. If not, another aproach would be replicate all the child socktets in all > the levels, so at the upper level i will end with a single machine with too > many sockets. How much is the overhead (in reources or CPU) of using > multiple sockets vs. single socket?. Is there any limit? I'd suggest you open as many sockets as the number of cores of your machine at least, and each socket could host multiple sockets. If you can implement a virtual socket, then it shouldn't be that difficult to implement. It would be really a great addition to MiNA project if such a facility is provided out of the box. > Sorry for my english. Thanks for your perfect English. HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: Mina 1 vs Mina 2 current
part of the reason I joined was to help with documentation. I will volunteer and start a new thread on this topic. On Dec 17, 2007 12:30 AM, Trustin Lee <[EMAIL PROTECTED]> wrote: > On Dec 17, 2007 2:17 PM, Mark <[EMAIL PROTECTED]> wrote: > > Trustin, has a migration guide been started? > > Not yet. If you are volunteering, it's a great news. > > Cheers, > Trustin > -- > what we call human nature is actually human habit > -- > http://gleamynode.net/ > -- > PGP Key ID: 0x0255ECA6 > -- The adjuration to be "normal" seems shockingly repellent to me; I see neither hope nor comfort in sinking to that low level. I think it is ignorance that makes people think of abnormality only with horror and allows them to remain undismayed at the proximity of "normal" to average and mediocre. For surely anyone who achieves anything is, essentially, abnormal. Dr. Karl Menninger
Re: Mina 1 vs Mina 2 current
On Dec 17, 2007 2:17 PM, Mark <[EMAIL PROTECTED]> wrote: > Trustin, has a migration guide been started? Not yet. If you are volunteering, it's a great news. Cheers, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: Revisiting logging in MINA 2.0
BTW I think we need something different from JarJar (http://code.google.com/p/jarjar/). We need a simple skeleton code from which a thin logging layer code is generated into the specified package (org.apache.mina.common in MINA's case). It could be reused among many frameworks including MINA. Trustin On Dec 17, 2007 2:25 PM, Trustin Lee <[EMAIL PROTECTED]> wrote: > Hi Maarten, > > On Dec 15, 2007 3:26 AM, Maarten Bosteels <[EMAIL PROTECTED]> wrote: > > about (4) : I thought the deadlock is caused by a bug in log4j (namely that > > it doesn't use proper synchronization) ? > > If that's the case I think we should not try to fix it in MINA. > > I think it's not really a bug of Log4J but a missing feature (i.e. > reentrant logging). There are two workaround for the dead lock; one > is to turn OFF logging for MINA, and the other is use a differnt > appender (i.e. non-MINA-based one). The second solution might be most > viable solution that causes no change in our source code. However, > some built-in filters that logs messages might be used for the > MINA-based appender, and the log messages logged by the filter might > need to be transmitted via the MINA-based appender because it's not a > critical but just informing message. So... the two workarounds I've > mentioned are not likely to solve this problem perfectly. > > We can ask Log4J team to fix this issue and it will be fixed, but, > again, considering that people wants to use the older version of Log4J > or doesn't want to upgrade the Log4J due to some reason (e.g. custom > patch) won't see this problem resolved in Log4J. > > And.. that's why I am suggesting a thin layer for logging. By doing > so, a user can bypass the existing logging framework to log messages > from MINA itself. Of course, this doesn't necessarily mean that we > will not experience dead lock or infinite recursion. However, at > least we have control over such a tricky situation, and cut down > unnecessary recursion. > > Another merit of the thin logging layer could be that it makes a JUL > user doesn't need to add SLF4J JARs unnecessary. I sometime don't > understand why the number of JARs are important. However, as David > pointed out, it's pretty critical to the frameworks that depends on > the other frameworks. For example, in the early stage of JMX > integration implementation, I have used Commons BeanUtils which > depends on commons logging. This meant a MiNA user who wants to use > JMX integration module needs to add another JAR to his or her > classpath. If he or she is using a Maven, then it also means that he > or she has to add many tags to section, which > is pain in the butt. > > These thoughts lead me to think all frameworks have to: > > 1) provide a thin logging layer or > 2) not log at all. > > I'd prefer the solution #1. > > David answered other questions pretty nicely, so that's all for me. > > > Trustin > -- > what we call human nature is actually human habit > -- > http://gleamynode.net/ > -- > PGP Key ID: 0x0255ECA6 > -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: Revisiting logging in MINA 2.0
Hi Maarten, On Dec 15, 2007 3:26 AM, Maarten Bosteels <[EMAIL PROTECTED]> wrote: > about (4) : I thought the deadlock is caused by a bug in log4j (namely that > it doesn't use proper synchronization) ? > If that's the case I think we should not try to fix it in MINA. I think it's not really a bug of Log4J but a missing feature (i.e. reentrant logging). There are two workaround for the dead lock; one is to turn OFF logging for MINA, and the other is use a differnt appender (i.e. non-MINA-based one). The second solution might be most viable solution that causes no change in our source code. However, some built-in filters that logs messages might be used for the MINA-based appender, and the log messages logged by the filter might need to be transmitted via the MINA-based appender because it's not a critical but just informing message. So... the two workarounds I've mentioned are not likely to solve this problem perfectly. We can ask Log4J team to fix this issue and it will be fixed, but, again, considering that people wants to use the older version of Log4J or doesn't want to upgrade the Log4J due to some reason (e.g. custom patch) won't see this problem resolved in Log4J. And.. that's why I am suggesting a thin layer for logging. By doing so, a user can bypass the existing logging framework to log messages from MINA itself. Of course, this doesn't necessarily mean that we will not experience dead lock or infinite recursion. However, at least we have control over such a tricky situation, and cut down unnecessary recursion. Another merit of the thin logging layer could be that it makes a JUL user doesn't need to add SLF4J JARs unnecessary. I sometime don't understand why the number of JARs are important. However, as David pointed out, it's pretty critical to the frameworks that depends on the other frameworks. For example, in the early stage of JMX integration implementation, I have used Commons BeanUtils which depends on commons logging. This meant a MiNA user who wants to use JMX integration module needs to add another JAR to his or her classpath. If he or she is using a Maven, then it also means that he or she has to add many tags to section, which is pain in the butt. These thoughts lead me to think all frameworks have to: 1) provide a thin logging layer or 2) not log at all. I'd prefer the solution #1. David answered other questions pretty nicely, so that's all for me. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: Mina 1 vs Mina 2 current
Trustin, has a migration guide been started? On Dec 16, 2007 11:53 PM, Trustin Lee <[EMAIL PROTECTED]> wrote: > Exactly. I'd like to start a vote as soon as a couple of bugs/design > issues are fixed and migration guide becomds available. > > Cheers, > Trustin > > On Dec 15, 2007 6:53 AM, Brian McCallister <[EMAIL PROTECTED]> wrote: > > If the committers are recommending using trunk, that suggests it is > > time for a release. > > > > Seriously. > > > > -Brian > > > > > > On Dec 14, 2007, at 1:35 PM, Mike Heath wrote: > > > > > mclovis wrote: > > >> mclovis wrote: > > >>> We currently have NIO server code working based on our own current > > >>> design. Looking at the Mina code we feel we could simplify things > > >>> somewhat > > >>> by switching to Mina. We are also currently in a refactoring > > >>> phase. That > > >>> being said it looks like you will release Mina2 -M1 soon and have > > >>> promised > > >>> GA by summer. In your opinion, could we refactor to Mina1 for > > >>> production > > >>> quality and later upgrade with some changes to Mina2 , or wait to > > >>> M2. If > > >>> we are going to refactor using Mina in the near future, now is the > > >>> time > > >>> for us. I am posting this trying gain some understanding of Mina1 > > >>> to Mina2 > > >>> features as well as compatibility. Any insights will be appreciated. > > >>> > > >> > > >> If there are any code committers following this thread any > > >> insights from > > >> them would also be appreciated. > > > > > > I'm a committer on MINA and I would recommend using MINA TRUNK for new > > > projects. There are a lot of really nice improvements to MINA TRUNK > > > in > > > terms of both performance and a better API. > > > > > > I'm using MINA TRUNK on a few projects right now. These projects are > > > still in development so changes to MINA haven't been much of an issue. > > > > > > We would also like to get as much feedback before cutting a MINA 2.0 > > > release so the more people using MINA TRUNK the better. > > > > > > -Mike > > > > > > > > -- > what we call human nature is actually human habit > -- > http://gleamynode.net/ > -- > PGP Key ID: 0x0255ECA6 > -- The adjuration to be "normal" seems shockingly repellent to me; I see neither hope nor comfort in sinking to that low level. I think it is ignorance that makes people think of abnormality only with horror and allows them to remain undismayed at the proximity of "normal" to average and mediocre. For surely anyone who achieves anything is, essentially, abnormal. Dr. Karl Menninger
Re: [New Committer] Everyone let's give a warm welcome to Jeff Genender
Welcome Jeff !!! On Dec 14, 2007 4:29 PM, Alex Karasulu <[EMAIL PROTECTED]> wrote: > Hi all, > > We have a new committer, Jeff Genender, who's a committer other projects > here at the ASF and a member of the foundation as well. He's great guy > and > has been working on some of the http client code and is pretty excited > about > MINA ... let me stop putting words in his mouth though. Jeff go ahead and > tell us about yourself if you have a minute. > > Welcome! > Alex > -- The adjuration to be "normal" seems shockingly repellent to me; I see neither hope nor comfort in sinking to that low level. I think it is ignorance that makes people think of abnormality only with horror and allows them to remain undismayed at the proximity of "normal" to average and mediocre. For surely anyone who achieves anything is, essentially, abnormal. Dr. Karl Menninger
Re: BUFFER_OVERFLOW
Please try to svn up again. You are not using the latest revision. HTH, Trustin On Dec 14, 2007 2:37 AM, Saurabh Jain <[EMAIL PROTECTED]> wrote: > > Hi, > > I am using mina-core-2.0.0-M1-SNAPSHOT which i compiled from trunk from > revision number 581243 (This is the highest reviosion number of the files on > my machine) > > Thanks > Saurabh > > > > > Trustin Lee wrote: > > > > Could you let us know the version number of MINA you are using? > > > > Trustin > > > > On Dec 12, 2007 4:18 AM, Saurabh Jain <[EMAIL PROTECTED]> wrote: > >> > >> Hi All, > >> > >> I have written an Client/Server application. When my server is trying to > >> send a big chink of data, i am getting the following exception > >> > >> javax.net.ssl.SSLException: SSLEngine error during encrypt: > >> BUFFER_OVERFLOW > >> src: java.nio.HeapByteBuffer[pos=16384 lim=16418 cap=16418]outNetBuffer: > >> java.nio.HeapByteBuffer[pos=16421 lim=32836 cap=32836] > >> at > >> org.apache.mina.filter.ssl.SslHandler.encrypt(SslHandler.java:380) > >> at > >> org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:506) > >> at > >> org.apache.mina.common.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:421) > >> at > >> org.apache.mina.common.DefaultIoFilterChain.access$1400(DefaultIoFilterChain.java:38) > >> at > >> org.apache.mina.common.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:745) > >> at > >> org.apache.mina.filter.codec.ProtocolCodecFilter$ProtocolEncoderOutputImpl.flush(ProtocolCodecFilter.java:384) > >> at > >> org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:210) > >> at > >> org.apache.mina.common.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:421) > >> at > >> org.apache.mina.common.DefaultIoFilterChain.access$1400(DefaultIoFilterChain.java:38) > >> at > >> org.apache.mina.common.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:745) > >> at > >> org.apache.mina.common.DefaultIoFilterChain$TailFilter.filterWrite(DefaultIoFilterChain.java:671) > >> at > >> org.apache.mina.common.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:421) > >> at > >> org.apache.mina.common.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:415) > >> at > >> org.apache.mina.common.AbstractIoSession.write(AbstractIoSession.java:241) > >> at > >> org.apache.mina.common.AbstractIoSession.write(AbstractIoSession.java:200) > >> > >> I get this problem in my office network ( Tested on 3 different machines) > >> but i am not able to reproduce it in my home network ( tried on 2 > >> different > >> machines). > >> > >> is it related to https://issues.apache.org/jira/browse/DIRMINA-471 ? > >> > >> Saurabh > >> > >> -- > >> View this message in context: > >> http://www.nabble.com/BUFFER_OVERFLOW-tp14281194s16868p14281194.html > >> 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 > > > > > > -- > View this message in context: > http://www.nabble.com/BUFFER_OVERFLOW-tp14281194s16868p14320888.html > > 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: Mina 1 vs Mina 2 current
Exactly. I'd like to start a vote as soon as a couple of bugs/design issues are fixed and migration guide becomds available. Cheers, Trustin On Dec 15, 2007 6:53 AM, Brian McCallister <[EMAIL PROTECTED]> wrote: > If the committers are recommending using trunk, that suggests it is > time for a release. > > Seriously. > > -Brian > > > On Dec 14, 2007, at 1:35 PM, Mike Heath wrote: > > > mclovis wrote: > >> mclovis wrote: > >>> We currently have NIO server code working based on our own current > >>> design. Looking at the Mina code we feel we could simplify things > >>> somewhat > >>> by switching to Mina. We are also currently in a refactoring > >>> phase. That > >>> being said it looks like you will release Mina2 -M1 soon and have > >>> promised > >>> GA by summer. In your opinion, could we refactor to Mina1 for > >>> production > >>> quality and later upgrade with some changes to Mina2 , or wait to > >>> M2. If > >>> we are going to refactor using Mina in the near future, now is the > >>> time > >>> for us. I am posting this trying gain some understanding of Mina1 > >>> to Mina2 > >>> features as well as compatibility. Any insights will be appreciated. > >>> > >> > >> If there are any code committers following this thread any > >> insights from > >> them would also be appreciated. > > > > I'm a committer on MINA and I would recommend using MINA TRUNK for new > > projects. There are a lot of really nice improvements to MINA TRUNK > > in > > terms of both performance and a better API. > > > > I'm using MINA TRUNK on a few projects right now. These projects are > > still in development so changes to MINA haven't been much of an issue. > > > > We would also like to get as much feedback before cutting a MINA 2.0 > > release so the more people using MINA TRUNK the better. > > > > -Mike > > -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: CumulativeProtocolDecoder and UDP
On Dec 14, 2007 2:41 AM, Trustin Lee <[EMAIL PROTECTED]> wrote: > On Dec 13, 2007 11:35 PM, Frederic Soulier <[EMAIL PROTECTED]> wrote: > > Hi Trustin > > > > Thx for your answer. It makes sense. > > > > In our case UDP messages from clients are guaranteed to fit in 1 UDP > > packet therefore the fact that UDP packet #2 may arrive before UDP > > packet #1 is not relevant. At our level we just get message #2 before > > message #1 and they are completely independant. > > Obviously should the need arise to have larger messages from the > > client we'll have to reconstruct the messages using UDP packets in > > the right order. > > > > The 2nd interesting finding which is more disconcerting is that using > > MINA 1.1.3 there's effectively no accumulation by the > > CumulativeProtocolDecoder for UDP traffic. > > We skipped MINA 1.1.4 because of an issue with ProtocolCodecExection > > I reported. > > With MINA 1.1.5 the ProtocolCodecException works as per 1.1.3 but the > > CumulativeProtocolDecoder now accumulates data for UDP! > > > > Our app using 1.1.3 --> no accumulation for UDP > > Our app using 1.1.4 --> accumulation for UDP > > > > Could you confirm this change of behaviour? > > That's very weird. If so, it's a compatibility bug. At least, in > 2.0, it should do nothing if TransportMetadata.hasFragmentation() > returns false. I think I didn't touch a line in > CumulativeProtocolDecoder in 1.x anyway. Let me check it out and get > back to you. Yeah, it seems like nobody made change in CumulativeProtocolDecoder. It's probably a side effect of some changed in other parts of the core. I don't know where it is though. Let me fix this in 2.0 rather than addressing it in 1.x, because it basically doesn't make sense to a UDP application to send a partial message and we don't have any means to figure out the transport has fragmentation or not. Thanks again for your understanding. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: Send Message Failure
On Dec 14, 2007 7:56 AM, Steve Johns <[EMAIL PROTECTED]> wrote: > > On Dec 14, 2007 6:40 AM, mat <[EMAIL PROTECTED]> wrote: > > > On Dec 14, 2007 1:35 AM, Trustin Lee <[EMAIL PROTECTED]> wrote: > > > > > Hi Steve, > > > > > > On Dec 13, 2007 11:49 PM, Steve Johns <[EMAIL PROTECTED]> > > wrote: > > > > Thanks for Mina. It is a great project. > > > > > > Whenever we hear this, we become happy and try to work harder for > > > MINA. Thank you too! > > > > :D > > > > > > > > > > > > After I am trying out the Mina, I had some questions. > > > > > > > > 1) If the server session.write() a message, however client network is > > > really > > > > SLOW. Will mina keep trying to send > > > > out the message until timeout?(I guess session.settimeout() is applied > > > > here). If so, how IoHandler get notified from this > > > > event message? (Through exceptionCaught, close session?). > > > > > > There's writeTimeout property in IoSessionConfig, so you can adjust > > > the timeout value. Once the write it timed out, WriteTimeoutException > > > is raised and forwarded to your IoHandler's exceptionCaught method. > > > And then the connection will be closed automatically. > > > > > > > Why > > > > NOT accumulated writeQueue size > user defined size and exception? > > > > > > Could you explain this question more in detail? > > > > Which meant: I need close the session whenever the write queue size(buffer > > size) for this session reaches a certain number. > > Yup. That was what I meant. You can always check the size of the write request queue via IoSession.getScheduledWriteRequests/Bytes(). You can call IoSession.close() explicitly when it returns the greater value than you expected. > > > 2) If the server wants to send the same message to all 1000 sessions, > > should > > > I encode the same message 1000 times > > > in the encoder extend the messageEncoder? If so, that kinda affects the > > > performance. > > > > Right. We got the same request before and I suggested him to use some > > cache. Would it work for you, either? > > A cache sounded workable. However where should I do the MESSAGE -> byte[] -> > > cache(If I do in IoHandler, is that kinda mixing business logic and > > protocol > > handler)? > > Can you give more hints about what the CACHE is? In you encoder, you could maintain a Map whose key is some message key and whose value is encoded ByteBuffer (or byte[]). It could probably be a LRUMap implementation that is provided by 3rd party collections API such as Apache Commons Collections. You could query the map if there's already an encoded form of the message, and reuse the encoded data if there's one in your encoder implementation. HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: Problem when use ObjectSerializationCodecFactory in Datagram broadcasting between linux and window
That's weird. Did you kick your machine's butt? :D Trustin On Dec 14, 2007 8:55 AM, Qi <[EMAIL PROTECTED]> wrote: > > Hi Trustin, > > For some reason that I don't know, messages are now transferred > successfully. > I've done nothing except my windows machine was rebooted. > Truly lost... > > Qi Cao > 14 Dec 2007 > > > > Qi wrote: > > > > Hi Trustin, > > > > I will upload the source files as a eclipse project archive. > > The archive includes mina-core1.1.5 and slf4j jar files, so it should be > > able to start with no extra settings. > > > > I've also uploaded it to: > > http://www.cs.mu.oz.au/~caoq/mina-broadcasting.zip > > Just in case if you have problem download if from the forum. > > > > Please feel free to modify the codes or show others as a bad example of > > using mina :) > > > > Cheers, http://www.nabble.com/file/p14326975/mina-broadcasting.zip > > mina-broadcasting.zip > > Qi Cao > > 14. Dec 2007 > > > > > > > > Trustin Lee wrote: > >> > >> Hi Qi, > >> > >> Such a small object should be fine I guess. Could you provide us full > >> source code so we can test? > >> > >> Trustin > >> > >> > > > > > > -- > View this message in context: > http://www.nabble.com/Problem-when-use-ObjectSerializationCodecFactory-in-Datagram-broadcasting-between-linux-and-window-tp14311279s16868p14327326.html > > 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
[jira] Commented: (DIRMINA-497) Thread safety issue: incorrect usage of Collections.synchronizedMap in DefaultIoSessionDataStructureFactory.DefaultIoSessionAttributeMap
[ https://issues.apache.org/jira/browse/DIRMINA-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552321 ] Trustin Lee commented on DIRMINA-497: - Are you sure that the Map implementation that Collections.synchronizedMap() returns uses the internal object for synchronization? I looked into the JavaDoc and JDK source code, but it seems like it synchronizes with the returned Map instance itself. Could you check that again? BTW, we have reverted back from ConcurrentHashMap to synchronized HashMap due to excessive memory usage of ConcurrentHashMap. It would be really nice if there's a compact ConcurrentHashMap implementation that doesn't consume too much heap. > Thread safety issue: incorrect usage of Collections.synchronizedMap in > DefaultIoSessionDataStructureFactory.DefaultIoSessionAttributeMap > > > Key: DIRMINA-497 > URL: https://issues.apache.org/jira/browse/DIRMINA-497 > Project: MINA > Issue Type: Bug > Components: Core >Reporter: David M. Lloyd > Attachments: DIRMINA-497-1.patch > > > In trunk, the DefaultIoSessionAttributeMap.setAttributeIfAbsent() > synchronizes on the attributes map in order to synchronize access with the > other get/setAttribute methods. However, Collections.synchronizedMap does NOT > synchronize on the map itself, but rather an internal object! So, > setAttributeIfAbsent() still contains a race condition. > A good solution for 2.x would be to simply use a ConcurrentMap, which has > putIfAbsent(). For 1.0.x, which has to run on JDK 1.4 (correct?), I'd > recommend to just drop Collections.synchronizedMap() and synchronize directly > on the Map reference itself. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Newbie Questions
On Dec 15, 2007 11:55 AM, Steve Johns <[EMAIL PROTECTED]> wrote:
> On Dec 15, 2007 5:52 AM, Mike Heath <[EMAIL PROTECTED]> wrote:
>
> > Steve Johns wrote:
> > > Thanks for Mina. It is a great project.
> > > After I am trying out the Mina, I had some questions.
> > > 1) If the server session.write() a message, however client network is
> > really
> > > SLOW. Will mina keep trying to send
> > > out the message until timeout?(I guess session.settimeout() is applied
> > > here). If so, how IoHandler get notified from this
> > > event message? (Through exceptionCaught, close session?). Why NOT
> > > accumulated writeQueue size > user defined size and exception?
> >
> > MINA only passes the message on to the OS once. It is the OS'
> > responsibility to manage TCP timeouts and resend dropped packets. If
> > the TCP connection timesout, an exception will be thrown and it can be
> > handled in IoHandler.exceptionCaught.
>
> I may not make myself clear. If I send 100 bytes length of packets, however,
> only 50 bytes are sent. (int sentBytes = socket.write(bytes[])). I meant if
> Mina will put the left 50 bytes back to the queue and send them again?
Yes. MINA will try to send when the NIO selector tells MINA that the
kernel buffer is reday to receive more write requests.
> > > 2) If the server wants to send the same message to all 1000 sessions,
> > should
> > > I encode the same message 1000 times
> > > in the encoder extend the messageEncoder? If so, that kinda affects the
> > > performance.
> >
> > If you send the message as a Java Object, it will have to be encoded
> > 1,000 times. If you're going to be broadcasting a message to lots of
> > clients, I would recommend encoding it once, and then doing something
> > like:
> >
> > for (IoSession session : allRecipients) {
> > session.write(myEncodedBuffer.duplicate());
> > }
>
> Which means I have to do the Encode part in the IoHandlerAdapter but NOT in
> my encoder, right? That really mixes up the communication and business
> logic.
Well, it doesn't necessarily mean that. You can use some cache in
your encoder to avoid encoding the same message over and over, not
hurting the separation of concerns.
> > > Finally, thanks Trustin.
> >
> > Yes, Trustin is my hero.
>
> You are my hero, too. :)
Any costume for me? :D
HTH,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: exceptions with SSL
Hi Alexander, On Dec 16, 2007 2:14 AM, _alexandr <[EMAIL PROTECTED]> wrote: > > sorry for my bad english :( Mine is poor too. :D > i configured MINA to use SSLFilter. It works OK with correct certificates. > But i try to use incorrect certificates (signing by not-trusted CA). > > Connection closed, but i have next strange log messages: > 14070 [SocketAcceptorIoProcessor-0.0] INFO > kz.avarlamov.otp.net.server.AuthModuleServerSessionHandler - > [/127.0.0.1:43957] CREATED > 14076 [AnonymousIoService-1] INFO > kz.avarlamov.otp.net.server.AuthModuleServerSessionHandler - > [/127.0.0.1:43957] OPENED > 14194 [AnonymousIoService-3] WARN > kz.avarlamov.otp.net.server.AuthModuleServerSessionHandler - > [/127.0.0.1:43957] EXCEPTION: > javax.net.ssl.SSLHandshakeException: SSL handshake failed. > > 14324 [AnonymousIoService-3] INFO > kz.avarlamov.otp.net.server.AuthModuleServerSessionHandler - > [/127.0.0.1:43957] CLOSE > javax.net.ssl.SSLHandshakeException: SSL handshake failed. > 14348 [AnonymousIoService-3] INFO > kz.avarlamov.otp.net.server.AuthModuleServerSessionHandler - > [/127.0.0.1:43957] CLOSED > 14348 [AnonymousIoService-3] WARN > kz.avarlamov.otp.net.server.AuthModuleServerSessionHandler - > [/127.0.0.1:43957] EXCEPTION: > org.apache.mina.filter.codec.ProtocolDecoderException: > org.apache.mina.common.BufferDataException: dataLength: 335741184 > > Connection closed? But why throws last exception? Well.. it might be a bug, but it'd like to see some reproduceable code or detailed explanation of what you are doing. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: [New Committer] Everyone let's give a warm welcome to Jeff Genender
Welcome on board Jeff! Please keep up the great work. :) Cheers, Trustin On Dec 15, 2007 6:34 PM, Niclas Hedhman <[EMAIL PROTECTED]> wrote: > On Saturday 15 December 2007 06:41, Jeff Genender wrote: > > Thank you and I am honored. ;-) > > Welcome to MINA... > > > Cheers > -- > Niclas Hedhman, Software Developer > > I live here; http://tinyurl.com/2qq9er > I work here; http://tinyurl.com/2ymelc > I relax here; http://tinyurl.com/2cgsug > -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
[jira] Commented: (DIRMINA-495) IoConnector needs a way to store information into the IoSession before the IoHandler gets ahold of it
[
https://issues.apache.org/jira/browse/DIRMINA-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552320
]
Trustin Lee commented on DIRMINA-495:
-
I think at least we need to add 'Io' prefix because all others in the core
module do. BTW, the patch looks great!
> IoConnector needs a way to store information into the IoSession before the
> IoHandler gets ahold of it
> -
>
> Key: DIRMINA-495
> URL: https://issues.apache.org/jira/browse/DIRMINA-495
> Project: MINA
> Issue Type: New Feature
> Components: Core
>Reporter: David M. Lloyd
>Assignee: Mike Heath
> Fix For: 2.0.0-M1
>
> Attachments: DIRMINA-495-3.patch, DIRMINA-495-mikeheath.patch,
> IoConnector.patch
>
>
> It is often necessary to pass information into the IoHandler associated with
> an IoConnector. Sometimes this information is needed even as early as
> IoSession creation time. A mechanism is needed to pass information in to the
> IoSession at the time you call IoConnector.connect(). Discussing this with
> Mike Heath, we determined that a logical approach could be to have variants
> of the connect() methods that accept information that can be attached to the
> IoSession when it is created.
> One option is to simply pass a Map in to the connect method. The contents of
> the Map would be copied into the IoSession's attribute map after it is
> constructed but before the IoHandler.sessionCreated method is created. In
> addition, it seems likely that in many cases only one entry would need to be
> added - in this case the user could simply do this:
>ioConnector.connect(addr, Collections.singletonMap(MY_KEY, theValue));
> Another option would be to use variable argument lists to accept any number
> of key-value pairs. The pairs could be represented by a class -
> AttributePair for example. It could look like this:
>public final class AttributePair {
>private final K key;
>private final V value;
>private AttributePair(K key, V value) { this.key = key; this.value =
> value; }
>public static AttributePair pair(K key, V value) { return
> new AttributePair(key, value); }
>}
> Then the user can use static imports to pull in the "pair" method. The
> connect() method on IoConnector could accept a variable list of AttributePair
> objects, so the user could write code like this:
> ioConnector.connect(addr, pair(MY_KEY1, myValue), pair(MY_KEY2,
> myValue2));
> Though this approach is somewhat more complicated than just using a Map.
> Other approaches may also be discussed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-495) IoConnector needs a way to store information into the IoSession before the IoHandler gets ahold of it
[
https://issues.apache.org/jira/browse/DIRMINA-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552319
]
Trustin Lee commented on DIRMINA-495:
-
What do you think about renaming it to IoSessionInitializer?
> IoConnector needs a way to store information into the IoSession before the
> IoHandler gets ahold of it
> -
>
> Key: DIRMINA-495
> URL: https://issues.apache.org/jira/browse/DIRMINA-495
> Project: MINA
> Issue Type: New Feature
> Components: Core
>Reporter: David M. Lloyd
>Assignee: Mike Heath
> Fix For: 2.0.0-M1
>
> Attachments: DIRMINA-495-3.patch, DIRMINA-495-mikeheath.patch,
> IoConnector.patch
>
>
> It is often necessary to pass information into the IoHandler associated with
> an IoConnector. Sometimes this information is needed even as early as
> IoSession creation time. A mechanism is needed to pass information in to the
> IoSession at the time you call IoConnector.connect(). Discussing this with
> Mike Heath, we determined that a logical approach could be to have variants
> of the connect() methods that accept information that can be attached to the
> IoSession when it is created.
> One option is to simply pass a Map in to the connect method. The contents of
> the Map would be copied into the IoSession's attribute map after it is
> constructed but before the IoHandler.sessionCreated method is created. In
> addition, it seems likely that in many cases only one entry would need to be
> added - in this case the user could simply do this:
>ioConnector.connect(addr, Collections.singletonMap(MY_KEY, theValue));
> Another option would be to use variable argument lists to accept any number
> of key-value pairs. The pairs could be represented by a class -
> AttributePair for example. It could look like this:
>public final class AttributePair {
>private final K key;
>private final V value;
>private AttributePair(K key, V value) { this.key = key; this.value =
> value; }
>public static AttributePair pair(K key, V value) { return
> new AttributePair(key, value); }
>}
> Then the user can use static imports to pull in the "pair" method. The
> connect() method on IoConnector could accept a variable list of AttributePair
> objects, so the user could write code like this:
> ioConnector.connect(addr, pair(MY_KEY1, myValue), pair(MY_KEY2,
> myValue2));
> Though this approach is somewhat more complicated than just using a Map.
> Other approaches may also be discussed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-495) IoConnector needs a way to store information into the IoSession before the IoHandler gets ahold of it
[
https://issues.apache.org/jira/browse/DIRMINA-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552282
]
David M. Lloyd commented on DIRMINA-495:
It works, woo. I'd say, commit!
> IoConnector needs a way to store information into the IoSession before the
> IoHandler gets ahold of it
> -
>
> Key: DIRMINA-495
> URL: https://issues.apache.org/jira/browse/DIRMINA-495
> Project: MINA
> Issue Type: New Feature
> Components: Core
>Reporter: David M. Lloyd
>Assignee: Mike Heath
> Fix For: 2.0.0-M1
>
> Attachments: DIRMINA-495-3.patch, DIRMINA-495-mikeheath.patch,
> IoConnector.patch
>
>
> It is often necessary to pass information into the IoHandler associated with
> an IoConnector. Sometimes this information is needed even as early as
> IoSession creation time. A mechanism is needed to pass information in to the
> IoSession at the time you call IoConnector.connect(). Discussing this with
> Mike Heath, we determined that a logical approach could be to have variants
> of the connect() methods that accept information that can be attached to the
> IoSession when it is created.
> One option is to simply pass a Map in to the connect method. The contents of
> the Map would be copied into the IoSession's attribute map after it is
> constructed but before the IoHandler.sessionCreated method is created. In
> addition, it seems likely that in many cases only one entry would need to be
> added - in this case the user could simply do this:
>ioConnector.connect(addr, Collections.singletonMap(MY_KEY, theValue));
> Another option would be to use variable argument lists to accept any number
> of key-value pairs. The pairs could be represented by a class -
> AttributePair for example. It could look like this:
>public final class AttributePair {
>private final K key;
>private final V value;
>private AttributePair(K key, V value) { this.key = key; this.value =
> value; }
>public static AttributePair pair(K key, V value) { return
> new AttributePair(key, value); }
>}
> Then the user can use static imports to pull in the "pair" method. The
> connect() method on IoConnector could accept a variable list of AttributePair
> objects, so the user could write code like this:
> ioConnector.connect(addr, pair(MY_KEY1, myValue), pair(MY_KEY2,
> myValue2));
> Though this approach is somewhat more complicated than just using a Map.
> Other approaches may also be discussed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Maximum buffer
You have to take these (strange) situations in consideration, and decide what action to take. It could be that you discard a previous session if you receive conflicting information. Remember that the 'conversations' (= the protocol communications) you have will not always be ideal. Sometimes you get corrupt information, sometimes the connection is dropped without any warning (or exit message!). In these situations you can easily get conflicting messages. An example: someone connects to a server. The server receives a connect message and keeps track of the client. It expects a disconnect message when the client disconnects. But what if the client is terminated before it can send this message? How long is the server going to wait for the client? What happens if the client tries to reconnect ... the old session is still active on the server... Oh, and packet routing is totally independent of both clients. Every router along the way decides what path each packet is going to take. This means that you are never sure about the route of each packet. In a LAN situation, this is of course much easier (since the routing choices are limited), but on the internet it's a whole different matter. A connection between two peers is often simplified as a straight line. In reality that is always never the case; if you would draw the routes each packet takes, it would look more like a mesh than a line. Jeroen Brattinga On Sun, 2007-12-16 at 07:40 -0800, pietry wrote: > I'm implementing the ADC protocol. > http://dcplusplus.sf.net/ADC.html > > The info received by any client is what happens to other client, which is > independent to current client. > In other words, the client receives for example notifications when somebody > enters or exits. > If somebody reconnects and the package of connection arrives before the one > of exiting, then the client receives like : "another client with the same > name connected, how is that possible now i have two of them " > If a connection between two peers is made once, why package X would be > routed through China and Y through Africa... > > > > Jeroen Brattinga wrote: > > > > What you're talking about takes place at a lower level. As an example, > > say you are sending a 5Kb payload (a couple of lines of text, for > > instance). > > > > This 5Kb is split up in packets; each one gets the right header and > > checksum and is sent to their destination. There the TCP layer assembles > > the separate packets, puts them in the right order and eventually passes > > the data to the application. In the end you'll see the 5Kb; nicely > > assembled in the proper order. > > > > This has nothing to do with the level you're talking about: the protocol > > level. You have to do the order and status housekeeping for your > > protocol. You could adding a unique ID to each message to do that. If > > you can't see how that's possible, try sharing some of the details of > > your protocol, maybe someone on this list has an idea. > > > > By the way, it might be a good idea to read up on the OSI model > > (http://en.wikipedia.org/wiki/OSI_model). What I'm talking about is the > > difference between the transport layer (TCP) and the application layer > > (where your protocol functions). > > > > -snip- > >> >> > >> > > >> > > >> > > >> > > > > > > >
Re: Maximum buffer
I'm implementing the ADC protocol. http://dcplusplus.sf.net/ADC.html The info received by any client is what happens to other client, which is independent to current client. In other words, the client receives for example notifications when somebody enters or exits. If somebody reconnects and the package of connection arrives before the one of exiting, then the client receives like : "another client with the same name connected, how is that possible now i have two of them " If a connection between two peers is made once, why package X would be routed through China and Y through Africa... Jeroen Brattinga wrote: > > What you're talking about takes place at a lower level. As an example, > say you are sending a 5Kb payload (a couple of lines of text, for > instance). > > This 5Kb is split up in packets; each one gets the right header and > checksum and is sent to their destination. There the TCP layer assembles > the separate packets, puts them in the right order and eventually passes > the data to the application. In the end you'll see the 5Kb; nicely > assembled in the proper order. > > This has nothing to do with the level you're talking about: the protocol > level. You have to do the order and status housekeeping for your > protocol. You could adding a unique ID to each message to do that. If > you can't see how that's possible, try sharing some of the details of > your protocol, maybe someone on this list has an idea. > > By the way, it might be a good idea to read up on the OSI model > (http://en.wikipedia.org/wiki/OSI_model). What I'm talking about is the > difference between the transport layer (TCP) and the application layer > (where your protocol functions). > > > Jeroen Brattinga > > On Sun, 2007-12-16 at 03:58 -0800, pietry wrote: >> Shouldnt the TCP/IP protocol handle this? The TCP specs say that it makes >> sure all packets are delivered, no losses and no misorder... >> >> The protocol can't be implemented response-based so there is nothing i >> can >> do in this matter.. hoped there would be a way to make sure the packets >> are >> received ok... >> >> >> Jeroen Brattinga wrote: >> > >> > That's common in TCP (and UDP) communications. Since you never really >> > know how a packet is routed (one could be routed through Japan, the >> next >> > through Russia, for instance), the order is something you have to keep >> > track of. >> > >> > There are various ways to implement this (e.g. don't send a packet >> > before you have received a packet), and it's one of the main things you >> > have to keep in mind when implementing any network protocol! >> > >> > >> > Jeroen Brattinga >> > >> > On Sun, 2007-12-16 at 03:04 -0800, pietry wrote: >> >> It works, thanks a lot :) >> >> >> >> I also have another problem with TCP packages.. it seems that >> sometimes >> >> they >> >> reach in different order then i wrote to the Sessions. My question is >> : >> >> is >> >> this possible to be because of MINA or the settings i had to my >> server? >> >> Or >> >> it's a bug in my code ? >> >> >> >> >> >> >> >> Jeroen Brattinga wrote: >> >> > >> >> > You're propable using the TextLineDecoder? Then you have to set the >> >> > maximum line length property (which defaults to 1KB). Use the >> >> > setMaxLineLength method to do this. >> >> > >> >> > Jeroen Brattinga >> >> > >> >> > >> >> > On Sun, 2007-12-16 at 01:43 -0800, pietry wrote: >> >> >> I tried to increase the mina buffer sizes ( both receive and send) >> but >> >> >> this >> >> >> still has no success. I always get the same exception : >> >> >> buffer.org.apache.mina.common.BufferDataException: Line is too >> long: >> >> 2954 >> >> >> (Hexdump: empty) >> >> >> Used this getSessionConfig().setReceiveBufferSize(); >> >> >> and getSessionConfig().setSendBufferSize(); >> >> >> Any suggestions ? >> >> > >> >> > >> >> > >> >> >> > >> > >> > >> > > > -- View this message in context: http://www.nabble.com/Maximum-buffer-tp14360017s16868p14362619.html Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.
Re: Maximum buffer
What you're talking about takes place at a lower level. As an example, say you are sending a 5Kb payload (a couple of lines of text, for instance). This 5Kb is split up in packets; each one gets the right header and checksum and is sent to their destination. There the TCP layer assembles the separate packets, puts them in the right order and eventually passes the data to the application. In the end you'll see the 5Kb; nicely assembled in the proper order. This has nothing to do with the level you're talking about: the protocol level. You have to do the order and status housekeeping for your protocol. You could adding a unique ID to each message to do that. If you can't see how that's possible, try sharing some of the details of your protocol, maybe someone on this list has an idea. By the way, it might be a good idea to read up on the OSI model (http://en.wikipedia.org/wiki/OSI_model). What I'm talking about is the difference between the transport layer (TCP) and the application layer (where your protocol functions). Jeroen Brattinga On Sun, 2007-12-16 at 03:58 -0800, pietry wrote: > Shouldnt the TCP/IP protocol handle this? The TCP specs say that it makes > sure all packets are delivered, no losses and no misorder... > > The protocol can't be implemented response-based so there is nothing i can > do in this matter.. hoped there would be a way to make sure the packets are > received ok... > > > Jeroen Brattinga wrote: > > > > That's common in TCP (and UDP) communications. Since you never really > > know how a packet is routed (one could be routed through Japan, the next > > through Russia, for instance), the order is something you have to keep > > track of. > > > > There are various ways to implement this (e.g. don't send a packet > > before you have received a packet), and it's one of the main things you > > have to keep in mind when implementing any network protocol! > > > > > > Jeroen Brattinga > > > > On Sun, 2007-12-16 at 03:04 -0800, pietry wrote: > >> It works, thanks a lot :) > >> > >> I also have another problem with TCP packages.. it seems that sometimes > >> they > >> reach in different order then i wrote to the Sessions. My question is : > >> is > >> this possible to be because of MINA or the settings i had to my server? > >> Or > >> it's a bug in my code ? > >> > >> > >> > >> Jeroen Brattinga wrote: > >> > > >> > You're propable using the TextLineDecoder? Then you have to set the > >> > maximum line length property (which defaults to 1KB). Use the > >> > setMaxLineLength method to do this. > >> > > >> > Jeroen Brattinga > >> > > >> > > >> > On Sun, 2007-12-16 at 01:43 -0800, pietry wrote: > >> >> I tried to increase the mina buffer sizes ( both receive and send) but > >> >> this > >> >> still has no success. I always get the same exception : > >> >> buffer.org.apache.mina.common.BufferDataException: Line is too long: > >> 2954 > >> >> (Hexdump: empty) > >> >> Used this getSessionConfig().setReceiveBufferSize(); > >> >> and getSessionConfig().setSendBufferSize(); > >> >> Any suggestions ? > >> > > >> > > >> > > >> > > > > > > >
Re: Maximum buffer
Shouldnt the TCP/IP protocol handle this? The TCP specs say that it makes sure all packets are delivered, no losses and no misorder... The protocol can't be implemented response-based so there is nothing i can do in this matter.. hoped there would be a way to make sure the packets are received ok... Jeroen Brattinga wrote: > > That's common in TCP (and UDP) communications. Since you never really > know how a packet is routed (one could be routed through Japan, the next > through Russia, for instance), the order is something you have to keep > track of. > > There are various ways to implement this (e.g. don't send a packet > before you have received a packet), and it's one of the main things you > have to keep in mind when implementing any network protocol! > > > Jeroen Brattinga > > On Sun, 2007-12-16 at 03:04 -0800, pietry wrote: >> It works, thanks a lot :) >> >> I also have another problem with TCP packages.. it seems that sometimes >> they >> reach in different order then i wrote to the Sessions. My question is : >> is >> this possible to be because of MINA or the settings i had to my server? >> Or >> it's a bug in my code ? >> >> >> >> Jeroen Brattinga wrote: >> > >> > You're propable using the TextLineDecoder? Then you have to set the >> > maximum line length property (which defaults to 1KB). Use the >> > setMaxLineLength method to do this. >> > >> > Jeroen Brattinga >> > >> > >> > On Sun, 2007-12-16 at 01:43 -0800, pietry wrote: >> >> I tried to increase the mina buffer sizes ( both receive and send) but >> >> this >> >> still has no success. I always get the same exception : >> >> buffer.org.apache.mina.common.BufferDataException: Line is too long: >> 2954 >> >> (Hexdump: empty) >> >> Used this getSessionConfig().setReceiveBufferSize(); >> >> and getSessionConfig().setSendBufferSize(); >> >> Any suggestions ? >> > >> > >> > >> > > > -- View this message in context: http://www.nabble.com/Maximum-buffer-tp14360017s16868p14360895.html Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.
Re: Maximum buffer
That's common in TCP (and UDP) communications. Since you never really know how a packet is routed (one could be routed through Japan, the next through Russia, for instance), the order is something you have to keep track of. There are various ways to implement this (e.g. don't send a packet before you have received a packet), and it's one of the main things you have to keep in mind when implementing any network protocol! Jeroen Brattinga On Sun, 2007-12-16 at 03:04 -0800, pietry wrote: > It works, thanks a lot :) > > I also have another problem with TCP packages.. it seems that sometimes they > reach in different order then i wrote to the Sessions. My question is : is > this possible to be because of MINA or the settings i had to my server? Or > it's a bug in my code ? > > > > Jeroen Brattinga wrote: > > > > You're propable using the TextLineDecoder? Then you have to set the > > maximum line length property (which defaults to 1KB). Use the > > setMaxLineLength method to do this. > > > > Jeroen Brattinga > > > > > > On Sun, 2007-12-16 at 01:43 -0800, pietry wrote: > >> I tried to increase the mina buffer sizes ( both receive and send) but > >> this > >> still has no success. I always get the same exception : > >> buffer.org.apache.mina.common.BufferDataException: Line is too long: 2954 > >> (Hexdump: empty) > >> Used this getSessionConfig().setReceiveBufferSize(); > >> and getSessionConfig().setSendBufferSize(); > >> Any suggestions ? > > > > > > >
Re: Maximum buffer
It works, thanks a lot :) I also have another problem with TCP packages.. it seems that sometimes they reach in different order then i wrote to the Sessions. My question is : is this possible to be because of MINA or the settings i had to my server? Or it's a bug in my code ? Jeroen Brattinga wrote: > > You're propable using the TextLineDecoder? Then you have to set the > maximum line length property (which defaults to 1KB). Use the > setMaxLineLength method to do this. > > Jeroen Brattinga > > > On Sun, 2007-12-16 at 01:43 -0800, pietry wrote: >> I tried to increase the mina buffer sizes ( both receive and send) but >> this >> still has no success. I always get the same exception : >> buffer.org.apache.mina.common.BufferDataException: Line is too long: 2954 >> (Hexdump: empty) >> Used this getSessionConfig().setReceiveBufferSize(); >> and getSessionConfig().setSendBufferSize(); >> Any suggestions ? > > > -- View this message in context: http://www.nabble.com/Maximum-buffer-tp14360017s16868p14360544.html Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.
Re: Maximum buffer
You're propable using the TextLineDecoder? Then you have to set the maximum line length property (which defaults to 1KB). Use the setMaxLineLength method to do this. Jeroen Brattinga On Sun, 2007-12-16 at 01:43 -0800, pietry wrote: > I tried to increase the mina buffer sizes ( both receive and send) but this > still has no success. I always get the same exception : > buffer.org.apache.mina.common.BufferDataException: Line is too long: 2954 > (Hexdump: empty) > Used this getSessionConfig().setReceiveBufferSize(); > and getSessionConfig().setSendBufferSize(); > Any suggestions ?
Maximum buffer
I tried to increase the mina buffer sizes ( both receive and send) but this still has no success. I always get the same exception : buffer.org.apache.mina.common.BufferDataException: Line is too long: 2954 (Hexdump: empty) Used this getSessionConfig().setReceiveBufferSize(); and getSessionConfig().setSendBufferSize(); Any suggestions ? -- View this message in context: http://www.nabble.com/Maximum-buffer-tp14360017s16868p14360017.html Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.
