[jira] Commented: (DIRMINA-653) IoSession.write not thread-safe? Loosing messages under heavy multi-threaded write on same session.
[
https://issues.apache.org/jira/browse/DIRMINA-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12845212#action_12845212
]
Yannick Lecaillez commented on DIRMINA-653:
---
Hi,
I got the same problem using CompressionFilter.
The problem come from CompressionFilter which is not thread safe. MINA
documentation
sates clearly that IoSession is thread-safe. But please note that performing
more than one write(Object) calls at the same time will cause the
IoFilter.filterWrite(IoFilter.NextFilter,IoSession,WriteRequest) to be
executed simultaneously, and therefore you have to make sure the IoFilter
implementations you're using are thread-safe, too.
The problem here is that zStream in CompressionFilter is not synchronized an
so, not thread-safe.
We fixed the problem simply by surrounding zStream access with a synchronized
in CompressionFilter.
Hope that helps,
Yannick.
IoSession.write not thread-safe? Loosing messages under heavy multi-threaded
write on same session.
---
Key: DIRMINA-653
URL: https://issues.apache.org/jira/browse/DIRMINA-653
Project: MINA
Issue Type: Bug
Components: Core, Filter
Affects Versions: 2.0.0-M4
Environment: Windows Vista 64-bit
Reporter: Mauritz Lovgren
Fix For: 2.0.0-M5
I am writing a stress-test that tests multi-thread safetyness of our
stateless encoder / decoder under heavy load and I am observing that messages
are silently lost during session.write(Object), (the lost messages do not
seem to reach the underlying socket buffer at all).
I am using one encoder / decoder that is stateless. No executor filter, only
the filter codec and a basic io handler.
Synchronizing on the session.write makes the problem go away;
synchronized (session)
{
future = session.write(message);
}
Do I really have to synchronize on the session to solve this issue?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (DIRMINA-774) CompressionFilter is not thread safe
CompressionFilter is not thread safe Key: DIRMINA-774 URL: https://issues.apache.org/jira/browse/DIRMINA-774 Project: MINA Issue Type: Bug Components: Filter Affects Versions: 2.0.0-RC1 Environment: All Reporter: Yannick Lecaillez Concurrent IoSession.write() can cause various error in CompressionFilter deflate method under load since zStream is not synchronized. I've a fix which simply synchronized access to zStream. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Black/White List in FTP Server
I've been trying to implement white/black lists in FTP server and thought of running my findings/ideas with you guys. Currently, each listener can have a black list. There is NO white listing capability. I've been thinking, instead of having the black list IPs/Subnets, simply have an interface called IPFilter. Each listener can have at most one IPFilter. The IPFilter requires an implementation for a method named accept(), which tells if the client's connection should be accepted or rejected based on the IP address. This gives us the flexibility of having a black or white list which ever is preferred by the server administrator. By default, we can ship default implementation for IPFilter which can be a black or white filter. For example, in the spring configuration, instead of having a blacklist element, we would have a ipFilter element as shown below: ipFilter type=whitelist|blacklist 192.168.1.200/32, 192.168.1.201/32 /ipFilter The type attribute in the ipFilter element tells us if it should be a white or black list. The value for this attribute could be whitelist or blacklist or something similar such as BLOCK/PASS. I could not think of any good usage scenarios where one might want to have both white and black lists for a given listener. So, one IP Filter per listener should be good enough, unless you guys think otherwise. The above should work for users who want to run the FTP server out-of-the-box. For people who want to override the default IP filter implementaton, could create a new class that implements the IPFilter interface and specify the class name(?) in the spring config or programmatically call ListenerFactory.setIPFilter(IPFilter) method. Let me know what do you guys think and we can decide on how best it should be implemented. I do have sometime this week to work on this if we finalize on something. Thanks Regards, Sai Pullabhotla
Re: Black/White List in FTP Server
On Mon, Mar 15, 2010 at 11:57 PM, Sai Pullabhotla sai.pullabho...@jmethods.com wrote: I've been trying to implement white/black lists in FTP server and thought of running my findings/ideas with you guys. Currently, each listener can have a black list. There is NO white listing capability. Is this IoListener or something specific to FtpServer? AFAIK, our filters are part of chain and get applied at session level. I've been thinking, instead of having the black list IPs/Subnets, simply have an interface called IPFilter. Each listener can have at most one IPFilter. The IPFilter requires an implementation for a method named accept(), which tells if the client's connection should be accepted or rejected based on the IP address. This gives us the flexibility of having a black or white list which ever is preferred by the server administrator. By default, we can ship default implementation for IPFilter which can be a black or white filter. For example, in the spring configuration, instead of having a blacklist element, we would have a ipFilter element as shown below: ipFilter type=whitelist|blacklist 192.168.1.200/32, 192.168.1.201/32 /ipFilter The type attribute in the ipFilter element tells us if it should be a white or black list. The value for this attribute could be whitelist or blacklist or something similar such as BLOCK/PASS. I could not think of any good usage scenarios where one might want to have both white and black lists for a given listener. So, one IP Filter per listener should be good enough, unless you guys think otherwise. me neither :) The above should work for users who want to run the FTP server out-of-the-box. For people who want to override the default IP filter implementaton, could create a new class that implements the IPFilter interface and specify the class name(?) in the spring config or programmatically call ListenerFactory.setIPFilter(IPFilter) method. Let me know what do you guys think and we can decide on how best it should be implemented. I do have sometime this week to work on this if we finalize on something. One suggestion is make the implementation more efficient. The current MINA balklist filter uses List for storing IP's and iteration through the list for each call is not efficient. So may be ConcurrentHashMap would be good idea for storing. However, this works fine for IP's. Need to think about Subnet and other stuff ;) -- thanks ashish
