Re: How to increase MINA application performance

[Maarten Bosteels]

Nikfarjam,

If your system has 2Gb of RAM, why are you only assigning 512M of it
to the JVM ?

Maarten

On Jan 14, 2008 8:59 AM, Nikfarjam <[EMAIL PROTECTED]> wrote:
>
> Dear Mr Lécharny
> Thanks for guidance.
> Our project is producing a gateway with
>  payload < 256 byte
>  avg 2000 msg/s
>  with limited clients (less than 10)
>
>  Reliability and performance are two key factors for us.
>
>  The machine that we used for running our application had these
> specifications:
>  - CPU Intel(R) Xeon(R) 5160 3.00GHz  (4 cores)
>  - Ram 2GB
>  - OS Debian
>  - JRE 6 with JVM options
>  > -server -Xms512m -Xmx512m -Xss128k -XX:+AggressiveOpts -XX:+UseParallelGC
> -XX:+UseBiasedLocking  -XX:NewSize=64m
>
>  And we faced these problems:
>  - a huge difference between our result and
> http://mina.apache.org/documentation.data/ACAsia2006.pdf ACAsia2006.pdf 's
> result. (page 7)
>  our message per second is less than 1000.
>  - Memory heap error witch we mentioned before.
>  best regards.
> --
> View this message in context: 
> http://www.nabble.com/How-to-increase-MINA-application-performance-tp14796729s16868p14796729.html
> Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.
>
>

How to increase MINA application performance

[Nikfarjam]

Dear Mr Lécharny
Thanks for guidance.
Our project is producing a gateway with
 payload < 256 byte
 avg 2000 msg/s
 with limited clients (less than 10)

 Reliability and performance are two key factors for us.

 The machine that we used for running our application had these
specifications:
 - CPU Intel(R) Xeon(R) 5160 3.00GHz  (4 cores)
 - Ram 2GB
 - OS Debian
 - JRE 6 with JVM options
 > -server -Xms512m -Xmx512m -Xss128k -XX:+AggressiveOpts -XX:+UseParallelGC
-XX:+UseBiasedLocking  -XX:NewSize=64m

 And we faced these problems:
 - a huge difference between our result and 
http://mina.apache.org/documentation.data/ACAsia2006.pdf ACAsia2006.pdf 's
result. (page 7)
 our message per second is less than 1000.
 - Memory heap error witch we mentioned before.
 best regards.
-- 
View this message in context: 
http://www.nabble.com/How-to-increase-MINA-application-performance-tp14796729s16868p14796729.html
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.

can anyone do me a favour

[张园]

My dear friends,

I got a question when I read the source code,how is the SocketIoProcessor
class dealing the situation that the buf is smaller than the data expected
in the SocketChannel?

sorry for my poor English.

Source code in the SocketIoProcessor class  

private void read(SocketSessionImpl session) {

ByteBuffer buf = ByteBuffer.allocate(session.getReadBufferSize());

SocketChannel ch = session.getChannel();

 

try {

int readBytes = 0;

int ret;

 

try {

while ((ret = ch.read(buf.buf())) > 0) {

readBytes += ret;

}

} finally {

buf.flip();

}

 

session.increaseReadBytes(readBytes);

 

if (readBytes > 0) {

session.getFilterChain().fireMessageReceived(session, buf);

buf = null;

 

if (readBytes * 2 < session.getReadBufferSize()) {

session.decreaseReadBufferSize();

} else if (readBytes == session.getReadBufferSize()) {

session.increaseReadBufferSize();

}

}

if (ret < 0) {

scheduleRemove(session);

}

} catch (Throwable e) {

if (e instanceof IOException)

scheduleRemove(session);

session.getFilterChain().fireExceptionCaught(session, e);

} finally {

if (buf != null)

buf.release();

}

}

 

Best  regards,
Andy (张园)
Mobile Internet Division
---
Address: Building A9,Neusoft Park,No.2 Xinxiu Street,Hunnan 
 Industrial Park ,Shenyang 110179, PRC
Tel: +86 024 83669709 13998390079
  Email:[EMAIL PROTECTED]
Website: http://www.neusoft.com 

 



--
Confidentiality Notice: The information contained in this e-mail and any 
accompanying attachment(s) is intended only for the use of the intended 
recipient and may be confidential and/or privileged of Neusoft Group Ltd., its 
subsidiaries and/or its affiliates. If any reader of this communication is not 
the intended recipient, unauthorized use, forwarding, printing, storing, 
disclosure or copying is strictly prohibited, and may be unlawful. If you have 
received this communication in error, please immediately notify the sender by 
return e-mail, and delete the original message and all copies from your system. 
Thank you. 
---

Re: SSLFilter problem on closing connection

[Kerekes András]

Hi,

did anybody encounter the problem described below using SSL?

Cheers,
András

Kerekes András wrote:

Hi,

I found an interesting issue when using SSL communication in Mina 
1.1.5 (and 1.1.3) . I use a custom protocol with custom message 
classes, one of them is LogoutMessage. When this is sent, it signals 
the server that the client is finishing the communication. After 
sending the LogoutMessage and receiving the corresponding response the 
client closes the session with: ioSession.close().join()


And this throws an exception:

Unexpected exception from SSLEngine.closeInbound().
javax.net.ssl.SSLException: Inbound closed before receiving peer's 
close_notify: possible truncation attack?

   at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source)
   at com.sun.net.ssl.internal.ssl.SSLEngineImpl.fatal(Unknown Source)
   at com.sun.net.ssl.internal.ssl.SSLEngineImpl.fatal(Unknown Source)
   at com.sun.net.ssl.internal.ssl.SSLEngineImpl.closeInbound(Unknown 
Source)
   at 
org.apache.mina.filter.support.SSLHandler.destroy(SSLHandler.java:167)

   at org.apache.mina.filter.SSLFilter.sessionClosed(SSLFilter.java:367)
   at 
org.apache.mina.common.support.AbstractIoFilterChain.callNextSessionClosed(AbstractIoFilterChain.java:269) 

   at 
org.apache.mina.common.support.AbstractIoFilterChain.access$800(AbstractIoFilterChain.java:53) 

   at 
org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.sessionClosed(AbstractIoFilterChain.java:633) 

   at 
org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java:230) 

   at 
org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(ExecutorFilter.java:264) 

   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown 
Source)

   at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
   at 
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51) 


   at java.lang.Thread.run(Unknown Source)

The server closes the connection normally. We made extensive debugging 
and it seems the when the client closes the session and the SSLFilter 
calls the initiateClosure method it sends the close_notification to 
the server but does not receive the confirmation from the server side. 
The same happens when the server initiates the closing of the session 
after sending the LogoutResponse, but this time the exception is 
thrown at the server side.


The reason for this behavior seems to be that the IoSession is removed 
in the SocketIoProcessor's worker thread at the doRemove() call, and 
the execution hits the 'break;' line so the infinite loop terminates 
and by the time the response (confirming the close notification) from 
the other end of the communication arrives there is no IoProcessor to 
process the message and let the SSLFilter close the SSL session properly.


I've attached a small example which produces this issue.

Is it a bug or am I doing something wrong?

Thanks for the help!
Andras

Re: How to increase MINA application performance

[Emmanuel Lecharny]

Nikfarjam wrote:

Dear Mr Lécharny
Thanks for guidance.
Our project is producing a gateway with
 payload < 256 byte
 avg 2000 msg/s
 with limited clients (less than 10)

 Reliability and performance are two key factors for us.

 The machine that we used for running our application had these
specifications:
 - CPU Intel(R) Xeon(R) 5160 3.00GHz  (4 cores)
 - Ram 2GB
 - OS Debian
 - JRE 6 with JVM options
 > -server -Xms512m -Xmx512m -Xss128k -XX:+AggressiveOpts -XX:+UseParallelGC
-XX:+UseBiasedLocking  -XX:NewSize=64m

 And we faced these problems:
 - a huge difference between our result and 
http://mina.apache.org/documentation.data/ACAsia2006.pdf ACAsia2006.pdf 's

result. (page 7)
 our message per second is less than 1000.
  
FYI, we are reaching more than 4500 msg/s on Apache Directory Server, 
which use Mina 1.1.4. Considering that a hell lot of processing is done 
on the backend part of our server, I'm pretty confident that Mina can 
process largely more than 10 000 req/s.


I'm wondering if you have not some kind of bottleneck somewhere in your 
program : likely the number of threads you are using to process the 
messages. Which kind of CPU load do you have when running your server? 
Is the System CPU is above 15% ? When you generate a HeapDump, how many 
threads are running concurrently ? Otherwise, if you get a OOM, may be 
you are not releasing the connections after having closed them, leading 
to such a problem.


Anyway, Maarten is right, as you have 2Gb on your box, use it for your 
Java app. As it's somehow a critical system for you, I don't think any 
other process will use the remaining 1.5 Gb ...


There are so many different potential problem that it's almost 
impossible, without the code, to tell what can goes wrong in your 
server. And getting the full code of your server won't help anyway, 
unless you strip everything which is not MINA related, and if you are 
not able to reproduce the very same problem in the smallest possible 
code base.


Keep in mind that MINA is widely used by people who have the very same 
requirements you have, and they are quite happy with it. You may have 
found a memory leak in MINA itself, but I would say it's very unlikely. 
Keep searching in your own code, this is a 99% way to get the solution. 
If you fell into the unpleasant 1%, I hope that while doing your 
experiments, you will find the MINA piece of code we have to fix, and 
you will provide us with that fix !




--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Can i use MINA to develop a telnet client that will communicate with exsiting SunOS telnet server?

[nickylba]

I am developing an application that will send "telnet"requests to different
servers with existing SunOS telnet daemons. The total number of servers will
be about 2000.
It is very likely that i will use MINA. But I don't know how to implement
the protocol detail. Would you please do me a favor to tell me:
1) how or where can i implement the telnet protocol with MINA?
2) Whether the client's requests using MINA will be understanded by existing
telnet daemons?

I am very appreciate your help!
-- 
View this message in context: 
http://www.nabble.com/Can-i-use-MINA-to-develop-a-telnet-client-that-will-communicate-with-exsiting-SunOS-telnet-server--tp14800541s16868p14800541.html
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.

Apache MINA Board Report, January 2008

[Trustin Lee]

Here's the January 2008 board report for the Apache MINA project.
(http://mina.apache.org)

Releases

We cut four minor releases: 1.0.7, 1.0.8, 1.1.4 and 1.1.5.  The new
releases contain backward-compatible minor improvements and bug fixes.

Community
=
FtpServer project has been graduated from the Incubator into the MINA
project.  It is in progress to merge the two web sites into one
seamlessly, and other infrastructure-related changes are being
discussed.  Niklas Gustavsson joined the MINA PMC as the lead of the
FtpServer project.

Jeff Genender, a member of the foundation and a MINA enthusiast,
joined the MINA PMC.  His primary focus is to implement high
performance asynchronous HTTP client implementation, along with HTTP
server implementation.  These client-server implementations are not a
stand-alone application but a library on top of the MINA framework, so
it will be the best fit together.

There was a serious discussion about changing logging framework of
MINA 2 in the mailing list, and we concluded to stick to the current
logging framework (i.e. SLF4J).  Instead, Trustin Lee will provide a
tool that converts a JAR which depends on a logging framework A into a
new JAR which depends on a logging framework B.  Maarten Bosteels is
also working with SLF4J team to make it more friendly with more
logging frameworks such as java.util.logging, which will simplify MINA
logging significantly.  The bottom line is that we will be able to
resolve every community member's concern with MINA 2 hopefully.

The community itself seems to be growing up and up steadily.  Please
refer to the markmail.org traffic graph: http://mina.markmail.org/  We
are seeing decreased traffic on December 2007, but it's probably due
to holidays.

Features

Julien Vermillard and Trustin Lee finished implementation of APR
transport.  This means MINA now can utilize ASF's high performance
cross platform library for network operations.  It seems to perform
10% better than the Sun epoll NIO provider.  Switching from NIO to APR
takes just a few minutes.

JMX integration has been rewritten, which means all MINA-based
applications are manageable via JMX very easily.

Synchronous reader API has been implemented.  MINA is basically an
asynchronous framework so some client developers will benefit from
this new feature.

The OSGi integration issue reported in the last report has been resolved.

Issues
==
We need to finish migration of FtpServer and release MINA 2.0.0-M1
this quarter to catch up the users' demand.  We might need more
committers who has good will for keeping MINA project run.

Cheers,
Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: Apache MINA Board Report, January 2008

[Emmanuel Lecharny]

Hi Trustin !

Trustin Lee wrote:

Jeff Genender, a member of the foundation and a MINA enthusiast,
joined the MINA PMC.  

So far, he is just one of our committer :)

--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: WriteFuture clarification

[Mark]

I am using netcat in cygwin.  I will continue to look into this.  Maybe some
others on the list have ideas...

On Jan 12, 2008 4:07 AM, Luis Neves <[EMAIL PROTECTED]> wrote:

> Hello,
>
> Mark wrote:
> > This is my output:
> >
> > Listening on port 1234
> > Session Opened
> > Time for write:31 ms
> > Time for write:32 ms
>
> This is much different from my results.
> Are you using netcat to test? Does the windows version of netcat honours
> the
> "-i" flag?
>
> Here's the output I get after writing 1 messages:
>
> Listening on port 1234
> Time for write:21 ms
> Time for write:20881 ms
> Time for write:32 ms
> Time for write:31 ms
> Time for write:30 ms
> Time for write:30 ms
> Time for write:21 ms
> Time for write:21 ms
> Time for write:21 ms
> Time for write:21161 ms
> Time for write:12652 ms
> Time for write:2488 ms
> Time for write:22530 ms
> Time for write:12585 ms
> Time for write:7513 ms
> Time for write:12457 ms
>
>
>
> > My setup is:
> > Windows XP
> > Dual Core 1.66GHz
> > 2GB RAM
>
> Over here the specs are:
> Linux 2.6.22-14
> Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_03-b05, mixed mode)
> Core2 Duo CPU T7700 @2.40GHz
> 4GB RAM
>
> > I am certain that none of this information will help your problem, but
> maybe
> > it will convince you that there is not necessarily a problem with the
> MINA
> > API.
>
> I'm not saying there is, like the subject says I'm just looking for
> clarification on how to use Mina do to what I want.
>
> Thanks for your help!
> --
> Luis Neves
>
>


-- 

Talent hits a target no one else can hit; Genius hits a target no one else
can see.

Re: WriteFuture clarification

[Emmanuel Lecharny]

Luis Filipe dos Santos Neves wrote:

Mark wrote:
  

Does not sound like it is working as planned.  Do you have a test program
that demonstrates this behavior?



Yes. You can test the code below using netcat:
nc -i 5 localhost 1234
  

I get an error while executing your code :

Exception in thread "main" java.lang.NoSuchMethodError: 
org.apache.mina.common.AbstractIoService.getTransportMetadata()Lorg/apache/mina/common/TransportMetadata;
   at 
org.apache.mina.common.AbstractIoService.(AbstractIoService.java:132)
   at 
org.apache.mina.common.AbstractIoAcceptor.(AbstractIoAcceptor.java:58)
   at 
org.apache.mina.common.AbstractPollingIoAcceptor.(AbstractPollingIoAcceptor.java:92)
   at 
org.apache.mina.common.AbstractPollingIoAcceptor.(AbstractPollingIoAcceptor.java:80)
   at 
org.apache.mina.transport.socket.nio.NioSocketAcceptor.(NioSocketAcceptor.java:64)

   at Test.main(Test.java:23)

I'm using MINA-2.0.0-M1-SNAPSHOT (freshly got from trunk) and Java 1.5.0-12.

Any clue ?

--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: WriteFuture clarification

[Luis Neves]

Emmanuel Lecharny wrote:

Luis Filipe dos Santos Neves wrote:

Mark wrote:
 
Does not sound like it is working as planned.  Do you have a test 
program

that demonstrates this behavior?



Yes. You can test the code below using netcat:
nc -i 5 localhost 1234
  

I get an error while executing your code :

Exception in thread "main" java.lang.NoSuchMethodError: 
org.apache.mina.common.AbstractIoService.getTransportMetadata()Lorg/apache/mina/common/TransportMetadata; 

   at 
org.apache.mina.common.AbstractIoService.(AbstractIoService.java:132)
   at 
org.apache.mina.common.AbstractIoAcceptor.(AbstractIoAcceptor.java:58) 

   at 
org.apache.mina.common.AbstractPollingIoAcceptor.(AbstractPollingIoAcceptor.java:92) 

   at 
org.apache.mina.common.AbstractPollingIoAcceptor.(AbstractPollingIoAcceptor.java:80) 

   at 
org.apache.mina.transport.socket.nio.NioSocketAcceptor.(NioSocketAcceptor.java:64) 


   at Test.main(Test.java:23)

I'm using MINA-2.0.0-M1-SNAPSHOT (freshly got from trunk) and Java 
1.5.0-12.


Any clue ?


No, no clue. I just upgraded to trunk (rev. 611827) and I have no such error.
Perhaps you have some stale files in your build?


--
Luis Neves

Re: WriteFuture clarification

[Emmanuel Lecharny]

Luis Neves wrote:

Emmanuel Lecharny wrote:

Luis Filipe dos Santos Neves wrote:

Mark wrote:
 
Does not sound like it is working as planned.  Do you have a test 
program

that demonstrates this behavior?



Yes. You can test the code below using netcat:
nc -i 5 localhost 1234
  

I get an error while executing your code :

Exception in thread "main" java.lang.NoSuchMethodError: 
org.apache.mina.common.AbstractIoService.getTransportMetadata()Lorg/apache/mina/common/TransportMetadata; 

   at 
org.apache.mina.common.AbstractIoService.(AbstractIoService.java:132) 

   at 
org.apache.mina.common.AbstractIoAcceptor.(AbstractIoAcceptor.java:58) 

   at 
org.apache.mina.common.AbstractPollingIoAcceptor.(AbstractPollingIoAcceptor.java:92) 

   at 
org.apache.mina.common.AbstractPollingIoAcceptor.(AbstractPollingIoAcceptor.java:80) 

   at 
org.apache.mina.transport.socket.nio.NioSocketAcceptor.(NioSocketAcceptor.java:64) 


   at Test.main(Test.java:23)

I'm using MINA-2.0.0-M1-SNAPSHOT (freshly got from trunk) and Java 
1.5.0-12.


Any clue ?


No, no clue. I just upgraded to trunk (rev. 611827) and I have no such 
error.

Perhaps you have some stale files in your build?

I don't think so... I just rm -rf everything under the MINA src directory...

I will doom my maven repo and see if it's better.



--
Luis Neves




--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: WriteFuture clarification

[Emmanuel Lecharny]

Luis Neves wrote:

Emmanuel Lecharny wrote:

Luis Filipe dos Santos Neves wrote:

Mark wrote:
 
Does not sound like it is working as planned.  Do you have a test 
program

that demonstrates this behavior?



Yes. You can test the code below using netcat:
nc -i 5 localhost 1234
  

I get an error while executing your code :

Exception in thread "main" java.lang.NoSuchMethodError: 
org.apache.mina.common.AbstractIoService.getTransportMetadata()Lorg/apache/mina/common/TransportMetadata; 

   at 
org.apache.mina.common.AbstractIoService.(AbstractIoService.java:132) 

   at 
org.apache.mina.common.AbstractIoAcceptor.(AbstractIoAcceptor.java:58) 

   at 
org.apache.mina.common.AbstractPollingIoAcceptor.(AbstractPollingIoAcceptor.java:92) 

   at 
org.apache.mina.common.AbstractPollingIoAcceptor.(AbstractPollingIoAcceptor.java:80) 

   at 
org.apache.mina.transport.socket.nio.NioSocketAcceptor.(NioSocketAcceptor.java:64) 


   at Test.main(Test.java:23)

I'm using MINA-2.0.0-M1-SNAPSHOT (freshly got from trunk) and Java 
1.5.0-12.


Any clue ?


No, no clue. I just upgraded to trunk (rev. 611827) and I have no such 
error.

Perhaps you have some stale files in your build?
ok, it works now. 


Very same resuts :

Time for write:15161 ms
Time for write:10181 ms
Time for write:22 ms
Time for write:10584 ms
Time for write:21 ms
Time for write:15184 ms
Time for write:10493 ms
Time for write:24 ms
Time for write:5365 ms
Time for write:21 ms
Time for write:24 ms
Time for write:15269 ms
...





--
Luis Neves




--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: Moving over FtpServer

[Niklas Gustavsson]

Mark wrote:

I realized that I have to build each subproject separately (I really need to
get some sleep).  I was able to get the core working, but I get a POM
validation error when running the "mvn eclipse:eclipse" command in
admin-gui.


My bad, should be fixed now.

/niklas

[jira] Updated: (DIRMINA-502) Typo in POM

[Trustin Lee (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Trustin Lee updated DIRMINA-502:


Fix Version/s: 1.1.6
   1.0.9
 Assignee: Trustin Lee
Affects Version/s: (was: 2.0.0-M1)
   1.0.8
   1.1.5

> Typo in POM
> ---
>
> Key: DIRMINA-502
> URL: https://issues.apache.org/jira/browse/DIRMINA-502
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.0.8, 1.1.5
>Reporter: Rich Dougherty
>Assignee: Trustin Lee
>Priority: Trivial
> Fix For: 1.0.9, 1.1.6
>
>
> Hi
> Just another small thing. There's an "h" missing from one of the URLs in the 
> POM. You can see the typo below:
>   
> Apache MINA Project
> http://mina.apace.org/
>   
> Rich

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (DIRMINA-502) Typo in POM

[Trustin Lee (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Trustin Lee resolved DIRMINA-502.
-

Resolution: Fixed

Thanks!  It has been fixed. :)

> Typo in POM
> ---
>
> Key: DIRMINA-502
> URL: https://issues.apache.org/jira/browse/DIRMINA-502
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.0.8, 1.1.5
>Reporter: Rich Dougherty
>Assignee: Trustin Lee
>Priority: Trivial
> Fix For: 1.0.9, 1.1.6
>
>
> Hi
> Just another small thing. There's an "h" missing from one of the URLs in the 
> POM. You can see the typo below:
>   
> Apache MINA Project
> http://mina.apace.org/
>   
> Rich

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-505) OOM errors when handling badly formed HTTP requests

[Trustin Lee (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12558916#action_12558916
 ] 

Trustin Lee commented on DIRMINA-505:
-

I've just checked in a possible fix.  Could you test if it doesn't cause OOM 
anymore or not?  Additionally, any jmap dump file is appreciated.

> OOM errors when handling badly formed HTTP requests
> ---
>
> Key: DIRMINA-505
> URL: https://issues.apache.org/jira/browse/DIRMINA-505
> Project: MINA
>  Issue Type: Bug
>  Components: Protocol - HTTP, Statemachine
>Affects Versions: 2.0.0-M2
>Reporter: Luis Neves
>
> Badly formed HTTP Requests can make the HTTP decoder to cause OOM errors.
> The following request captured with the command "tcpdump -nnASs 0 'dst port 
> 80'" is an example of such request (beware wrapping):
> **
> 21:26:55.828483 IP 83.174.45.34.59872 > 213.13.146.84.80: S 
> 3131042262:3131042262(0) win 65535  13682342 0>
> .T...P...
> 
> 21:26:55.828606 IP 89.181.19.190.64449 > 213.13.146.84.80: . ack 4109384713 
> win 16407
> .T...Py'<[EMAIL PROTECTED]
> 21:26:55.837645 IP 83.174.45.34.59872 > 213.13.146.84.80: . ack 12756759 win 
> 65535 
> .T...P...
> 1...
> 21:26:55.838271 IP 82.155.88.187.3485 > 213.13.146.84.80: . ack 4268305021 
> win 17021
> ..Pei*}P.B}.|
> 21:26:55.838317 IP 83.174.45.34.59872 > 213.13.146.84.80: P 
> 3131042263:3131043023(760) ack 12756759 win 65535  221364412>
> .T...P]..
> 1..GET /analytics.js HTTP/1.1
> Host: wa.sl.pt
> Pragma: no-cache
> accept-language: pt
> ua-os: Windows CE (Smartphone) - Version 5.2
> ua-color: color16
> x-wap-profile: "http://www.htcmms.com.tw/gen/Volans-1.0.xml";
> ua-voice: TRUE
> referer: http://auto.sapo.pt/vehicleDetails.aspx
> --
> user-agent: HTC_S730 Mozilla/4.0 (compatible; MSIE 6.0; Windows CE; IEMobile 
> 7.6)
> x-wsb-contextid: D51E281020EEAF0E
> accept: application/vnd.wap.mms-message;*/*,*/*;q=0.001
> accept-charset: *;q=0.001
> accept-encoding: gzip,deflate,*;q=0.001
> Max-Forwards: 10
> Connection: Keep-Alive
> X-BlueCoat-Via: 80B23F200A28D3DE
> **
> Another source of problems are requests that have Header names but no Header 
> values, e.g:
> **
> 21:12:36.953721 IP 87.103.25.114.4160 > 213.13.146.84.80: . ack 3029163034 
> win 32224
> [EMAIL PROTECTED]
> 21:12:37.060742 IP 89.26.250.104.4602 > 213.13.146.84.80: S 
> 2765090470:2765090470(0) win 16384 
> [EMAIL PROTECTED]
> 21:12:37.082011 IP 89.26.250.104.4602 > 213.13.146.84.80: . ack 3407385009 
> win 17680
> .T...PP.E..S
> 21:12:37.090524 IP 89.26.250.104.4602 > 213.13.146.84.80: P 
> 2765090471:2765090506(35) ack 3407385009 win 17680
> .T...PP.E.GET /robots.txt HTTP/1.0
> Host:
> **
> Notice the missing Host Header value.
> My local fix for these issues was to use bounded collections in 
> HttpHeaderDecodingState to hold Header information and to add extra sanity 
> checks for header values, a better solution will probably fix the issue at 
> the "state machine level".
> --
> Luis Neves

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: READ_STATUS_CODE bug in filter-codec-http State Machine

[Trustin Lee]

Hi Eric,

I simply removed AFTER_READ_STATUS_CODE state and it seems to work fine. :)
Please let me know if my fix works.

Thanks!
Trustin

On Jan 5, 2008 5:29 AM, Eric Gaumer <[EMAIL PROTECTED]> wrote:
> Hello All,
>
> I ran across another interesting problem today in handling status codes
> inside of:
>
> src/main/java/org/apache/mina/filter/codec/http/HttpResponseLineDecodingStat
> e.java
>
> This is mina-2.0 snapshot.
>
> I'm building an RSS client that needs to poll thousands of RSS channels. I'm
> using conditional gets as not to waste bandwidth.
>
> I noticed a particular site was raising a "Bad Status Code" exception
> whenever the server responded with a 304 (Not Modified).
>
> It seems that the server (Apache version ??) was sending back a status code
> without the Reason Phrase.
>
> I found the BNF notation that describes the Reason Phrase in RFC2616:
>
> http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i94
>
> Which states:
>
> TEXT   = 
> LWS= [CRLF] 1*( SP | HT )
> CRLF   = CR LF
> Reason-Phrase  = *
>
> This means that a Reason Phrase could be empty and still be considered valid
> (e.g., 0 or more Octets).
>
> The state machine expects to see a Reason Phrase and when it doesn't, it
> consumes part of the next header (Date) and then throws an exception trying
> to convert this value to an Integer.
>
> What I did was override the isTerminator() method for the
> ConsumeToLinearWhitespaceDecodingState adding a check for a CR.
>
> This stops the scanner from pulling in excess bytes. I wasn't sure how the
> remaining states would handle this but AFTER_READ_STATUS_CODE returns
> immediately as does READ_REASON_PHRASE (since we left a remaining LF byte on
> the input buffer) and we cleanly move to a final acceptance state.
>
> I've run about 500 feeds through this and nothing seems to have broke.
>
> Here's a patch:
>
> --- HttpResponseLineDecodingState.orig.java 2008-01-04
> 14:29:25.0 -0500
> +++ HttpResponseLineDecodingState.java  2008-01-04 14:28:40.0 -0500
> @@ -80,6 +80,10 @@
>  }
>  return AFTER_READ_STATUS_CODE;
>  }
> +@Override
> +protected boolean isTerminator(byte b) {
> +return b == 32 || b == 9 || b == 13;
> +}
>  };
>
>  private final DecodingState AFTER_READ_STATUS_CODE = new
> LinearWhitespaceSkippingState() {
>
>
> This _should_ be safe since the response line has to be terminated with a
> CR/LF pair. As long as we leave the LF byte, it's enough to satisfy the
> state requirements for the trailing states.
>
> You can use this site for testing. If you set the eTag you should get a 304
> with no Reason Phrase.
>
> http://www.mattweber.org/feed/
>
> Thanks,
> -Eric
>
> P.S. Did I mention how much fun I've been having with mina? Love it!
>
>
>



-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: Traffic Shape Filter

[Trustin Lee]

Hi Scott,

TrafficShapingFilter is far from perfection.  It will shape the
traffic in the long term.  It will not control the traffic inflows
within a very short amount time.

We need to figure out better way to shape traffic.

Trustin

On Jan 5, 2008 8:37 AM, Scott Peters <[EMAIL PROTECTED]> wrote:
> Are there any examples of how to use the Traffic Shaping filter?  I do
> not see any unit test cases so it brings to question if this filter has
> been tested or ready yet?
>
> With this code below I do not see any change in behavior that would show
> the throughput is being slowed down.
>
> My goal is to allow us to simulate different network through puts [
> GPRS, EDGE, T1, etc ] that different parts of our product use.
>
> 
> public static ScheduledExecutorService  s_scheduler
> Executors.newScheduledThreadPool(Runtime.getRuntime().availableProcessor
> s());
>
> Public sessionCreated(IoSession session)
> {
> ...
> TrafficShapingFilter tsf = new TrafficShapingFilter(s_scheduler,
> 100, 100);
> session.getFilterChain().addFirst(TRAFFIC_SHAPING_FILTER, tsf);
> ...
> }
> 
>
>
> Thank you,
> Scott Peters
>



-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: Mina filter-codec-http bug?

[Trustin Lee]

Your patch has been applied. Thanks again!

Cheers,
Trustin

On Jan 4, 2008 1:24 PM, Trustin Lee <[EMAIL PROTECTED]> wrote:
> Hi Eric,
>
> Thank you so much for your bug report.  I'm forwarding this message to
> our official mailing list for better and faster assistance.  :)
>
> HTH,
> Trustin
>
>
> On Jan 4, 2008 1:18 PM, Eric Gaumer <[EMAIL PROTECTED]> wrote:
> > Hey Trustin,
> >
> > I'm building an enterprise RSS retriever for submitting RSS feeds to a
> > search engine (leveraging meta data found in the channel).
> >
> > I was working in Python with Twisted but when I came across mina I decided
> > to port things over to Java. You've created a nice framework for
> > asynchronous sockets.
> >
> > I'm using a 2.0 snapshot from about a week ago.
> >
> > The protocol-http-client is geared more for connecting to a single site and
> > retrieving multiple pages. For the RSS fetcher, I need to connect to many
> > sites and fetch a single page.
> >
> > I removed the blocking call to connect and added a listener, etc... I am
> > using the filter-codec-http package because most of what's being done here
> > is over my head right now and I see no reason to re-implement it.
> >
> > Everything is running great. I'm able to fetch and parse 500 RSS channels in
> > about 41s and 4,175 RSS channels in 5m 59s. This is quite good considering
> > there is about 1s average latency just in a typical request/response.
> >
> > The one problem I have noticed is that I would get a fair amount (maybe 10%)
> > of IllegalArgumentExceptions. Initially I just removed the offending feeds
> > from my tests.
> >
> > Tonight I had a chance to return to these problematic feeds and investigate
> > further. After some tests, I found that they all used Chunked Transfer
> > Coding.
> >
> > Looking at the raw response and reviewing the code in
> > src/main/java/org/apache/mina/filter/codec/http/ChunkedBodyDecodingState.jav
> > a I found that the error was generated because of a space between the chunk
> > size and the CR/LF bytes.
> >
> > For instance:
> >
> >8a·(CR)(LF)
> >
> > Rather than:
> >
> >8a(CR)(LF)
> >
> > I've browsed the RFC but I won't claim to fully understand it all. Should
> > whitespace be handled or should an exception be thrown here?
> >
> > Here is an example with some debug output:
> >
> > Byte:13
> >
> > LENGTH:eb1
> >
> > Byte:13
> >
> > LENGTH:f48
> >
> > Byte:13
> >
> > LENGTH:15b
> >
> > Byte:13
> >
> > LENGTH:d77
> >
> > Byte:13
> >
> > LENGTH:b81
> >
> > Byte:13
> >
> > LENGTH:f39
> >
> > Byte:13
> >
> > LENGTH:d0
> >
> > Byte:13
> >
> > LENGTH:53b
> >
> > Byte:13
> >
> > LENGTH:3f30
> >
> > Byte:13
> >
> > LENGTH:3a1
> >
> > Byte:13
> >
> > LENGTH:e4c
> >
> > Byte:32
> >
> > Illegal Argument Here: 32
> >
> > Callback Exception: org.apache.mina.filter.codec.ProtocolDecoderException:
> > java.lang.IllegalArgumentException
> >
> > So you see that we read "8", "a", and " " which causes an exception inside
> > isTerminator()
> >
> > This happens on a fair amount of sites so I'm assuming it's valid to have
> > whitespace here? The RFC provides an EBNF style language but doesn't
> > explicitly mention anything about allowing whitespace here. Yet, some
> > servers seem to occasionally add this whitespace.
> >
> > At any rate here is a simple patch that I did which seems to make these
> > errors disappear.
> >
> >
> > --- ChunkedBodyDecodingState.orig.java  2008-01-03 22:48:14.0 -0500
> > +++ ChunkedBodyDecodingState.java   2008-01-03 22:49:34.0 -0500
> > @@ -94,7 +94,7 @@
> > .throwDecoderException("Expected a chunk length.");
> > }
> >
> > -String length = product.getString(asciiDecoder);
> > +String length = product.getString(asciiDecoder).trim();
> > lastChunkLength = Integer.parseInt(length, 16);
> > if (chunkHasExtension) {
> > return SKIP_CHUNK_EXTENSION;
> > @@ -106,7 +106,7 @@
> > @Override
> > protected boolean isTerminator(byte b) {
> > if (!(b >= '0' && b <= '9' || b >= 'a' && b <= 'f' || b >= 'A'
> > -&& b <= 'F')) {
> > +&& b <= 'F' || b == ' ')) {
> > if (b == '\r' || b == ';') {
> > chunkHasExtension = b == ';';
> > return true;
> >
> >
> > Maybe this is helpful to you. Thanks again for a great framework. I expect
> > to get much use out of it ;-)
> >
> > -Eric
> >
> >
> >
>
>
>
> --
> 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: Question regarding mina server with high load client

[Trustin Lee]

Hi Ashish,

I just cannot reproduce your problem.  I tested with the following code:

import java.io.BufferedReader;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.io.OutputStream;
import java.io.OutputStreamWriter;
import java.net.Socket;



public class Foo {
public static void main(String[] args) throws Exception {
Socket s = new Socket("localhost", 5683);
InputStream in = s.getInputStream();
OutputStream out = s.getOutputStream();
BufferedReader reader = new BufferedReader(new
InputStreamReader(in, "UTF-8"));
OutputStreamWriter writer = new OutputStreamWriter(out, "UTF-8");
while(true) {
writer.write("jmd\n");
writer.flush();
System.out.println(reader.readLine());
}
}
}


You might try the default charset instead of UTF-8 though.

HTH,
Trustin

On Jan 7, 2008 3:34 AM, Ashish Sharma <[EMAIL PROTECTED]> wrote:
> Hi
> I am using mina core 2 snap shot "mina-core-2.0.0-M1-20071219.081925-109".
>
> Here is the code snippet of the time server
>
> IoAcceptor acceptor = new NioSocketAcceptor();
>
> acceptor.getFilterChain().addLast("codec", new ProtocolCodecFilter(
> new TextLineCodecFactory(Charset.forName("UTF-8";
>
> acceptor.setHandler(new TimeServerHandler());
>
> acceptor.setDefaultLocalAddress(new InetSocketAddress(5683));
> acceptor.bind();
>
> complete code can be found at http://pastebin.com/f22ec4749
>
> I have executed the same program on both windows and linux platforms and the
> problem is the same. When my client connects to mina server, i can see a lot
> of "message written..." lines in server's terminal window but hardly any
> messages reach client. Here is the client code snippet.
>
> while(true) {
> writer.write("jmd\n");
> writer.flush();
> }
>
> A sleep of 10 solves the problem. But this behaviour seems to contradict
> this:
>
> I'm not able to answer your Q 1 and 3 right now, but I can assure you
> > that MINA can handle high load from many clients. We are using it into
> > Apache Directory Server, and were able to simulate this with hundreds of
> > clients and thousands of messages per second, for hours ( we did a test
> > which lasted 72 hours, for hundreds of millions messages).
> >
>
> I hope i am configuring something wrong here. Please let me know.
>
> Thanks
> Ashish
>
>
>
> On Dec 28, 2007 8:55 AM, Trustin Lee <[EMAIL PROTECTED]> wrote:
>
> > Hi Ashish,
> >
> > On Dec 28, 2007 2:21 AM, Ashish Sharma <[EMAIL PROTECTED]> wrote:
> > > Hi
> > >
> > > Recently I have been experimenting with mina core 2 and I have a few
> > > questions regarding the behaviour of mina in some sample programs I
> > made.
> > >
> > > here is the client code. its simple, it simply rams as many messages as
> > > possible into the server.
> > >
> > > http://pastebin.com/m14ac361e
> > >
> > > Now I made two servers. One mina based, which is simply the date/time
> > echo
> > > server as described in the documentation. The second one is a simple
> > "one
> > > thread per client" server. Here is the code
> > http://pastebin.com/m3a5a14a7
> > >
> > > Now the result from both the servers differ a lot. The second server
> > works
> > > in lock step with client and responds to messages without any delay. But
> > > with mina server the response is very slow and after about 10 messages
> > the
> > > response is almost nill and after a few seconds I start getting out of
> > > memory exceptions while creating more date objects.
> > >
> > >
> > > Now I have the following questions (I very good spirit)
> > >
> > > 1. What is the reason behind this behaviour ?
> >
> > Please make sure that you are using heap buffers and configured the
> > thread model correctly.  And I hope you are using the latest stable
> > release.
> >
> > > 3. Is there a solution to this ? IMHO, first server example demonstrates
> > > that such high load can be handled at server.
> >
> > If your client connects and disconnects very frequently, it might slow
> > down your MINA application.  Please try to keep the connection alive
> > whenever possible.
> >
> > HTH,
> > 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

[jira] Resolved: (DIRMINA-508) org.apache.mina.filter.reqres.Request creates LinkedBlockingQueue when not required

[Trustin Lee (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Trustin Lee resolved DIRMINA-508.
-

Resolution: Fixed
  Assignee: Trustin Lee

Thank for the patch Kevin.  It works flawlessly.  It has been checked in.

> org.apache.mina.filter.reqres.Request creates LinkedBlockingQueue when not 
> required
> ---
>
> Key: DIRMINA-508
> URL: https://issues.apache.org/jira/browse/DIRMINA-508
> Project: MINA
>  Issue Type: Improvement
>  Components: Filter
>Affects Versions: 2.0.0-M1
>Reporter: Kevin Koltzau
>Assignee: Trustin Lee
> Attachments: ondemandrequestqueue.diff
>
>
> Request always creates a LinkedBlockingQueue, even when the response queue 
> will not be used.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Question About ExcecutorFilter and OrderedThreadPoolExecutor

[Trustin Lee]

On Jan 5, 2008 9:28 AM, Geoff Cadien <[EMAIL PROTECTED]> wrote:
> The javadoc for OrderedThreadPoolExecutor states:
>
> The event order is never mixed up. (e.g. messageReceived is always invoked
> before sessionClosed or messageSent.)
>
> Does this apply when using an IoConnector as opposed to and IoAcceptor?  I
> seem to be having messageReceived called before messageSent in my IoHandler
> when using NioConnector to make outbound connections in conjuction with
> ExecutorFilter.  Which really isn't what I want. :-)

It's probably the I/O processor produced the events such an order due
to some reason.  Can you reproduce the same issue without inserting
any ExecutorFilter?  I guess you will still have the same issue after
removing OrderedThreadPoolExecutor.  Please let me know the result.

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: Catching IO exception

[Trustin Lee]

Hi James,

On Jan 1, 2008 8:02 AM, James Mansion <[EMAIL PROTECTED]> wrote:
> I'm having a play with mina-core-2.0.0-M1-20071221.061156-110
>
> I'm using slf4j-simple-1.4.3.
>
> If I add a LoggingFilter using addLast to the filter chain (as the first
> such addLast call), then the logging filter will use its
> EXCEPTION_CAUGHT if I have a socket client that connects, does not send
> anything, and then disconnects.
>
> The trace looks like:
>
> Listening on port 2960
> 10836 [NioProcessor-1] WARN org.apache.mina.filter.logging.LoggingFilter
> - [/127.0.0.1:4036] EXCEPTION:
> java.io.IOException: An existing connection was forcibly closed by the
> remote host
> at sun.nio.ch.SocketDispatcher.read0(Native Method)
> at sun.nio.ch.SocketDispatcher.read(Unknown Source)
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(Unknown Source)
> (and so on)
>
> Two things:
>
> 1) I'd like to receive this in the exceptionCaught method of my
> IoHandlerAdapter - and if I don't push the logger into the filter chain
> then its what happens.

That's weird.  I tried to reproduce this problem but failed.  Could
you provide reproducing source code?

> 2) It doesn't seem to be thrown for clients that connect, write a
> message (which I handle with a specialised codec) and then quites.

I think it depends on network status.  The client might not know if
the connection has been closed yet.

> I'd like to have the filter so I can turn on logging for the session and
> message events, but setting the log level to NONE for EXCEPTION_CAUGHT
> doesn't pass it on - it seems to consume it silently.
>
> Is there any way I can achieve what I want?  Ideally I'd like my
> exceptionCaught handler to be called first and to be able to filter the
> exception at that level, so that only exceptions I don't discard will be
> reported by the filter.

Any filter implementation is supposed to propagate EXCEPTION_CAUGHT
event to the next filter or the IoHandler, so what you are
experiencing might be a bug of a MINA filter or your filter
implementation, if you inserted your own filter.

> A further issue is that if I 'pass on' to super.exceptionCaught then I
> get 'please implement .exceptionCaught() for proper handling'
> and in the case of a client dumping the connection untidily without
> writing the exception repeats - nothing closes the session and the
> process spams its log.

The log message was added to force a user to override
exceptionCaught() method because we found some people forget to
override it and fails to spot a problem.

> Is the difference of behaviour between the cases of a client that does
> write and one that doesn't indicative of a bug?

Well.. I don't think so.  It would be really nice if you could come up
with some example code that reproduces the problem.

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: Simple SSL question from the FAQ

[Trustin Lee]

Hi James,

It means you need to set reader idle time and close the session when
your IoHandler is notified with sessionIdle event.

Trustin

On Jan 7, 2008 11:54 PM, James Apfel <[EMAIL PROTECTED]> wrote:
> Hi,
>
>  says
>
> "Server developers will also have to disconnect users who doesn't
> initiate SSL handshake."
>
> What does that exactly mean? Do I have to schedule a task that checks
> after 30 seconds or so if the SSL handshake was successful and if not
> drop the connection?
>
> Thanks
>  James
>



-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

RE: Traffic Shape Filter

[Scott Peters]

Trustin,

Thank you for the reply.  As 2.0 is not fully released yet I was not
sure what the state was of this new filter and it sounds like it is
still in the works.

For the time being we are looking into other options for traffic shaping
outside our emulators that sit on top of MINA.

FYI: I moved our stuff over to 2.0 a few weeks ago and the memory
footprint went down dramatically as well as CPU load dropped some.  We
were already using heap buffers in 1.1 for both the socket and SSL but
for 10k SSL client connections the overhead was still pretty high.  The
new version has been great.

Cheers,
-Scott

-Original Message-
From: Trustin Lee [mailto:[EMAIL PROTECTED] 
Sent: Monday, January 14, 2008 9:28 PM
To: dev@mina.apache.org
Subject: Re: Traffic Shape Filter

Hi Scott,

TrafficShapingFilter is far from perfection.  It will shape the
traffic in the long term.  It will not control the traffic inflows
within a very short amount time.

We need to figure out better way to shape traffic.

Trustin

On Jan 5, 2008 8:37 AM, Scott Peters <[EMAIL PROTECTED]> wrote:
> Are there any examples of how to use the Traffic Shaping filter?  I do
> not see any unit test cases so it brings to question if this filter
has
> been tested or ready yet?
>
> With this code below I do not see any change in behavior that would
show
> the throughput is being slowed down.
>
> My goal is to allow us to simulate different network through puts [
> GPRS, EDGE, T1, etc ] that different parts of our product use.
>
> 
> public static ScheduledExecutorService  s_scheduler
>
Executors.newScheduledThreadPool(Runtime.getRuntime().availableProcessor
> s());
>
> Public sessionCreated(IoSession session)
> {
> ...
> TrafficShapingFilter tsf = new
TrafficShapingFilter(s_scheduler,
> 100, 100);
> session.getFilterChain().addFirst(TRAFFIC_SHAPING_FILTER,
tsf);
> ...
> }
> 
>
>
> Thank you,
> Scott Peters
>



-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: [DISCUSS] Time to move AsyncHttpClient out of Sandbox

[Trustin Lee]

Hi Kevan,

On Jan 12, 2008 2:59 AM, Kevan Miller <[EMAIL PROTECTED]> wrote:
> Note that this is cross-posted to geronimo dev and mina dev lists...
> Hopefully the last one...
>
> Alex and Trustin,
> Thanks for the info... More below...
>
> On Jan 9, 2008, at 6:16 PM, Trustin Lee wrote:
>
> > Well, I think it's OK for the Geronimo team to fork AHC, and I'd like
> > to respect them if Jeff already gave the information that his AHC work
> > will be placed under MINA trunk.  They have their release schedule and
> > I don't want to let them wait for us.  They will need to migrate to
> > the official MINA AHC eventually though.  Jeff could show us better
> > road map for this.
>
> Sounds like a good plan. We wouldn't necessarily *have* to migrate,
> but I, for one, would expect that we'll *want* to migrate to Mina
> (once Mina was able to release the functionality and assuming Mina is
> as good as AHC... ;-)

AHC already depends on MINA.  For now, MINA has older version of AHC
as a submodule, and Jeff is trying to move the stuff in the G sandbox
here.

> Sangjin, Rick, *and* Jeff have been making a number of changes and
> enhancements to AHC in our sandbox. Looks like some nice stuff... I
> would assume you'd be interested in their work (and would guess they'd
> like to share it with you)? Best to work out those details on mina
> dev, I would think... Rick has been a G committer for a while...
> Sangjin is new to our community, but has been making a number of good
> contributions to AHC.

Sure we are! Please feel free to start to make contribution.  :)

BTW is there any express procedure for accepting the existing AHC
committers (i.e. Sangjin and Rick) in the MINA PMC?  As you know, they
are not ASF members and didn't contribute directly to the MINA project
so far.  I wonder what I am supposed to do.  Should I wait for some
patches from them just like we do for most people?

> Yet another list to subscribe to... ;-)

Welcome! ;)

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

[jira] Resolved: (DIRMINA-512) ProtocolDecoderException.getHexDump always returns 'empty'

[Trustin Lee (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Trustin Lee resolved DIRMINA-512.
-

Resolution: Fixed

Resolved.

> ProtocolDecoderException.getHexDump always returns 'empty'
> --
>
> Key: DIRMINA-512
> URL: https://issues.apache.org/jira/browse/DIRMINA-512
> Project: MINA
>  Issue Type: Bug
>  Components: Filter
>Affects Versions: 1.0.8, 1.1.5
>Reporter: Trustin Lee
>Assignee: Trustin Lee
>Priority: Minor
> Fix For: 1.0.9, 1.1.6
>
>
> Hakan Guleryuz <[EMAIL PROTECTED]> reported this issue:
> Hi,
> I have extended DemuxingProtocolCodecFactory with multiple codecs attached,
> When I send a message that is not parsed by any of the codecs I receive the
> ProtocolDecoderException exception from my handler:
> public void exceptionCaught(IoSession session, Throwable cause) throws
> Exception
> in my IoHandlerAdapter
> but here ProtocolDecoderException.getHexDump is always empty.
> The cause is here at the doDecode method of DemuxingProtocolCodecFactory
> .CumulativeProtocolDecoder class
>if (undecodables == decoders.length) {
>// Throw an exception if all decoders cannot decode
> data.
>String dump = in.getHexDump();
>in.position(in.limit()); // Skip data
>throw new ProtocolDecoderException(
>"No appropriate message decoder: " + dump);
>}
> It should be changed to something like
>if (undecodables == decoders.length) {
>// Throw an exception if all decoders cannot decode
> data.
>String dump = in.getHexDump();
>in.position(in.limit()); // Skip data
>ProtocolDecoderException e =  new
> ProtocolDecoderException(
>"No appropriate message decoder: " + dump);
>e.setHexDump(dump); <-- I believe, this is
> missed here
>throw e;
>}
> I have checked the source of 1.1.5 and the issue was still there.
> Thank you for all the efforts in the Mina framework.
> Hakan.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (DIRMINA-512) ProtocolDecoderException.getHexDump always returns 'empty'

[Trustin Lee (JIRA)]

ProtocolDecoderException.getHexDump always returns 'empty'
--

 Key: DIRMINA-512
 URL: https://issues.apache.org/jira/browse/DIRMINA-512
 Project: MINA
  Issue Type: Bug
  Components: Filter
Affects Versions: 1.1.5, 1.0.8
Reporter: Trustin Lee
Assignee: Trustin Lee
Priority: Minor
 Fix For: 1.0.9, 1.1.6


Hakan Guleryuz <[EMAIL PROTECTED]> reported this issue:

Hi,
I have extended DemuxingProtocolCodecFactory with multiple codecs attached,
When I send a message that is not parsed by any of the codecs I receive the
ProtocolDecoderException exception from my handler:
public void exceptionCaught(IoSession session, Throwable cause) throws
Exception
in my IoHandlerAdapter

but here ProtocolDecoderException.getHexDump is always empty.

The cause is here at the doDecode method of DemuxingProtocolCodecFactory
.CumulativeProtocolDecoder class
   if (undecodables == decoders.length) {
   // Throw an exception if all decoders cannot decode
data.
   String dump = in.getHexDump();
   in.position(in.limit()); // Skip data
   throw new ProtocolDecoderException(
   "No appropriate message decoder: " + dump);
   }
It should be changed to something like
   if (undecodables == decoders.length) {
   // Throw an exception if all decoders cannot decode
data.
   String dump = in.getHexDump();
   in.position(in.limit()); // Skip data
   ProtocolDecoderException e =  new
ProtocolDecoderException(
   "No appropriate message decoder: " + dump);
   e.setHexDump(dump); <-- I believe, this is
missed here
   throw e;
   }

I have checked the source of 1.1.5 and the issue was still there.

Thank you for all the efforts in the Mina framework.
Hakan.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: ProtocolDecoderException.getHexDump always returns 'empty'

[Trustin Lee]

Hi Hakan,

I've just checked in the fix.  Please let me know if it works or not.

Thanks,
Trustin

On Jan 10, 2008 8:45 PM, Hakan Guleryuz <[EMAIL PROTECTED]> wrote:
>
> Hi,
> I have extended DemuxingProtocolCodecFactory with multiple codecs attached,
> When I send a message that is not parsed by any of the codecs I receive the
> ProtocolDecoderException exception from my handler:
> public void exceptionCaught(IoSession session, Throwable cause) throws
> Exception
> in my IoHandlerAdapter
>
> but here ProtocolDecoderException.getHexDump is always empty.
>
> The cause is here at the doDecode method of DemuxingProtocolCodecFactory
> .CumulativeProtocolDecoder class
> if (undecodables == decoders.length) {
> // Throw an exception if all decoders cannot decode
> data.
> String dump = in.getHexDump();
> in.position(in.limit()); // Skip data
> throw new ProtocolDecoderException(
> "No appropriate message decoder: " + dump);
> }
> It should be changed to something like
> if (undecodables == decoders.length) {
> // Throw an exception if all decoders cannot decode
> data.
> String dump = in.getHexDump();
> in.position(in.limit()); // Skip data
> ProtocolDecoderException e =  new
> ProtocolDecoderException(
> "No appropriate message decoder: " + dump);
> e.setHexDump(dump); <-- I believe, this is
> missed here
> throw e;
> }
>
> I have checked the source of 1.1.5 and the issue was still there.
>
> Thank you for all the efforts in the Mina framework.
> Hakan.
> --
> View this message in context: 
> http://www.nabble.com/ProtocolDecoderException.getHexDump-always-returns-%27empty%27-tp14731177s16868p14731177.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: [DISCUSS] Time to move AsyncHttpClient out of Sandbox

[Jeff Genender]

Trustin Lee wrote:

Sure we are! Please feel free to start to make contribution.  :)

BTW is there any express procedure for accepting the existing AHC
committers (i.e. Sangjin and Rick) in the MINA PMC? 


You mean committer, not PMC? ;-)


As you know, they
are not ASF members and didn't contribute directly to the MINA project
so far.  I wonder what I am supposed to do.  Should I wait for some
patches from them just like we do for most people?


Yes...absolutely (wait and have patches subitted or some contribution). 
 Follow the Apache way ;-)





Yet another list to subscribe to... ;-)


Welcome! ;)

Trustin

Re: fuzzing test filter

[Trustin Lee]

Please include this filter into the trunk if you feel it's ready. :)

As a person who's unnecessarily picky in naming, I'd suggest
ErrorGeneratingFilter :)

Cheers,
Trustin

On Jan 11, 2008 11:04 PM, Julien Vermillard <[EMAIL PROTECTED]> wrote:
> On Thu, 10 Jan 2008 23:52:38 -0800 (PST)
> "Steve Ulrich (proemion)" <[EMAIL PROTECTED]> wrote:
>
> >
> >
> > Julien Vermillard wrote:
> > >
> > > I made a little filter for generate random garbage in your byte
> > > streams.
> > >
> >
> > Hi!
> > Thanks, looks very nice. Just startet a test, and found a bug in my
> > app at the first try. :-)
> > The output of the changed bytes is very useful, you just have check
> > for 0-values, because there are some "inserted 0 bytes" messages.
> >
> > regards
> >
> > Steve
> >
> Hi,
> Nice to see it was useful for you ;)
> The logging is quite basic, I need to change it for use a correct slf4j
> logging.
>
> Doh, I though I fixed the zero byte modified bug, I'll take a look.
>
> Thanks for the feedback,
>
> Julien
>



-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

[jira] Updated: (DIRMINA-511) Coding mistake in org.apache.mina.common.AbstractPollingIoProcessor.java

[Trustin Lee (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Trustin Lee updated DIRMINA-511:


Affects Version/s: (was: 2.0.0-M2)
Fix Version/s: (was: 2.0.0-M2)

We didn't even release 2.0.0-M2 or M1... so let me clear the Fix Versions and 
Affects Versions field.

> Coding mistake in org.apache.mina.common.AbstractPollingIoProcessor.java
> 
>
> Key: DIRMINA-511
> URL: https://issues.apache.org/jira/browse/DIRMINA-511
> Project: MINA
>  Issue Type: Bug
>  Components: Core
> Environment: All platform
>Reporter: Frederick Haebin Na
>
> 468 line.
> should comment following lines.
>   // } catch (IOException e) {
>   // session.getFilterChain().fireExceptionCaught(e);
>   } catch (Throwable e) {
>   if (e instanceof IOException) {
>   scheduleRemove(session);
>   }
>   session.getFilterChain().fireExceptionCaught(e);
>   }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (DIRMINA-511) Coding mistake in org.apache.mina.common.AbstractPollingIoProcessor.java

[Trustin Lee (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Trustin Lee resolved DIRMINA-511.
-

Resolution: Fixed
  Assignee: Trustin Lee

Thanks for reporting a critical bug.  It has been fixed.

> Coding mistake in org.apache.mina.common.AbstractPollingIoProcessor.java
> 
>
> Key: DIRMINA-511
> URL: https://issues.apache.org/jira/browse/DIRMINA-511
> Project: MINA
>  Issue Type: Bug
>  Components: Core
> Environment: All platform
>Reporter: Frederick Haebin Na
>Assignee: Trustin Lee
>
> 468 line.
> should comment following lines.
>   // } catch (IOException e) {
>   // session.getFilterChain().fireExceptionCaught(e);
>   } catch (Throwable e) {
>   if (e instanceof IOException) {
>   scheduleRemove(session);
>   }
>   session.getFilterChain().fireExceptionCaught(e);
>   }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Apache MINA Board Report, January 2008

[Trustin Lee]

uh, my bad. :)

On Jan 14, 2008 10:17 PM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
> Hi Trustin !
>
> Trustin Lee wrote:
> > Jeff Genender, a member of the foundation and a MINA enthusiast,
> > joined the MINA PMC.
> So far, he is just one of our committer :)
>
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>



-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: can anyone do me a favour

[Trustin Lee]

Hi Andy,

2008/1/14 张园 <[EMAIL PROTECTED]>:
> My dear friends,
>
> I got a question when I read the source code,how is the SocketIoProcessor
> class dealing the situation that the buf is smaller than the data expected
> in the SocketChannel?

If the allocated read buffer is smaller than the data to be read,
SocketIoProcessor will read it again in the next read loop, with the
increased read buffer size.  It's exactly what the source code you
pasted is doing.

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

[jira] Commented: (DIRMINA-507) IoBuffer: Support prepending data

[Trustin Lee (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12558944#action_12558944
 ] 

Trustin Lee commented on DIRMINA-507:
-

Doesn't prepending slow down the overall performance unless we create a 
CompositeIoBuffer?

We could simply provide move() method to create some room for prepending.  WDYT?

> IoBuffer: Support prepending data
> -
>
> Key: DIRMINA-507
> URL: https://issues.apache.org/jira/browse/DIRMINA-507
> Project: MINA
>  Issue Type: New Feature
>  Components: Core
>Reporter: David M. Lloyd
>Priority: Minor
>
> I'd like to see IoBuffer enhanced to support prepending data.  It could work 
> as follows:
> * A means to specificy or reserve space should be provided.  An 
> IoBuffer.reserve() method could do the trick, and maybe a 3-parameter version 
> of IoBuffer.  IoBuffer.reserve() would keep the position at zero, but 
> decrease the capacity and limit by the given number of bytes, and move the 
> buffer start up by the given number of bytes.
> * A means to reclaim the space must be provided.  An IoBuffer.reclaim() would 
> work by moving the buffer start back down by the given amount, maybe 
> returning a slice to the recovered area.  Or another alternative would be to 
> have a series of prepend* methods which would prepend bytes/ints/etc. similar 
> to put*(), but rather than adding to the end of the buffer, they would add to 
> the beginning, moving the buffer start back down to the start of the 
> just-written data.  Though I'm not sure how helpful it would be to add 
> another dozen methods to a class that already has probably over a hundred 
> methods.
> * Care should be taken that the mechanism to prepend data does not allow a 
> user to "escape" a buffer slice.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (DIRMINA-507) IoBuffer: Support prepending data

[Trustin Lee (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12558944#action_12558944
 ] 

trustin edited comment on DIRMINA-507 at 1/14/08 11:16 PM:
---

Doesn't prepending slow down the overall performance degradation unless we have 
a CompositeIoBuffer?

We could simply provide move() method to create some room for prepending.  WDYT?

  was (Author: trustin):
Doesn't prepending slow down the overall performance unless we create a 
CompositeIoBuffer?

We could simply provide move() method to create some room for prepending.  WDYT?
  
> IoBuffer: Support prepending data
> -
>
> Key: DIRMINA-507
> URL: https://issues.apache.org/jira/browse/DIRMINA-507
> Project: MINA
>  Issue Type: New Feature
>  Components: Core
>Reporter: David M. Lloyd
>Priority: Minor
>
> I'd like to see IoBuffer enhanced to support prepending data.  It could work 
> as follows:
> * A means to specificy or reserve space should be provided.  An 
> IoBuffer.reserve() method could do the trick, and maybe a 3-parameter version 
> of IoBuffer.  IoBuffer.reserve() would keep the position at zero, but 
> decrease the capacity and limit by the given number of bytes, and move the 
> buffer start up by the given number of bytes.
> * A means to reclaim the space must be provided.  An IoBuffer.reclaim() would 
> work by moving the buffer start back down by the given amount, maybe 
> returning a slice to the recovered area.  Or another alternative would be to 
> have a series of prepend* methods which would prepend bytes/ints/etc. similar 
> to put*(), but rather than adding to the end of the buffer, they would add to 
> the beginning, moving the buffer start back down to the start of the 
> just-written data.  Though I'm not sure how helpful it would be to add 
> another dozen methods to a class that already has probably over a hundred 
> methods.
> * Care should be taken that the mechanism to prepend data does not allow a 
> user to "escape" a buffer slice.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[VOTE] Release Apache MINA 1.0.9 and 1.1.6.

[Trustin Lee]

Hi community,

We have fixed 6 issues in 1.0.9 and 1.1.6 since 1.0.8 and 1.1.5.  The
following URL shows the list of the fixed issues:

https://issues.apache.org/jira/browse/DIRMINA?report=com.atlassian.jira.plugin.system.project:roadmap-panel

[ ]: +1, Release
[ ]: 0, Abstain
[ ]: -1, Don't release

Cheers,
Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Network is unreachable exception

[Ran Kornfeld]

Hello 

I am getting an java.io.IOException: Network is unreachable sometimes on the
SocketIoProcessor.read() method.

I have a MINA based server which handles hundreds of messages per hour, and
I get this every 2-3 days. It seems that everything continues with no
problem, I just wonder what it means.

Regards
Ran.
-- 
View this message in context: 
http://www.nabble.com/Network-is-unreachable-exception-tp14833233s16868p14833233.html
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.