Nabble - Apache MINA Developer Forum

[jira] Commented: (DIRMINA-489) Composite IoBuffer

2008-11-21T18:52:46Z

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

Mark Webb commented on DIRMINA-489:
-----------------------------------

Fine by me.

> Composite IoBuffer
> ------------------
>
> Key: DIRMINA-489
> URL: https://issues.apache.org/jira/browse/DIRMINA-489
> Project: MINA
> Issue Type: New Feature
> Components: Core
> Reporter: David M. Lloyd
> Assignee: Mark Webb
> Fix For: 3.0.0-M1
>
> Attachments: mina-composite-20080515.patch.gz, mina-composite-20080517.patch, mina-composite-20080521-2.patch, mina-composite-20080521.patch, mina-composite-20080723-1.patch, mina-composite-20080723-2.patch
>
>
> Provide a way to create a large IoBuffer from several smaller IoBuffers, without copying the underlying data.
> It would probably be acceptable to constrain the composite buffer in various ways, for example by disallowing autoexpanding or otherwise changing the capacity, the implementation could be greatly simplified.
> The goal is to be able to process large messages with a minimum of copying.

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

[jira] Created: (DIRMINA-640) 通过IOFilterAdpater添加线程池

2008-11-21T18:34:44Z

通过IOFilterAdpater添加线程池
----------------------

Key: DIRMINA-640
URL: https://issues.apache.org/jira/browse/DIRMINA-640
Project: MINA
Issue Type: Improvement
Reporter: ChinaEstone
Assignee: peter royal
Fix For: 0.9.5

Attached is the start of a patch to allow the ThreadPool that a ThreadPoolFilter uses to be pluggable. Currently depends on Java5, but works as an illustration of thoughts.

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

[jira] Commented: (DIRMINA-489) Composite IoBuffer

2008-11-21T17:26:44Z

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

Emmanuel Lecharny commented on DIRMINA-489:
-------------------------------------------

Yes, I know it's in the base line, but it's not used atm. So I prefer to keep the issue open, until we use this code in the chain (hich is not the case atm).

This is the reason why I postponed the issue to 3.0.

Is that OK ?

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

Re: 2.0-RC1 road to success ...

2008-11-21T17:23:50Z

Sorry if I missed some binding votes ... I forget to count mine in the
3 binding votes, even if I included it (because I forgot to vote
explicitely), so it's 4. Marc ? Is this a binding vote ?

On Fri, Nov 21, 2008 at 8:54 PM, Maarten Bosteels
<mbosteels.dns@...> wrote:

--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

[jira] Commented: (DIRMINA-489) Composite IoBuffer

2008-11-21T12:19:44Z

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

Mark Webb commented on DIRMINA-489:
-----------------------------------

The code submitted by David Lloyd has been placed in the baseline. Unless there are problems, this should be closed.

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

Re: 2.0-RC1 road to success ...

2008-11-21T11:54:37Z

On Fri, Nov 21, 2008 at 7:18 PM, Emmanuel Lecharny <elecharny@...>wrote:

> Hi guys,
>
> the vote for the 2.0-RC1 code freeze is now closed. the result :
> +1 : 3 binding votes (mine included), 6 non binding

Hello,

My apologies for nitpicking, but according to
http://www.nabble.com/-Votes--MINA-2.0-RC1-to20557460.html
I see 5 binding votes: Emmanuel, Maarten, Julien, Niklas G, Marc
and 5 non-binding: Eero, Edouard, Steve, Jeff, Ashish

Maarten

[jira] Updated: (DIRMINA-624) Message handlers selection is not efficient in the DemuxingIoHandler

2008-11-21T11:13:44Z

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

Emmanuel Lecharny updated DIRMINA-624:
--------------------------------------

Fix Version/s: 3.0.0-M1

Postponed to 3.0

> Message handlers selection is not efficient in the DemuxingIoHandler
> --------------------------------------------------------------------
>
> Key: DIRMINA-624
> URL: https://issues.apache.org/jira/browse/DIRMINA-624
> Project: MINA
> Issue Type: Improvement
> Affects Versions: 2.0.0-M3
> Reporter: Emmanuel Lecharny
> Fix For: 3.0.0-M1
>
>
> The way we are selecting a message handler in the DemuxingIoHandler is far from being optimal. The problem is that we are registering a handler without checking its inheritence scheme, but we do so when receiving a message.
> It would be much more efficient to do the inheritence discovering while registering a handler, avoiding such a discovery when receiving a message.
> There is only one tricky issue we have to take care of : as we can associate a handler with one of it's inherited class or implemented interface, if there is another handler associated with those classes/interfaces added later, this should override the default association. So we must flag the automatically added handlers in order to be able to replace them if needed.

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

[jira] Updated: (DIRMINA-418) sendUrgentData feature is needed

2008-11-21T11:07:44Z

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

Emmanuel Lecharny updated DIRMINA-418:
--------------------------------------

Fix Version/s: 3.0.0-M1

Postponed to 3.0

> sendUrgentData feature is needed
> --------------------------------
>
> Key: DIRMINA-418
> URL: https://issues.apache.org/jira/browse/DIRMINA-418
> Project: MINA
> Issue Type: New Feature
> Reporter: mina tds
> Fix For: 3.0.0-M1
>
>
> Java Sockets support sendUrgentData method on sockets.
> Similar feature is needed in MINA.
> For example, in proxy application that need to forward out of band packets like urgent data packet to its remote destination.
> It can receive the urgent data packet as inlne through setting
> tSessionConfig.setOobInline(true);
> But It cannot create/send any urgent packet after It receives such packet.
> Trustin suggested to open an issue in JIRA

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

[jira] Updated: (DIRMINA-57) 100% Test Coverage

2008-11-21T11:05:44Z

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

Emmanuel Lecharny updated DIRMINA-57:
-------------------------------------

Fix Version/s: 3.0.0-M1

Far too late for 2.0 !!! It should have been started from day one, as for the Javadoc ...

Postponed to 3.0 (And 100% test coverage is just a wet dream ... ;)

> 100% Test Coverage
> ------------------
>
> Key: DIRMINA-57
> URL: https://issues.apache.org/jira/browse/DIRMINA-57
> Project: MINA
> Issue Type: Task
> Reporter: Trustin Lee
> Fix For: 3.0.0-M1
>
>
> We need to add more test codes to be confident MINA is stable.

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

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

2008-11-21T11:05:44Z

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

Emmanuel Lecharny updated DIRMINA-507:
--------------------------------------

Fix Version/s: 3.0.0-M1

Will be rethink totally in 3.0.

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

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

[jira] Updated: (DIRMINA-438) Multicast support for MINA API

2008-11-21T11:03:44Z

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

Emmanuel Lecharny updated DIRMINA-438:
--------------------------------------

Fix Version/s: 3.0.0-M1

Postponed to 3.0

> Multicast support for MINA API
> -------------------------------
>
> Key: DIRMINA-438
> URL: https://issues.apache.org/jira/browse/DIRMINA-438
> Project: MINA
> Issue Type: New Feature
> Components: Core
> Reporter: Julien Vermillard
> Priority: Minor
> Fix For: 3.0.0-M1
>
>
> For supporting multicast over UDP we need to change the MINA API for
> Set the multicast Time to Live (TTL) for a multicast transmission.
> Joining a multicast group for a given session.
> Leaving a multicast group.

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

[jira] Updated: (DIRMINA-56) Create a Benchmark Suite That Generates HTML Reports.

2008-11-21T11:01:44Z

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

Emmanuel Lecharny updated DIRMINA-56:
-------------------------------------

Fix Version/s: 3.0.0-M1

Postponed to 3.0

> Create a Benchmark Suite That Generates HTML Reports.
> -----------------------------------------------------
>
> Key: DIRMINA-56
> URL: https://issues.apache.org/jira/browse/DIRMINA-56
> Project: MINA
> Issue Type: Task
> Reporter: Trustin Lee
> Priority: Minor
> Fix For: 3.0.0-M1
>
>
> We need benchmark suite before releasing 0.8 (stable stream)

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

[jira] Updated: (DIRMINA-631) AbstractIoFilter: increment writen- and receivedMessages statistics on application end of filter chain

2008-11-21T11:01:44Z

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

Emmanuel Lecharny updated DIRMINA-631:
--------------------------------------

Fix Version/s: 3.0.0-M1

I suggest a potspone to 3.0, as we will redesign the chain.

> AbstractIoFilter: increment writen- and receivedMessages statistics on application end of filter chain
> ------------------------------------------------------------------------------------------------------
>
> Key: DIRMINA-631
> URL: https://issues.apache.org/jira/browse/DIRMINA-631
> Project: MINA
> Issue Type: Improvement
> Components: Filter
> Affects Versions: 2.0.0-M3
> Environment: MINA 2.0.0-M3
> Reporter: Barend Garvelink
> Fix For: 3.0.0-M1
>
>
> This is the JIRA for the mina-dev mailing list discussion here:
> http://markmail.org/message/e7qw6k5tp52knpav
> To summarise:
> {quote}
> I would like to suggest that the invocations of increaseWrittenMessages() and increaseReceivedMessages() are moved from their current spot in AbstractIoFilter into the appropriate methods of TailFilter. The increaseWrittenBytes() and increaseReceivedBytes() invocations can stay where they are.
> [...]
> I have an IoFilter chain in which a SegmentationFilter takes in a single application message to filterWrite() and splits it into multiple packets. On the way back, it filters the messageSent() events for every packet sent, collating them into a single call to nextFilter#messageSent() for each original application-level message. Further down the chain, I have an ARQ filter which can re-send packets that weren't acknowledged in time. Both filters can cause a different number of messages to come out at the IoService end than went into them at the Application end (and vice versa).
> [...]
> In this scenario the writtenBytes/receivedBytes counters are fine as they are, but the writtenMessages/readMessages counters are basically useless in their current form. Their value depends on the size of the messages my application sends and on the quality of the network connection (i.e. if any retries were necessary) and even on whether the outgoing ACK packets can piggyback on a data packet or have to be sent out on their own. Compared to a message counter I keep at the application level, the messages sent/received values tracked in IoServiceStatistics diverge immediately.
> {quote}

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

[jira] Commented: (DIRMINA-596) Sessions generated by NioSocketConnector cannot be closed in time (within MINA2.0 M1,M2)

2008-11-21T10:59:44Z

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

Emmanuel Lecharny commented on DIRMINA-596:
-------------------------------------------

Still waiting for a sample to work on. Otherwise, we will have to postpone the issue to 3.0...

> Sessions generated by NioSocketConnector cannot be closed in time (within MINA2.0 M1,M2)
> ----------------------------------------------------------------------------------------
>
> Key: DIRMINA-596
> URL: https://issues.apache.org/jira/browse/DIRMINA-596
> Project: MINA
> Issue Type: Bug
> Components: Core, Transport
> Affects Versions: 2.0.0-M1, 2.0.0-M2
> Environment: MINA:mina-core-2.0.0-M2-20080427.091119-1.jar
> JDK: java version "1.5.0_05"
> Plat: Windows XP
> Reporter: Silver
>
> I use MINA 2.0.0 M1 and M2 to build my application.
> When I use one NioSocketConnector to generate 10 sessions and then close them in the messageReceived event of each session, only 5 or 6 sessions(that is to say, not of all sessions) can be closed correctly, others cannot, but I can receive the sessionClosed event. The number of the closed sessions varies from 2-6 during my experiments.
> Another intersting event will occur:
> Since the rest sessions cannot be closed, I tried to generate a new session by the same NioSocketConnector, then all of the 10 "old" sessions were closed as one might expect, except the last new session.
> the main method:
> public static void main(String[] args)
> {
> NioSocketConnector acceptor = new NioSocketConnector();
> acceptor.setDefaultRemoteAddress(new InetSocketAddress("127.0.0.1", 2361));
> acceptor.getFilterChain().addLast( "executor", new ExecutorFilter(100) );
> acceptor.setHandler( new TimeServerHandler() );
> for(int i=0; i<10; i++)
> acceptor.connect();
> }
> the messageReceived method in TimeServerHandler class:
> public void messageReceived(IoSession session, Object message)
> throws Exception
> {
> System.out.println(((IoBuffer) message).getString(Charset.forName("UTF-8")
> .newDecoder()));
> session.close();
> }
> the log of the test server:
> 2008-5-27 17:09:32 Connected ++++++++++++++++++++++++127.0.0.1 / 3211>
> 2008-5-27 17:09:32 Connected ++++++++++++++++++++++++127.0.0.1 / 3212>
> 2008-5-27 17:09:32 Connected ++++++++++++++++++++++++127.0.0.1 / 3213>
> 2008-5-27 17:09:32 Connected ++++++++++++++++++++++++127.0.0.1 / 3214>
> 2008-5-27 17:09:32 Connected ++++++++++++++++++++++++127.0.0.1 / 3215>
> 2008-5-27 17:09:32 Connected ++++++++++++++++++++++++127.0.0.1 / 3216>
> 2008-5-27 17:09:32 Connected ++++++++++++++++++++++++127.0.0.1 / 3217>
> 2008-5-27 17:09:32 Connected ++++++++++++++++++++++++127.0.0.1 / 3218>
> 2008-5-27 17:09:32 Connected ++++++++++++++++++++++++127.0.0.1 / 3219>
> 2008-5-27 17:09:32 Connected ++++++++++++++++++++++++127.0.0.1 / 3220>
> 2008-5-27 17:09:32 Disconnected -----------------------127.0.0.1 / 3211>
> 2008-5-27 17:09:32 Disconnected -----------------------127.0.0.1 / 3213>
> 2008-5-27 17:09:32 Disconnected -----------------------127.0.0.1 / 3214>
> 2008-5-27 17:09:32 Disconnected -----------------------127.0.0.1 / 3212>
> 2008-5-27 17:09:32 Disconnected -----------------------127.0.0.1 / 3216>
> 2008-5-27 17:09:32 Disconnected -----------------------127.0.0.1 / 3215>
> 2008-5-27 17:09:37 Connected ++++++++++++++++++++++++127.0.0.1 / 3221>
> 2008-5-27 17:09:37 Disconnected -----------------------127.0.0.1 / 3217>
> 2008-5-27 17:09:37 Disconnected -----------------------127.0.0.1 / 3218>
> 2008-5-27 17:09:37 Disconnected -----------------------127.0.0.1 / 3219>
> 2008-5-27 17:09:37 Disconnected -----------------------127.0.0.1 / 3220>

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

[jira] Updated: (DIRMINA-627) ByteBuffer.getObject() doesn't support Class objects for non-serializable classes

2008-11-21T10:57:44Z

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

Emmanuel Lecharny updated DIRMINA-627:
--------------------------------------

Fix Version/s: 3.0.0-M1

I _think_ that's belong to 3.0. Anyway, we will have most certainly a better way to handle buffers in 3.0

> ByteBuffer.getObject() doesn't support Class objects for non-serializable classes
> ---------------------------------------------------------------------------------
>
> Key: DIRMINA-627
> URL: https://issues.apache.org/jira/browse/DIRMINA-627
> Project: MINA
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.1.7
> Reporter: Owen Jacobson
> Fix For: 3.0.0-M1
>
> Attachments: fix.patch, tests.patch
>
>
> Instances of java.lang.Class are serializable, whether or not the class they represent is serializable. However, org.apache.mina.common.ByteBuffer's optimizations prevent it from unserializing Class instances representing classes that are not serializable. For example, given
> public interface NotSerializable {}
> /*...*/
> ObjectOutputStream o = /*...*/;
> o.writeObject (NotSerializable.class);
> /*...*/
> ObjectInputStream i = /*..bytes written by o, above..*/;
> Object read = i.readObject();
> The 'read' object will be NotSerializable.class.
> Trying the same thing with buffer.putObject (NotSerializable.class); buffer.flip(); buffer.getObject() throws a NullPointerException.

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

[jira] Updated: (DIRMINA-617) JMX - IoServiceMBean doesn't expose IoService statistics

2008-11-21T10:55:44Z

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

Emmanuel Lecharny updated DIRMINA-617:
--------------------------------------

Fix Version/s: 3.0.0-M1

Postponed to 3.0

> JMX - IoServiceMBean doesn't expose IoService statistics
> --------------------------------------------------------
>
> Key: DIRMINA-617
> URL: https://issues.apache.org/jira/browse/DIRMINA-617
> Project: MINA
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.0.0-M3
> Reporter: simon trudeau
> Fix For: 3.0.0-M1
>
>
> As of Mina 2.0.0-M3 it is not possible to browse Mina's statistics using JMX and IoServiceMBean. Only the object memory address is exposed and not its attributes.
> This should also be looked into for IoSession too.

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

[jira] Updated: (DIRMINA-597) AbstractIoAcceptor.toString() blocks when invoked from IoServiceListener.serviceActivated()

2008-11-21T10:53:44Z

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

Emmanuel Lecharny updated DIRMINA-597:
--------------------------------------

Fix Version/s: 2.0.0-M4

has to be fixed for 2.0.0-M4

> AbstractIoAcceptor.toString() blocks when invoked from IoServiceListener.serviceActivated()
> -------------------------------------------------------------------------------------------
>
> Key: DIRMINA-597
> URL: https://issues.apache.org/jira/browse/DIRMINA-597
> Project: MINA
> Issue Type: Bug
> Components: Core, Transport
> Affects Versions: 2.0.0-M1
> Environment: MINA-2.0.0-RC1, tested on both JDK 1.5 and JDK 1.6
> Reporter: Barend Garvelink
> Fix For: 2.0.0-M4
>
> Attachments: ServiceActivatedBlocksDatagramAcceptorToString.java
>
>
> When NioDatagramAcceptor.toString() is invoked from the serviceActivated() method of IoServiceListener, the system locks up. The [NioDatagramAcceptor-1] thread ends up waiting for a lock held by [main] which is waiting for [NioDatagramAcceptor-1] to finish activating the service.
> I will attach a JUnit test case that demonstrates the problem. I'm not yet comfortable enough around MINA's innards to submit a patch.

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

[jira] Updated: (DIRMINA-598) ByteBuffer passed to ProtocolEncoderOutput.write(ByteBuffer) does not get released back to the pool

2008-11-21T10:53:44Z

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

Emmanuel Lecharny updated DIRMINA-598:
--------------------------------------

Fix Version/s: 1.1.8
2.0.0-M4

We have to check the proposal, see if it applies to 2.0 too.

> ByteBuffer passed to ProtocolEncoderOutput.write(ByteBuffer) does not get released back to the pool
> ---------------------------------------------------------------------------------------------------
>
> Key: DIRMINA-598
> URL: https://issues.apache.org/jira/browse/DIRMINA-598
> Project: MINA
> Issue Type: Bug
> Components: Filter
> Affects Versions: 1.1.7
> Reporter: Greg Dhuse
> Fix For: 2.0.0-M4, 1.1.8
>
>
> When pooled ByteBuffers are used in conjunction with a ProtocolCodecFilter, buffers passed to ProtocolEncoderOutput.write() do not get released back to the pool in all circumstances, causing unnecessary memory allocation.
> The following patch appears to resolve this issue in a simple filter chain, but it should be verified that there is no case where this change would cause a buffer to be released too early.
> Best regards,
> Greg
> Index: core/src/main/java/org/apache/mina/filter/codec/ProtocolCodecFilter.java
> ===================================================================
> --- core/src/main/java/org/apache/mina/filter/codec/ProtocolCodecFilter.java (revision 657929)
> +++ core/src/main/java/org/apache/mina/filter/codec/ProtocolCodecFilter.java (working copy)
> @@ -186,6 +186,10 @@
> public void messageSent(NextFilter nextFilter, IoSession session,
> Object message) throws Exception {
> if (message instanceof HiddenByteBuffer) {
> + // Release buffer originally passed to ProtocolEncoderOutput.write(ByteBuffer)
> + // See http://mina.apache.org/report/1.1/apidocs/org/apache/mina/common/ByteBuffer.html
> + ((HiddenByteBuffer) message).release();
> +
> return;
> }
>

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

[jira] Updated: (DIRMINA-32) Revise JavaDoc, PPT, and Tutorial

2008-11-21T10:51:44Z

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

Emmanuel Lecharny updated DIRMINA-32:
-------------------------------------

Affects Version/s: 2.0.0-M3
Fix Version/s: 2.0.0-RC1

I will reuse this issue to avoid recreating a new one.

> Revise JavaDoc, PPT, and Tutorial
> ---------------------------------
>
> Key: DIRMINA-32
> URL: https://issues.apache.org/jira/browse/DIRMINA-32
> Project: MINA
> Issue Type: Task
> Components: Web Site / Documentation
> Affects Versions: 2.0.0-M3
> Reporter: Trustin Lee
> Fix For: 2.0.0-RC1
>
>
> 0.9 will integrate I/O layer and Protocol layer. We need up-to-date documentation.

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

[jira] Updated: (DIRMINA-629) The IoServiceStatistics methods are called for every new session creation

2008-11-21T10:35:44Z

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

Emmanuel Lecharny updated DIRMINA-629:
--------------------------------------

Fix Version/s: (was: 2.0.0-M4)
3.0.0-M1

Not urgent either... 3.0

> The IoServiceStatistics methods are called for every new session creation
> -------------------------------------------------------------------------
>
> Key: DIRMINA-629
> URL: https://issues.apache.org/jira/browse/DIRMINA-629
> Project: MINA
> Issue Type: Improvement
> Affects Versions: 2.0.0-M3
> Reporter: Emmanuel Lecharny
> Priority: Minor
> Fix For: 3.0.0-M1
>
>
> When a session is established, some methods of the IoServiceStatistics class are called :
> protected final void finishSessionInitialization(IoSession session, IoFuture future, IoSessionInitializer sessionInitializer) {
> if (stats.getLastReadTime() == 0) {
> ((IoServiceStatistics)stats).setLastReadTime(getActivationTime());
> There are two problems with this approach :
> - first, many of the members of this classes are not thread safe, leading to some random value potentially be put into the stats instance for the service
> - second, if we protect those members using some synchronization (or volatile data), it might slow down the connection initialization.
> The IoServiceStatistics class should be thread safe, and these statistics should not be updated if the user don't want them, ie, it should be optionnal (the Configuration object should take care of this)

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

[jira] Updated: (DIRMINA-612) Add documentation on SingleSessionIohandler

2008-11-21T10:33:44Z

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

Emmanuel Lecharny updated DIRMINA-612:
--------------------------------------

Fix Version/s: (was: 2.0.0-M4)
2.0.0-RC1

Documentation will be fixed for 2.0-RC1

> Add documentation on SingleSessionIohandler
> -------------------------------------------
>
> Key: DIRMINA-612
> URL: https://issues.apache.org/jira/browse/DIRMINA-612
> Project: MINA
> Issue Type: Task
> Components: Web Site / Documentation
> Affects Versions: 2.0.0-M2
> Reporter: Geert Schuring
> Priority: Minor
> Fix For: 2.0.0-RC1
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> A normal multi-session IoHandler can be added to the acceptor using the "addHandler" method. However, when writing a single-session IoHandler I can't find any information about how to register it with the acceptor. The "addHandler" method doesn't accept single-session IoHandlers.

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

[jira] Updated: (DIRMINA-489) Composite IoBuffer

2008-11-21T10:33:44Z

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

Emmanuel Lecharny updated DIRMINA-489:
--------------------------------------

Fix Version/s: (was: 2.0.0-M4)
3.0.0-M1

This is a major improvement, but it will be done in 3.0

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

[jira] Updated: (DIRMINA-594) Javadoc & documentation for APR transport

2008-11-21T10:33:44Z

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

Emmanuel Lecharny updated DIRMINA-594:
--------------------------------------

Fix Version/s: (was: 2.0.0-M4)
2.0.0-RC1

Documentation will be fixed for 2.0-RC1

> Javadoc & documentation for APR transport
> -----------------------------------------
>
> Key: DIRMINA-594
> URL: https://issues.apache.org/jira/browse/DIRMINA-594
> Project: MINA
> Issue Type: Improvement
> Components: Transport, Web Site / Documentation
> Affects Versions: 2.0.0-M1
> Reporter: Julien Vermillard
> Fix For: 2.0.0-RC1
>
>
> The APR transport module is javadoc less and probably need a like documentation in the wiki (instalation of APR & jni bindings)

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

[jira] Updated: (DIRMINA-477) Update page about differences between 1.x and 2.x

2008-11-21T10:31:44Z

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

Emmanuel Lecharny updated DIRMINA-477:
--------------------------------------

Fix Version/s: (was: 2.0.0-M4)
2.0.0-RC1

Documentation will be fixed for 2.0-RC1

> Update page about differences between 1.x and 2.x
> -------------------------------------------------
>
> Key: DIRMINA-477
> URL: https://issues.apache.org/jira/browse/DIRMINA-477
> Project: MINA
> Issue Type: Task
> Components: Web Site / Documentation
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Fix For: 2.0.0-RC1
>
>
> Our current web site doesn't describe what have been changed in 2.x comparing to 1.x. We need to carefully put all changes together there so people can migrate more easily.

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

[jira] Updated: (DIRMINA-605) Add documentation for using and building serial port connection

2008-11-21T10:31:44Z

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

Emmanuel Lecharny updated DIRMINA-605:
--------------------------------------

Fix Version/s: (was: 2.0.0-M4)
2.0.0-RC1

Documentation will be fixed for 2.0-RC1

> Add documentation for using and building serial port connection
> ---------------------------------------------------------------
>
> Key: DIRMINA-605
> URL: https://issues.apache.org/jira/browse/DIRMINA-605
> Project: MINA
> Issue Type: Improvement
> Components: Transport
> Affects Versions: 2.0.0-M1
> Environment: Windows XP
> Reporter: john wang
> Assignee: Julien Vermillard
> Fix For: 2.0.0-RC1
>
>
> Add the documentation for building serial-transport and use it in your MINA application

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

[jira] Updated: (DIRMINA-593) Javadoc & documentation for org/apache/mina/filter/reqres

2008-11-21T10:31:44Z

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

Emmanuel Lecharny updated DIRMINA-593:
--------------------------------------

Fix Version/s: (was: 2.0.0-M4)
2.0.0-RC1

Documentation will be fixed for 2.0-RC1

> Javadoc & documentation for org/apache/mina/filter/reqres
> ---------------------------------------------------------
>
> Key: DIRMINA-593
> URL: https://issues.apache.org/jira/browse/DIRMINA-593
> Project: MINA
> Issue Type: Improvement
> Components: Filter, Web Site / Documentation
> Affects Versions: 2.0.0-M1
> Reporter: Julien Vermillard
> Fix For: 2.0.0-RC1
>
>
> no javadoc nor doc on the request/response filter, it need some examples too

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

[jira] Updated: (DIRMINA-577) Implement a Selector pool

2008-11-21T10:29:44Z

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

Emmanuel Lecharny updated DIRMINA-577:
--------------------------------------

Fix Version/s: (was: 2.0.0-M4)
3.0.0-M1

Postponed

> Implement a Selector pool
> --------------------------
>
> Key: DIRMINA-577
> URL: https://issues.apache.org/jira/browse/DIRMINA-577
> Project: MINA
> Issue Type: Improvement
> Affects Versions: 2.0.0-M1
> Reporter: Emmanuel Lecharny
> Fix For: 3.0.0-M1
>
>
> There is an interesting post from Jean-François Arcand : http://weblogs.java.net/blog/jfarcand/archive/2006/07/tricks_and_tips_4.html
> where he explains that we may use more than one single Selector to manage the incoming and outgoing events.
> Separating OP_READ, OP_WRITE and OP_ACCEPT selectors may lead to some improvement, depending on which kind of server you want to build.
> It seems interesting to implement these ideas in MINA.

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

[jira] Updated: (DIRMINA-574) ClassCastException when a message is written on a closed session.

2008-11-21T10:29:44Z

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

Emmanuel Lecharny updated DIRMINA-574:
--------------------------------------

Fix Version/s: (was: 2.0.0-M4)
3.0.0-M1

Will be fixed when the MessageSent message will be removed, something that can't be done for 2.0

> ClassCastException when a message is written on a closed session.
> -----------------------------------------------------------------
>
> Key: DIRMINA-574
> URL: https://issues.apache.org/jira/browse/DIRMINA-574
> Project: MINA
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.10, 1.1.7, 2.0.0-M1
> Reporter: Trustin Lee
> Assignee: Emmanuel Lecharny
> Priority: Blocker
> Fix For: 3.0.0-M1
>
>
> Steps to reproduce:
> 1) Connection is closed at the socket level.
> 2) A user writes a message.
> 3) the message is encoded by a ProtocolCodecFilter.
> 4) MINA notices the closed socket and fires a sessionClosed event.
> 5) After the sessionClosed event is fired, IoFilterChain.clear() is called.
> 6) MINA tries to write the user write request, but the session is closed already - all write requests are discarded.
> 7) Before MINA discards all write requests, MINA checks if the first item in the queue is an empty buffer, which means a special separator which is handled by ProtocolCodecFilter.
> 8) If there's an empty buffer in the head of the queue, MINA fires a messageSent event with the empty buffer in the hope that ProtocolCodecFilter will catch it.
> 9) However, the filter chain is empty and therefore IoHandler implementation gets ClassCastException.
> A possible workaround is just to ignore the exception, but we need to provide a correct fix for this issue.
> The following is the stack trace that explains this scenario:
> 25151 [SocketAcceptorIoProcessor-0.4] WARN ServerPortSessionHandler -
> > [/127.0.0.1:57120 <http://127.0.0.1:57120>]
> > java.lang.ClassCastException:
> > org.apache.mina.filter.codec.ProtocolCodecFilter$MessageByteBuffer
> > incompatible with com.daishin.eai.adapter.socket.message.Por
> > tMessage
> > at
> > com.daishin.eai.adapter.socket.handler.ServerPortSessionHandler.messageSent(ServerPortSessionHandler.java:80)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageSent(AbstractIoFilterChain.java:579)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageSent(AbstractIoFilterChain.java:320)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain.access$1200(AbstractIoFilterChain.java:53)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageSent(AbstractIoFilterChain.java:653)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain$HeadFilter.messageSent(AbstractIoFilterChain.java:504)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageSent(AbstractIoFilterChain.java:320)
> > at
> > org.apache.mina.common.support.AbstractIoFilterChain.fireMessageSent(AbstractIoFilterChain.java:314)
> > at
> > org.apache.mina.transport.socket.nio.SocketIoProcessor.releaseWriteBuffers(SocketIoProcessor.java:359)
> > at
> > org.apache.mina.transport.socket.nio.SocketIoProcessor.doFlush(SocketIoProcessor.java:314)
> > at
> > org.apache.mina.transport.socket.nio.SocketIoProcessor.access$500(SocketIoProcessor.java:45)
> > at
> > org.apache.mina.transport.socket.nio.SocketIoProcessor$Worker.run(SocketIoProcessor.java:488)
> > at
> > org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
> > at
> > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
> > at
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
> > at java.lang.Thread.run(Thread.java:810)

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

[jira] Updated: (DIRMINA-639) WriteFuture are updated long after a session.write() is done

2008-11-21T10:27:44Z

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

Emmanuel Lecharny updated DIRMINA-639:
--------------------------------------

Fix Version/s: (was: 2.0.0-M4)
3.0.0-M1

Postponed to 3.0. It's not possible to fix this without rethinking the chain completely

> WriteFuture are updated long after a session.write() is done
> ------------------------------------------------------------
>
> Key: DIRMINA-639
> URL: https://issues.apache.org/jira/browse/DIRMINA-639
> Project: MINA
> Issue Type: Bug
> Affects Versions: 2.0.0-M3
> Reporter: Emmanuel Lecharny
> Priority: Blocker
> Fix For: 3.0.0-M1
>
>
> While expecting the writeFuture to be updated when the write has been done, it's done only when we get out of the chain. This is a major problem as you can't rely on this to bail a connection based on a slow client. Typically, we may stack thousands of message into the writeQueuebuffer, as the flush is only done when we have gone though the whole chain, and back.
> The only way to get the data be blushed immediately is to add an executorFilter on the WRITE eventType, in order to create a new thread to handle this flush, otherwise we have to wait for the current processor to be done with the chain processing.

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