[jira] Updated: (DIRMINA-803) ProtocolCodecFilter.filterWrite() is no longer thread-safe
[
https://issues.apache.org/jira/browse/DIRMINA-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny updated DIRMINA-803:
--
Fix Version/s: 2.0.1
ProtocolCodecFilter.filterWrite() is no longer thread-safe
--
Key: DIRMINA-803
URL: https://issues.apache.org/jira/browse/DIRMINA-803
Project: MINA
Issue Type: Bug
Components: Filter
Affects Versions: 2.0.0
Reporter: Stuart Scott
Fix For: 2.0.1
In revision 'r912149 | elecharny | 2010-02-20 22:04:32 +0500 (Sat, 20 Feb
2010)' the loop that flushes the encoded messages was modified and is no
longer thread-safe. In the trunk the queue is checked if it is empty then
polled for the next element. Between these calls another thread could have
taken the last element in the queue and the element is not checked if it is
null.
Starting at line 328:
while (!bufferQueue.isEmpty()) {
Object encodedMessage = bufferQueue.poll();
...
could be replaced with the previous loop:
for (;;) {
Object encodedMessage = bufferQueue.poll();
if (encodedMessage == null) {
break;
}
...
to make the method thread-safe again.
The same issue exists in ProtocolEncoderOutputImpl.flush().
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-593) Javadoc documentation for org/apache/mina/filter/reqres
[ https://issues.apache.org/jira/browse/DIRMINA-593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRMINA-593: -- Fix Version/s: (was: 2.0.1) 2.0.2 Javadoc documentation for org/apache/mina/filter/reqres - Key: DIRMINA-593 URL: https://issues.apache.org/jira/browse/DIRMINA-593 Project: MINA Issue Type: Improvement Components: Filter, Web Site / Documentation Affects Versions: 2.0.0-M1 Reporter: Julien Vermillard Assignee: Ashish Paliwal Fix For: 2.0.2 no javadoc nor doc on the request/response filter, it need some examples too -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-790) 2.0.0M6 + 2.0.0RC1: Win7 performance issue
[ https://issues.apache.org/jira/browse/DIRMINA-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRMINA-790: -- Fix Version/s: (was: 2.0.1) 2.0.2 2.0.0M6 + 2.0.0RC1: Win7 performance issue -- Key: DIRMINA-790 URL: https://issues.apache.org/jira/browse/DIRMINA-790 Project: MINA Issue Type: Bug Affects Versions: 2.0.0-RC1 Environment: WinXP SP3 with disabled Firewall + Virusscanner, Win7 64bit with disabled Virusscanner and Firewall, Win7 32bit with absolutely no virusscanner and with disabled firewall, all Systems with 32bit JRE6U20 Ubuntu Linux 64bit mit JRE6U20 64bit Reporter: Alex C. Assignee: Emmanuel Lecharny Priority: Blocker Fix For: 2.0.2 Attachments: MINASocketTransfer.zip Hi there, I've written a kind of RMI replacement uses MINA for network communication layer that is also able to transfer files very fast (without reflection and complex serialisation stuff). One of my customers faced a performance problem as soon as the receiving application part is running in Win7. I tried to create an reproducer: First I wrote a small test application using Java IO that simply transfers 1.000.000 bytes of random data from a client to a server. That's very fast. It doesn't matter if I try on localhost, or from WinXP-Win7 oder Win7-WinXP. Even Linux-Win7 is fast. Then I wrote the same kind of application with mina. No additional codec, nothing complex. I just transfer 100 IoBuffers with 10.000 bytes each from A to B. If I run the application on WinXP via localhost, it's very fast. 1sec runtime. If I run client and server in Win7, it's f*cking slow. Takes 1min to complete. Please find attached the test application. Just extract and run: java -cp MINASocketTransfer.jar;./lib/* minasockettransfer.Client IP or Hostname of Server java -cp MINASocketTransfer.jar;./lib/* minasockettransfer.Server The lib folder contains 2.0.0M6 and 2.0.0RC1. To switch from the one to the other version, simple move the tailing _ to exclude the specified lib from classpath. Java-Source files are included in the MINASocketTransfer.jar ... I tested it with 2.0.0M6 and 2.0.0RC1. It's reproducible with both versions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-788) RequestResponseFilter - Javadoc and Examples
[ https://issues.apache.org/jira/browse/DIRMINA-788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRMINA-788: -- Fix Version/s: (was: 2.0.1) 2.0.2 RequestResponseFilter - Javadoc and Examples Key: DIRMINA-788 URL: https://issues.apache.org/jira/browse/DIRMINA-788 Project: MINA Issue Type: Wish Components: Web Site / Documentation Affects Versions: 2.0.0-RC1 Environment: Windows XP, IDE Eclipse, JDK 1.6.0_16 Reporter: Alan Amir Priority: Trivial Fix For: 2.0.2 I have my doubts about MINA's RequestResponseFilter I would like to know if anyone have an idea when are going to post the javadoc from Mina's Filter Request Response package?? I also viewed the next 2 references but I still have some questions about its operation. Kind regards and thanks for any help with this issue. * https://issues.apache.org/jira/browse/DIRMINA-92#action_12488311 * http://svn.apache.org/viewvc/mina/trunk/core/src/main/java/org/apache/mina/filter/reqres/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-760) Client fails to detect disconnection
[ https://issues.apache.org/jira/browse/DIRMINA-760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRMINA-760: -- Fix Version/s: (was: 2.0.1) 2.0.2 Client fails to detect disconnection Key: DIRMINA-760 URL: https://issues.apache.org/jira/browse/DIRMINA-760 Project: MINA Issue Type: Bug Components: Core Reporter: Omry Yadan Fix For: 2.0.2 Tested against revision 901694 (which is a bit after 2.0.0-RC1) My client need to maintain an open connection to the server. If I kill the server right before calling session.write(), the client does not detect that the server is gone. there is no exceptionCaught event, and messageSent is actually called (which suggests successful delivery). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-800) Review the Maven files to fix some issues in the release
[ https://issues.apache.org/jira/browse/DIRMINA-800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRMINA-800: -- Fix Version/s: (was: 2.0.1) 2.0.2 Review the Maven files to fix some issues in the release Key: DIRMINA-800 URL: https://issues.apache.org/jira/browse/DIRMINA-800 Project: MINA Issue Type: Improvement Affects Versions: 2.0.0 Reporter: Emmanuel Lecharny Fix For: 2.0.2 Currently, releasing MINA using the pom.xml we have requires that the project itself has been fully built, because the build is not launched by the release:prepare goal. We can fix that in 2.0.1 release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-682) We need a better documentation for the ExecutorFilter [was :Writing more than one message will block until the MessageReceived as been fully proceced]
[
https://issues.apache.org/jira/browse/DIRMINA-682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny updated DIRMINA-682:
--
Fix Version/s: (was: 2.0.1)
2.0.2
We need a better documentation for the ExecutorFilter [was :Writing more than
one message will block until the MessageReceived as been fully proceced]
--
Key: DIRMINA-682
URL: https://issues.apache.org/jira/browse/DIRMINA-682
Project: MINA
Issue Type: Improvement
Affects Versions: 2.0.0-M4
Reporter: Emmanuel Lecharny
Priority: Critical
Fix For: 2.0.2
When a message generates mor ethan one response, then the written responses
will be sent to the client only when the initial message has been totally
processed.
Suppose that we receive one message M, it will be handled by a IoProcessor in
the process() method, go through the chain to the IoHandler.MessageReceive()
method. Now, if one want to write more than one response (session.write( R
)), then those responses will be enqueued until we are back to the process()
method.
The issue is due to the fact that the write is done using the IoProcessor
associated to the current session, leading to a problem : we can't ask the
IoProcessor instance to unqueue the written message until it is done with the
current processing( it's running in one single thread).
The consequences are painfull :
- if one tries to write two responses, waiting for the first responses to be
written, this will end with a DeadLock, as we are waiting on the processor we
are holding
- if we don't care about waiting for the write to be done, then all the
responses will be enqueued and stored in memory, until the IoProcessor exit
from the read processing and start processing the writes, leading to OOM
Exception
One solution would be to have to sets of IoProcessors, one for the read, and
one for the writes. Or to pick a random Processor to process the writes, as
soon as the processor is not the same as the one processing the reads.
Here is a sample exhibiting the problem. Just launch it, and use 'telnet
localhost 8080' in a console, type something, it should write twice the typed
message, but it just generates an exception - see further - and write back
the message once. Removing the wait will work, but the messages will be sent
only when the read has been processed in the
AbstractPollingIoProcessor.process(T session) method :
/**
* Deal with session ready for the read or write operations, or both.
*/
private void process(T session) {
// Process Reads
if (isReadable(session) !session.isReadSuspended()) {
read(session);
}
// Process writes
if (isWritable(session) !session.isWriteSuspended()) {
scheduleFlush(session);
}
}
The sample code :
package org.apache.mina.real.life;
import java.net.InetSocketAddress;
import org.apache.mina.core.buffer.IoBuffer;
import org.apache.mina.core.future.WriteFuture;
import org.apache.mina.core.service.IoHandlerAdapter;
import org.apache.mina.core.session.IoSession;
import org.apache.mina.filter.logging.LoggingFilter;
import org.apache.mina.transport.socket.SocketAcceptor;
import org.apache.mina.transport.socket.nio.NioSocketAcceptor;
/**
* (bEntry point/b) Echo server
*
* @author The Apache MINA Project (dev@mina.apache.org)
*/
public class Main {
private static class EchoProtocolHandler extends IoHandlerAdapter {
public void messageReceived(IoSession session, Object message)
throws Exception {
System.out.println(new String(((IoBuffer)message).array()));
// Write the received data back to remote peer
WriteFuture wf = session.write(((IoBuffer) message).duplicate());
// Here, we will get a Deadlock detection
wf.awaitUninterruptibly();
// Do a second write
session.write(((IoBuffer) message).duplicate());
}
}
/** Choose your favorite port number. */
private static final int PORT = 8080;
public static void main(String[] args) throws Exception {
SocketAcceptor acceptor = new NioSocketAcceptor();
// Add a logging filter
acceptor.getFilterChain().addLast( Logger, new LoggingFilter() );
// Bind
acceptor.setHandler(new EchoProtocolHandler());
acceptor.bind(new InetSocketAddress(PORT));
System.out.println(Listening on port + PORT);
}
}
The exception :
Listening on port 8080
[20:08:17] INFO
[jira] Updated: (DIRMINA-477) Update page about differences between 1.x and 2.x
[ https://issues.apache.org/jira/browse/DIRMINA-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRMINA-477: -- Fix Version/s: (was: 2.0.1) 2.0.2 Update page about differences between 1.x and 2.x - Key: DIRMINA-477 URL: https://issues.apache.org/jira/browse/DIRMINA-477 Project: MINA Issue Type: Task Components: Web Site / Documentation Reporter: Trustin Lee Assignee: Ashish Paliwal Fix For: 2.0.2 Our current web site doesn't describe what have been changed in 2.x comparing to 1.x. We need to carefully put all changes together there so people can migrate more easily. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-771) Calling NioSocketSession.toString() causes java.lang.Error
[ https://issues.apache.org/jira/browse/DIRMINA-771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRMINA-771: -- Fix Version/s: (was: 2.0.1) 2.0.2 Calling NioSocketSession.toString() causes java.lang.Error -- Key: DIRMINA-771 URL: https://issues.apache.org/jira/browse/DIRMINA-771 Project: MINA Issue Type: Bug Affects Versions: 2.0.0-RC1 Environment: WinXP JDK 1.6.1_18 Reporter: Jörg Michelberger Priority: Critical Fix For: 2.0.2 Hi there, using MINA 2.0.0 RC1 and have a log statement in my IOHandler.exceptionCaught() method plugged on top of a NioSocketSession. The log statement calls toString() on the IoSession passed in. In some cases I get the appended Exception. Thats not good. Regards Jörg 2010-03-03 09:51:46,818 WARN [NioProcessor-2] filterchain.DefaultIoFilterChain::callNextExceptionCaught() (DefaultIoFilterChain.java:483) - Unexpected exception from exceptionCaught handler. java.lang.Error: java.net.SocketException: Socket operation on nonsocket: getsockname at sun.nio.ch.Net.localAddress(Net.java:125) at sun.nio.ch.SocketChannelImpl.localAddress(SocketChannelImpl.java:430) at sun.nio.ch.SocketAdaptor.getLocalAddress(SocketAdaptor.java:147) at java.net.Socket.getLocalSocketAddress(Socket.java:703) at org.apache.mina.transport.socket.nio.NioSocketSession.getLocalAddress(NioSocketSession.java:158) at org.apache.mina.transport.socket.nio.NioSocketSession.getLocalAddress(NioSocketSession.java:47) at org.apache.mina.core.session.AbstractIoSession.toString(AbstractIoSession.java:1139) at com.ndsatcom.cecsdatamodel.cecsclient.newmulti.mina.MinaCecsIoHandler.exceptionCaught(MinaCecsIoHandler.java:33) at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.exceptionCaught(DefaultIoFilterChain.java:694) at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextExceptionCaught(DefaultIoFilterChain.java:480) at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1100(DefaultIoFilterChain.java:46) at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.exceptionCaught(DefaultIoFilterChain.java:788) at org.apache.mina.core.filterchain.IoFilterAdapter.exceptionCaught(IoFilterAdapter.java:111) at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextExceptionCaught(DefaultIoFilterChain.java:480) at org.apache.mina.core.filterchain.DefaultIoFilterChain.fireExceptionCaught(DefaultIoFilterChain.java:468) at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:397) at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$900(DefaultIoFilterChain.java:46) at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.sessionClosed(DefaultIoFilterChain.java:778) at org.apache.mina.core.filterchain.IoFilterAdapter.sessionClosed(IoFilterAdapter.java:95) at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:395) at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$900(DefaultIoFilterChain.java:46) at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.sessionClosed(DefaultIoFilterChain.java:778) at org.apache.mina.filter.codec.ProtocolCodecFilter.sessionClosed(ProtocolCodecFilter.java:345) at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:395) at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$900(DefaultIoFilterChain.java:46) at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.sessionClosed(DefaultIoFilterChain.java:778) at org.apache.mina.core.filterchain.IoFilterAdapter.sessionClosed(IoFilterAdapter.java:95) at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextSessionClosed(DefaultIoFilterChain.java:395) at org.apache.mina.core.filterchain.DefaultIoFilterChain.fireSessionClosed(DefaultIoFilterChain.java:388) at org.apache.mina.core.service.IoServiceListenerSupport.fireSessionDestroyed(IoServiceListenerSupport.java:210) at org.apache.mina.core.polling.AbstractPollingIoProcessor.removeNow(AbstractPollingIoProcessor.java:535) at org.apache.mina.core.polling.AbstractPollingIoProcessor.removeSessions(AbstractPollingIoProcessor.java:497) at org.apache.mina.core.polling.AbstractPollingIoProcessor.access$600(AbstractPollingIoProcessor.java:61) at org.apache.mina.core.polling.AbstractPollingIoProcessor$Processor.run(AbstractPollingIoProcessor.java:974)
[jira] Updated: (DIRMINA-777) IoSessionConfig.setUseReadOperation(true) doesn't seem to work
[
https://issues.apache.org/jira/browse/DIRMINA-777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny updated DIRMINA-777:
--
Fix Version/s: (was: 2.0.1)
2.0.2
IoSessionConfig.setUseReadOperation(true) doesn't seem to work
--
Key: DIRMINA-777
URL: https://issues.apache.org/jira/browse/DIRMINA-777
Project: MINA
Issue Type: Bug
Components: Core
Affects Versions: 2.0.0-RC1
Environment: Mac OS X 10.6.2, Java 1.6, Android SDK
Reporter: Matt Huggins
Priority: Blocker
Fix For: 2.0.2
I'm attempting to perform a synchronous write/read in a demux-based client
application with MINA 2.0 RC1, but it seems to get stuck. Here is my code:
{code}
public boolean login(final String username, final String password) {
// block inbound messages
session.getConfig().setUseReadOperation(true);
// send the login request
final LoginRequest loginRequest = new LoginRequest(username, password);
final WriteFuture writeFuture = session.write(loginRequest);
writeFuture.awaitUninterruptibly();
if (writeFuture.getException() != null) {
session.getConfig().setUseReadOperation(false);
return false;
}
// retrieve the login response
final ReadFuture readFuture = session.read();
readFuture.awaitUninterruptibly();
if (readFuture.getException() != null) {
session.getConfig().setUseReadOperation(false);
return false;
}
// stop blocking inbound messages
session.getConfig().setUseReadOperation(false);
// determine if the login info provided was valid
final LoginResponse loginResponse =
(LoginResponse)readFuture.getMessage();
return loginResponse.getSuccess();
}
{code}
I can see on the server side that the LoginRequest object is retrieved, and a
LoginResponse message is sent. On the client side, the
DemuxingProtocolCodecFactory receives the response, but after throwing in
some logging, I can see that the client gets stuck on the call to
`readFuture.awaitUninterruptibly() `.
I can't for the life of me figure out why it is stuck here based upon my own
code. I properly set the read operation to true on the session config,
meaning that messages should be blocked. However, it seems as if the message
no longer exists by time I try to read response messages synchronously.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-539) NioDatagramConnector doesn't takes the TrafficClass value set to his DatagramSessionConfig
[ https://issues.apache.org/jira/browse/DIRMINA-539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRMINA-539: -- Fix Version/s: (was: 2.0.1) 2.0.2 NioDatagramConnector doesn't takes the TrafficClass value set to his DatagramSessionConfig --- Key: DIRMINA-539 URL: https://issues.apache.org/jira/browse/DIRMINA-539 Project: MINA Issue Type: Bug Affects Versions: 2.0.0-M1 Environment: WinXP, RHEL5 (probably not important) Reporter: martin krivosik Assignee: Emmanuel Lecharny Fix For: 2.0.2 Original Estimate: 0.33h Remaining Estimate: 0.33h client sending datagrams without taking care to the trafficClas set in the config, so the ToS byte is not set in the packet sent from client. client code: NioDatagramAcceptor acceptor = new NioDatagramAcceptor(); DatagramSessionConfig dcfg = ((NioDatagramAcceptor)acceptor).getSessionConfig(); dcfg.setTrafficClass(tosByte); InetSocketAddress bindAddrPort = new InetSocketAddress(originatingIP, port); acceptor.bind(bindAddrPort); - connecting to another computer with NioDatagramConnector. for me it looks like in the newHandle method of NioDatagramConnector is not cared about TrafficClass (like it is done in NioDatagramAcceptor.open()) The server part with the accceptor is OK and the correct ToS byte is set in the packet. (the same problem may be in the socket, i have to check it) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-784) Error with MDCInjectionFilter on Windows
[ https://issues.apache.org/jira/browse/DIRMINA-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRMINA-784: -- Fix Version/s: (was: 2.0.1) 2.0.2 Error with MDCInjectionFilter on Windows Key: DIRMINA-784 URL: https://issues.apache.org/jira/browse/DIRMINA-784 Project: MINA Issue Type: Bug Affects Versions: 2.0.0-RC1 Reporter: Emmanuel Lecharny Assignee: Ashish Paliwal Fix For: 2.0.2 One test is randomly failing on Windows only : http://hudson.zones.apache.org/hudson/job/MINA-trunk-jdk1.6-windows/lastBuild/org.apache.mina$mina-core/testReport/org.apache.mina.filter.logging/MdcInjectionFilterTest/testOnlyRemoteAddress/ It may be the test which is broken, or something we added since the last version, as it was working in 2.0.0-RC1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-799) We should not export the distribution files to Maven repo
[ https://issues.apache.org/jira/browse/DIRMINA-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRMINA-799: -- Fix Version/s: (was: 2.0.1) 2.0.2 We should not export the distribution files to Maven repo - Key: DIRMINA-799 URL: https://issues.apache.org/jira/browse/DIRMINA-799 Project: MINA Issue Type: Improvement Affects Versions: 2.0.0-RC1 Reporter: Emmanuel Lecharny Fix For: 2.0.2 Currently, we are exporting the full packaged files into repo1.apache.org. We should not do that (many other project do so) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-780) Writing null objects to the Session should raise an Exception
[ https://issues.apache.org/jira/browse/DIRMINA-780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny updated DIRMINA-780: -- Fix Version/s: (was: 2.0.1) 2.0.2 Writing null objects to the Session should raise an Exception - Key: DIRMINA-780 URL: https://issues.apache.org/jira/browse/DIRMINA-780 Project: MINA Issue Type: Improvement Components: Core Affects Versions: 2.0.0-RC1 Reporter: Norman Maurer Fix For: 2.0.2 When using MINA in JAMES we saw malformated packets when processing POP3. This was a cause of a bug in our code which wrote a null object to the session. Unfortunally MINA don't throw an exception in this case and just write garbage to the session. We only found the bug because we have a netty implementation too which throws a NullPointerException in this case. I think MINA should do something similar.. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-779) SSLHandler can re-order data that it reads
[
https://issues.apache.org/jira/browse/DIRMINA-779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny updated DIRMINA-779:
--
Fix Version/s: (was: 2.0.1)
2.0.2
SSLHandler can re-order data that it reads
--
Key: DIRMINA-779
URL: https://issues.apache.org/jira/browse/DIRMINA-779
Project: MINA
Issue Type: Bug
Components: Filter
Affects Versions: 1.1.7, 2.0.0-M1, 2.0.0-M2, 2.0.0-M3, 2.0.0-M4, 2.0.0-M5,
2.0.0-M6, 2.0.0-RC1
Reporter: Jason Resch
Fix For: 2.0.2
Attachments: ssl_reodering_fix.diff
The code in question is the flushScheduledEvents() method in SSLHandler.java:
public void flushScheduledEvents() {
// Fire events only when no lock is hold for this handler.
if (Thread.holdsLock(this)) {
return;
}
Event e;
// We need synchronization here inevitably because filterWrite can be
// called simultaneously and cause 'bad record MAC' integrity error.
synchronized (this) {
while ((e = filterWriteEventQueue.poll()) != null) {
e.nextFilter.filterWrite(session, (WriteRequest) e.data);
}
}
while ((e = messageReceivedEventQueue.poll()) != null) {
e.nextFilter.messageReceived(session, e.data);
}
}
This method is called both by threads which handle writes, and threads that
handle reads. Therefore, as the comments suggest, multiple threads may go
through this code simultaneously. However, since there is no
synchronization around processing of the messageReceivedEventQueue, it is
possible that the received messages will be sent to the next filter out of
order, should there be more than one message in the queue and a context
switch happen at the wrong time.
The bug would manifest in our application as a failure of our protocol layer
to decode a message, we believe, due to a re-ordering. It only occurred in
environments with a large amount of contention and network traffic and when
using TLS. The fix I have tested was to move the closing brace of the
synchronized block to extend to cover both while loops. I've attached a
patch representing that change. Since making that change we have not
encountered the bug again after about 30 hours of testing and 1.5 TB of
traffic, whereas before the change we could reproduce it after a few
minutes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[VOTE] MINA 2.0.1
Hi, a serious regression has been found in MINA 2.0.0. It has been fixed in 2.0.1 and I suggest we vote a release. Here is the regression description : * [DIRMINA-803 https://issues.apache.org/jira/browse/DIRMINA-803] - ProtocolCodecFilter.filterWrite() is no longer thread-safe Here's the Jira link for this version if you'd like to review issues in more details: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10670styleName=Htmlversion=12313702 A temporary tag has been created (it can be removed if the vote is not approved): http://svn.apache.org/viewvc/mina/tags/2.0.1/ The svn revision is :http://svn.apache.org/viewvc?rev=1026395 The newly approved Nexus has been used for the preparation of this release and all final artifacts are stored in a staging repository: https://repository.apache.org/content/repositories/orgapachemina-002/ The distributions are available for download on : https://repository.apache.org/content/repositories/orgapachemina-004/org/apache/mina/mina-parent/2.0.1/ Let's vote again : [ ] +1 | Release MINA 2.0.1 [ ] ±0 | Abstain [ ] -1 | Do *NOT* release MINA 2.0.1 Thanks ! -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: [VOTE] MINA 2.0.1
+1 Jeff On Oct 22, 2010, at 11:19 AM, Emmanuel Lecharny wrote: Hi, a serious regression has been found in MINA 2.0.0. It has been fixed in 2.0.1 and I suggest we vote a release. Here is the regression description : * [DIRMINA-803 https://issues.apache.org/jira/browse/DIRMINA-803] - ProtocolCodecFilter.filterWrite() is no longer thread-safe Here's the Jira link for this version if you'd like to review issues in more details: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10670styleName=Htmlversion=12313702 A temporary tag has been created (it can be removed if the vote is not approved): http://svn.apache.org/viewvc/mina/tags/2.0.1/ The svn revision is :http://svn.apache.org/viewvc?rev=1026395 The newly approved Nexus has been used for the preparation of this release and all final artifacts are stored in a staging repository: https://repository.apache.org/content/repositories/orgapachemina-002/ The distributions are available for download on : https://repository.apache.org/content/repositories/orgapachemina-004/org/apache/mina/mina-parent/2.0.1/ Let's vote again : [ ] +1 | Release MINA 2.0.1 [ ] ±0 | Abstain [ ] -1 | Do *NOT* release MINA 2.0.1 Thanks ! -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: [VOTE] MINA 2.0.1
+1 release early, release often On Fri, Oct 22, 2010 at 8:27 PM, Jeff Genender jgenen...@apache.org wrote: +1 Jeff On Oct 22, 2010, at 11:19 AM, Emmanuel Lecharny wrote: Hi, a serious regression has been found in MINA 2.0.0. It has been fixed in 2.0.1 and I suggest we vote a release. Here is the regression description : * [DIRMINA-803 https://issues.apache.org/jira/browse/DIRMINA-803] - ProtocolCodecFilter.filterWrite() is no longer thread-safe Here's the Jira link for this version if you'd like to review issues in more details: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10670styleName=Htmlversion=12313702 A temporary tag has been created (it can be removed if the vote is not approved): http://svn.apache.org/viewvc/mina/tags/2.0.1/ The svn revision is :http://svn.apache.org/viewvc?rev=1026395 The newly approved Nexus has been used for the preparation of this release and all final artifacts are stored in a staging repository: https://repository.apache.org/content/repositories/orgapachemina-002/ The distributions are available for download on : https://repository.apache.org/content/repositories/orgapachemina-004/org/apache/mina/mina-parent/2.0.1/ Let's vote again : [ ] +1 | Release MINA 2.0.1 [ ] ±0 | Abstain [ ] -1 | Do *NOT* release MINA 2.0.1 Thanks ! -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: [VOTE] MINA 2.0.1
[X] +1 | Release MINA 2.0.1 -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: [VOTE] MINA 2.0.1
[X] +1 | Release MINA 2.0.1 On Fri, Oct 22, 2010 at 10:49 PM, Emmanuel Lecharny elecha...@gmail.com wrote: Hi, a serious regression has been found in MINA 2.0.0. It has been fixed in 2.0.1 and I suggest we vote a release. Here is the regression description : * [DIRMINA-803 https://issues.apache.org/jira/browse/DIRMINA-803] - ProtocolCodecFilter.filterWrite() is no longer thread-safe Here's the Jira link for this version if you'd like to review issues in more details: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10670styleName=Htmlversion=12313702 A temporary tag has been created (it can be removed if the vote is not approved): http://svn.apache.org/viewvc/mina/tags/2.0.1/ The svn revision is :http://svn.apache.org/viewvc?rev=1026395 The newly approved Nexus has been used for the preparation of this release and all final artifacts are stored in a staging repository: https://repository.apache.org/content/repositories/orgapachemina-002/ The distributions are available for download on : https://repository.apache.org/content/repositories/orgapachemina-004/org/apache/mina/mina-parent/2.0.1/ Let's vote again : [ ] +1 | Release MINA 2.0.1 [ ] ą0 | Abstain [ ] -1 | Do *NOT* release MINA 2.0.1 Thanks ! -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com -- thanks ashish Blog: http://www.ashishpaliwal.com/blog My Photo Galleries: http://www.pbase.com/ashishpaliwal
