[
https://issues.apache.org/jira/browse/DIRMINA-663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12673872#action_12673872
]
Serge Baranov commented on DIRMINA-663:
---------------------------------------
Done more testing:
CentOS 5.2 - works fine with M4/RC1
Windows 2003 Server x64 -- works fine with M4/RC1
Windows Vista 32-bit laptop -- works fine with M4/RC1
Windows VIsta 64-bit clean VMWare image -- works fine with M4/RC1
Windows VIsta 64-bit real system -- fails with M4/RC1, works fine with M3
(under any JVM)
So, it looks like the problem is specific to both the windows
environment/hardware and the MINA version. Really puzzled. Any ideas?
> CumulativeProtocolDecoder doDecode performance problem
> ------------------------------------------------------
>
> Key: DIRMINA-663
> URL: https://issues.apache.org/jira/browse/DIRMINA-663
> Project: MINA
> Issue Type: Bug
> Components: Filter
> Affects Versions: 2.0.0-RC1
> Environment: JDK 1.6.0_12 32-bit, Windows Vista 64-bit, MINA
> 2.0.0-RC1 (up to current date trunk).
> Reporter: Serge Baranov
> Priority: Critical
> Attachments: tdump.txt
>
>
> To reproduce get the mina_test_2.0.zip from DIRMINA-609.
> It seems to be working even worse with the current trunk version, it takes ~5
> seconds between messages and then times out after the first message, if wait
> is increased to 10 seconds, it times out after the second message:
> time = 03:49:36.320
> remaining = 1024
> limit = 1024
> capacity = 2048
> time = 03:49:41.619
> remaining = 2048
> limit = 2048
> capacity = 2097156
> java.lang.AssertionError: No message received
> The issue differs from DIRMINA-609 as it affects not only large messages, but
> any message that doesn't fit into buffer (when doDecode returns false) and
> also all the subsequent messages (when doDecode returns true).
> It's a serious issue making CumulativeProtocolDecoder completely useless.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.