[jira] Assigned: (FTPSERVER-303) Passive data connection stuck in CLOSE_WAIT.
[ https://issues.apache.org/jira/browse/FTPSERVER-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre reassigned FTPSERVER-303: --- Assignee: David Latorre Passive data connection stuck in CLOSE_WAIT. Key: FTPSERVER-303 URL: https://issues.apache.org/jira/browse/FTPSERVER-303 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.0, 1.0.1 Reporter: Alberto Vazquez Assignee: David Latorre We are using a week old snapshot from Ftpserver (it seems a bit newer than the 1.0.1 freeze). One of our clients reported that the data connection was being kept open for a long time ... They are using a propietary client its name I cannot remember and it was an SSL data connection in passive mode. After checking this using a windows Filezilla client and a Linux server running ftpserver (on top of Sun Java Application Server 9) we noticed that the FTP Server had several sockets in CLOSE_WAIT state. At the client side, the state was FIN_WAIT_2. To my mind , this could be related with the Socket leaking bug that was previously reported with SSL passive connections or its workaround although it might be SJAS fault or-who-knows. Since we don't have a linux machine available for testing I don't know what the real problem is. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r778323 - /mina/ftpserver/branches/1.0.0/core/src/main/java/org/apache/ftpserver/impl/IODataConnectionFactory.java
Thanks for fixing this David. However, this commit went into the wrong
branch. It should go into the
https://svn.apache.org/repos/asf/mina/ftpserver/branches/1.0.x/ branch
(the 1.0.0 is a left over that I will delete).
/niklas
On Mon, May 25, 2009 at 9:31 AM, d...@apache.org wrote:
Author: dlat
Date: Mon May 25 07:31:29 2009
New Revision: 778323
URL: http://svn.apache.org/viewvc?rev=778323view=rev
Log:
FTPSERVER-303 Underlying plain socket in SSL passive data connections was not
being closed properly.
Modified:
mina/ftpserver/branches/1.0.0/core/src/main/java/org/apache/ftpserver/impl/IODataConnectionFactory.java
Modified:
mina/ftpserver/branches/1.0.0/core/src/main/java/org/apache/ftpserver/impl/IODataConnectionFactory.java
URL:
http://svn.apache.org/viewvc/mina/ftpserver/branches/1.0.0/core/src/main/java/org/apache/ftpserver/impl/IODataConnectionFactory.java?rev=778323r1=778322r2=778323view=diff
==
---
mina/ftpserver/branches/1.0.0/core/src/main/java/org/apache/ftpserver/impl/IODataConnectionFactory.java
(original)
+++
mina/ftpserver/branches/1.0.0/core/src/main/java/org/apache/ftpserver/impl/IODataConnectionFactory.java
Mon May 25 07:31:29 2009
@@ -41,7 +41,7 @@
/**
* strongInternal class, do not use directly./strong
- *
+ *
* We can get the FTP data connection using this class. It uses either PORT or
* PASV command.
*
@@ -198,7 +198,7 @@
Data connection SSL required but not
configured.);
}
- // this method does not actually create the SSL socket, due
to a JVM bug
+ // this method does not actually create the SSL socket, due
to a JVM bug
// (https://issues.apache.org/jira/browse/FTPSERVER-241).
// Instead, it creates a regular
// ServerSocket that will be wrapped as a SSL socket in
createDataSocket()
@@ -237,7 +237,7 @@
/*
* (non-Javadoc)
- *
+ *
* @see org.apache.ftpserver.FtpDataConnectionFactory2#getInetAddress()
*/
public InetAddress getInetAddress() {
@@ -246,7 +246,7 @@
/*
* (non-Javadoc)
- *
+ *
* @see org.apache.ftpserver.FtpDataConnectionFactory2#getPort()
*/
public int getPort() {
@@ -255,7 +255,7 @@
/*
* (non-Javadoc)
- *
+ *
* @see org.apache.ftpserver.FtpDataConnectionFactory2#openConnection()
*/
public DataConnection openConnection() throws Exception {
@@ -307,10 +307,10 @@
// if no local address has been configured, make sure we use
the same as the client connects from
if(localAddr == null) {
localAddr =
((InetSocketAddress)session.getLocalAddress()).getAddress();
- }
+ }
SocketAddress localSocketAddress = new
InetSocketAddress(localAddr, dataConfig.getActiveLocalPort());
-
+
LOG.debug(Binding active data connection to {},
localSocketAddress);
dataSoc.bind(localSocketAddress);
@@ -319,12 +319,12 @@
if (secure) {
LOG.debug(Opening secure passive data connection);
- // this is where we wrap the unsecured socket as a
SSLSocket. This is
+ // this is where we wrap the unsecured socket as a
SSLSocket. This is
// due to the JVM bug described in FTPSERVER-241.
// get server socket factory
SslConfiguration ssl = getSslConfiguration();
-
+
// we've already checked this, but let's do it again
if (ssl == null) {
throw new FtpException(
@@ -339,7 +339,7 @@
SSLSocket sslSocket = (SSLSocket) ssocketFactory
.createSocket(serverSocket, serverSocket
.getInetAddress().getHostName(),
- serverSocket.getPort(), false);
+ serverSocket.getPort(), true);
sslSocket.setUseClientMode(false);
// initialize server socket
@@ -398,7 +398,7 @@
/*
* (non-Javadoc)
- *
+ *
* @see org.apache.ftpserver.DataConnectionFactory#isSecure()
*/
public boolean isSecure() {
@@ -414,7 +414,7 @@
/*
* (non-Javadoc)
- *
+ *
* @see org.apache.ftpserver.DataConnectionFactory#isZipMode()
*/
public boolean isZipMode() {
[jira] Closed: (FTPSERVER-303) Passive data connection stuck in CLOSE_WAIT.
[ https://issues.apache.org/jira/browse/FTPSERVER-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Latorre closed FTPSERVER-303. --- Resolution: Fixed Fix Version/s: 1.0.0 1.0.1 1.0.2 Committed to 1.0.0, 1.0.1 and trunk. I'm sorry for the delay! Alberto, can you proceed to test the fix and see if it's solving your problem? In my tests the connections are immediately closed so you should expect no issues here though. Passive data connection stuck in CLOSE_WAIT. Key: FTPSERVER-303 URL: https://issues.apache.org/jira/browse/FTPSERVER-303 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.0, 1.0.1 Reporter: Alberto Vazquez Assignee: David Latorre Fix For: 1.0.2, 1.0.1, 1.0.0 We are using a week old snapshot from Ftpserver (it seems a bit newer than the 1.0.1 freeze). One of our clients reported that the data connection was being kept open for a long time ... They are using a propietary client its name I cannot remember and it was an SSL data connection in passive mode. After checking this using a windows Filezilla client and a Linux server running ftpserver (on top of Sun Java Application Server 9) we noticed that the FTP Server had several sockets in CLOSE_WAIT state. At the client side, the state was FIN_WAIT_2. To my mind , this could be related with the Socket leaking bug that was previously reported with SSL passive connections or its workaround although it might be SJAS fault or-who-knows. Since we don't have a linux machine available for testing I don't know what the real problem is. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r778323 - /mina/ftpserver/branches/1.0.0/core/src/main/java/org/apache/ftpserver/impl/IODataConnectionFactory.java
Just a word about Javadoc: better than using @see to refer to the interface
or extended class's javadoc, use the @{inheritdoc} annotation. It's probably
more appropriate, and AFAIK, the generated javadoc will contain the
generated doc from the inherited class.
On Mon, May 25, 2009 at 10:53 AM, David Latorre dvl...@gmail.com wrote:
Oops,
Fixed
2009/5/25 Niklas Gustavsson nik...@protocol7.com:
Thanks for fixing this David. However, this commit went into the wrong
branch. It should go into the
https://svn.apache.org/repos/asf/mina/ftpserver/branches/1.0.x/ branch
(the 1.0.0 is a left over that I will delete).
/niklas
On Mon, May 25, 2009 at 9:31 AM, d...@apache.org wrote:
Author: dlat
Date: Mon May 25 07:31:29 2009
New Revision: 778323
URL: http://svn.apache.org/viewvc?rev=778323view=rev
Log:
FTPSERVER-303 Underlying plain socket in SSL passive data connections
was not being closed properly.
Modified:
mina/ftpserver/branches/1.0.0/core/src/main/java/org/apache/ftpserver/impl/IODataConnectionFactory.java
Modified:
mina/ftpserver/branches/1.0.0/core/src/main/java/org/apache/ftpserver/impl/IODataConnectionFactory.java
URL:
http://svn.apache.org/viewvc/mina/ftpserver/branches/1.0.0/core/src/main/java/org/apache/ftpserver/impl/IODataConnectionFactory.java?rev=778323r1=778322r2=778323view=diff
==
---
mina/ftpserver/branches/1.0.0/core/src/main/java/org/apache/ftpserver/impl/IODataConnectionFactory.java
(original)
+++
mina/ftpserver/branches/1.0.0/core/src/main/java/org/apache/ftpserver/impl/IODataConnectionFactory.java
Mon May 25 07:31:29 2009
@@ -41,7 +41,7 @@
/**
* strongInternal class, do not use directly./strong
- *
+ *
* We can get the FTP data connection using this class. It uses either
PORT or
* PASV command.
*
@@ -198,7 +198,7 @@
Data connection SSL required but not
configured.);
}
-// this method does not actually create the SSL socket,
due to a JVM bug
+// this method does not actually create the SSL socket,
due to a JVM bug
// (https://issues.apache.org/jira/browse/FTPSERVER-241
).
// Instead, it creates a regular
// ServerSocket that will be wrapped as a SSL socket in
createDataSocket()
@@ -237,7 +237,7 @@
/*
* (non-Javadoc)
- *
+ *
* @see
org.apache.ftpserver.FtpDataConnectionFactory2#getInetAddress()
*/
public InetAddress getInetAddress() {
@@ -246,7 +246,7 @@
/*
* (non-Javadoc)
- *
+ *
* @see org.apache.ftpserver.FtpDataConnectionFactory2#getPort()
*/
public int getPort() {
@@ -255,7 +255,7 @@
/*
* (non-Javadoc)
- *
+ *
* @see
org.apache.ftpserver.FtpDataConnectionFactory2#openConnection()
*/
public DataConnection openConnection() throws Exception {
@@ -307,10 +307,10 @@
// if no local address has been configured, make sure we
use the same as the client connects from
if(localAddr == null) {
localAddr =
((InetSocketAddress)session.getLocalAddress()).getAddress();
-}
+}
SocketAddress localSocketAddress = new
InetSocketAddress(localAddr, dataConfig.getActiveLocalPort());
-
+
LOG.debug(Binding active data connection to {},
localSocketAddress);
dataSoc.bind(localSocketAddress);
@@ -319,12 +319,12 @@
if (secure) {
LOG.debug(Opening secure passive data connection);
-// this is where we wrap the unsecured socket as a
SSLSocket. This is
+// this is where we wrap the unsecured socket as a
SSLSocket. This is
// due to the JVM bug described in FTPSERVER-241.
// get server socket factory
SslConfiguration ssl = getSslConfiguration();
-
+
// we've already checked this, but let's do it again
if (ssl == null) {
throw new FtpException(
@@ -339,7 +339,7 @@
SSLSocket sslSocket = (SSLSocket) ssocketFactory
.createSocket(serverSocket, serverSocket
.getInetAddress().getHostName(),
-serverSocket.getPort(), false);
+serverSocket.getPort(), true);
sslSocket.setUseClientMode(false);
// initialize server socket
@@ -398,7 +398,7 @@
/*
* (non-Javadoc)
- *
+ *
* @see org.apache.ftpserver.DataConnectionFactory#isSecure()
*/
public
Re : Re : Re : Preparing a 2.0.0-M6 release
Okay (i tested the two ways last night but either failed ...) Do i have to put some lines in my settings.xml file ? here are the steps i followed : svn co . branches/mina/2.0.0-M6 mina cd mina mvn -Pserial clean install mvn -Pserial site mvn -Pserial assembly:assembly - fails here Cordialement, Regards, -Edouard De Oliveira- Blog: http://tedorgwp.free.fr WebSite: http://tedorg.free.fr/en/main.php - Message d'origine De : Emmanuel Lecharny elecha...@apache.org À : dev@mina.apache.org Envoyé le : Lundi, 25 Mai 2009, 8h18mn 52s Objet : Re: Re : Re : Preparing a 2.0.0-M6 release Edouard De Oliveira wrote: No i didn't i used mvn -Dwith-LGPL-dependencies clean install Ok, it's equivalent. -Pserial defines a maven profile which defines the with-LGPL-dependencies property. It's just shorter to type and easier to remember ;) -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
[jira] Updated: (FTPSERVER-303) Passive data connection stuck in CLOSE_WAIT.
[ https://issues.apache.org/jira/browse/FTPSERVER-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niklas Gustavsson updated FTPSERVER-303: Fix Version/s: (was: 1.0.1) (was: 1.0.0) 1.1 Changing the fix versions as we can only make fixes to future versions, 1.0.0 and 1.0.1 has already been released. Passive data connection stuck in CLOSE_WAIT. Key: FTPSERVER-303 URL: https://issues.apache.org/jira/browse/FTPSERVER-303 Project: FtpServer Issue Type: Bug Components: Core Affects Versions: 1.0.0, 1.0.1 Reporter: Alberto Vazquez Assignee: David Latorre Fix For: 1.0.2, 1.1 We are using a week old snapshot from Ftpserver (it seems a bit newer than the 1.0.1 freeze). One of our clients reported that the data connection was being kept open for a long time ... They are using a propietary client its name I cannot remember and it was an SSL data connection in passive mode. After checking this using a windows Filezilla client and a Linux server running ftpserver (on top of Sun Java Application Server 9) we noticed that the FTP Server had several sockets in CLOSE_WAIT state. At the client side, the state was FIN_WAIT_2. To my mind , this could be related with the Socket leaking bug that was previously reported with SSL passive connections or its workaround although it might be SJAS fault or-who-knows. Since we don't have a linux machine available for testing I don't know what the real problem is. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-16) org.apache.mina.common.TransportType
[ https://issues.apache.org/jira/browse/DIRMINA-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-16. org.apache.mina.common.TransportType Key: DIRMINA-16 URL: https://issues.apache.org/jira/browse/DIRMINA-16 Project: MINA Issue Type: Improvement Environment: Improve TransportType for permit to extend MINA supported transport types Reporter: Julien Vermillard Assignee: Trustin Lee Fix For: 0.7.0, 2.0.0-M1 the TransportType define the differents TransportType in MINA (Socket,Datagram, VM Pipe). The types are static and hardcoded. The constructor of Transport type is private. It leave no room for new Transport. I propose : 1st : change the transportType constructor visibility to public 2snd : move the staticly defined TransportTypes to the different io.datagram, io.socket, etc.. packages -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-73) The new close(boolean wait) logic seems flawed, never waiting for flush
[
https://issues.apache.org/jira/browse/DIRMINA-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny closed DIRMINA-73.
The new close(boolean wait) logic seems flawed, never waiting for flush
---
Key: DIRMINA-73
URL: https://issues.apache.org/jira/browse/DIRMINA-73
Project: MINA
Issue Type: Bug
Affects Versions: 0.7.3
Environment: N/A
Reporter: Magnus Naeslund
Assignee: Trustin Lee
Priority: Critical
Fix For: 0.7.4
Attachments: mina-SocketSession-close-fix1.diff
It seems the while (disposed) test should be inverted.
Patch:
--- org/apache/mina/io/socket/SocketSession.java(revision 219643)
+++ org/apache/mina/io/socket/SocketSession.java(working copy)
@@ -130,7 +130,7 @@
SocketIoProcessor.getInstance().removeSession( this );
if( wait )
{
-while( disposed )
+while( !disposed )
{
try
{
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-78) ByteBuffer.wrap((byte[],?) The element of least suprise
[ https://issues.apache.org/jira/browse/DIRMINA-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-78. ByteBuffer.wrap((byte[],?) The element of least suprise --- Key: DIRMINA-78 URL: https://issues.apache.org/jira/browse/DIRMINA-78 Project: MINA Issue Type: New Feature Affects Versions: 0.7.0, 0.7.1, 0.7.2, 0.7.3 Reporter: Magnus Naeslund Assignee: Trustin Lee Priority: Minor Fix For: 0.7.4 Attachments: mina-bytebuffer-wrap-example.diff, mina-bytebuffer-wrap-fix-1.diff *This is just an discussion, not a bug* The problem: When mina wraps (buffers or arrays) external data, it keeps push()ing the nio buffer to the stacks of buffers, but it can't reuse them when wrapping (since they either already exist or was created from nio wrap()). This could be fixed in two ways: 1) When wrapping, re-use buffers as usual, con: extra copy 2) Have a flag that causes the underlying nio buffer to not be pooled after release I would rather see minas bytebuffer to copy the data than cause an memory leak. I've just debugged a project that writes byte arrays (old code, needs to write arrays), and found the memory leak that is (kind of) described in the mina ByteBuffer documentation. I ended up with a unbounded leak of nio HeapByteBuffers. I know that this is discouraged in the documentation, but I don't like these kind of suprises that you get from using mina without carefully reading the documentation (note that the javadoc warning isn't at the method level). It's like the close(true) that doesn't flush the buffers before closing the session (I can't understand why anyone wants it the way it is now). I know copy it's slower, but if you're using wrap(), you'll need to do something like that anyways... I implemented the copy for byte arrays as an example, because it is the least modification, I'll attach it to this issue. So after this little rant, what do you think about this suggestion? Regards, Magnus Naeslund Magnus -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-82) IdleSession reported only once per IO
[
https://issues.apache.org/jira/browse/DIRMINA-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny closed DIRMINA-82.
IdleSession reported only once per IO
-
Key: DIRMINA-82
URL: https://issues.apache.org/jira/browse/DIRMINA-82
Project: MINA
Issue Type: Bug
Affects Versions: 0.7.3
Reporter: Ash Hornbeck
Assignee: Trustin Lee
Fix For: 0.8.0
IdleSession reported only once per IO
For example, if I do something like this
// session is a ProtocolSession from an IoProtocolConnector
session.getConfig().setIdleTime(IdleStatus.BOTH_IDLE,30 );
and a connection is idle for 301 seconds (both read and write), I expect
roughly 10 IdleStatus.BOTH_IDLE events. In 0.7.3 it will only be fired once
and only once until IO occurs. It looks like it is due to the way idle
sessions are detected in the following:
SocketIoProcessor.java:
private void notifyIdleSession0( SocketSession session, long currentTime,
long idleTime, IdleStatus status,
long lastIoTime )
{
if( idleTime 0 !session.isIdle( status ) lastIoTime != 0
( currentTime - lastIoTime ) = idleTime )
{
session.setIdle( status, true );
session.getManagerFilterChain().sessionIdle( session, status );
}
}
Please correct me if I am wrong but it looks as though the statement in the
if clause, !session.isIdle( status ), is used to detect if the idle event has
been fired. This prevents multiple session idle events from being fired due
to selector timeouts in Worker.run().
The problem is that using this method there is no way to know that the last
idle event was fired greater than idle timeout seconds ago and another event
needs to be fired.
My suggestion is to add lastIdleEventForBoth/Read/Write and replace
!session.isIdle( status) with (currentTime ? lastIdleEvent) = idleTime.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-83) SocketIoProcessor halts if channel is closed while flushing.
[ https://issues.apache.org/jira/browse/DIRMINA-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-83. SocketIoProcessor halts if channel is closed while flushing. Key: DIRMINA-83 URL: https://issues.apache.org/jira/browse/DIRMINA-83 Project: MINA Issue Type: Bug Affects Versions: 0.7.3 Reporter: Trustin Lee Assignee: Trustin Lee Fix For: 0.7.4 From Rodrigo Kumpera's report: Great work with mina, it do makes writting nio servers easy. I´m writing a filtering server and have the following scenario: 1-incoming connections, using ServiceRegistry with IoHandler. 2-filtering is done in a separate pool (using doug lea's util.concurrent package) 3-fowarding the result to another server, using SocketIoProcessor and IoThreadPoolFilter. So fair I´ve been able to fine tune the thread pool used by the ServiceRegistry (1). My problem is with (2) and (3), I want to have a single thread pool to be shared by the 3 stages of the server. With the filtering stage I´m thinking about playing with IoThreadPoolFilter implementation to use util.concurrent and expose it's interface. My problem when using a thread pool with the last stage, when connecting to foreign hosts, is that it throws the following exception under moderate load: java.nio.channels.CancelledKeyException at sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:55) at sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:59) at org.apache.mina.io.socket.SocketIoProcessor.flush(SocketIoProcessor.j ava:511) at org.apache.mina.io.socket.SocketIoProcessor.flushSessions(SocketIoPro cessor.java:422) at org.apache.mina.io.socket.SocketIoProcessor.access$300(SocketIoProces sor.java:41) at org.apache.mina.io.socket.SocketIoProcessor$Worker.run(SocketIoProces sor.java:546) I tried to use the same IoThreadPoolFilter with an instance of SocketIoProcessor and ServiceRegistry, but it doesn´t seen to work, the server halts and don't make any progress. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-79) The number of ThreadPoolFilter threads becomes 0 sometimes.
[ https://issues.apache.org/jira/browse/DIRMINA-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-79. The number of ThreadPoolFilter threads becomes 0 sometimes. --- Key: DIRMINA-79 URL: https://issues.apache.org/jira/browse/DIRMINA-79 Project: MINA Issue Type: Bug Affects Versions: 0.7.3 Reporter: Trustin Lee Assignee: Trustin Lee Fix For: 0.7.4 Related forum thread: http://gleamynode.net/dev/forum/read.php?1,20 It seems like all thread pool threads suicide without any exceptions at some situation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-89) MINA for JDK1.3
[ https://issues.apache.org/jira/browse/DIRMINA-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-89. MINA for JDK1.3 --- Key: DIRMINA-89 URL: https://issues.apache.org/jira/browse/DIRMINA-89 Project: MINA Issue Type: New Feature Affects Versions: 0.9.0 Environment: JDK1.3 Reporter: Donald_liu Attachments: MINA-for-JDK1.3.rar MINA for JDK1.3 add package of : org.apache.mina.biosocket org.apache.mina.buffer main change on package of org.apache.mina.common TODO: see TODO.txt in the eclipse project -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-130) SSLFilter has to dispose SSLEngine when the filter is removed from a chain.
[ https://issues.apache.org/jira/browse/DIRMINA-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-130. - SSLFilter has to dispose SSLEngine when the filter is removed from a chain. --- Key: DIRMINA-130 URL: https://issues.apache.org/jira/browse/DIRMINA-130 Project: MINA Issue Type: Bug Affects Versions: 0.8.0, 0.8.1 Reporter: Vinod Panicker Assignee: Trustin Lee Priority: Minor Fix For: 0.9.0 SSLFilter should dispose of the SSLEngine object when SSLFilter is removed from the session -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-161) A ObjectSerializationEncoder that works with Java's ObjectInputStream.readObject()
[ https://issues.apache.org/jira/browse/DIRMINA-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-161. - A ObjectSerializationEncoder that works with Java's ObjectInputStream.readObject() -- Key: DIRMINA-161 URL: https://issues.apache.org/jira/browse/DIRMINA-161 Project: MINA Issue Type: New Feature Affects Versions: 0.9.0 Reporter: Andy Korth Assignee: Trustin Lee Priority: Minor Fix For: 1.0.0 Having a class similar to ObjectSerializationDecoder/Encoder that was compatable with ObjectInputStream.readObject() would be very helpful for those who are rewriting servers to use MINA without the ability to change client code. Currently, an attempt to use readObject() to receive information from the existing ObjectSerializationEncoder results in: org.apache.mina.filter.codec.ProtocolDecoderException: org.apache.mina.common.BufferDataException: dataLength: -1393754107 (Hexdump: empty) I suspect this has something to do with the reading of the prefixed data. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-192) Clustering for transparent load balancing
[ https://issues.apache.org/jira/browse/DIRMINA-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-192. - Clustering for transparent load balancing - Key: DIRMINA-192 URL: https://issues.apache.org/jira/browse/DIRMINA-192 Project: MINA Issue Type: Wish Reporter: Federico Bonelli I wish I can manage more MINA cores running on different computers, binding and unbinding addresses as if they were on my own JVM. This way could help fixing problems related to low bandwidth. This is the issue we discussed about on mail list, with the thread title of [MINA] What about a cluster for network load balancing? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-198) Naming conventions
[ https://issues.apache.org/jira/browse/DIRMINA-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-198. - Naming conventions -- Key: DIRMINA-198 URL: https://issues.apache.org/jira/browse/DIRMINA-198 Project: MINA Issue Type: Wish Affects Versions: 0.9.3 Reporter: Michael Bauroth Assignee: Trustin Lee Priority: Trivial It would be a great idea to define some naming conventions for the source code. Especially for new users, but also for all others it can be confusing to know, if a special variable in a longer method is static or global or anything else. Naming conventions can generate more readable code and a quicker programming progress. In our company we use the following conventions: static final variables: UPPER_CASE static variables: sStatic (leading -s, next letter big) global variables: mMember (leading -m, next letter big) local (temporary) variables: tTemp (leading -t, next letter big) parameters: pParam (leading -p, next letter big) What do you think? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-200) IBM iSeries throws unexpected SocketException
[ https://issues.apache.org/jira/browse/DIRMINA-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-200. - IBM iSeries throws unexpected SocketException - Key: DIRMINA-200 URL: https://issues.apache.org/jira/browse/DIRMINA-200 Project: MINA Issue Type: Bug Affects Versions: 0.9.3, 0.9.4 Environment: mina-0.9.3 JDK 1.4.2 IBM iSeries OS/400 V5R2 Reporter: Simon Temple Assignee: Trustin Lee Priority: Blocker Fix For: 0.9.5 Attachments: mina-ex.patch Proposal of a change to nio SocketSessionImpl. I'd like the calls to: getTrafficClass setTrafficClass setSendBufferSize setReceiveBufferSize to not throw RuntimeIOException when a SocketException is caught. My reasoning is based on the Socket class javadoc: E.g. setTrafficClass As the underlying network implementation may ignore this value applications should consider it a hint. and Setting bits in the precedence field may result in a SocketException indicating that the operation is not permitted. The other getter/setter method javadoc also refer to 'hints' and a 'if there is an error obtaining' condition. Some operating systems (OS/400 in my case ;-) ), do not allow the trafficClass value to be read or written. I think this may also be the case as reported here on Linux: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4709474 By ignoring the SocketException thrown by these methods (perhaps issuing a log4j WARN instead? Or hooking up with an appropriate monitor?), socket sessions can be established without error on an IBM iSeries. Example stack trace: 2006-04-03 17:26:26,343 WARN [org.apache.mina.common.support.DefaultExceptionMonitor](SocketAcceptor-0) Unexpected exception. org.apache.mina.common.RuntimeIOException: java.net.SocketException at java.lang.Throwable.init(Throwable.java:240) at java.lang.Exception.init(Exception.java:77) at java.lang.RuntimeException.init(RuntimeException.java:77) at org.apache.mina.common.RuntimeIOException.init(RuntimeIOException.java:48) at org.apache.mina.transport.socket.nio.support.SocketSessionImpl$SocketSessionConfigImpl.setTrafficClass(SocketSessionImpl.java:342) at org.apache.mina.transport.socket.nio.support.SocketSessionImpl.init(SocketSessionImpl.java:71) at org.apache.mina.transport.socket.nio.support.SocketAcceptorDelegate$Worker.processSessions(SocketAcceptorDelegate.java:379) at org.apache.mina.transport.socket.nio.support.SocketAcceptorDelegate$Worker.run(SocketAcceptorDelegate.java:326) Caused by: java.net.SocketException at java.lang.Throwable.init(Throwable.java:180) at java.lang.Exception.init(Exception.java:29) at java.io.IOException.init(IOException.java:28) at java.net.SocketException.init(SocketException.java:35) at sun.nio.ch.Net.setIntOption(Net.java:156) at sun.nio.ch.SocketChannelImpl$1.setInt(SocketChannelImpl.java:398) at sun.nio.ch.SocketOptsImpl.setInt(SocketOptsImpl.java:46) at sun.nio.ch.SocketOptsImpl$IP.typeOfService(SocketOptsImpl.java:249) at sun.nio.ch.OptionAdaptor.setTrafficClass(OptionAdaptor.java:158) at sun.nio.ch.SocketAdaptor.setTrafficClass(SocketAdaptor.java:320) ... 4 more I have attached a proposed patch and welcome any comments. SimonT -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-207) Charset.getDefaultEncoding doesn't work with JDK 1.6.0-beta2
[ https://issues.apache.org/jira/browse/DIRMINA-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-207. - Charset.getDefaultEncoding doesn't work with JDK 1.6.0-beta2 Key: DIRMINA-207 URL: https://issues.apache.org/jira/browse/DIRMINA-207 Project: MINA Issue Type: Bug Affects Versions: 0.9.3 Reporter: Michael Bauroth Assignee: Trustin Lee Priority: Minor Fix For: 0.9.4 version check doesn't exist ... version.startsWith( 1.6 ) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-205) Create a utility to list ports and sockets being used
[ https://issues.apache.org/jira/browse/DIRMINA-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-205. - Create a utility to list ports and sockets being used - Key: DIRMINA-205 URL: https://issues.apache.org/jira/browse/DIRMINA-205 Project: MINA Issue Type: New Feature Environment: all Reporter: Chris Allen Assignee: Trustin Lee Priority: Minor Fix For: 0.9.5 Create a utility to list the sockets and ports MINA is binding to and list the handlers attached to them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-214) The InputStream that StreamIoHandler provides is closed too early.
[ https://issues.apache.org/jira/browse/DIRMINA-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-214. - The InputStream that StreamIoHandler provides is closed too early. -- Key: DIRMINA-214 URL: https://issues.apache.org/jira/browse/DIRMINA-214 Project: MINA Issue Type: Bug Reporter: Trustin Lee Assignee: Trustin Lee Fix For: 0.9.5 Zohar Amir wrote: While trying to demonstrate the issue I found that the exception _is_ thrown, but sometimes sessionClosed is invoked before the new thread gets a chance to read the available data from the stream. I followed the example of the httpserver that is provided with MINA, only there is no handling of client socket closure there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-209) SocketIoProcessor singleton causes performance wall under load
[ https://issues.apache.org/jira/browse/DIRMINA-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-209. - SocketIoProcessor singleton causes performance wall under load -- Key: DIRMINA-209 URL: https://issues.apache.org/jira/browse/DIRMINA-209 Project: MINA Issue Type: Bug Affects Versions: 0.9.4 Reporter: peter royal Fix For: 0.9.4 The changes to have SocketIoProcessor have a fixed number of instances that are shared between connectors and acceptors results in a default performance degradation for applications that used both. This will be fixed by having socket acceptor and connectors each use their own processor. Additionally, the number of processors for each will be configurable independently. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-219) Example test cases fail on IBM JVM due to lacking SSL algorithms
[ https://issues.apache.org/jira/browse/DIRMINA-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-219. - Example test cases fail on IBM JVM due to lacking SSL algorithms Key: DIRMINA-219 URL: https://issues.apache.org/jira/browse/DIRMINA-219 Project: MINA Issue Type: Bug Affects Versions: 0.9.0, 0.9.1, 0.9.2, 0.9.3, 0.9.4, 0.9.5 Environment: Java(TM) 2 Runtime Environment, Standard Edition (build pxp32devifx-20060310 (SR1)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux ppc-32 j9vmxp3223ifx-20060310 (JIT enabled) J9VM - 20060220_05389_bHdSMR JIT - 20060220_2133_r8 GC - 20060214_AA) JCL - 20060222a Reporter: Alex Karasulu Assignee: Trustin Lee Fix For: 0.9.5 The example test cases for the AcceptorTest and ConnectorTest fail due to not finding SSL algorithm on IBM JVM: --- Test set: org.apache.mina.examples.echoserver.AcceptorTest --- Tests run: 3, Failures: 0, Errors: 3, Skipped: 0, Time elapsed: 3.422 sec FAILURE! testTCP(org.apache.mina.examples.echoserver.AcceptorTest) Time elapsed: 3.079 sec ERROR! java.security.GeneralSecurityException: Can't create Server SSLContext:java.security.NoSuchAlgorithmException: SunX509 KeyManagerFactory not available at org.apache.mina.examples.echoserver.ssl.BogusSSLContextFactory.getInstance(BogusSSLContextFactory.java:89) at org.apache.mina.examples.echoserver.AbstractTest.setUp(AbstractTest.java:87) at junit.framework.TestCase.runBare(TestCase.java:125) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-224) Data Corruption
[ https://issues.apache.org/jira/browse/DIRMINA-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-224. - Data Corruption --- Key: DIRMINA-224 URL: https://issues.apache.org/jira/browse/DIRMINA-224 Project: MINA Issue Type: Bug Environment: Linux version 2.4.29-3.2a (gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-98)) #1 Fri May 27 10:39:22 PDT 2005 java version 1.5.0_05 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode) Reporter: Hanson Char Assignee: Trustin Lee Attachments: Mina-0.8.2-bug.jar, Mina-0.9.4-bug.jar, TEST-test.JUnitTest.jar Messages written to the session get corrupted when Mina 0.8.2 is run on Linux 7.2, but not when run on Windows XP. Note there is no explicit use of thread pool. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-223) Addition of SocketConnector method to handle socks proxies.
[
https://issues.apache.org/jira/browse/DIRMINA-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny closed DIRMINA-223.
-
Addition of SocketConnector method to handle socks proxies.
---
Key: DIRMINA-223
URL: https://issues.apache.org/jira/browse/DIRMINA-223
Project: MINA
Issue Type: Improvement
Affects Versions: 0.9.4
Environment: All platforms
Reporter: John Preston
When using MINA to to establish a SocketConnector behind a firewall it is
necessary to specify socks proxie to use. The SocketConnector can be ammended
as follows: (svn diff)
Index:
core/src/main/java/org/apache/mina/transport/socket/nio/SocketConnector.java
===
---
core/src/main/java/org/apache/mina/transport/socket/nio/SocketConnector.java
(revision 415629)
+++
core/src/main/java/org/apache/mina/transport/socket/nio/SocketConnector.java
(working copy)
@@ -21,6 +21,7 @@
import java.io.IOException;
import java.net.ConnectException;
import java.net.InetSocketAddress;
+import java.net.Proxy;
import java.net.SocketAddress;
import java.nio.channels.SelectionKey;
import java.nio.channels.Selector;
@@ -61,6 +62,7 @@
private final Set managedSessions = Collections.synchronizedSet( new
HashSet() );
private final SocketIoProcessor[] ioProcessors;
private final int processorCount;
+private final Proxy socketProxy;
/**
* @noinspection FieldAccessedSynchronizedAndUnsynchronized
@@ -73,9 +75,17 @@
/**
* Create a connector with a single processing thread
*/
+public SocketConnector(Proxy proxy)
+{
+this( 1, proxy );
+}
+
+/**
+ * Create a connector with a single processing thread
+ */
public SocketConnector()
{
-this( 1 );
+this( 1, Proxy.NO_PROXY );
}
/**
@@ -83,7 +93,7 @@
*
* @param processorCount Number of processing threads
*/
-public SocketConnector( int processorCount )
+public SocketConnector( int processorCount, Proxy proxy )
{
if( processorCount 1 )
{
@@ -91,6 +101,7 @@
}
this.processorCount = processorCount;
+this.socketProxy = proxy == null ? Proxy.NO_PROXY : proxy;
ioProcessors = new SocketIoProcessor[processorCount];
for( int i = 0; i processorCount; i++ )
@@ -153,11 +164,12 @@
boolean success = false;
try
{
-ch = SocketChannel.open();
-ch.socket().setReuseAddress( true );
+Socket s = new Socket(socketProxy);
+s.setReuseAddress( true );
+ch = s.getChannel().open();
if( localAddress != null )
{
-ch.socket().bind( localAddress );
+s.bind( localAddress );
}
ch.configureBlocking( false );
@@ -475,4 +487,4 @@
this.config = config;
}
}
-}
\ No newline at end of file
+}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-226) IoSessionInputStream.read() does not properly return -1 to indicate end-of-stream.
[
https://issues.apache.org/jira/browse/DIRMINA-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny closed DIRMINA-226.
-
IoSessionInputStream.read() does not properly return -1 to indicate
end-of-stream.
--
Key: DIRMINA-226
URL: https://issues.apache.org/jira/browse/DIRMINA-226
Project: MINA
Issue Type: Bug
Affects Versions: 0.9.4
Reporter: peter royal
Assignee: peter royal
Fix For: 0.9.5
With the following snippet:
BufferedReader in = new BufferedReader(
new InputStreamReader( this.in ) );
String line;
while ( ( line = in.readLine() ) != null
!line.equals( ) )
{
System.out.println(data is: + line);
}
After the data is printed, there is an exception
java.io.IOException: Stream is closed.
at
org.apache.mina.handler.support.IoSessionInputStream.waitForData(IoSessionInputStream.java:131)
at
org.apache.mina.handler.support.IoSessionInputStream.read(IoSessionInputStream.java:102)
at
sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:411)
at
sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183)
at java.io.InputStreamReader.read(InputStreamReader.java:167)
at java.io.BufferedReader.fill(BufferedReader.java:136)
at java.io.BufferedReader.readLine(BufferedReader.java:299)
at java.io.BufferedReader.readLine(BufferedReader.java:362)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-233) Provide an extra thin logging layer for those who don't want SLF4J
[ https://issues.apache.org/jira/browse/DIRMINA-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-233. - Provide an extra thin logging layer for those who don't want SLF4J -- Key: DIRMINA-233 URL: https://issues.apache.org/jira/browse/DIRMINA-233 Project: MINA Issue Type: Task Reporter: Trustin Lee As MINA gets more and more popular, the number of people who doesn't want SLF4J increased because they were using other logging frameworks such as Log4J or commons-logging. We know SLF4J provides what exactly Log4J or commons-logging provides, but it's just a matter of preference. We need to meet as many people's preference as we can as a general network application framework. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-238) IoService.add/removeListener()
[ https://issues.apache.org/jira/browse/DIRMINA-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-238. - IoService.add/removeListener() -- Key: DIRMINA-238 URL: https://issues.apache.org/jira/browse/DIRMINA-238 Project: MINA Issue Type: New Feature Reporter: Trustin Lee Assignee: Trustin Lee Priority: Minor Fix For: 0.9.5 For now, we're providing IoSession.gerManagedSessions() which returns the list of managed sessions. But this is basically polling which can bring us a lot of overhead. We could provide an event listener interface that monitors the creation and destruction of IoSessions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-235) Reliable hang of DS during query
[ https://issues.apache.org/jira/browse/DIRMINA-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-235. - Reliable hang of DS during query Key: DIRMINA-235 URL: https://issues.apache.org/jira/browse/DIRMINA-235 Project: MINA Issue Type: Bug Affects Versions: 0.9.4, 0.9.5, 1.0.0 Reporter: Jörg Henne Assignee: Trustin Lee Fix For: 1.0.1 In DIRSERVER-586 I describe a weird behaviour where channels vanish from the SocketIoProcessor's selector. I strongly suspect there's a problem wit MINA here. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-241) Calling other session's write() in messageReceived() handler causes deadlock when a SSLFilter is used.
[
https://issues.apache.org/jira/browse/DIRMINA-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny closed DIRMINA-241.
-
Calling other session's write() in messageReceived() handler causes deadlock
when a SSLFilter is used.
--
Key: DIRMINA-241
URL: https://issues.apache.org/jira/browse/DIRMINA-241
Project: MINA
Issue Type: Bug
Components: Filter
Affects Versions: 1.0.0, 1.0.1, 1.0.2
Reporter: jo,sung jun
Assignee: Trustin Lee
Fix For: 1.0.3
Attachments: thread thump.txt
Hello,
Could you advise for me about this problem.
I attached server thread thumb.
I run the server , There are many clients,
When I use session.write , it happened deadlock.
I don't know why~
this is some sample about multicast.
public void multicast(String channelName, Object message) {
if (!(message instanceof ByteBuffer)) {
return;
}
ByteBuffer rb = (ByteBuffer) message;
//try{
GameRoom channel = RoomManager.getRoom(channelName);
List list = (List) channel.getUsers();
Iterator it = list.iterator();
while (it.hasNext()) {
ByteBuffer buf = rb.duplicate();
User user = (User) it.next();
WrteFuture future =
users.getSession().write(buf);
future.join();
}
rb.release();
//}catch(Throwable t) {
//}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-242) ByteBuffer.getString(ByteBuffer buf, int fieldSize, CharsetDecoder decoder, boolean stopOnZero )
[
https://issues.apache.org/jira/browse/DIRMINA-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny closed DIRMINA-242.
-
ByteBuffer.getString(ByteBuffer buf, int fieldSize, CharsetDecoder decoder,
boolean stopOnZero )
Key: DIRMINA-242
URL: https://issues.apache.org/jira/browse/DIRMINA-242
Project: MINA
Issue Type: New Feature
Affects Versions: 0.8.2
Reporter: Pavel Zdenek
Assignee: Trustin Lee
Priority: Trivial
The method would read an ASCIIZ string off the buffer as the existing method
without added parameter.
If stopOnZero is false, it would continue blindly reading the stream up to
the required fieldSize.
So far MINA has no support for reading fixed (small) size strings. This is
common for protocols constructed at devices with limited resources (i.e.
network attached microcontrollers) and above the mandatory ending zero may be
whatever garbage left from previous memory usage.
My temporary implementation follows, to get the idea.
It also solves the problem with getString behavior when reading ASCIIZ at the
end of buffer (apparently fixed in dev 0.9)
public static String getString(ByteBuffer buf, int fieldSize,
CharsetDecoder decoder, boolean stopOnZero )
throws CharacterCodingException
{
if( fieldSize == 0) fieldSize = buf.remaining(); // convenience 0 ~
till the end
int origLimit = buf.limit();
int posStrEnd = 0;
buf.mark(); // beginning of string
boolean foundZero = false;
while(buf.hasRemaining() (fieldSize-- 0) )
{
if( (buf.get() == 0) !foundZero )
{
foundZero = true;
posStrEnd = buf.position()-1;
if( stopOnZero ) break;
}
}
int reachedPos = buf.position(); // later must return here
buf.reset(); // position to string begin
if(foundZero) buf.limit( posStrEnd );
String str = buf.getString(decoder);
if(foundZero) buf.limit(origLimit);
buf.position(reachedPos);
return str;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-244) Example HTTP server using ProtocolCodeFactory
[ https://issues.apache.org/jira/browse/DIRMINA-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-244. - Example HTTP server using ProtocolCodeFactory - Key: DIRMINA-244 URL: https://issues.apache.org/jira/browse/DIRMINA-244 Project: MINA Issue Type: New Feature Environment: Fedora Core 5 Linux Reporter: John Preston Assignee: Trustin Lee Priority: Minor Fix For: 1.0.0 Attachments: mina-http.tgz The attached files implement a HTTP server by providing a protocol codec for HTTP requests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-248) ProtocolDecoder should get notified when a connection is closed.
[ https://issues.apache.org/jira/browse/DIRMINA-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-248. - ProtocolDecoder should get notified when a connection is closed. Key: DIRMINA-248 URL: https://issues.apache.org/jira/browse/DIRMINA-248 Project: MINA Issue Type: Improvement Reporter: Trustin Lee Assignee: Trustin Lee Fix For: 0.9.5 Randy Watlet wrote: == I am attempting to use Mina to build a scalable Ajax web application test harness, (a Mina client). So far, so good... :-). One quick question: I have an operational HTTP message decoder in place, but I am not sure how to support the parsing of a complete HTTP response when the HTTP Content-length is not known. In particular, I need to know when the underling session is closing, (IoSession.isClosing() == true), while parsing the last packet from the server. It seems this is not now the case. I will eventually get an IoHander.sessionClosing() callback, but the undecoded message is left hanging out there with decodable() returning false. To hack this, I figure I could add a last unknown content length ByteBuffer as a session attribute from MessageDecoder.decodable(), (carefully acquire() and release() managed), and process it on IoHandler.sessionClosing() manually. This seems kind of ugly and not within the spirit of the Mina API. Any suggestions how to better handle this? My idea: Ah, so.. in HTTP/1.0, 'EOC (end of connection)' can be a useful information for decoding, but it is not informed to ProtocolDecoder, right? This is certainly a problem. For now, ProtocolDecoder.dispose () is invoked just before sessionClosed() is invoked. So we could add a ProtocolDecoderOutput parameter to dispose() method, but I think is not a good idea. Providing another method like 'finishDecode()' would be better to separate the decoding code and the resource management code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-373) NullPointer Exception in SocketAccept class
[ https://issues.apache.org/jira/browse/DIRMINA-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-373. - NullPointer Exception in SocketAccept class --- Key: DIRMINA-373 URL: https://issues.apache.org/jira/browse/DIRMINA-373 Project: MINA Issue Type: Bug Affects Versions: 0.8.0 Environment: Windows XP Reporter: S. Nageswara Rao Assignee: Trustin Lee Fix For: 0.8.0 I am using MINA v0.8.0 in my component. I hit upon the following NullPointer Exception when I try to call unbind method to unregister the service from the registry. java.lang.NullPointerException at org.apache.mina.io.socket.SocketAcceptor.cancelKeys(SocketAcceptor.java:431) at org.apache.mina.io.socket.SocketAcceptor.access$900(SocketAcceptor.java:47) at org.apache.mina.io.socket.SocketAcceptor$Worker.run(SocketAcceptor.java:240) This has a considerable impact on my component. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-251) PooledThreadModel must allow the application to specify a ThreadPool implementation
[ https://issues.apache.org/jira/browse/DIRMINA-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-251. - PooledThreadModel must allow the application to specify a ThreadPool implementation --- Key: DIRMINA-251 URL: https://issues.apache.org/jira/browse/DIRMINA-251 Project: MINA Issue Type: Improvement Affects Versions: 0.9.5 Environment: All Reporter: Vinod Panicker Assignee: Trustin Lee Fix For: 1.0.0 Attachments: diff.txt Currently the PooledThreadModel by default creates a L-F thread pool instance. It should be flexible in supporting different thread pool implementations, such as the Java5 Executor based one. This way, the application can specify what kind of thread pool implementation it wants. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-254) Add links to all examples
[ https://issues.apache.org/jira/browse/DIRMINA-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-254. - Add links to all examples - Key: DIRMINA-254 URL: https://issues.apache.org/jira/browse/DIRMINA-254 Project: MINA Issue Type: Task Reporter: Trustin Lee Assignee: Niklas Therning Fix For: 1.0.0 Some examples such as proxy is not linked from our getting started page. All examples should be linked. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-275) Exception in thread SocketAcceptor-1 java.nio.channels.CancelledKeyException
[ https://issues.apache.org/jira/browse/DIRMINA-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-275. - Exception in thread SocketAcceptor-1 java.nio.channels.CancelledKeyException -- Key: DIRMINA-275 URL: https://issues.apache.org/jira/browse/DIRMINA-275 Project: MINA Issue Type: Bug Components: Core Affects Versions: 0.8.3, 1.0.0 Environment: Unix (Asianux) with Service Wrapper Reporter: Phan Thanh Hieu Assignee: Trustin Lee Fix For: 0.8.4, 1.0.1 Attachments: log.log, mina.zip Environment: Unix (Asianux) with Service Wrapper. My software (called DC) works a server listening on some Port, it will receive messages from several of BC. Each BC will get and keep the connection then sending the messages through this session (if disconnect, BC will re-connect and continue sending the messages). My problem is: When executing long-run testing: has 5 BC sending messages to DC. I tried to stop the DC via: ./dc-deamon.sh stop (this script is got from Service Wrapper site). = the kind of exception below had occurred: --- main| 2006/10/02 09:12:23 | 2006-10-02 09:12:23:170 [SocketAcceptor-1] [com.yokogawa.toshibaks.dc.protocol.DataMessageSessionHandler:98] INFO [][][] - [/172.16.10.199:13301] CREATED: Accept connection on DataPort: 9870 main| 2006/10/02 09:12:23 | 2006-10-02 09:12:23:235 [ProtocolThreadPool-5] [com.yokogawa.toshibaks.dc.protocol.DataMessageSessionHandler:98] INFO [][][] - [/172.16.10.199:13301] OPENED main| 2006/10/02 09:12:23 | 2006-10-02 09:12:23:236 [ProtocolThreadPool-21] [com.yokogawa.toshibaks.dc.protocol.DataMessageSessionHandler:98] INFO [][][] - [/172.16.10.199:13301] CLOSED: Connection on DataPort [9870] has been closed. main| 2006/10/02 09:12:24 | 2006-10-02 09:12:24:237 [SocketAcceptor-1] [com.yokogawa.toshibaks.dc.protocol.DataMessageSessionHandler:98] INFO [][][] - [/172.16.10.142:46806] CREATED: Accept connection on DataPort: 9874 main| 2006/10/02 09:12:24 | 2006-10-02 09:12:24:237 [ProtocolThreadPool-5] [com.yokogawa.toshibaks.dc.protocol.DataMessageSessionHandler:98] INFO [][][] - [/172.16.10.142:46806] OPENED main| 2006/10/02 09:18:04 | TERM trapped. Shutting down. main| 2006/10/02 09:18:04 | Stoping the DC... main| 2006/10/02 09:18:04 | 2006-10-02 09:18:04:284 [Wrapper-Connection] [com.yokogawa.toshibaks:99] INFO [][][] - DC is stopping. main| 2006/10/02 09:18:04 | 2006-10-02 09:18:04:305 [Wrapper-Connection] [com.yokogawa.toshibaks:285] INFO [][][] - Stop listening on all Data ports and close all data sessions... main| 2006/10/02 09:18:05 | Exception in thread SocketAcceptor-1 java.nio.channels.CancelledKeyException main| 2006/10/02 09:18:05 | at sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:55) main| 2006/10/02 09:18:05 | at sun.nio.ch.SelectionKeyImpl.readyOps(SelectionKeyImpl.java:69) main| 2006/10/02 09:18:05 | at java.nio.channels.SelectionKey.isAcceptable(SelectionKey.java:342) main| 2006/10/02 09:18:05 | at org.apache.mina.io.socket.SocketAcceptor$Worker.processSessions(SocketAcceptor.java:297) main| 2006/10/02 09:18:05 | at org.apache.mina.io.socket.SocketAcceptor$Worker.run(SocketAcceptor.java:244) main| 2006/10/02 09:22:24 | 2006-10-02 09:22:24:858 [ProtocolThreadPool-21] [com.yokogawa.toshibaks.dc.protocol.DataMessageSessionHandler:98] INFO [][][] - [/172.16.10.142:46806] IDLE: both idle main| 2006/10/02 09:22:24 | 2006-10-02 09:22:24:904 [ProtocolThreadPool-21] [com.yokogawa.toshibaks.dc.protocol.DataMessageSessionHandler:313] INFO [][][] - Idle timeout occurred. K/S is disconnecting... main| 2006/10/02 09:32:25 | 2006-10-02 09:32:25:428 [ProtocolThreadPool-4] [com.yokogawa.toshibaks.dc.protocol.DataMessageSessionHandler:98] INFO [][][] - [/172.16.10.142:46806] IDLE: both idle main| 2006/10/02 09:32:25 | 2006-10-02 09:32:25:429 [ProtocolThreadPool-4] [com.yokogawa.toshibaks.dc.protocol.DataMessageSessionHandler:313] INFO [][][] - Idle timeout occurred. K/S is disconnecting... main| 2006/10/02 09:42:26 | 2006-10-02 09:42:26:029 [ProtocolThreadPool-15] [com.yokogawa.toshibaks.dc.protocol.DataMessageSessionHandler:98] INFO [][][] - [/172.16.10.142:46806] IDLE: both idle main| 2006/10/02 09:42:26 | 2006-10-02 09:42:26:029 [ProtocolThreadPool-15] [com.yokogawa.toshibaks.dc.protocol.DataMessageSessionHandler:313] INFO [][][] - Idle timeout occurred. K/S is disconnecting...
[jira] Closed: (DIRMINA-245) MINA does not fire read events
[ https://issues.apache.org/jira/browse/DIRMINA-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-245. - MINA does not fire read events -- Key: DIRMINA-245 URL: https://issues.apache.org/jira/browse/DIRMINA-245 Project: MINA Issue Type: Bug Affects Versions: 0.9.4, 0.9.5 Environment: Java 5, Java 6. Not reproducible on Windows Reporter: Vinod Panicker Assignee: Trustin Lee Priority: Blocker Fix For: 1.0.0 We've been stumped with a serious issue with MINA where it stops firing read events after a particular scenario occurs. The scenario is such - 1. A MINA server is listening for connections 2. Clients connect to it and send requests - server responds 3. Number of clients concurrently connected doing the same activity is around 60-100 4. Clients are terminated abruptly 5. Server processes disconnects and is idle 6. New client connects and sends requests 7. Server accepts connection, but a read event is not fired. This happens with each subsequent client connection. On debugging, we found that the JVM is notifying MINA about the read event, but after the event is put into the queue for processing, MINA does not process it and a read event is not fired. sessionCreated, however is fired. On using the Executor based thread pool implementation, this problem does not occur. This problem is not reproducible on Windows based systems. Reproduced on Linux systems with java 5 and 6. Unfortunately, we can't provide a test case at the moment since we were able to reproduce this only with our application server and custom client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-273) Session created with non-existent service
[ https://issues.apache.org/jira/browse/DIRMINA-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-273. - Session created with non-existent service - Key: DIRMINA-273 URL: https://issues.apache.org/jira/browse/DIRMINA-273 Project: MINA Issue Type: Bug Components: Core Affects Versions: 0.9.4, 0.9.5, 1.0.0 Environment: Windows 2000 SP4, Java 1.5.0_08 Reporter: Raman Gupta Assignee: Trustin Lee Fix For: 1.0.1 Attachments: MinaConnectTest.java, MinaConnectTest10.java, MinaConnectTestNew.java On Windows 2000, when attempting to connect to a service on a port where no service is running (either locally or remotely), Mina will sometimes create and open a session instead of throwing an IoException. This session is of course unusable, and when attempting to use it an exception is thrown (the following exception from Mina 0.9.4): java.nio.channels.NotYetConnectedException at sun.nio.ch.SocketChannelImpl.ensureWriteOpen(SocketChannelImpl.java:129) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:294) at org.apache.mina.transport.socket.nio.SocketIoProcessor.doFlush(SocketIoProcessor.java:480) at org.apache.mina.transport.socket.nio.SocketIoProcessor.doFlush(SocketIoProcessor.java:412) at org.apache.mina.transport.socket.nio.SocketIoProcessor.access$500(SocketIoProcessor.java:41) at org.apache.mina.transport.socket.nio.SocketIoProcessor$Worker.run(SocketIoProcessor.java:568) This is reproducible within a few seconds with the attached test case on Windows 2000 on Mina 0.9.4 and Mina 1.0.0. I also attempted to reproduce this on Linux 2.6.17 but was unable to. I have attached two test cases, one MinaConnectTest and one MinaConnectTest10, the former is for 0.9.4 and the latter is for 1.0.0 -- the only change is the exception caught. Though the attached test case fails uses only localhost (to avoid DNS complications), the test case also fails if a remote host is used. I tested with a remote host running Solaris 8 from a Windows client. Lastly, netcat in a tight loop was used concurrently with the test to verify that the port was indeed refusing connections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-288) Add SessionLog.info( session, CREATED ); to LoggingFilter.sessionCreated method
[
https://issues.apache.org/jira/browse/DIRMINA-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny closed DIRMINA-288.
-
Add SessionLog.info( session, CREATED ); to LoggingFilter.sessionCreated
method
-
Key: DIRMINA-288
URL: https://issues.apache.org/jira/browse/DIRMINA-288
Project: MINA
Issue Type: Bug
Components: Core
Affects Versions: 1.0.0
Reporter: Michael Newcomb
Assignee: Julien Vermillard
Priority: Trivial
Fix For: 1.0.1
Please add the following to the LoggingFilter.sessionCreated method:
public void sessionCreated( NextFilter nextFilter, IoSession session )
{
SessionLog.info( session, CREATED );
nextFilter.sessionCreated( session );
}
Thanks,
Michael
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-266) SocketAcceptor.bind() requires address != null and port != 0... why? Also can get to ServerSocketChannel.socket().getLocalSocketAddress()
[
https://issues.apache.org/jira/browse/DIRMINA-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny closed DIRMINA-266.
-
SocketAcceptor.bind() requires address != null and port != 0... why? Also can
get to ServerSocketChannel.socket().getLocalSocketAddress()
-
Key: DIRMINA-266
URL: https://issues.apache.org/jira/browse/DIRMINA-266
Project: MINA
Issue Type: Bug
Affects Versions: 0.9.5
Reporter: Michael Newcomb
Assignee: Trustin Lee
Fix For: 1.0.1
public void bind( SocketAddress address, IoHandler handler, IoServiceConfig
config ) throws IOException
{
// if( address == null )
// {
// throw new NullPointerException( address );
// }
if( handler == null )
{
throw new NullPointerException( handler );
}
if( address != null !( address instanceof InetSocketAddress ) )
{
throw new IllegalArgumentException( Unexpected address type: +
address.getClass() );
}
// if( ( ( InetSocketAddress ) address ).getPort() == 0 )
// {
// throw new IllegalArgumentException( Unsupported port number: 0 );
// }
...
Also, you need to fix the physical binding and registration in the channels
map:
// and bind.
ssc.socket().bind( req.address, cfg.getBacklog() );
// assign what was actually bound
//
req.address = ssc.socket().getLocalSocketAddress();
ssc.register( selector, SelectionKey.OP_ACCEPT, req );
I am by no means a networking genius, but is there a reason why this type of
use is not allowed?
Also, if assigning the SocketAddress at bind is used, there needs to be a way
for you to get the local socket address from the IoSession api.
Thanks,
Michael
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-349) ByteBuffer.getString() has bug,code piece: if( ( get() == 0 ) ( get() == 0 ) ), in ByteBuffer.java line 982 and line 1105,mina1.0.0
[ https://issues.apache.org/jira/browse/DIRMINA-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-349. - ByteBuffer.getString() has bug,code piece: if( ( get() == 0 ) ( get() == 0 ) ), in ByteBuffer.java line 982 and line 1105,mina1.0.0 --- Key: DIRMINA-349 URL: https://issues.apache.org/jira/browse/DIRMINA-349 Project: MINA Issue Type: Bug Components: Core Affects Versions: 1.0.1 Environment: win2000,jse5.5 Reporter: chentao Assignee: Trustin Lee Fix For: 1.0.2 ByteBuffer.getString(CharsetDecoder decoder) if decodeer is UTF-16 etc,code: if( ( get() == 0 ) ( get() == 0 ) ),the second get() perhaps not execute -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-347) Server: StreamIoHandler does not close InputStream and OutputStream on sessionClosed()
[
https://issues.apache.org/jira/browse/DIRMINA-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny closed DIRMINA-347.
-
Server: StreamIoHandler does not close InputStream and OutputStream on
sessionClosed()
--
Key: DIRMINA-347
URL: https://issues.apache.org/jira/browse/DIRMINA-347
Project: MINA
Issue Type: Bug
Components: Core
Affects Versions: 1.0.1
Environment: Ubuntu 6.06
Reporter: Eric Fitchett
Assignee: Trustin Lee
Priority: Minor
Fix For: 1.0.2
Attachments: StreamIoHandler_CloseStreams.diff
When reading from the InputStream provided by StreamIoHandler, the read can
block indefinitely if the client closes the connection.
This is caused by the StreamIoHandler not closing the provided streams in the
sessionClosed() method. The InputStream remains open, waiting for more data.
After many connections, there may be a large number of zombie threads that
will never wake up.
I will upload a patch to fix this problem. In the mean time, a workaround I
am currently using follows. It keeps track of the InputStream for each
session, and closes it when the session closes. This ensures the thread has
a chance to terminate properly.
protected final void processStreamIo(
IoSession session,
InputStream in,
OutputStream out) {
sessionStreams.put(session, in);
// Process the streams in a separate thread
new Worker(in, out).start();
}
// Ensures session's InputStream gets closed, so the thread doesn't lock
up
private MapIoSession,InputStream sessionStreams = new
HashMapIoSession, InputStream();
@Override
public void sessionClosed(IoSession session) throws Exception {
super.sessionClosed(session);
InputStream is = sessionStreams.get(session);
if(null != is) {
try {
is.close();
} catch(IOException ioe) {
// Ignore
}
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-346) huge memory impact on receiving big packets (about 1MByte) due to CumulativeProtocolDecoder.storeRemainingInSession behaviour
[
https://issues.apache.org/jira/browse/DIRMINA-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny closed DIRMINA-346.
-
huge memory impact on receiving big packets (about 1MByte) due to
CumulativeProtocolDecoder.storeRemainingInSession behaviour
-
Key: DIRMINA-346
URL: https://issues.apache.org/jira/browse/DIRMINA-346
Project: MINA
Issue Type: Improvement
Components: Filter
Affects Versions: 1.0.1
Environment: Windows XP Sp2
Java 1.5.0_10
Client / Server VM
Reporter: andrea sillari
Assignee: Trustin Lee
Fix For: 1.0.2
When receiving big TCP packets (about 1Mbyte or more) the current behavior of
CumulativeProtocolDecoder.storeRemainingInSession implies that the session
buffer is duplicated (and data copied) even if there is room for receiving
another chunk of data from the socket (i.e. buf.limit() buf.capacity()). In
this situation there are spikes of memory consumption due to the fact that
1Mbyte / 8k (== session.getReadBufferSize()) = 128 buffers of increasing
size are required for reading the entire packet.
The attached patch prevents this, by explicitly checking if there is at least
session.getReadBufferSize() space in the buffer, before requesting the
allocation of a new buffer.
The method session.getReadBufferSize() has been added to the IOSession
Interface.
private void storeRemainingInSession(ByteBuffer buf, IoSession session)
{
if (buf.limit() + session.getReadBufferSize() buf.capacity()) //
reuse the buffer
{
buf.position(buf.limit());
buf.limit(buf.capacity());
ByteBuffer sessBuff = (ByteBuffer) session.getAttribute(BUFFER);
if (sessBuff != buf) // this should happens only the first time
when sessBuff is null
{
session.setAttribute( BUFFER, buf );
buf.acquire();
}
}
else // old behavior
{
ByteBuffer remainingBuf = ByteBuffer.allocate( buf.remaining()
);
remainingBuf.setAutoExpand( true );
remainingBuf.put( buf );
session.setAttribute( BUFFER, remainingBuf );
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-332) Improve performance of StatCollector
[ https://issues.apache.org/jira/browse/DIRMINA-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-332. - Improve performance of StatCollector Key: DIRMINA-332 URL: https://issues.apache.org/jira/browse/DIRMINA-332 Project: MINA Issue Type: Improvement Components: Core Affects Versions: 1.0.1 Reporter: Gaston Dombiak Assignee: Trustin Lee Fix For: 1.0.2 Attachments: changes.patch StatCollector#addSession and StatCollector#removeSession are blocking the entire object. Therefore under heavy load of new sessions or remove of sessions we will have a bottleneck. Instead we can take advantage of new Java 5 concurrent util classes. Throughput is incorrectly being estimated. It is missing packets/bytes and when dealing with a very big number of sessions the rate will be off. Instead of keeping stats of throughput we can just stats of total traffic.So stats will change from -- to MsgWrittenThroughput -- totalMsgWritten MsgReadThroughput -- totalMsgRead BytesWrittenThroughput -- totalBytesWritten BytesReadThroughput -- totalBytesRead The rate can then be estimated by the client of this class. We can add 2 new stats that are very helpful (at least to me): 1) scheduled writes: Number of current scheduled writes for all existing sessions. 2) queueved events: Number of current queued events for all existing sessions. Stat #1 can always be estimated. However stat #2 can only be estimated when the ExecutorFilter is present in the filter chain. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-331) StatCollector is not thread safe and some stats are being mixed up
[ https://issues.apache.org/jira/browse/DIRMINA-331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-331. - StatCollector is not thread safe and some stats are being mixed up -- Key: DIRMINA-331 URL: https://issues.apache.org/jira/browse/DIRMINA-331 Project: MINA Issue Type: Bug Components: Core Affects Versions: 1.0.1 Reporter: Gaston Dombiak Assignee: Trustin Lee Fix For: 1.0.2 The instance variable polledSessions is not thread-safe (i.e. uses ArrayList) and its access is not always protected (e.g. StatCollector$Worker#run()). Under heavy load this is producing an error in the Worker. The bytesReadThroughput statistic is incorrectly being set. It is adding up the throughput of written messages. Instance variables: msgWrittenThroughput, msgReadThroughput, bytesWrittenThroughputand bytesReadThroughput could be corrupted and return an unexpected value since they are not thread safe and 2 different threads may be changing them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-328) org.apache.mina.filter.codec.CumulativeProtocolDecoder uses an inefficient accumulation strategy
[
https://issues.apache.org/jira/browse/DIRMINA-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny closed DIRMINA-328.
-
org.apache.mina.filter.codec.CumulativeProtocolDecoder uses an inefficient
accumulation strategy
Key: DIRMINA-328
URL: https://issues.apache.org/jira/browse/DIRMINA-328
Project: MINA
Issue Type: Improvement
Components: Filter
Affects Versions: 1.0.2, 1.1.0, 2.0.0-M1
Environment: I have only studied the implementation thus far, and
environment isn't a factor in this analysis.
Reporter: Steven E. Harris
Assignee: Trustin Lee
Priority: Minor
Fix For: 1.0.2
Attachments: CumulativeProtocolDecoder.java.patch
I've just started writing a MINA protocol decoder extending the class
org.apache.mina.filter.codec.CumulativeProtocolDecoder, and I noticed
some potential pathological behavior with its current implementation
of its storeRemainingInSession() method:
,
| private void storeRemainingInSession(ByteBuffer buf, IoSession session)
| {
| ByteBuffer remainingBuf = ByteBuffer.allocate( buf.remaining() );
| remainingBuf.setAutoExpand( true );
| remainingBuf.put( buf );
| session.setAttribute( BUFFER, remainingBuf );
| }
`
The ByteBuffer passed as the first argument is either the buffer
supplied to the decode() method, or it's buffer stored in the
IoSession by a previous call to decode(), allocated and owned by
CumulativeProtocolDecoder.
The current implementation unconditionally allocates a fresh buffer
and copies any unconsumed data from the current buffer in use to the
new buffer, then stores this new buffer for use on a subsequent call
to decode().
Consider two abberrant cases: when the doDecode() method consumes only
one byte and returns false, and when it consumes all but one byte and
returns false. Assume the buffer to be decoded had N bytes
remaining.
In the first case, a new buffer gets allocated of size N - 1, with N -
1 bytes copied, and the current buffer is abandoned. That's a lot of
spurious allocation with a potential reduction in buffer capacity for
the next pass.
In the second case, a new buffer gets allocated of size 1, with 1 byte
copied, and the current buffer is abandoned. We now have a capacity of
only 1 in the new buffer, having tossed away the larger capacity of
the previous buffer. This new buffer will certainly have to grow to
accommodate any new content, causing even more reallocation.
I suggest we take advantage of the ByteBuffer.compact() method to
attempt to preserve capacity and avoid reallocation when possible. Of
course, the same amount of bytes must be copied with either approach.
My proposed implementations assume that we're not allowed to hang on
to the buffer supplied to our ProtocolDecoder.decode() call. First,
here's one that checks the session attribute again to see if we're
using a buffer we've previously allocated ourselves:
,
| private void storeRemainingInSession(ByteBuffer buf, IoSession session)
| {
| ByteBuffer sessionBuf = ( ByteBuffer ) session.getAttribute( BUFFER );
| if ( sessionBuf != null )
| {
| // We're reusing our own buffer.
| assert( buf == sessionBuf );
| buf.compact();
| }
| else
| {
| // We're using a supplied buffer, so we need to copy it.
| final ByteBuffer remainingBuf = ByteBuffer.allocate( buf.capacity()
);
| remainingBuf.setAutoExpand( true );
| remainingBuf.put( buf );
| session.setAttribute( BUFFER, remainingBuf );
| }
| }
`
Alternately, we could keep a boolean flag around from the beginning of
the decode() method the first time we check the session attribute, and
only call storeRemainingInSession() if we need to copy a buffer we
didn't allocate:
,
| public void decode( IoSession session, ByteBuffer in,
| ProtocolDecoderOutput out ) throws Exception
| {
| boolean usingSessionBuffer = true;
| ByteBuffer buf = ( ByteBuffer ) session.getAttribute( BUFFER );
| // if we have a session buffer, append data to that otherwise
| // use the buffer read from the network directly
| if( buf != null )
| {
| buf.put( in );
| buf.flip();
| }
| else
| {
| usingSessionBuffer = false;
| buf = in;
| }
`
...
,
| if ( buf.hasRemaining() )
| {
| if ( usingSessionBuffer )
| buf.compact();
| else
| storeRemainingInSession( buf, session );
| }
| else
| {
| if ( usingSessionBuffer )
| session.removeAttribute( BUFFER );
| }
[jira] Closed: (DIRMINA-296) ByteBuffer.limit() incorrect when CharacterCodingException() occurred
[ https://issues.apache.org/jira/browse/DIRMINA-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-296. - ByteBuffer.limit() incorrect when CharacterCodingException() occurred - Key: DIRMINA-296 URL: https://issues.apache.org/jira/browse/DIRMINA-296 Project: MINA Issue Type: Bug Components: Core Affects Versions: 1.0.0 Environment: Window/Unix Reporter: Phan Thanh Hieu Assignee: Trustin Lee Fix For: 1.0.2 Attachments: ByteBuffer.java, bytebuffer.jpg, TestByteBuffer.java ByteBuffer.limit() is INCORRECT when CharacterCodingException occurred. Information: my app just support ASCII-character messages. So when receiving non-ASCII message = CharacterCodingException occurrec and my expected action: save the raw-data into a Error file but the limit of the ByteBuffer is changed so i could not save whole raw data to this kind of file. I have reviewed the getString() method of MINA ByteBuffer. I could found the problem, please see the attachment. Thanks, Hieu Phan. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-306) Invalid sequence of events with VmPipe Transport
[ https://issues.apache.org/jira/browse/DIRMINA-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-306. - Invalid sequence of events with VmPipe Transport Key: DIRMINA-306 URL: https://issues.apache.org/jira/browse/DIRMINA-306 Project: MINA Issue Type: Bug Components: Transport Affects Versions: 1.0.0, 1.0.1 Reporter: Simon Raess Assignee: Trustin Lee Fix For: 1.0.2 Sometimes when using VmPipe transport, event sequences get out of order. Namely, the messageReceived method is invoked before the sessionOpened. To following sequence of events highlights the problem: - using VmPipeConnector and VmPipeAcceptor - client connects to server - server's IoHandler#sessionOpened method is called - server sends a message from the sessionOpened method - client receives that message (IoHandler#messageReceived) - client's IoHandler#sessionOpened method is invoked IoHandler#sessionOpened should always be invoked before the first invocation of IoHandler#messageReceived. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-299) innacurate JMX statistics
[ https://issues.apache.org/jira/browse/DIRMINA-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-299. - innacurate JMX statistics - Key: DIRMINA-299 URL: https://issues.apache.org/jira/browse/DIRMINA-299 Project: MINA Issue Type: Bug Components: Core Affects Versions: 1.1.0 Environment: Fedora Core 5, Eclipse 3.2 using Java 1.4 compiler settings. Reporter: Mark Webb Assignee: Julien Vermillard Priority: Minor Fix For: 1.0.2 Attachments: HttpProtocolHandler.java, jmx.diff, JmxTestMain.java The class org.apache.mina.integration.jmx.IoServiceManager computes the bytes read/written using the service's managed sessions using the method IoService.getManagedSessions(). This method returns a java.util.Set object, which only contains the sessions currently active. The IoServiceManager class uses org.apache.mina.management.StatCollector class to assist with tracking data throughput. The StatCollector class only operates on active sessions. The problem is that the values returned from the managed bean interface is computed only on the currently active sessions. Based on the names of the methods, the values returned should be running totals, to include sessions that are no longer active. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-358) default implementation of exceptionCaught in IOHandlerAdapter eats exceptions
[ https://issues.apache.org/jira/browse/DIRMINA-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-358. - default implementation of exceptionCaught in IOHandlerAdapter eats exceptions - Key: DIRMINA-358 URL: https://issues.apache.org/jira/browse/DIRMINA-358 Project: MINA Issue Type: Bug Reporter: keith mcneill Assignee: Trustin Lee Fix For: 1.0.3 IOHandlerAdapter.exceptionCaught eats the exception. It doesn't do anything with it. By default this class (and anything else like it) should log the exception. Exceptions should never be eaten. It makes it very hard to track problems with progams and ensure their correctness if exceptions are being eaten and not reported. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-261) ioSession.close().join() when SO_LINGERING set
[
https://issues.apache.org/jira/browse/DIRMINA-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny closed DIRMINA-261.
-
ioSession.close().join() when SO_LINGERING set
--
Key: DIRMINA-261
URL: https://issues.apache.org/jira/browse/DIRMINA-261
Project: MINA
Issue Type: Bug
Affects Versions: 0.9.4, 0.9.5, 1.0.0
Environment: FC5 + Sun JDK 1.5.0_07 (also with _08 and JDK 6 b2)
CentOS 3.7 + Sun JDK 1.5.0_07
SUSE 9.1 + Sun JDK 1.5.0_07
Windows XP SP2 + Sun JDK 1.5.0_08
Reporter: Frederic Soulier
Assignee: Trustin Lee
Fix For: 1.0.2
ioSession.close().join() with SO_LINGERING set behaves completely differently
on Windows and Linux.
On a linux machine (acting as the server) when a disconnection occurs (say
you pull the plug on the client machine) and depending on the value set for
the SO_LINGERING the whole server will block for as long as the value
specified in the SO_LINGERING.
As far as I can tell it gets stuck in the lock.wait() of the IoFuture because
it's not ready.
/**
* Wait for the asynchronous operation to end.
*/
public void join()
{
synchronized( lock )
{
while( !ready )
{
try
{
lock.wait();
}
catch( InterruptedException e )
{
}
}
}
}
Running the same server code on a Windows machine, it doesn't block.
Here is a full thread dump:
Full thread dump Java HotSpot(TM) Server VM (1.5.0_07-b03 mixed mode):
PooledByteBufferExpirer-0 daemon prio=1 tid=0x08dfa180 nid=0xa90
waiting on condition [0x8b479000..0x8b479fc0]
at java.lang.Thread.sleep(Native Method)
at org.apache.mina.common.PooledByteBufferAllocator
$Expirer.run(PooledByteBufferAllocator.java:289)
AnonymousIoService-2-2 daemon prio=1 tid=0x08b5a780 nid=0xa8f in
Object.wait() [0x8b4fa000..0x8b4fb040]
at java.lang.Object.wait(Native Method)
- waiting on 0xae623b98 (a org.apache.mina.util.BlockingQueue)
at java.lang.Object.wait(Object.java:474)
at
org.apache.mina.util.BlockingQueue.waitForNewItem(BlockingQueue.java:55)
- locked 0xae623b98 (a org.apache.mina.util.BlockingQueue)
at org.apache.mina.filter.ThreadPoolFilter
$Worker.fetchBuffer(ThreadPoolFilter.java:447)
- locked 0xae623b98 (a org.apache.mina.util.BlockingQueue)
at org.apache.mina.filter.ThreadPoolFilter
$Worker.run(ThreadPoolFilter.java:422)
SocketAcceptorIoProcessor-0.0 prio=1 tid=0x08b5b808 nid=0xa8c runnable
[0x8b57b000..0x8b57c0c0]
at sun.nio.ch.FileDispatcher.preClose0(Native Method)
at sun.nio.ch.SocketDispatcher.preClose(SocketDispatcher.java:41)
at
sun.nio.ch.SocketChannelImpl.implCloseSelectableChannel(SocketChannelImpl.java:626)
- locked 0xae6b1418 (a java.lang.Object)
at
java.nio.channels.spi.AbstractSelectableChannel.implCloseChannel(AbstractSelectableChannel.java:201)
at
java.nio.channels.spi.AbstractInterruptibleChannel.close(AbstractInterruptibleChannel.java:97)
- locked 0xae6b13f0 (a java.lang.Object)
at
org.apache.mina.transport.socket.nio.SocketIoProcessor.doRemove(SocketIoProcessor.java:217)
at org.apache.mina.transport.socket.nio.SocketIoProcessor.access
$600(SocketIoProcessor.java:41)
at org.apache.mina.transport.socket.nio.SocketIoProcessor
$Worker.run(SocketIoProcessor.java:569)
AnonymousIoService-2-1 daemon prio=1 tid=0x08b5b330 nid=0xa8b in
Object.wait() [0x8b5fc000..0x8b5fd140]
at java.lang.Object.wait(Native Method)
- waiting on 0xae6f2a48 (a java.lang.Object)
at org.apache.mina.filter.ThreadPoolFilter
$Worker.waitForPromotion(ThreadPoolFilter.java:546)
- locked 0xae6f2a48 (a java.lang.Object)
at org.apache.mina.filter.ThreadPoolFilter
$Worker.run(ThreadPoolFilter.java:419)
DestroyJavaVM prio=1 tid=0x086293d0 nid=0xa64 waiting on condition
[0x..0xbf831bb0]
SocketAcceptor-1 prio=1 tid=0x089bb9f0 nid=0xa85 runnable
[0x8b67d000..0x8b67e1c0]
at sun.nio.ch.PollArrayWrapper.poll0(Native Method)
at sun.nio.ch.PollArrayWrapper.poll(PollArrayWrapper.java:100)
at sun.nio.ch.PollSelectorImpl.doSelect(PollSelectorImpl.java:56)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
- locked 0xae676e58 (a sun.nio.ch.Util$1)
- locked 0xae676e48 (a java.util.Collections$UnmodifiableSet)
- locked 0xae676c50 (a sun.nio.ch.PollSelectorImpl)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:84)
at org.apache.mina.transport.socket.nio.SocketAcceptor
[jira] Closed: (DIRMINA-356) StatCollector deadlocks in 1.0.2
[
https://issues.apache.org/jira/browse/DIRMINA-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny closed DIRMINA-356.
-
StatCollector deadlocks in 1.0.2
Key: DIRMINA-356
URL: https://issues.apache.org/jira/browse/DIRMINA-356
Project: MINA
Issue Type: Bug
Components: Core
Affects Versions: 1.0.2
Environment: Ubuntu 6.06, Sun Java 1.5.0_05
Reporter: Eric Fitchett
Assignee: Trustin Lee
Priority: Minor
Fix For: 1.0.3
Attachments: TestMinaStatCollectorHang.java
Mina's StatCollector hangs when calling the stop() method, if at least one
client has connected. I have tested this on 1.0.1, and it works fine there -
this is new behavior as of the 1.0.2 release.
I ran an svn diff on StatCollector.java between 1.0.1 and 1.0.2 tags. I
believe the problem is (at least in part) here:
@@ -332,12 +329,14 @@
/ ( pollingInterval / 1000f );
tmpMsgWrittenThroughput +=
sessStat.messageWrittenThroughput;
-msgWrittenThroughput = tmpMsgWrittenThroughput;
-msgReadThroughput = tmpMsgReadThroughput;
-bytesWrittenThroughput = tmpBytesWrittenThroughput;
-bytesReadThroughput = tmpMsgWrittenThroughput;
-
-sessStat.lastPollingTime = System.currentTimeMillis();
+synchronized( StatCollector.this )
+{
+msgWrittenThroughput = tmpMsgWrittenThroughput;
+msgReadThroughput = tmpMsgReadThroughput;
+bytesWrittenThroughput = tmpBytesWrittenThroughput;
+bytesReadThroughput = tmpBytesReadThroughput;
+sessStat.lastPollingTime =
System.currentTimeMillis();
+}
}
}
}
I have also created JUnit 4 tests to demonstrate the problem. Please excuse
the awful naming conventions and code - I was just trying to throw together a
working example!
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-324) ProtocolCodecFilter can not be dynamicly be replaced by another.
[
https://issues.apache.org/jira/browse/DIRMINA-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny closed DIRMINA-324.
-
ProtocolCodecFilter can not be dynamicly be replaced by another.
Key: DIRMINA-324
URL: https://issues.apache.org/jira/browse/DIRMINA-324
Project: MINA
Issue Type: Bug
Components: Filter
Affects Versions: 1.0.0, 1.0.1
Reporter: Wolter Eldering
Assignee: Trustin Lee
Priority: Minor
Fix For: 1.0.2
ProtocolCodecFilter can not be dynamicly added and removed because the
encoder en decoder attributes are not removed from the IoSession when the
ProtocolCodecFilter is removed.
Index:
core/src/main/java/org/apache/mina/filter/codec/ProtocolCodecFilter.java
===
--- core/src/main/java/org/apache/mina/filter/codec/ProtocolCodecFilter.java
(revision 487691)
+++ core/src/main/java/org/apache/mina/filter/codec/ProtocolCodecFilter.java
(working copy)
@@ -141,6 +141,12 @@
}
}
+public void onPostRemove(IoFilterChain parent, String name, NextFilter
nextFilter) throws Exception {
+ disposeEncoder(parent.getSession());
+ disposeDecoder(parent.getSession());
+}
+
+
public void messageReceived( NextFilter nextFilter, IoSession session,
Object message ) throws Exception
{
if( !( message instanceof ByteBuffer ) )
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-395) DatagramSessionImpl getLocalAddress doesn't return the local address
[
https://issues.apache.org/jira/browse/DIRMINA-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny closed DIRMINA-395.
-
DatagramSessionImpl getLocalAddress doesn't return the local address
Key: DIRMINA-395
URL: https://issues.apache.org/jira/browse/DIRMINA-395
Project: MINA
Issue Type: Bug
Components: Transport
Affects Versions: 1.1.0
Environment: All OSes
Reporter: Adam Fisk
Assignee: Trustin Lee
Fix For: 1.0.4, 1.1.1
Attachments: datagramLocalHostConnectorPath.patch
I don't fully understand the comment in the constructor below, but I believe
it's only relevant for acceptors, not connectors. In the case of connectors,
the serviceAddress argument below is just the remote host address, which
should clearly not be set to the local address as it is.
DatagramSessionImpl( IoService wrapperManager,
DatagramService managerDelegate,
IoServiceConfig serviceConfig,
DatagramChannel ch, IoHandler defaultHandler,
SocketAddress serviceAddress )
{
.
// We didn't set the localhost by calling getLocalSocketAddress() to
avoid
// the case that getLocalSocketAddress() returns IPv6 address while
// serviceAddress represents the same address in IPv4.
this.localAddress = this.serviceAddress = serviceAddress;
This is called from DatagramConnectorDelegate in the registerNew method,
which reads:
DatagramSessionImpl session = new DatagramSessionImpl(
wrapper, this,
req.config,
req.channel, req.handler,
req.channel.socket().getRemoteSocketAddress() );
The last argument req.channel.socket().getRemoteSocketAddress() should
clearly not be assigned to the local address.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-390) IoHandler.messageSent is not called when FilterChain contains SSLFilter
[ https://issues.apache.org/jira/browse/DIRMINA-390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-390. - IoHandler.messageSent is not called when FilterChain contains SSLFilter --- Key: DIRMINA-390 URL: https://issues.apache.org/jira/browse/DIRMINA-390 Project: MINA Issue Type: Bug Components: Filter Affects Versions: 1.0.3, 1.1.0 Reporter: Maarten Bosteels Assignee: Trustin Lee Fix For: 1.0.4, 1.1.1 Attachments: SSLFilter.java.diff, SSLFilterTest.java, SSLFilterTest.java SSLFilter swallows too many messageSent events When the FilterChain contains both SSLFilter and ProtocolCodecFilter, the IoHandler does not receive messageSent events. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-383) CumulativeProtocolDecoder ByteOrder.LITTLE_ENDIAN
[ https://issues.apache.org/jira/browse/DIRMINA-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-383. - CumulativeProtocolDecoder ByteOrder.LITTLE_ENDIAN --- Key: DIRMINA-383 URL: https://issues.apache.org/jira/browse/DIRMINA-383 Project: MINA Issue Type: Bug Components: Core Affects Versions: 1.0.2 Environment: Win-XP Reporter: Michael Link Assignee: Trustin Lee Fix For: 1.0.4, 1.1.1 When the decoder returns false, the CumulativeProtocolDecoder saves the remaining buffer in a copy in a session attribute. That copy doesn't inherit the ByteOrder-Setting of the original buffer, therefore I have to switch the ByteOrder manually. Is this correct behaviour ? I would expect that the copied buffer inherits the ByteOrder-Setting. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-410) DefaultIoFilterChainBuilder synchronization issue with contains(...) methods
[
https://issues.apache.org/jira/browse/DIRMINA-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny closed DIRMINA-410.
-
DefaultIoFilterChainBuilder synchronization issue with contains(...) methods
Key: DIRMINA-410
URL: https://issues.apache.org/jira/browse/DIRMINA-410
Project: MINA
Issue Type: Bug
Affects Versions: 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.1.0, 1.0.4, 1.1.1
Reporter: im-james
Assignee: Trustin Lee
Fix For: 1.0.5, 1.1.2
In org.apache.mina.common.DefaultIoFilterChainBuilder, most public methods
are synchronized to guard the variables entries and entriesByName.
However, 2 methods are not synchronized and I believe that they should be
synchronized.
I'm talking about these 2:
public boolean contains(IoFilter filter) {...}
public boolean contains(Class? extends IoFilter filterType) {...}
it should be:
public synchronized boolean contains(IoFilter filter) {...}
public synchronized boolean contains(Class? extends IoFilter filterType)
{...}
The version on the trunk is different but I've got the impression that there
is another type of bug:
I've noticed that the variable entries is initialized with a new
CopyOnWriteArrayListEntry(). However, the clear() method put a regular
new ArrayListEntry() into it. This is probably not what is intended.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-412) WriteFuture.join() hangs when exception thrown in filterWrite
[ https://issues.apache.org/jira/browse/DIRMINA-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-412. - WriteFuture.join() hangs when exception thrown in filterWrite - Key: DIRMINA-412 URL: https://issues.apache.org/jira/browse/DIRMINA-412 Project: MINA Issue Type: Bug Components: Core Affects Versions: 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.1.0, 1.0.4, 1.1.1 Environment: Windows XP Reporter: Marc Friedman Assignee: Trustin Lee Fix For: 1.0.5, 1.1.2 Attachments: WhenWriteFails.java If an exception is thrown in the filterWrite() method of a filter then the processing of the write on the session is abandoned and an ExceptionCaught event is transmitted down the filter chain. However, the WriteFuture is returned normally from session.write() and the future is not notified of the write failure. As a result, a join() without timeout on the WriteFuture will cause the calling thread to hang. The attached code illustrates this behavior. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-409) Duplicate syncronization in SocketAcceptor.startupWorker()
[
https://issues.apache.org/jira/browse/DIRMINA-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny closed DIRMINA-409.
-
Duplicate syncronization in SocketAcceptor.startupWorker()
--
Key: DIRMINA-409
URL: https://issues.apache.org/jira/browse/DIRMINA-409
Project: MINA
Issue Type: Bug
Components: Transport
Affects Versions: 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.1.0, 1.0.4, 1.1.1
Reporter: im-james
Assignee: Trustin Lee
Priority: Trivial
Fix For: 1.0.5, 1.1.2
In org.apache.mina.transport.socket.nio.SocketAcceptor, the method reads like
that:
private synchronized void startupWorker() throws IOException {
synchronized (lock) {
if (worker == null) {
selector = Selector.open();
worker = new Worker();
executor.execute(new NamePreservingRunnable(worker));
}
}
}
The 'synchronized' keyword of the method is, in my opinion, superfluous and
should be removed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-369) StreamIoHandler can flush garbled data.
[
https://issues.apache.org/jira/browse/DIRMINA-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny closed DIRMINA-369.
-
StreamIoHandler can flush garbled data.
---
Key: DIRMINA-369
URL: https://issues.apache.org/jira/browse/DIRMINA-369
Project: MINA
Issue Type: Bug
Components: Handler
Affects Versions: 1.0.1, 1.0.2, 1.0.3, 1.1.0
Reporter: Trustin Lee
Assignee: Trustin Lee
Fix For: 1.0.4, 1.1.1
The OutputStream which StreamIoHandler provided doesn't perform defensive
copy. Some wrapper OutputStreams and Writers (e.g. BufferedOutputStream and
BufferedWriter) reuse their internal byte array, and causes the byte buffer
to be modified before it's actually written out to the channel. There are
two solutions:
1) Perform defensive copy in write(byte[], int, int):
public void write( byte[] b, int off, int len ) throws IOException
{
write( ByteBuffer.wrap( (byte[]) b.clone(), off, len ) );
}
2) Wait for the WriteFuture for every operation.
The former sounds better IMO.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-416) Possible visibility problem against Selector access
[ https://issues.apache.org/jira/browse/DIRMINA-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-416. - Possible visibility problem against Selector access --- Key: DIRMINA-416 URL: https://issues.apache.org/jira/browse/DIRMINA-416 Project: MINA Issue Type: Bug Components: Transport Affects Versions: 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.1.0, 1.0.4, 1.1.1 Reporter: Trustin Lee Assignee: Trustin Lee Priority: Minor Fix For: 1.0.5, 1.1.2 selector member variable of various NIO transport services is not declared as 'volatile', so it can possibly lead to a visibility problem, as discussed like the following: http://www.nabble.com/Unsafe-concurrency-issue-in-SocketIoProcessor---tf4162935s16868.html In 1.1, we could simply use volatile keyword for the member variables, but will need explicit synchronization block in 1.0 because most Java 1.4 VMs doesn't support volatile keyword. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-437) AccessControlException on 127.0.01 when using Mina in an Applet
[ https://issues.apache.org/jira/browse/DIRMINA-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-437. - AccessControlException on 127.0.01 when using Mina in an Applet --- Key: DIRMINA-437 URL: https://issues.apache.org/jira/browse/DIRMINA-437 Project: MINA Issue Type: Bug Components: Transport Affects Versions: 1.0.5, 1.1.2 Reporter: Trustin Lee Assignee: Trustin Lee Priority: Blocker Fix For: 1.0.6, 1.1.3 On 9/8/07, Fady f...@legsem.com wrote: Hello Using Mina 1.1.2 from an Applet, trying to connect to a remote server (192.168.0.6 port 1139) from which the Applet originates. I get the following exception: Caused by: java.security.AccessControlException: access denied (java.net.SocketPermission [0:0:0:0:0:0:0:1]:1025 connect,resolve) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkConnect(Unknown Source) at java.net.Socket.connect(Unknown Source) at org.apache.mina.transport.socket.nio.SocketSessionConfigImpl.initializeDefaultSocketParameters(SocketSessionConfigImpl.java:144) at org.apache.mina.transport.socket.nio.SocketSessionConfigImpl.clinit(SocketSessionConfigImpl.java:77) ... 15 more As you can see the access is denied for address 0 port 1025 which is not the IP address I am trying to connect to. Looking into the SocketSessionConfigImpl code, it seems this is a consequence of a series of attempts to connect locally in initializeDefaultSocketParameters(). In Mina 1.1.0, there was no attempts to connect locally and my applet worked fine. Has anyone else run into a similar issue? Any workarounds? Thanks for your help. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-431) Deadlock in VmPipe mode
[ https://issues.apache.org/jira/browse/DIRMINA-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-431. - Deadlock in VmPipe mode --- Key: DIRMINA-431 URL: https://issues.apache.org/jira/browse/DIRMINA-431 Project: MINA Issue Type: Bug Components: Transport Affects Versions: 1.0.5, 1.1.2 Reporter: peter royal Assignee: Trustin Lee Priority: Blocker Fix For: 1.0.6, 1.1.3 It is possible to get threads for the VmPipe implementation to deadlock when re-using connections. See VmPipeSessionCrossCommunicationTest. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-436) DemuxingProtocolCodecFactory doesn't reset the current MessageDecoder when NOT_OK is returned.
[
https://issues.apache.org/jira/browse/DIRMINA-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny closed DIRMINA-436.
-
DemuxingProtocolCodecFactory doesn't reset the current MessageDecoder when
NOT_OK is returned.
--
Key: DIRMINA-436
URL: https://issues.apache.org/jira/browse/DIRMINA-436
Project: MINA
Issue Type: Bug
Components: Filter
Affects Versions: 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.1.0, 1.0.4, 1.1.1, 1.0.5,
1.1.2
Reporter: Trustin Lee
Assignee: Trustin Lee
Fix For: 1.0.6, 1.1.3
On 9/8/07, Igor Grigoryev grigoryev.i...@gmail.com wrote:
I'm wondering why not set currentDecoder = null before throwing exceptions
here (see below)
...
if( result == MessageDecoder.OK )
{
currentDecoder = null;
return true;
}
else if( result == MessageDecoder.NEED_DATA )
{
return false;
}
else if( result == MessageDecoder.NOT_OK )
{
//^^^
//I mean here first of all
throw new ProtocolDecoderException( Message decoder
returned NOT_OK. );
}
else
{
//^^^
//And here possibly
throw new IllegalStateException( Unexpected decode result
(see your decode()): + result );
}
Without this it's not possible to recover codec state after unexpected
message being received.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-459) IoSession.getScheduledWriteMessages() returns a negative value.
[ https://issues.apache.org/jira/browse/DIRMINA-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-459. - IoSession.getScheduledWriteMessages() returns a negative value. --- Key: DIRMINA-459 URL: https://issues.apache.org/jira/browse/DIRMINA-459 Project: MINA Issue Type: Bug Components: Transport Affects Versions: 1.0.6, 1.1.3 Reporter: Trustin Lee Assignee: Trustin Lee Priority: Critical Fix For: 1.0.7, 1.1.4 Calling increaseWrittenMessages() causes scheduledWriteMessages to decrease. It seems like the number of increaseScheduledWriteMessages() calls and the number of increaseWrittenMessages() differ. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-430) IoSession.getScheduledWriteBytes() slows with size of queue
[ https://issues.apache.org/jira/browse/DIRMINA-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-430. - IoSession.getScheduledWriteBytes() slows with size of queue --- Key: DIRMINA-430 URL: https://issues.apache.org/jira/browse/DIRMINA-430 Project: MINA Issue Type: Improvement Components: Core, Transport Affects Versions: 1.0.5, 1.1.2 Reporter: peter royal Assignee: peter royal Fix For: 1.0.6, 1.1.3 Whenever you call SocketSessionImpl.getScheduledWriteBytes, it manually tallies the size of the queue. This is inefficient when the queue has a decent number of outstanding requests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-406) ProtocolDecoder.dispose() is called for every read.
[
https://issues.apache.org/jira/browse/DIRMINA-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny closed DIRMINA-406.
-
ProtocolDecoder.dispose() is called for every read.
---
Key: DIRMINA-406
URL: https://issues.apache.org/jira/browse/DIRMINA-406
Project: MINA
Issue Type: Bug
Components: Filter
Affects Versions: 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.1.0, 1.0.4, 1.1.1
Reporter: Trustin Lee
Assignee: Trustin Lee
Fix For: 1.0.5, 1.1.2
Since MINA 1.0, even connectionless sessions have a virtual connection
managed by IoSessionRecycler.
ProtocolCodecFilter contains the following code though:
} finally {
// Dispose the encoder if this session is connectionless.
if (session.getTransportType().isConnectionless()) {
disposeEncoder(session);
}
}
Which causes invocation of ProtocolDecoder.dispose() too often (i.e. for
every messageReceived event)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-429) AbstractIoFilterChain.doWrite slows as outstanding writes increase
[ https://issues.apache.org/jira/browse/DIRMINA-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-429. - AbstractIoFilterChain.doWrite slows as outstanding writes increase -- Key: DIRMINA-429 URL: https://issues.apache.org/jira/browse/DIRMINA-429 Project: MINA Issue Type: Improvement Components: Core, Transport Affects Versions: 1.0.5, 1.1.2 Reporter: peter royal Assignee: Trustin Lee Priority: Critical Fix For: 1.0.6, 1.1.3 SocketFilterChain.doWrite slows down as the number of outstanding write requests increases. This is because it calls .size() on the queue, and the queue implementation used does not have a constant-time size operation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-305) SocketIoProcessor is biased to write operations.
[ https://issues.apache.org/jira/browse/DIRMINA-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-305. - SocketIoProcessor is biased to write operations. Key: DIRMINA-305 URL: https://issues.apache.org/jira/browse/DIRMINA-305 Project: MINA Issue Type: Bug Components: Transport Affects Versions: 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.1.0, 1.0.4, 1.1.1, 1.0.5, 1.1.2 Reporter: Trustin Lee Assignee: Trustin Lee Fix For: 1.0.6, 1.1.3 High performance network devices can flush socket write buffers very fast, and SocketIoProcessor can stay for quite long time in flush loop. Related mailing list thread: http://article.gmane.org/gmane.comp.apache.directory.mina.devel/2177 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-455) Add XBean tag to sources to enable XBean based configuration
[ https://issues.apache.org/jira/browse/DIRMINA-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-455. - Add XBean tag to sources to enable XBean based configuration Key: DIRMINA-455 URL: https://issues.apache.org/jira/browse/DIRMINA-455 Project: MINA Issue Type: Improvement Components: Core, Filter Reporter: Alex Karasulu Assignee: Trustin Lee Fix For: 1.0.7, 1.1.4 The following tag when added to the javadocs enables XBean based configuration of the MINA components with absolutely no effect on the operation of MINA: * @org.apache.xbean.XBean Adding this will enable MINA users that use the Spring integration classes to optionally make their spring application configurations much more succinct. For more information please see http://geronimo.apache.org/xbean/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-452) IdentittyHashMap Iterator has bug in it.
[
https://issues.apache.org/jira/browse/DIRMINA-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny closed DIRMINA-452.
-
IdentittyHashMap Iterator has bug in it.
Key: DIRMINA-452
URL: https://issues.apache.org/jira/browse/DIRMINA-452
Project: MINA
Issue Type: Bug
Components: Core
Affects Versions: 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.1.0, 1.0.4, 1.1.1, 1.0.5,
1.1.2
Environment: Java, all 1.5 and 1.6 versions at least.
Reporter: Rupert Smith
Assignee: Trustin Lee
Fix For: 1.0.7, 1.1.4
There is a bug in IdentityHashMap Iterator which causes an infinite loop.
This can manifest itself anywhere that the iterator.remove() method is
called, in conjunction with the put() method. In particular this has been
observed in the VmPipeIdleStatus checker.
Certain sequences of puts/iterator.removes cause the map to allow put() to be
called with a full table. The code then loops round the table forever looking
for a free slot to add the new entry to.
A bug report has been submitted to Sun for this problem.
Suggested work arounds:
Use HashMap instead of IdentityHashMap.
Do not use the remove() method on the iterator, find all elements to remove
in one step, then remove in another.
Here is some sample test code that exhibits the bug in isolation. Call it
repeatedly with n=1000, until it locks up:
public void testRandomPutRemove(final int n)
{
final MapTestElement, TestElement idMap = new
IdentityHashMapTestElement, TestElement();
final Random r = new Random();
final float removeProbability = r.nextFloat();
final float addProbability = r.nextFloat();
final QueueString opSequence = new LinkedListString();
Runnable tester =
new Runnable()
{
public void run()
{
for (int i = 0; i n; i++)
{
if (r.nextFloat() addProbability)
{
synchronized (idMap)
{
TestElement e = new TestElement();
idMap.put(e, e);
opSequence.offer(put);
}
}
else
{
synchronized (idMap)
{
Iterator it = idMap.keySet().iterator();
for (int j = 0; it.hasNext(); j++)
{
it.next();
if (r.nextFloat() removeProbability)
{
it.remove();
opSequence.offer(remove + j);
}
}
}
}
}
}
};
Thread testThread = new Thread(tester);
testThread.start();
try
{
testThread.join(5000);
}
catch (InterruptedException e)
{
fail(Test interrupted.);
}
if (testThread.getState() == Thread.State.RUNNABLE)
{
System.out.println(opSequence = + opSequence);
System.out.println(removeProbability = + removeProbability);
System.out.println(addProbability = + addProbability);
// Wait forever here, to give an opportunity to take thread/heap
dumps etc.
try
{
testThread.join();
}
catch (InterruptedException e)
{
// Ignore.
}
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-512) ProtocolDecoderException.getHexDump always returns 'empty'
[
https://issues.apache.org/jira/browse/DIRMINA-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny closed DIRMINA-512.
-
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 hakan_guler...@yahoo.com 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] Closed: (DIRMINA-486) Deadlock in SocketConnectorIoProcessor AnonymousIoService
[ https://issues.apache.org/jira/browse/DIRMINA-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-486. - Deadlock in SocketConnectorIoProcessor AnonymousIoService --- Key: DIRMINA-486 URL: https://issues.apache.org/jira/browse/DIRMINA-486 Project: MINA Issue Type: Bug Components: Core Affects Versions: 1.0.8, 1.1.5 Environment: Linux, Java 6, box with 8 cores Reporter: Roger Kapsi Assignee: Trustin Lee Fix For: 1.0.9, 1.1.6 Hi, here's the stack trace of a deadlock we caught via JMX while shutting down one of our servers. Thanks -Roger Name: AnonymousIoService-7 State: BLOCKED on org.apache.mina.common.support.defaultclosefut...@7aa47c0d owned by: SocketConnectorIoProcessor-0.0 Total blocked: 219 Total waited: 22,100 Stack trace: org.apache.mina.common.support.DefaultIoFuture.isReady(DefaultIoFuture.java:105) org.apache.mina.common.support.DefaultCloseFuture.isClosed(DefaultCloseFuture.java:40) org.apache.mina.common.support.BaseIoSession.isClosing(BaseIoSession.java:125) org.apache.mina.common.support.BaseIoSession.close(BaseIoSession.java:147) - locked java.lang.obj...@1777b741 com.m.m.stream.Connection.close(Connection.java:83) com.m.m.util.IOUtils.close(IOUtils.java:56) com.m.m.stream.Connection.exceptionCaught(Connection.java:96) org.apache.mina.handler.multiton.SingleSessionIoHandlerDelegate.exceptionCaught(SingleSessionIoHandlerDelegate.java:120) org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.exceptionCaught(AbstractIoFilterChain.java:564) org.apache.mina.common.support.AbstractIoFilterChain.callNextExceptionCaught(AbstractIoFilterChain.java:345) org.apache.mina.common.support.AbstractIoFilterChain.access$1000(AbstractIoFilterChain.java:53) org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.exceptionCaught(AbstractIoFilterChain.java:643) org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java:224) org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(ExecutorFilter.java:264) java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51) java.lang.Thread.run(Thread.java:619) Name: SocketConnectorIoProcessor-0.0 State: BLOCKED on java.lang.obj...@1777b741 owned by: AnonymousIoService-7 Total blocked: 769 Total waited: 40 Stack trace: org.apache.mina.common.support.BaseIoSession.close(BaseIoSession.java:147) com.m.m.stream.Connection.close(Connection.java:83) com.m.m.app.connector.ConnectorFuture.close(ConnectorFuture.java:198) com.m.m.app.connector.ConnectorFuture.access$100(ConnectorFuture.java:30) com.m.m.app.connector.ConnectorFuture$2.operationComplete(ConnectorFuture.java:94) org.apache.mina.common.support.DefaultIoFuture.notifyListener(DefaultIoFuture.java:191) org.apache.mina.common.support.DefaultIoFuture.notifyListeners(DefaultIoFuture.java:182) - locked org.apache.mina.common.support.defaultclosefut...@7aa47c0d org.apache.mina.common.support.DefaultIoFuture.setValue(DefaultIoFuture.java:124) - locked org.apache.mina.common.support.defaultclosefut...@7aa47c0d org.apache.mina.common.support.DefaultCloseFuture.setClosed(DefaultCloseFuture.java:48) org.apache.mina.common.support.AbstractIoFilterChain.fireSessionClosed(AbstractIoFilterChain.java:257) org.apache.mina.common.support.IoServiceListenerSupport.fireSessionDestroyed(IoServiceListenerSupport.java:208) org.apache.mina.transport.socket.nio.SocketIoProcessor.doRemove(SocketIoProcessor.java:188) org.apache.mina.transport.socket.nio.SocketIoProcessor.access$600(SocketIoProcessor.java:45) org.apache.mina.transport.socket.nio.SocketIoProcessor$Worker.run(SocketIoProcessor.java:489) org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51) java.lang.Thread.run(Thread.java:619) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-488) ClassLoader is not used to load the class in ByteBuffer.getObject()
[ https://issues.apache.org/jira/browse/DIRMINA-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-488. - ClassLoader is not used to load the class in ByteBuffer.getObject() --- Key: DIRMINA-488 URL: https://issues.apache.org/jira/browse/DIRMINA-488 Project: MINA Issue Type: Bug Components: Core Affects Versions: 1.1.5 Reporter: Guillaume Nodet Assignee: Trustin Lee Priority: Critical Fix For: 1.0.9, 1.1.6 Attachments: DIRMINA-488.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-502) Typo in POM
[ https://issues.apache.org/jira/browse/DIRMINA-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-502. - 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: organization nameApache MINA Project/name urlhttp://mina.apace.org//url /organization Rich -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-549) Inconsistency in managed session set under heavy load
[ https://issues.apache.org/jira/browse/DIRMINA-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-549. - Inconsistency in managed session set under heavy load - Key: DIRMINA-549 URL: https://issues.apache.org/jira/browse/DIRMINA-549 Project: MINA Issue Type: Bug Components: Core Affects Versions: 1.0.9, 1.1.6 Reporter: Trustin Lee Assignee: Trustin Lee Priority: Critical Fix For: 1.0.10, 1.1.7 The detailed analysis can be found at: http://mina.markmail.org/search/?q=sessionClosed%20is%20not%20called%20sometimes#query:sessionClosed%20is%20not%20called%20sometimes+page:1+mid:cc5uj66xt5mb5rrs+state:results The thing is that IoServiceListenerSupport.fireSessionCreated() and fireSessionDestroyed() can be invoked at the same time by more than one I/O processor threads, and that can cause sessionClosed event is not fired at all under heavy load. The solution is to acquire a per-service lock whenever managed session set changes. So far, we were acquiring locks separated as two phases, and that was the root cause of the problem. By fixing this issue, performance might decrease slightly, but accuracy is the first concern for us. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
