date:20090526


Niklas Gustavsson wrote:

On Tue, May 26, 2009 at 3:08 PM, Emmanuel Lecharny  wrote:
  

I didn't produced any package, as the mavn assembly plugin is deeply bugged



Binaries available at http://people.apache.org/~ngn/mina/2.0.0-M6/
  


Niklas, can you tell us you you managed to generate those binaries ?

Many thanks !

--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: [VOTE] Release MINA 2.0.0-M6

2009-05-26 Thread Mondain

Thanks for the heads-up Shawn. Also thanks to the team for an excellent
library!

On Tue, May 26, 2009 at 12:17 PM, Maarten Bosteels
wrote:

> +1
>
> Maarten
>
> On Tue, May 26, 2009 at 8:58 PM, Jeff Genender 
> wrote:
>
> > +1
> >
> >
> >
> > On May 26, 2009, at 12:52 PM, Niklas Gustavsson wrote:
> >
> >  On Tue, May 26, 2009 at 3:08 PM, Emmanuel Lecharny <
> elecha...@apache.org>
> >> wrote:
> >>
> >>> I didn't produced any package, as the mavn assembly plugin is deeply
> >>> bugged
> >>>
> >>
> >> Binaries available at http://people.apache.org/~ngn/mina/2.0.0-M6/<
> http://people.apache.org/%7Engn/mina/2.0.0-M6/>
> >>
> >>  [X] +1: Yes, release MINA-2.0.0-M6
> >>>
> >>
> >> /niklas
> >>
> >
> >
>



-- 
http://gregoire.org/
http://osflash.org/red5

Re: [VOTE] Release MINA 2.0.0-M6

2009-05-26 Thread Maarten Bosteels

+1

Maarten

On Tue, May 26, 2009 at 8:58 PM, Jeff Genender  wrote:

> +1
>
>
>
> On May 26, 2009, at 12:52 PM, Niklas Gustavsson wrote:
>
>  On Tue, May 26, 2009 at 3:08 PM, Emmanuel Lecharny 
>> wrote:
>>
>>> I didn't produced any package, as the mavn assembly plugin is deeply
>>> bugged
>>>
>>
>> Binaries available at 
>> http://people.apache.org/~ngn/mina/2.0.0-M6/
>>
>>  [X] +1: Yes, release MINA-2.0.0-M6
>>>
>>
>> /niklas
>>
>
>

Re: [VOTE] Release MINA 2.0.0-M6

2009-05-26 Thread Jeff Genender


+1


On May 26, 2009, at 12:52 PM, Niklas Gustavsson wrote:

On Tue, May 26, 2009 at 3:08 PM, Emmanuel Lecharny > wrote:
I didn't produced any package, as the mavn assembly plugin is  
deeply bugged


Binaries available at http://people.apache.org/~ngn/mina/2.0.0-M6/


[X] +1: Yes, release MINA-2.0.0-M6


/niklas

Re: [VOTE] Release MINA 2.0.0-M6

On Tue, May 26, 2009 at 3:08 PM, Emmanuel Lecharny  wrote:
> I didn't produced any package, as the mavn assembly plugin is deeply bugged

Binaries available at http://people.apache.org/~ngn/mina/2.0.0-M6/

> [X] +1    : Yes, release MINA-2.0.0-M6

/niklas

Re: [jira] Commented: (FTPSERVER-304) The Idle Timeout set in the listener configuration does not have any effect

On Tue, May 26, 2009 at 7:01 PM, Johannes Katelaan  
wrote:
> I absolutely agree with you. The listener timeout should be a default
> timeout.

Since this would break our API, it's not something we can do for the
1.X series. So, if we want to introduce a default idle time, in
addition to the existing maximum idle time, it needs to be a new
configuration.

/niklas

Re: [jira] Commented: (FTPSERVER-304) The Idle Timeout set in the listener configuration does not have any effect

2009-05-26 Thread Johannes Katelaan

Sai,

I absolutely agree with you. The listener timeout should be a default
timeout.
As a developer embedding ftpserver I should only have to set a user
level timeout, if I want it different from the default timeout.
More important as a developer I really should not need to know about a
user level timeout and it still should work in a way you would expect.

As you will have guessed by now, I did not know about a user level
timeout and therefore was quite confused about the fact, that setting
the listener timeout did not seem to have any effect.

Johannes

Am 26.05.2009 um 17:32 schrieb Sai Pullabhotla (JIRA):

[ https://issues.apache.org/jira/browse/FTPSERVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12713055
#action_12713055 ]

Sai Pullabhotla commented on FTPSERVER-304:
---

gets

You wrote:

Not sure what you meant by that.

currently, if the user's timeout is set to zero, the session never
times

out. It does not use the listener's timeout.

I think most/all FTP servers that I've worked with have a global
timeout

option that can be overriddden at a user level. Have not seen the
"max-idle-time" option. So, I guess, we should treat our listener
timeout as
default-timeout instead of max-timeout. It would help if other users
in the

group throw in their ideas too.

Sai Pullabhotla
www.jMethods.com

On Mon, May 25, 2009 at 2:18 PM, Niklas Gustavsson (JIRA)
wrote:

The Idle Timeout set in the listener configuration does not have
any effect

---

Key: FTPSERVER-304
URL: https://issues.apache.org/jira/browse/FTPSERVER-304
Project: FtpServer
Issue Type: Bug
Components: Core
Affects Versions: 1.0.1
Reporter: Sai Pullabhotla
Fix For: 1.0.2

As reported on the mailing list by Johannes, I confirmed that the
idle timeout set on the listener factory did not have any effect.
The connection/session is still good long after the specified idle
timeout. As far as I can remember this used to work fine in pre-1.0
releases. We also have to make sure that the idle timeout on the
data connections works.

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

Re: [VOTE] Release MINA 2.0.0-M6


Shawn Pearce wrote:

On Tue, May 26, 2009 at 09:35, Mondain  wrote:

  

Guys,I've had no response to my query about the exception that i get in M6
but not in M5. It is critical to setting up the Acceptors and if I have
missed something please let me know; I would hate to see M6 go out with
such
an obvious difference.
java.lang.NoSuchMethodError:

org.apache.mina.transport.socket.SocketAcceptor.bind([Ljava/net/SocketAddress;)V




This method changed signature between M4 and M5.  In M5 the signature was
modified to be bind(SocketAddress ...), which is really
bind(SocketAddress[]) once the compiler gets through with it.

This was reported as a bug against M5, and unfortunately, the fix made for
M6 was to change it back to the M4 signature, of bind(SocketAddress).
  
yeah, with was intended, as we were supposed not to change the methods' 
signature, something I did by mistake. So I reverted back to what it was 
before.

Instead, the method should have been overloaded:

  bind(SocketAddress addr) {
bind(new SocketAddress[]{addr});
  }

  bind(SocketAddress ... addr) {
  ... do real work ...
 }

so that both pre-M5 and post-M5 code can link against the methods.
  
Probably the best solution, yep. I don't know why I didn't thought about 
it when I reverted the patch... My bad again.

I don't carry a vote around here, but if I had one, I'd say -1 on M6 until
the method is overloaded and both signatures are supported.
  
Typically a -0 vote :) The initial modification was stupid, the 
correction was stupid too. Sorry for that.


At least, Mondain's issue is gone with M6.


--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: [VOTE] Release MINA 2.0.0-M6

2009-05-26 Thread Shawn Pearce

On Tue, May 26, 2009 at 09:35, Mondain  wrote:

> Guys,I've had no response to my query about the exception that i get in M6
> but not in M5. It is critical to setting up the Acceptors and if I have
> missed something please let me know; I would hate to see M6 go out with
> such
> an obvious difference.
> java.lang.NoSuchMethodError:
>
> org.apache.mina.transport.socket.SocketAcceptor.bind([Ljava/net/SocketAddress;)V

This method changed signature between M4 and M5.  In M5 the signature was
modified to be bind(SocketAddress ...), which is really
bind(SocketAddress[]) once the compiler gets through with it.

This was reported as a bug against M5, and unfortunately, the fix made for
M6 was to change it back to the M4 signature, of bind(SocketAddress).

Instead, the method should have been overloaded:

  bind(SocketAddress addr) {
bind(new SocketAddress[]{addr});
  }

  bind(SocketAddress ... addr) {
  ... do real work ...
 }

so that both pre-M5 and post-M5 code can link against the methods.

I don't carry a vote around here, but if I had one, I'd say -1 on M6 until
the method is overloaded and both signatures are supported.

Re: [VOTE] Release MINA 2.0.0-M6

2009-05-26 Thread Mondain

Guys,I've had no response to my query about the exception that i get in M6
but not in M5. It is critical to setting up the Acceptors and if I have
missed something please let me know; I would hate to see M6 go out with such
an obvious difference.
java.lang.NoSuchMethodError:
org.apache.mina.transport.socket.SocketAcceptor.bind([Ljava/net/SocketAddress;)V

Paul

On Tue, May 26, 2009 at 6:57 AM, Emmanuel Lecharny wrote:

> My vote ...
>
>> [X] +1: Yes, release MINA-2.0.0-M6
>>
>>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>

-- 
http://gregoire.org/
http://osflash.org/red5

[jira] Closed: (DIRMINA-194) Extract Reactor from Acceptor and Connector like ACE in C++.


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

Emmanuel Lecharny closed DIRMINA-194.
-


> Extract Reactor from Acceptor and Connector like ACE in C++.
> 
>
> Key: DIRMINA-194
> URL: https://issues.apache.org/jira/browse/DIRMINA-194
> Project: MINA
>  Issue Type: Improvement
>Reporter: Xu Liang
>Assignee: Trustin Lee
>Priority: Trivial
> Fix For: 2.0.0-M1
>
>
>I'm a programmer in C++ and JAVA. In C++ I have used ACE (The ADAPTIVE 
> Communication Environment, http://www.cs.wustl.edu/~schmidt/ACE.html) as my 
> network framework for five years. I like ACE. I had tried to implement my NIO 
> network framework like ACE in JAVA. But after I found MINA, I decided to 
> adopt it because it has the beautiful filter mechanism. But the Reactor of 
> ACE, which was discussed in "Pattern-Oriented Software Architecture: Patterns 
> for Concurrent and Networked Objects", is better than the worker of MINA. The 
> Reactor can encapsulate the thread and Selector. The Acceptor and Connector 
> accept a Reactor as parameter. In this way the user can reuse the thread in 
> Acceptor, Connector and Processor. The IoHandler can work in single thread. 
> In addition the Reactor works as a timer like the idle timer in MINA. The 
> IoHandler can schedule some timer tasks and process timer events in same 
> thread as network events and user can enjoy the simple and effective source 
> code in single thread.

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

[jira] Closed: (DIRMINA-92) Utility classes for asynchronous request-response protocols.


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

Emmanuel Lecharny closed DIRMINA-92.



> Utility classes for asynchronous request-response protocols.
> 
>
> Key: DIRMINA-92
> URL: https://issues.apache.org/jira/browse/DIRMINA-92
> Project: MINA
>  Issue Type: New Feature
>Affects Versions: 0.7.0
>Reporter: Trustin Lee
>Assignee: Trustin Lee
> Fix For: 2.0.0-M1
>
> Attachments: Protocol.zip, queryreply.zip, requestResponse.zip
>
>
> There are so many existing asynchronous protocols whose messages have 
> request-response structure.  A request message usually has a message ID, and 
> the corresponding response message, which makes a pair, contains the message 
> ID in the request message.
> It would be great if we can provide a common interface and classes to help 
> users implement this type of protocols easily.

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

[jira] Closed: (DIRMINA-107) Mock objects that helps unit testing


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

Emmanuel Lecharny closed DIRMINA-107.
-


> Mock objects that helps unit testing
> 
>
> Key: DIRMINA-107
> URL: https://issues.apache.org/jira/browse/DIRMINA-107
> Project: MINA
>  Issue Type: New Feature
>Reporter: Trustin Lee
>Assignee: Trustin Lee
>Priority: Minor
> Fix For: 2.0.0-M1
>
>
> Unit-testing MINA applications requires a bogus implementation of IoSession 
> and many other classes.  Providing pre-made mock objects will help users test 
> their applications.

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

[jira] Closed: (DIRMINA-289) Change MINA to create heap buffers by default.


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

Emmanuel Lecharny closed DIRMINA-289.
-


> Change MINA to create heap buffers by default.
> --
>
> Key: DIRMINA-289
> URL: https://issues.apache.org/jira/browse/DIRMINA-289
> Project: MINA
>  Issue Type: Task
>  Components: Core
>Reporter: Trustin Lee
>Assignee: Trustin Lee
>Priority: Trivial
> Fix For: 2.0.0-M1
>
>
> Many benchmark reports have shown that heap buffer performs better in many 
> modern JVMs.  Using heap buffers also helps us from keep answering to 
> increase the direct buffer memory size in user's JVM settings.

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

[jira] Updated: (DIRMINA-616) New release.xml file


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

Emmanuel Lecharny updated DIRMINA-616:
--

Fix Version/s: 2.0.0-M7

I would like to see the assembly phase to be reviewed. There is a bad bug in 
Maven which forbid us to use mvn assembly:assembly. Jason has described a 
"workaround" on 
http://www.sonatype.com/books/maven-book/reference/assemblies-set-dist-assemblies.html
 

> New release.xml file
> 
>
> Key: DIRMINA-616
> URL: https://issues.apache.org/jira/browse/DIRMINA-616
> Project: MINA
>  Issue Type: Improvement
>Reporter: Barend Garvelink
>Assignee: Julien Vermillard
> Fix For: 2.0.0-M7
>
> Attachments: release.xml
>
>
> In response to http://markmail.org/message/fhjl74dnlyaojrzr , here's an 
> updated release.xml file. 
> It generally works as it should, but it's affected by 
> http://jira.codehaus.org/browse/MASSEMBLY-285, which causes duplicate entries 
> in the lib/ directory inside the archive. When extracting the archive using 
> 7zip for win32, I get prompted to overwrite/skip/cancel for each duplicate 
> entry. Other archivers may file entirely (?). The only work-around I can come 
> up with as a fix right now is to add a maven-antrun-plugin to the package 
> phase of the root pom which post-processes the release file to fix this. I 
> haven't done that, but if MASSEMBLY-285 isn't fixed before the next release, 
> we may have to.

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

[jira] Closed: (DIRMINA-249) exceptionCaught() should provide more information


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

Emmanuel Lecharny closed DIRMINA-249.
-


> exceptionCaught() should provide more information
> -
>
> Key: DIRMINA-249
> URL: https://issues.apache.org/jira/browse/DIRMINA-249
> Project: MINA
>  Issue Type: Improvement
> Environment: All
>Reporter: Vinod Panicker
>Assignee: Trustin Lee
> Fix For: 2.0.0-M1
>
>
> Currently if the application calls a write() on MINA, it will get notified of 
> any exceptions via the exceptionCaught() method.  The problem is that the 
> application does not have any information as to what data could not be 
> written on the session.  To figure that out, it either has to wait on the 
> WriteFuture or implement some state mechanism within the IoSession.
> Trustin recommended that a WriteException could be created, which could 
> provide the necessary information. It should have the ByteBuffer for which 
> the write() failed.

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

[jira] Updated: (DIRMINA-708) Unbound thread growth on discovery attempts : Improve documentation


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

Emmanuel Lecharny updated DIRMINA-708:
--

Affects Version/s: 2.0.0-M5
Fix Version/s: 2.0.0-RC1
   Issue Type: Task  (was: Bug)
  Summary: Unbound thread growth on discovery attempts : Improve 
documentation  (was: Unbound thread growth on discovery attempts)

Affected to 2.0.0-RC1

> Unbound thread growth on discovery attempts : Improve documentation
> ---
>
> Key: DIRMINA-708
> URL: https://issues.apache.org/jira/browse/DIRMINA-708
> Project: MINA
>  Issue Type: Task
>Affects Versions: 2.0.0-M5
>Reporter: boB Gage
> Fix For: 2.0.0-RC1
>
> Attachments: profile-mina.txt.gz
>
>
> Using several different possible protocol handlers (handler, codecs, et al) 
> on several potential ports (serial and/or network), our code attempts to 
> discover devices on the far end and attach the proper decoders on the proper 
> ports.
> Generally, this process is working, however, every failed discovery attempt 
> has launched roughly 6 threads, but only destroyed roughly 4 of them.The 
> 2 delta threads sit in WAIT states forever.
> More details are available in the "Unbound thread growth" thread of the 
> listserv.

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

[jira] Closed: (DIRMINA-24) Performance profiler filter


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

Emmanuel Lecharny closed DIRMINA-24.



> Performance profiler filter
> ---
>
> Key: DIRMINA-24
> URL: https://issues.apache.org/jira/browse/DIRMINA-24
> Project: MINA
>  Issue Type: New Feature
>  Components: Filter
>Affects Versions: 0.7.0, 0.8.0
>Reporter: Trustin Lee
>Assignee: Mark Webb
> Fix For: 2.0.0-M1
>
>
> We could profile event handler methods of ProtocolHandler to find bottleneck 
> in runtime.  It will be very useful because filters can be added and removed 
> on the fly in runtime.

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

[jira] Closed: (DIRMINA-280) AutoStart setting for IoServiceManager.startCollectingStats().


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

Emmanuel Lecharny closed DIRMINA-280.
-


> AutoStart setting for IoServiceManager.startCollectingStats().
> --
>
> Key: DIRMINA-280
> URL: https://issues.apache.org/jira/browse/DIRMINA-280
> Project: MINA
>  Issue Type: Improvement
>  Components: Integration
>Affects Versions: 1.0.0
>Reporter: Trustin Lee
>Assignee: Julien Vermillard
>Priority: Minor
> Fix For: 2.0.0-M1
>
>
> IoServiceManager.startCollectingStats() has to be called by user manually to 
> start the collection of I/O statistics.  It would be nice to provide a 
> constructor parameter that triggers startCollectingStats() to be invoked 
> automatically.

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

[jira] Closed: (DIRMINA-314) LoggingFilter should use different loggers for each event and the logger prefix and level should be configurable


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

Emmanuel Lecharny closed DIRMINA-314.
-


> LoggingFilter should use different loggers for each event and the logger 
> prefix and level should be configurable
> 
>
> Key: DIRMINA-314
> URL: https://issues.apache.org/jira/browse/DIRMINA-314
> Project: MINA
>  Issue Type: New Feature
>Reporter: Niklas Therning
>Assignee: Niklas Therning
>Priority: Minor
> Fix For: 2.0.0-M1
>
>
> It would be nice to be able to set my own logger name for LoggingFilter to 
> use. It can be done today by setting an attribute in my session but then the 
> prefix used by SessionLog will be null. 
> It would also be nice to be able to set the log level to be used. Currently 
> the level is always INFO.

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

[jira] Closed: (DIRMINA-290) Make IoService (IoConnector and IoAcceptor) manage only one service.


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

Emmanuel Lecharny closed DIRMINA-290.
-


> Make IoService (IoConnector and IoAcceptor) manage only one service.
> 
>
> Key: DIRMINA-290
> URL: https://issues.apache.org/jira/browse/DIRMINA-290
> Project: MINA
>  Issue Type: Task
>  Components: Core
>Reporter: Trustin Lee
>Assignee: Trustin Lee
> Fix For: 2.0.0-M1
>
>
> Allowing IoAcceptor to bind more than one ports per one instance makes the 
> API complex.  Restricting an acceptor to bind to only one port will 
> dramatically simplify the API.  The properties of IoServiceConfig will be 
> merged into IoService.  Applying this practice to IoConnector will also be 
> very helpful to implement reconnection feature.

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

[jira] Closed: (DIRMINA-292) Shared I/O processors.


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

Emmanuel Lecharny closed DIRMINA-292.
-


> Shared I/O processors.
> --
>
> Key: DIRMINA-292
> URL: https://issues.apache.org/jira/browse/DIRMINA-292
> Project: MINA
>  Issue Type: New Feature
>  Components: Core
>Reporter: Trustin Lee
>Assignee: Trustin Lee
> Fix For: 2.0.0-M1
>
>
> Currently, I/O processor threads belong to its parent IoService, which means 
> that I/O processors cannot be shared among different services.  This becomes 
> a serious issue when more than one service is deployed into the same JVM.  
> Therefore, we need a way to share the I/O processors among the services with 
> the same transport type.

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

[jira] Closed: (DIRMINA-302) Unbounded nature of writeRequestQueue can cause OutOfMemoryException


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

Emmanuel Lecharny closed DIRMINA-302.
-


> Unbounded nature of writeRequestQueue can cause OutOfMemoryException
> 
>
> Key: DIRMINA-302
> URL: https://issues.apache.org/jira/browse/DIRMINA-302
> Project: MINA
>  Issue Type: Bug
>  Components: Filter
>Affects Versions: 1.0.0
>Reporter: Martin Ritchie
>Assignee: Trustin Lee
> Fix For: 2.0.0-M1
>
> Attachments: WriteBufferLimitFilterBuilder.java
>
>
> As referenced in the following JIRAs:
>  DIRMINA-206 Prevent OutOfMemoryError when a server or a client is overloaded
>  DIRMINA-144 Traffic shaping filter
>  DIRMINA-262 Controlling rate of writes in Mina 0.8.2
> Raised to hightlight the problem. There are a number of approaches that have 
> been mentioned and could be used as an approach.
> Limiting the queue to number of requests or total size. 
> Then either blocking on a write or throwing an exception.

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

[jira] Closed: (DIRMINA-34) New transport type: Java Communications API


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

Emmanuel Lecharny closed DIRMINA-34.



> New transport type: Java Communications API
> ---
>
> Key: DIRMINA-34
> URL: https://issues.apache.org/jira/browse/DIRMINA-34
> Project: MINA
>  Issue Type: New Feature
>Affects Versions: 0.7.0
>Reporter: Trustin Lee
>Assignee: Julien Vermillard
> Fix For: 2.0.0-M1
>
>
> Java Communications API provides ways to access serial and parallel ports 
> available.  We could implement transport type implementation of Java 
> Communications to provides users access to serial and parallel ports.

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

[jira] Closed: (DIRMINA-269) Cancellation operation for ConnectFuture


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

Emmanuel Lecharny closed DIRMINA-269.
-


> Cancellation operation for ConnectFuture
> 
>
> Key: DIRMINA-269
> URL: https://issues.apache.org/jira/browse/DIRMINA-269
> Project: MINA
>  Issue Type: New Feature
>  Components: Core, Transport
>Reporter: Hooman Valibeigi
>Assignee: Trustin Lee
> Fix For: 2.0.0-M1
>
>
> Currently I'm using the following logic to connect to server
> ConnectFuture future = socket.connect(SocketAddress, IoHandler);
> future.join();
> try {
> session = future.getSession();
> } catch (Exception e) {
> // e.getCause() tells the error
> }
> it waits till the connection is established. but I want the user to be able 
> to stop the connect process while it is not yet established. for example in 
> cases that Connection_Timeout would occur, the user should wait till the time 
> out is finished. is it possible to stop it whenever we desire?

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

[jira] Closed: (DIRMINA-281) Move millisecondsPolling parameter in IoServiceManager.startCollectingStats() to a separate property 'pollingInterval'


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

Emmanuel Lecharny closed DIRMINA-281.
-


> Move millisecondsPolling parameter in IoServiceManager.startCollectingStats() 
> to a separate property 'pollingInterval'
> --
>
> Key: DIRMINA-281
> URL: https://issues.apache.org/jira/browse/DIRMINA-281
> Project: MINA
>  Issue Type: Task
>  Components: Integration
>Affects Versions: 1.0.0
>Reporter: Trustin Lee
>Assignee: Julien Vermillard
>Priority: Minor
> Fix For: 2.0.0-M1
>
>
> IoServiceManager.startCollectingStats() requires a parameter that indicates 
> the polling interval.  This parameter can be removed and provided as a 
> separate property for easier JMX management.

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

[jira] Closed: (DIRMINA-286) Remove IoSession.writtenWriteRequests and Rename IoSession.scheduledWriteRequests


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

Emmanuel Lecharny closed DIRMINA-286.
-


> Remove IoSession.writtenWriteRequests and Rename 
> IoSession.scheduledWriteRequests
> -
>
> Key: DIRMINA-286
> URL: https://issues.apache.org/jira/browse/DIRMINA-286
> Project: MINA
>  Issue Type: Task
>  Components: Core
>Reporter: Trustin Lee
>Assignee: Trustin Lee
>Priority: Trivial
> Fix For: 2.0.0-M1
>
>
> IoSession.writtenWriteRequests and writtenMessages have the same semantic, so 
> let's just remove writtenWriteRequests property.  Because we are using the 
> term 'message' all over the place, scheduledWriteRequests should be renamed 
> to scheduledWriteMessages.

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

[jira] Closed: (DIRMINA-316) Manual shutdown of I/O worker threads and Selectors


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

Emmanuel Lecharny closed DIRMINA-316.
-


> Manual shutdown of I/O worker threads and Selectors
> ---
>
> Key: DIRMINA-316
> URL: https://issues.apache.org/jira/browse/DIRMINA-316
> Project: MINA
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 1.0.0
>Reporter: Trustin Lee
>Assignee: Trustin Lee
>Priority: Minor
> Fix For: 2.0.0-M1
>
>
> As discussed in the mailing list:
> http://www.nabble.com/SocketConnector.setWorkerTimeout%28%29-tf2695998.html
> we will change the previous behavior (automatic shutdown) to the manual 
> shutdown.

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

[jira] Commented: (FTPSERVER-304) The Idle Timeout set in the listener configuration does not have any effect

2009-05-26 Thread Sai Pullabhotla (JIRA)

[ 
https://issues.apache.org/jira/browse/FTPSERVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12713055#action_12713055
 ] 

Sai Pullabhotla commented on FTPSERVER-304:
---

gets

You wrote:

Not sure what you meant by that.

currently, if the user's timeout is set to zero, the session never times
out. It does not use the listener's timeout.

I think most/all FTP servers that I've worked with have a global timeout
option that can be overriddden at a user level. Have not seen the
"max-idle-time" option. So, I guess, we should treat our listener timeout as
default-timeout instead of max-timeout. It would help if other users in the
group throw in their ideas too.

Sai Pullabhotla
www.jMethods.com

On Mon, May 25, 2009 at 2:18 PM, Niklas Gustavsson (JIRA)
wrote:

> The Idle Timeout set in the listener configuration does not have any effect
> ---
>
> Key: FTPSERVER-304
> URL: https://issues.apache.org/jira/browse/FTPSERVER-304
> Project: FtpServer
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.0.1
>Reporter: Sai Pullabhotla
> Fix For: 1.0.2
>
>
> As reported on the mailing list by Johannes, I confirmed that the idle 
> timeout set on the listener factory did not have any effect. The 
> connection/session is still good long after the specified idle timeout. As 
> far as I can remember this used to work fine in pre-1.0 releases. We also 
> have to make sure that the idle timeout on the data connections works. 

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

[jira] Closed: (DIRMINA-325) Configuration of SSLSession cacheSize and sessionTimeout


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

Emmanuel Lecharny closed DIRMINA-325.
-


> Configuration of SSLSession cacheSize and sessionTimeout
> 
>
> Key: DIRMINA-325
> URL: https://issues.apache.org/jira/browse/DIRMINA-325
> Project: MINA
>  Issue Type: Improvement
>  Components: Integration
>Affects Versions: 1.0.0
>Reporter: Wolter Eldering
>Assignee: Niklas Therning
> Fix For: 2.0.0-M1
>
>
> The defaults values for session cache and timeout could lead to a large 
> number of sessions being cached under a SSLContext.
> The is no way to set these values in SSLContextFactoryBean.
> Index: 
> integration-spring/src/main/java/org/apache/mina/integration/spring/ssl/SSLContextFactoryBean.java
> ===
> --- 
> integration-spring/src/main/java/org/apache/mina/integration/spring/ssl/SSLContextFactoryBean.java
>   (revision 487691)
> +++ 
> integration-spring/src/main/java/org/apache/mina/integration/spring/ssl/SSLContextFactoryBean.java
>   (working copy)
> @@ -76,6 +76,10 @@
>  private String trustManagerFactoryProvider = null;
>  private boolean trustManagerFactoryAlgorithmUseDefault = false;
>  private ManagerFactoryParameters trustManagerFactoryParameters = null;
> +private int clientSessionCacheSize = -1;
> +private int clientSessionTimeout = -1;
> +private int serverSessionCacheSize = -1;
> +private int serverSessionTimeout = -1;
>  
>  protected Object createInstance() throws Exception
>  {
> @@ -156,7 +160,27 @@
>  }
>  
>  context.init( keyManagers, trustManagers, secureRandom );
> +
> +if( clientSessionCacheSize >= 0 )
> +{
> +context.getClientSessionContext().setSessionCacheSize( 
> clientSessionCacheSize );
> +}
>  
> +if( clientSessionTimeout >= 0 )
> +{
> +context.getClientSessionContext().setSessionTimeout( 
> clientSessionTimeout );
> +}
> +
> +if( serverSessionCacheSize >= 0 )
> +{
> +context.getServerSessionContext().setSessionCacheSize( 
> serverSessionCacheSize );
> +}
> +
> +if( serverSessionTimeout >= 0 )
> +{
> +context.getServerSessionContext().setSessionTimeout( 
> serverSessionTimeout );
> +}
> +
>  return context;
>  }
>  
> @@ -393,5 +417,47 @@
>  this.secureRandom = secureRandom;
>  }
>  
> +/**
> + * Sets the SSLSession cache size for the {...@link SSLSessionContext} 
> for use in client mode.
> + *  
> + * @param size the new session cache size limit; zero means there is no 
> limit.
> + * @see SSLSessionContext#setSessionCacheSize(int size)
> + */
> +public void setClientSessionCacheSize(int size)
> +{
> +this.clientSessionCacheSize = size;
> +   }
>  
> +/**
> + * Set the SSLSession timeout limit for the {...@link SSLSessionContext} 
> for use in client mode.
> + * 
> + * @param seconds the new session timeout limit in seconds; zero means 
> there is no limit.
> + * @see SSLSessionContext#setSessionTimeout(int seconds)
> + */
> +public void setClientSessionTimeout(int seconds)
> +{
> +this.clientSessionTimeout = seconds;
> +   }
> +
> +/**
> + * Sets the SSLSession cache size for the {...@link SSLSessionContext} 
> for use in server mode.
> + *  
> + * @param size the new session cache size limit; zero means there is no 
> limit.
> + * @see SSLSessionContext#setSessionCacheSize(int size)
> + */
> +public void setServerSessionCacheSize(int serverSessionCacheSize)
> +{
> +this.serverSessionCacheSize = serverSessionCacheSize;
> +   }
> +
> +/**
> + * Set the SSLSession timeout limit for the {...@link SSLSessionContext} 
> for use in server mode.
> + * 
> + * @param seconds the new session timeout limit in seconds; zero means 
> there is no limit.
> + * @see SSLSessionContext#setSessionTimeout(int seconds)
> + */
> +public void setServerSessionTimeout(int serverSessionTimeout)
> +{
> +this.serverSessionTimeout = serverSessionTimeout;
> +   }
>  }

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

[jira] Closed: (DIRMINA-336) Remove cyclic dependencies among packages


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

Emmanuel Lecharny closed DIRMINA-336.
-


> Remove cyclic dependencies among packages
> -
>
> Key: DIRMINA-336
> URL: https://issues.apache.org/jira/browse/DIRMINA-336
> Project: MINA
>  Issue Type: Task
>Reporter: Trustin Lee
>Assignee: Trustin Lee
> Fix For: 2.0.0-M1
>
>
> Cyclic dependency is generally a bad thing.  We have a lot of cyclic 
> dependencies comparing the number of classes we have.  Some are intended, and 
> others are not.  Having unintended cyclic dependencies is an obvious problem. 
>  Having intended cyclic dependencies is not really a problem, but they will 
> hinder us from finding out unintended cyclic dependencies, which is bad.

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

[jira] Closed: (DIRMINA-326) Cached SSLSessions won't be reused by the SSLFilter if in client mode.


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

Emmanuel Lecharny closed DIRMINA-326.
-


> Cached SSLSessions won't be reused by the SSLFilter if in client mode.
> --
>
> Key: DIRMINA-326
> URL: https://issues.apache.org/jira/browse/DIRMINA-326
> Project: MINA
>  Issue Type: Bug
>  Components: Filter
>Affects Versions: 1.0.0
>Reporter: Wolter Eldering
>Assignee: Niklas Therning
> Fix For: 2.0.0-M1
>
>
> SSLSessions won't be reused by the SSLFilter if in client mode.
> In client mode SSLContext.createSSLEngine() will always create a new 
> SSLSession.
> The only way to reuse cached SSLSessions in client mode is to use the 
> SSLContext.createSSLEngine(String peerHost, int peerPort) factory method.
> Index: filter-ssl/src/main/java/org/apache/mina/filter/support/SSLHandler.java
> ===
> --- filter-ssl/src/main/java/org/apache/mina/filter/support/SSLHandler.java   
>   (revision 487691)
> +++ filter-ssl/src/main/java/org/apache/mina/filter/support/SSLHandler.java   
>   (working copy)
> @@ -36,6 +36,7 @@
>  import org.apache.mina.filter.SSLFilter;
>  import org.apache.mina.util.Queue;
>  import org.apache.mina.util.SessionLog;
> +import java.net.InetSocketAddress;
>  
>  /**
>   * A helper class using the SSLEngine API to decrypt/encrypt data.
> @@ -110,7 +111,12 @@
>  return;
>  }
>  
> -sslEngine = ctx.createSSLEngine();
> + InetSocketAddress hint = (InetSocketAddress) 
> session.getAttribute(SSLFilter.SESSION_HINT);
> + if (hint == null) {
> +   sslEngine = ctx.createSSLEngine();
> +} else {
> +sslEngine = ctx.createSSLEngine(hint.getHostName(), 
> hint.getPort());
> + }
>  sslEngine.setUseClientMode( parent.isUseClientMode() );
>  
>  if ( parent.isWantClientAuth() )
> Index: filter-ssl/src/main/java/org/apache/mina/filter/SSLFilter.java
> ===
> --- filter-ssl/src/main/java/org/apache/mina/filter/SSLFilter.java  
> (revision 487691)
> +++ filter-ssl/src/main/java/org/apache/mina/filter/SSLFilter.java  
> (working copy)
> @@ -101,6 +101,9 @@
>   * doesn't emit any events related with SSL session flow control.
>   */
>  public static final String USE_NOTIFICATION = SSLFilter.class.getName() 
> + ".UseNotification";
> +
> +public static final String SESSION_HINT = SSLFilter.class.getName() + 
> ".SessionHint";
> +
>  
>  /**
>   * A special message object which is emitted with a {...@link 
> IoHandler#messageReceived(IoSession, Object)}

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

[jira] Closed: (DIRMINA-334) Add an option that disables event ordering in ExecutorFilter.


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

Emmanuel Lecharny closed DIRMINA-334.
-


> Add an option that disables event ordering in ExecutorFilter.
> -
>
> Key: DIRMINA-334
> URL: https://issues.apache.org/jira/browse/DIRMINA-334
> Project: MINA
>  Issue Type: New Feature
>  Components: Core
>Reporter: Trustin Lee
>Assignee: Trustin Lee
>Priority: Minor
> Fix For: 2.0.0-M1
>
> Attachments: ExecutorFilter.java
>
>
> Some applications don't need to receive events in order, but need to process 
> events more simultaneously for performance.  ExecutorFilter could provide an 
> option that disables event ordering for such applications.

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

[jira] Closed: (DIRMINA-339) IoFilterChain.replace()


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

Emmanuel Lecharny closed DIRMINA-339.
-


> IoFilterChain.replace()
> ---
>
> Key: DIRMINA-339
> URL: https://issues.apache.org/jira/browse/DIRMINA-339
> Project: MINA
>  Issue Type: New Feature
>  Components: Core
>Reporter: Trustin Lee
>Assignee: Trustin Lee
>Priority: Minor
> Fix For: 2.0.0-M1
>
>
> in MINA 1.x, people have to remove a filter and add a new filter to replace a 
> filter.  This is not thread-safe because there's a gap between the removal 
> and the addition.  Introducing replace() method could help this problem:
> filterChain.replace("codec", newCodec);  // Switch to the new codec.
> filterChain.replace(oldCodec, newCodec); // Switch by explicit reference

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

[jira] Closed: (DIRMINA-337) SwingChatClient example throws NPE


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

Emmanuel Lecharny closed DIRMINA-337.
-


> SwingChatClient example throws NPE
> --
>
> Key: DIRMINA-337
> URL: https://issues.apache.org/jira/browse/DIRMINA-337
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 2.0.0-M1
>Reporter: Maarten Bosteels
>Assignee: Trustin Lee
>Priority: Trivial
> Fix For: 2.0.0-M1
>
> Attachments: patch.txt
>
>
> session.write( "LOGIN " + name );
> is called before the session is retrieved from the ConnectFuture
> I will attach a trivial patch.
> (also added an ExecutorFilter to serverContext.xml)
> java.lang.NullPointerException
>  at 
> org.apache.mina.example.chat.client.ChatClientSupport.login(ChatClientSupport.java:93)
> at 
> org.apache.mina.example.chat.client.SwingChatClient.connected(SwingChatClient.java:283)
> at 
> org.apache.mina.example.chat.client.SwingChatClientHandler.sessionOpened(SwingChatClientHandler.java:69)
> at 
> org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.sessionOpened(AbstractIoFilterChain.java:658)
> at 
> org.apache.mina.common.support.AbstractIoFilterChain.callNextSessionOpened(AbstractIoFilterChain.java:290)
> at 
> org.apache.mina.common.support.AbstractIoFilterChain.access$700(AbstractIoFilterChain.java:53)
> at 
> org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.sessionOpened(AbstractIoFilterChain.java:760)
> at 
> org.apache.mina.filter.LoggingFilter.sessionOpened(LoggingFilter.java:114)
> at 
> org.apache.mina.common.support.AbstractIoFilterChain.callNextSessionOpened(AbstractIoFilterChain.java:290)
> at 
> org.apache.mina.common.support.AbstractIoFilterChain.access$700(AbstractIoFilterChain.java:53)
> at 
> org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.sessionOpened(AbstractIoFilterChain.java:760)
> at 
> org.apache.mina.common.IoFilterAdapter.sessionOpened(IoFilterAdapter.java:63) 
>at 
> org.apache.mina.common.support.AbstractIoFilterChain.callNextSessionOpened(AbstractIoFilterChain.java:290)
> at 
> org.apache.mina.common.support.AbstractIoFilterChain.access$700(AbstractIoFilterChain.java:53)
> at 
> org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.sessionOpened(AbstractIoFilterChain.java:760)
> at 
> org.apache.mina.common.support.AbstractIoFilterChain$HeadFilter.sessionOpened(AbstractIoFilterChain.java:593)
> at 
> org.apache.mina.common.support.AbstractIoFilterChain.callNextSessionOpened(AbstractIoFilterChain.java:290)
> at 
> org.apache.mina.common.support.AbstractIoFilterChain.fireSessionOpened(AbstractIoFilterChain.java:282)
> at 
> org.apache.mina.common.support.IoServiceListenerSupport.fireSessionCreated(IoServiceListenerSupport.java:197)
> at 
> org.apache.mina.transport.socket.nio.SocketIoProcessor.doAddNew(SocketIoProcessor.java:172)
> at 
> org.apache.mina.transport.socket.nio.SocketIoProcessor.access$300(SocketIoProcessor.java:49)
> at 
> org.apache.mina.transport.socket.nio.SocketIoProcessor$Worker.run(SocketIoProcessor.java:535)
> at 
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:43)
> at
> java.lang.Thread.run(Thread.java:595)

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

[jira] Closed: (DIRMINA-341) Allow binding multiple SocketAddresses per IoAcceptor.


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

Emmanuel Lecharny closed DIRMINA-341.
-


> Allow binding multiple SocketAddresses per IoAcceptor.
> --
>
> Key: DIRMINA-341
> URL: https://issues.apache.org/jira/browse/DIRMINA-341
> Project: MINA
>  Issue Type: New Feature
>  Components: Core
>Reporter: Trustin Lee
>Assignee: Trustin Lee
> Fix For: 2.0.0-M1
>
>
> 2.0-M1-SNAPSHOT allows only one SocketAddress to be bound per IoAcceptor.  
> People want to bind the same protocol handler into more than one NICs with 
> different port.

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

[jira] Closed: (DIRMINA-361) Event type and EventType enum


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

Emmanuel Lecharny closed DIRMINA-361.
-


> Event type and EventType enum
> -
>
> Key: DIRMINA-361
> URL: https://issues.apache.org/jira/browse/DIRMINA-361
> Project: MINA
>  Issue Type: New Feature
>  Components: Core
>Reporter: Trustin Lee
>Assignee: Trustin Lee
>Priority: Trivial
> Fix For: 2.0.0-M1
>
>
> Filters which queues received events into a collection needs to convert a 
> method invocation into an event object. ExecutorFilter and SSLFilter are good 
> examples, and we might have more than that in the near future.  It would be 
> great to extract Event and EventType types from ExecutorFilter and to provide 
> them as a utility.

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

[jira] Closed: (DIRMINA-360) Provide interruptable wait methods in IoFuture.


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

Emmanuel Lecharny closed DIRMINA-360.
-


> Provide interruptable wait methods in IoFuture.
> ---
>
> Key: DIRMINA-360
> URL: https://issues.apache.org/jira/browse/DIRMINA-360
> Project: MINA
>  Issue Type: New Feature
>  Components: Core
>Reporter: Trustin Lee
>Assignee: Trustin Lee
>Priority: Minor
> Fix For: 2.0.0-M1
>
>
> IoFuture.join() and IoFuture.join(long) are uninterruptable, that is, calling 
> Thread.interrupt() won't make the call return immediately, which often causes 
> unexpectedly delayed shutdown of a thread.  As other classes in 
> java.util.concurrent package provide both interruptable and uninterruptable 
> wait methods, we need to provide both types of methods for IoFuture.

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

[jira] Closed: (DIRMINA-367) 1.1 proxy example broken with svn revision: 522721


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

Emmanuel Lecharny closed DIRMINA-367.
-


> 1.1 proxy example broken with svn revision: 522721
> --
>
> Key: DIRMINA-367
> URL: https://issues.apache.org/jira/browse/DIRMINA-367
> Project: MINA
>  Issue Type: Bug
>  Components: Core
> Environment: linux
>Reporter: keith mcneill
>Assignee: Trustin Lee
> Fix For: 2.0.0-M1
>
>
> I just updated to the latest version of mina and my server app broke.  It is 
> partially based on the proxy example.  Looking back through the svn logs, 
> things seem to break on r522721.   I've confirmed this with the stock proxy 
> example.
> The proxy sometimes closes sessions without writing results to the client.  
> Client gets back zero bytes.   My clients have lots of HTTP like 
> callsquick in and out exchanges with the server.  
> The line in question is in: 
> core/src/main/java/org/apache/mina/transport/socket/nio/SocketIoProcessor.java
> in the doFlush() method the added line from that svn revision is:
> if( key.isWritable() )   ~ line 426
> breaks things.  If I comment it out, things work fine.  
> Looking more closely at the code I don't quite understand how the method is 
> supposed to work.  My nio knowledge is somewhat limited but.  
> When the method is entered we do the following:
> // Clear OP_WRITE
> SelectionKey key = session.getSelectionKey();
> key.interestOps( key.interestOps() & ( ~SelectionKey.OP_WRITE ) );
> We clear OP_WRITE.
> then in the for loop we do the:
> if( key.isWritable() ) 
> test.
> How is it ever supposed to report back as writable if we clear OP_WRITE.  
> Does it work sometimes now because of a race condition with further writes on 
> the socket?

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

[jira] Closed: (DIRMINA-368) IoFilter.messageSent should have access to WriteRequest instead of the written message.


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

Emmanuel Lecharny closed DIRMINA-368.
-


> IoFilter.messageSent should have access to WriteRequest instead of the 
> written message.
> ---
>
> Key: DIRMINA-368
> URL: https://issues.apache.org/jira/browse/DIRMINA-368
> Project: MINA
>  Issue Type: Improvement
>  Components: Core
>Reporter: Trustin Lee
>Assignee: Trustin Lee
> Fix For: 2.0.0-M1
>
>
> IoFilter.filterWrite() accepts WriteRequest as its parameter to allow an 
> IoFilter implementation to alter the WriteRequest or create a new 
> WriteRequest.  This is particularly useful when the filter transforms a 
> received message.  Good examples of this scenario are ProtocolCodecFilter and 
> SSLFilter.
> Because these examples are wrapping an outgoing message with an internal 
> type, the filter implementor was able to get the original message by 
> unwrapping in IoFilter.messageSent() like the following:
> public void filterWrite(NextFilter nextFilter, IoSession session, 
> WriteRequest req) {
> nextFilter.filterWrite(session, new WriteRequest(new 
> TransformedMessage(req.getMessage(;
> }
> public void messageSent(NextFilter nextFilter, IoSession session, Object 
> message) {
> if (message instanceof TransformedMessage) {
> nextFilter.messageSent(session, ((TransformedMessage) 
> message).getOriginalMessage());
> return;
> }
> ..
> }
> But, what if the transformation is not wrapping but unwrapping?  We can't 
> perform the reverse-transformation like we did in the example above, because 
> we don't know what the original message was in IoFilter.messageSent().
> public void filterWrite(NextFilter nextFilter, IoSession session, 
> WriteRequest req) {
> nextFilter.filterWrite(session, new WriteRequest(
> ((OuterMessage) req.getMessage()).getInnerMessage()));  // 
> Unwrap on write.
> }
> public void messageSent(NextFilter nextFilter, IoSession session, Object 
> message) {
> if (message instanceof InnerMessage) {
> // TODO Transform the message back to OuterMessage.  But how?
> }
> ..
> }
> To fix this problem, there should be at least one common type that any 
> IoFilter implementation can understand, and that type has to be the parameter 
> of IoFilter.messageSent().  A good candidate is WriteRequest, which is 
> already exposed in the IoFilter interface.  With this change applied, the 
> IoFilter implementation will look like the following:
> public void filterWrite(NextFilter nextFilter, IoSession session, 
> WriteRequest req) {
> // Wrap on write.
> nextFilter.filterWrite(session, new TransformedWriteRequest(request));
> }
> public void messageSent(NextFilter nextFilter, IoSession session, 
> WriteRequest request) {
> if (request instanceof TransformedWriteRequest) {
> // Unwrap on messageSent.
> nextFilter.messageSent(session, ((TransformedWriteRequest) 
> request).getWriteRequest());
> return;
> }
> ..
> }
> private static class TransformedWriteRequest extends WriteRequestWrapper {
> private TransformedWriteRequest(WriteRequest req) {
> super(req);
> }
> public Object getMessage() {
> // Wrapping with TransformedWriteRequest is actually unwrapping 
> the message.
> // and unwrapping this write request is actually wrapping the 
> message back.
> return ((OuterMessage) super.getMessage()).getInnerMessage();
> }
> }

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

[jira] Closed: (DIRMINA-370) More atomic operations for user defined session attributes.


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

Emmanuel Lecharny closed DIRMINA-370.
-


> More atomic operations for user defined session attributes.
> ---
>
> Key: DIRMINA-370
> URL: https://issues.apache.org/jira/browse/DIRMINA-370
> Project: MINA
>  Issue Type: New Feature
>  Components: Core
>Reporter: Trustin Lee
>Assignee: Trustin Lee
>Priority: Trivial
> Fix For: 2.0.0-M1
>
>
> MINA 1.1 and above uses ConcurrentHashMap in IoSession.  ConcurrentMap has 
> more atomic operations than just Map; replace w/ oldValue, remove w/ value, 
> and putIfAbsent.  We could expose these operations in IoSession, too.
> A good example of the usage of these methods is 
> ProtocolCodecFilter.getDecoderLock().
> private Object getDecoderLock( IoSession session )
> {
> Object lock = session.getAttribute( DECODER_LOCK );
> if( lock == null )
> {
> lock = new Object();
> session.setAttribute( DECODER_LOCK, lock );
> }
> return lock;
> }
> We could remove the possibility of returning different locks without a 
> synchronized block.
> private Object getDecoderLock( IoSession session )
> {
> Object lock = session.getAttribute( DECODER_LOCK );
> if( lock == null )
> {
> session.setAttributeIfAbsent( DECODER_LOCK, new Object() );
> lock = session.getAttribute( DECODER_LOCK );
> }
> return lock;
> }

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

[jira] Closed: (DIRMINA-382) Provide a close() method that doesn't close the connection until all messages are written.


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

Emmanuel Lecharny closed DIRMINA-382.
-


> Provide a close() method that doesn't close the connection until all messages 
> are written.
> --
>
> Key: DIRMINA-382
> URL: https://issues.apache.org/jira/browse/DIRMINA-382
> Project: MINA
>  Issue Type: New Feature
>  Components: Core
>Reporter: Trustin Lee
>Assignee: Trustin Lee
> Fix For: 2.0.0-M1
>
>
> Currently, IoSession.close() closes the connection immediately no matter how 
> many messages are not written yet.  Calling close() will discard all pending 
> writes and close the connection immediately.  Although we can add a 
> IoFutureListener.CLOSE to the last WriteFuture, it will be more convenient to 
> provide another close method that doesn't close the connection until all 
> message are written.  
> Adding a boolean parameter to the close method will be fine. Of course, 
> original method without a parameter will be retained.
> To implement this, the implementation should satisfy the following condition.
> 1) IoSession.isClosing() must return true after close() is called no matter 
> what boolean parameter is specified.
> 2) The session should be closed after all messages are written out.

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

[jira] Closed: (DIRMINA-385) SSLFilter starts writing to session before filter chain is complete


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

Emmanuel Lecharny closed DIRMINA-385.
-


> SSLFilter starts writing to session before filter chain is complete
> ---
>
> Key: DIRMINA-385
> URL: https://issues.apache.org/jira/browse/DIRMINA-385
> Project: MINA
>  Issue Type: Bug
>  Components: Filter
>Affects Versions: 1.0.3, 1.1.0
>Reporter: Chris Audley
>Assignee: Trustin Lee
> Fix For: 2.0.0-M1
>
> Attachments: SSLFilter-1.1.0.patch, SSLFilter-HEAD.patch
>
>
> The SSLFilter starts to write packets to the session as soon as it is added 
> to the filter chain (in onPostAdd).  However, this can result in errors if a 
> filter exists or is added before SSLFilter in the processing order. Writing 
> to the session in onPostAdd should be considered breaking the contract 
> between filters and the session.
> If a filter is added in the processing order before the SSLFilter, but after 
> the SSLFilter has been added, SSLFilter will have already sent some messages 
> that the newly added filter will never have the opportunity to process.  Any 
> subsequent SSLFilter messages *will* be processed by the newly added filter, 
> potentially creating inconsistencies.
> Even if the filter before the SSLFilter in processing order is added before 
> the SSLFilter is added, having SSLFilter send messages in onPostAdd ignores 
> the possibility that the other filter needs to send and/or receive messages 
> before the connection is considered open by later filters in the chain.
> The specific circumstances of my problem is a web proxy traversal filter that 
> needs to be placed in front of the SSLFilter in order to function correctly.  
> This filter is responsible for sending the CONNECT message to the proxy to 
> open an outside connection before the SSL session is negotiated.  With the 
> current behavior of SSLFilter, this is simply not possible.
> I have created a patch for SSLFilter that moves the code for initiated the 
> handshake to sessionOpened.  This works correctly in my situation, but breaks 
> the case where an SSLFilter is added to the chain after the connection is 
> opened.  I try to address this by adding a conditional handshake initiation 
> to onPostAdd only if the session is already connected.  Unfortunately, the 
> IoSession.isConnected() method only indicates if the session hasn't been 
> closed.  What SSLFilter.onPostAdd() needs is a way to determine if the 
> sessionOpened event for the session has been fired.  My patches disable the 
> code in onPostAdd() until isConnected or another method is able to provide 
> the necessary information.

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

[jira] Closed: (DIRMINA-393) Allow users to choose a Map implementation for storing session attributes.


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

Emmanuel Lecharny closed DIRMINA-393.
-


> Allow users to choose a Map implementation for storing session attributes.
> --
>
> Key: DIRMINA-393
> URL: https://issues.apache.org/jira/browse/DIRMINA-393
> Project: MINA
>  Issue Type: New Feature
>  Components: Core
>Reporter: Trustin Lee
>Assignee: Trustin Lee
>Priority: Minor
> Fix For: 2.0.0-M1
>
>
> Currently, users don't have any control over how session attributes are 
> stored and managed.  Adding SessionAttributesMapFactory property to IoService 
> will give more control to the users, although we will have to provide the 
> best generic implementation.

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

[jira] Closed: (DIRMINA-400) Selective event processing in ExecutorFilter


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

Emmanuel Lecharny closed DIRMINA-400.
-


> Selective event processing in ExecutorFilter
> 
>
> Key: DIRMINA-400
> URL: https://issues.apache.org/jira/browse/DIRMINA-400
> Project: MINA
>  Issue Type: New Feature
>  Components: Filter
>Reporter: Trustin Lee
>Assignee: Trustin Lee
> Fix For: 2.0.0-M1
>
>
> Previous implementation of ExecutorFilter forwarded only sessionOpened, 
> sessionIdle, sessionClosed, messageReceived and messageSent events to the 
> executor.  It often becomes a cause of resource contention for other I/O 
> events such as filterWrite.
> If we can provide a set of event types that has to be forwarded to the 
> executor, we will be able to apply more sophisticated thread model.  The 
> following is a typical usage example:
> chain.addLast("executor1", new ExecutorFilter());  // Default behavior of 
> ExecutorFilter will be retained.
> chain.addLast("codec", new ProtocolCodecFilter(...));
> chain.addLast("logger", new LoggingFilter());
> chain.addLast("executor2", new ExecutorFilter(IoEventType.WRITE, 
> IoEventType.CLOSE));

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

[jira] Closed: (DIRMINA-432) IoService method for writing Object to all the managed IoSession


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

Emmanuel Lecharny closed DIRMINA-432.
-


> IoService method for writing Object to all the managed IoSession
> 
>
> Key: DIRMINA-432
> URL: https://issues.apache.org/jira/browse/DIRMINA-432
> Project: MINA
>  Issue Type: New Feature
>  Components: Core
>Reporter: Julien Vermillard
>Assignee: Trustin Lee
>Priority: Trivial
> Fix For: 2.0.0-M1
>
>
> Would be convenient to ad a method to IoService for writing a message to all 
> the managed sessions.
> in IoService : 
> public WriteFuture writeAllSession(Object message);
> the implementation could be done in AbstractIoService.

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

[jira] Closed: (DIRMINA-420) Missing Class in latest maven snapshot


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

Emmanuel Lecharny closed DIRMINA-420.
-


> Missing Class in latest maven snapshot
> --
>
> Key: DIRMINA-420
> URL: https://issues.apache.org/jira/browse/DIRMINA-420
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 2.0.0-M1
>Reporter: Goran Oberg
>Priority: Critical
> Fix For: 2.0.0-M1
>
>
> Latest maven  Mina 2.0.0 M1 snapshot Jar doesn't contain the SessionLog class
> java.lang.NoClassDefFoundError: org/apache/mina/util/SessionLog
>   at org.apache.mina.filter.SSLFilter.sessionClosed(SSLFilter.java:393)
>   at 
> org.apache.mina.common.AbstractIoFilterChain.callNextSessionClosed(AbstractIoFilterChain.java:320)

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

[jira] Closed: (DIRMINA-428) Message priorities


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

Emmanuel Lecharny closed DIRMINA-428.
-


> Message priorities
> --
>
> Key: DIRMINA-428
> URL: https://issues.apache.org/jira/browse/DIRMINA-428
> Project: MINA
>  Issue Type: New Feature
>  Components: Core
>Reporter: Adrian Sandor
>Assignee: Trustin Lee
> Fix For: 2.0.0-M1
>
>
> I would like MINA to support sending messages with different priorities, so 
> that higher-priority messages will get sent out first (in the order that they 
> were added to the queue, if they have the same priority)
> Here's how I think this could be implemented:
> - define different priorities; I suggest using numeric constants, such as 
> LOWEST=0, LOW=25, NORMAL=50, HIGH=75, HIGHEST=100, allowing any custom values 
> from 0 to 100
> - add a priority field to WriteRequest, and implement Comparable using it
> - add a write(Object message, int priority) method to IoSession
> - make write(message) call write(message, NORMAL)
> - make the writeRequestQueue in the session implementations a priority queue, 
> but one that preserves the original order of "equal" elements
> - ensure that a higher priority message won't interrupt sending out another 
> message (if pending)
> - if desired, write an IoFilter that can manipulate the priority

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

[jira] Closed: (DIRMINA-422) a new IoFilter that leverages SLF4J's MDC feature


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

Emmanuel Lecharny closed DIRMINA-422.
-


> a new IoFilter that leverages SLF4J's MDC feature
> -
>
> Key: DIRMINA-422
> URL: https://issues.apache.org/jira/browse/DIRMINA-422
> Project: MINA
>  Issue Type: New Feature
>  Components: Filter
>Reporter: Maarten Bosteels
>Assignee: Maarten Bosteels
>Priority: Minor
> Fix For: 2.0.0-M1
>
>
> A logging filter that puts some basic info about the IoSession in the MDC 
> (Mapped Diagnostic Context)
> has the advantage that all logging events down the call stack include this 
> info.
> Even if those log events are generated by code that is not aware of MINA at 
> all.

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

[jira] Closed: (DIRMINA-433) Http codec needs to properly handle the Host header


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

Emmanuel Lecharny closed DIRMINA-433.
-


> Http codec needs to properly handle the Host header
> ---
>
> Key: DIRMINA-433
> URL: https://issues.apache.org/jira/browse/DIRMINA-433
> Project: MINA
>  Issue Type: Bug
>  Components: Filter
>Affects Versions: 2.0.0-M1
>Reporter: Jeff Genender
>Assignee: Mark Webb
> Fix For: 2.0.0-M1
>
> Attachments: DIRMINA-433.jgenender.patch
>
>
> Via the Http spec, the HTTP/1.1 spec needs to have a "Host" line. Currently 
> the code in the HttpRequestEncoder is not testing for default ports or the -1 
> for a port that is a default for a port not set on a URL.
> Patch attached

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

[jira] Closed: (DIRMINA-440) Consistent naming style for acronyms (SSL, HTTP, MDC, IO, ...)


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

Emmanuel Lecharny closed DIRMINA-440.
-


> Consistent naming style for acronyms (SSL, HTTP, MDC, IO, ...)
> --
>
> Key: DIRMINA-440
> URL: https://issues.apache.org/jira/browse/DIRMINA-440
> Project: MINA
>  Issue Type: Improvement
>Reporter: Trustin Lee
>Assignee: Trustin Lee
>Priority: Trivial
> Fix For: 2.0.0-M1
>
>
> As discussed here:
> http://www.nabble.com/-Poll--Naming-style-for-acronyms-tf4467353s16868.html
> We decided to use a capital letter only for the initial letter of an acronym.

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

[jira] Closed: (DIRMINA-445) SessionLog improvement


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

Emmanuel Lecharny closed DIRMINA-445.
-


> SessionLog improvement
> --
>
> Key: DIRMINA-445
> URL: https://issues.apache.org/jira/browse/DIRMINA-445
> Project: MINA
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 1.1.3, 2.0.0-M1
> Environment: Use Object instead of String inSessionLog logging method 
> to allow for massive perfs improvement on production running instances (when 
> logs filtering is used).
>Reporter: vincent bourdaraud
>Assignee: Maarten Bosteels
>Priority: Minor
> Fix For: 2.0.0-M1
>
>
> SessionLog.debug(IoSession,String), info(IoSession,String), 
> warn(IoSession,String) and error(IoSession,String) should be changed to 
> SessionLog.debug(IoSession,Object), info(IoSession,Object), 
> warn(IoSession,Object) and error(IoSession,Object), as in log4j.
> The reason for this is that if passing Objects instead of String allow to 
> delay the composition of the logging message (.toString() call) until really 
> needed and that could greatly improve performance. This kind of feature is 
> needed to build SW able to be turned in debug while in production using 
> NDC/MDC filters (using log4j e.g.).
> Some code snippet the illustrate this:
> public void messageReceived(IoSession session, Object o) throws Exception
> {
>MyProtocolRequest req = (MyProtocolRequest) o;
>NDC.put(req.getUserId());
>SessionLog.debug(session, new RequestDumper(req));
>NDC.pop();
> }
>
> class RequestDumper()
> {
> public RequestDumper(MyProtocolRequest req)
> {
> this.req = req;
> }
> 
> public String toString()
> {
> return req.toString();
> }
> 
> private MyProtocolRequest req;
> }
> In that snippet, the cost of converting MyProtocolRequest to a String is not 
> paied when SessionLog.debug() is called, but when the underlying logging 
> framework needs the string for logging. The perf improvement could be massive 
> if the underlying protocol uses some kind of filtering to filter-out most 
> debug logs; in that example, the logging framework would be configured to 
> filter-in only logs with a NDC set to a specific user.
> With this feature, we could enable debug in production for some few users 
> only, without killing the overall performances.

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

[jira] Closed: (DIRMINA-439) DemuxingProtocolEncoder and DemuxingProtocolDecoder by refactoring DemuxingProtocolCodecFactory


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

Emmanuel Lecharny closed DIRMINA-439.
-


> DemuxingProtocolEncoder and DemuxingProtocolDecoder by refactoring 
> DemuxingProtocolCodecFactory
> ---
>
> Key: DIRMINA-439
> URL: https://issues.apache.org/jira/browse/DIRMINA-439
> Project: MINA
>  Issue Type: New Feature
>  Components: Filter
>Reporter: Trustin Lee
>Assignee: Trustin Lee
>Priority: Minor
> Fix For: 2.0.0-M1
>
>
> DemuxingProtocolCodecFactory is somewhat monolithic and needs polishing.  It 
> would be more elegant to provide DemuxingProtocolEncoder and 
> DemuxingProtocolDecoder separately, and to implement 
> DemuxingProtocolCodecFactory by combining the two.

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

[jira] Closed: (DIRMINA-434) Cookies need to handle domain


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

Emmanuel Lecharny closed DIRMINA-434.
-


> Cookies need to handle domain
> -
>
> Key: DIRMINA-434
> URL: https://issues.apache.org/jira/browse/DIRMINA-434
> Project: MINA
>  Issue Type: Bug
>  Components: Filter
>Affects Versions: 2.0.0-M1
>Reporter: Jeff Genender
>Assignee: Mark Webb
> Fix For: 2.0.0-M1
>
> Attachments: DIRMINA-434.jgenender.patch
>
>
> The cookie handler currently does not handle the domain.
> Patch attached.

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

[jira] Closed: (DIRMINA-456) Provide mechanism for detecting a dead lock caused by calling IoFuture.await() in an I/O processor thread.


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

Emmanuel Lecharny closed DIRMINA-456.
-


> Provide mechanism for detecting a dead lock caused by calling 
> IoFuture.await() in an I/O processor thread.
> --
>
> Key: DIRMINA-456
> URL: https://issues.apache.org/jira/browse/DIRMINA-456
> Project: MINA
>  Issue Type: Improvement
>  Components: Core
>Reporter: Mike Heath
>Assignee: Trustin Lee
>Priority: Minor
> Fix For: 2.0.0-M1
>
>
> As described in this thread http://tinyurl.com/3cwkb3, we need to provide 
> support for flushing the session's write queue from the 
> IoHandler.messageRecieved() method.

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

[jira] Closed: (DIRMINA-463) Find the best way to specify both MINA and non-MINA events.


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

Emmanuel Lecharny closed DIRMINA-463.
-


> Find the best way to specify both MINA and non-MINA events.
> ---
>
> Key: DIRMINA-463
> URL: https://issues.apache.org/jira/browse/DIRMINA-463
> Project: MINA
>  Issue Type: Task
>  Components: Statemachine
>Reporter: Trustin Lee
>Assignee: Niklas Therning
>Priority: Minor
> Fix For: 2.0.0-M1
>
>
> As discussed here: http://tinyurl.com/2omrl9
> For now, we use String to identify event types, which is somewhat unsafe.  
> Using an enum might be useful, but there are a few disadvantages:
> * Wildcard event type cannot be used, which could be extended further (e.g. 
> "message*" or "session(Opened|Closed)")
> Probably sticking to String might be the best solution? :)

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

[jira] Closed: (DIRMINA-467) IoFilter has to filter a setTrafficMask call.


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

Emmanuel Lecharny closed DIRMINA-467.
-


> IoFilter has to filter a setTrafficMask call.
> -
>
> Key: DIRMINA-467
> URL: https://issues.apache.org/jira/browse/DIRMINA-467
> Project: MINA
>  Issue Type: New Feature
>  Components: Core
>Affects Versions: 2.0.0-M1
>Reporter: Trustin Lee
>Assignee: Trustin Lee
> Fix For: 2.0.0-M1
>
>
> So far, setTrafficMask operation (such as suspend/resume Read/Write) was 
> treated differently from other session operations such as close and write.  
> It simply bypassed IoFilterChain, so no IoFilter implementation was able to 
> override the operation.  An IoFilter can suspend and resume traffic by 
> calling IoSession.setTrafficMask(), but it can be simply overridden by a user 
> request, which subverts the filter implementation.
> For example, ReadThrottleFilter will not work as expected if a user changes 
> the traffic mask randomly.
> Another reason for supporting setTrafficMask filtering is that it makes more 
> than one traffic-controlling filters harmonize with each other instead of 
> breaking each other.  For example, TrafficShapingFilter and 
> ReadThrottleFilter could be added to one filter chain, and both filters will 
> want to suspend incoming traffic if any condition doesn't meet and resume if 
> all conditions meet.  Without setTrafficMask filtering, two filters will have 
> to be tightly coupled to adjust the traffic mask carefully.  With proper 
> setTrafficMasek filtering support, such a tight coupling is unnecessary 
> because any filter can override the traffic mask in a filter chain.  An 
> IoFilter which is placed in front of other filters will have precedence in 
> traffic control.
> Adding this feature means that we have to add some facility like we did for 
> write operations (IoFilter.filterWrite, WriteFuture and WriteRequest), which 
> breaks backward compatibility of an IoFilter.  I think it's OK because we 
> have broken the backward compatibility of IoFilter long time ago. ;)

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

[jira] Closed: (DIRMINA-464) Provide better way to throttle read buffer.


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

Emmanuel Lecharny closed DIRMINA-464.
-


> Provide better way to throttle read buffer.
> ---
>
> Key: DIRMINA-464
> URL: https://issues.apache.org/jira/browse/DIRMINA-464
> Project: MINA
>  Issue Type: Task
>  Components: Filter
>Reporter: Trustin Lee
>Assignee: Trustin Lee
>Priority: Critical
> Fix For: 2.0.0-M1
>
>
> 1.x provides ReadThrottleFilterBuilder for throttling read operation to 
> prevent OOM.  It works pretty well only in a certain configuration; only when 
> all the filters are placed *after* an ExecutorFilter.  For example, it 
> doesn't work at all if ProtocolCodecFilter is placed before ExecutorFilter.  
> We need to provide more robust solution for throttling I/O events.  Please 
> note this issue is for read operations.  Write operations will be taken care 
> of in DIRMINA-302.

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

[jira] Closed: (DIRMINA-475) Include various throughputs to the default performance statistics.


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

Emmanuel Lecharny closed DIRMINA-475.
-


> Include various throughputs to the default performance statistics.
> --
>
> Key: DIRMINA-475
> URL: https://issues.apache.org/jira/browse/DIRMINA-475
> Project: MINA
>  Issue Type: New Feature
>  Components: Core
>Affects Versions: 2.0.0-M1
>Reporter: Trustin Lee
>Assignee: Trustin Lee
>Priority: Minor
> Fix For: 2.0.0-M1
>
>
> For now, read/write throughputs are calculated from a separate thread managed 
> by IoStatisticsCollector.  However, all these values can be calculated very 
> easily in an I/O processor.  I think there's no reason to provide those 
> numbers as a separate class.

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

[jira] Closed: (DIRMINA-471) Reduce SSL buffers overhead


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

Emmanuel Lecharny closed DIRMINA-471.
-


> Reduce SSL buffers overhead
> ---
>
> Key: DIRMINA-471
> URL: https://issues.apache.org/jira/browse/DIRMINA-471
> Project: MINA
>  Issue Type: Improvement
>  Components: Filter
>Affects Versions: 1.0.7, 1.1.4
> Environment: NA
>Reporter: Michael Matovsky
>Assignee: Trustin Lee
> Fix For: 2.0.0-M1
>
>
> There is a significant overhead for SSL connections.
> Investigation shows that every SSL connection requires an SSLHandler, which 
> contains 3 buffers:
> - Two buffers for encrypted inbound and outbound packets, respectively.
> - One buffer for decrypted application data
> The buffer sizes are computed as follows:
> Packet buffer size = the current size of the largest SSL/TLS packet that is 
> expected when using this session (SSLSession.packetBufferSize())
> Application buffer size = 2 x packet buffer size
> In Sun JSSE the SSLSession.packetBufferSize() equals to 16K, which implies a 
> total of 64K SSL buffer space per connection. For 10K active this means that 
> 640MB of memory is required just for SSL buffers.
> Such overhead really limits the number of concurrent connections an 
> application can support. 
> A possible resolution is to dynamically re-adjusting the buffer capacity, and 
> allowing to configure the initial buffer sizes.

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

[jira] Closed: (DIRMINA-476) Revamp JMX integration


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

Emmanuel Lecharny closed DIRMINA-476.
-


> Revamp JMX integration
> --
>
> Key: DIRMINA-476
> URL: https://issues.apache.org/jira/browse/DIRMINA-476
> Project: MINA
>  Issue Type: New Feature
>  Components: Integration
>Reporter: Trustin Lee
>Assignee: Trustin Lee
>Priority: Minor
> Fix For: 2.0.0-M1
>
>
> Once DIRMINA-475 is resolved, we won't need org.apache.mina.management 
> package at all, and JMX integration will become cleaner.

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

[jira] Closed: (DIRMINA-490) Add a getSlice(int) method to IoBuffer


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

Emmanuel Lecharny closed DIRMINA-490.
-


> Add a getSlice(int) method to IoBuffer
> --
>
> Key: DIRMINA-490
> URL: https://issues.apache.org/jira/browse/DIRMINA-490
> Project: MINA
>  Issue Type: New Feature
>  Components: Core
>Reporter: David M. Lloyd
>Assignee: Trustin Lee
>Priority: Minor
> Fix For: 2.0.0-M1
>
> Attachments: getSlice.patch
>
>
> Add a method to IoBuffer that lets you read a given number of bytes, 
> returning those bytes as a slice IoBuffer.
> Enclosed is a simple patch to do this.  This method can be implemented 
> completely in terms of other IoBuffer methods; therefore it can go on the 
> IoBuffer base class without affecting other subclasses.

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

[jira] Closed: (DIRMINA-493) SingleSessionIoHandlerFactory.getHandler(IoSession) should throw IOException or Exception


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

Emmanuel Lecharny closed DIRMINA-493.
-


> SingleSessionIoHandlerFactory.getHandler(IoSession) should throw IOException 
> or Exception
> -
>
> Key: DIRMINA-493
> URL: https://issues.apache.org/jira/browse/DIRMINA-493
> Project: MINA
>  Issue Type: Improvement
>  Components: Core
>Reporter: David M. Lloyd
>Assignee: Trustin Lee
>Priority: Minor
> Fix For: 2.0.0-M1
>
> Attachments: SingleSessionIoHandler.patch
>
>
> Since the only place that this method is used is within a method that throws 
> Exception, the method should be allowed to throw Exception or IoException.  
> This makes life easier if the creation of the session could fail, for example 
> creating an ObjectOutputStream which could throw IOException.

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

[jira] Closed: (DIRMINA-517) MINA HTTP codec handles HTTP 100 Continue improperly


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

Emmanuel Lecharny closed DIRMINA-517.
-


> MINA HTTP codec handles HTTP 100 Continue improperly
> 
>
> Key: DIRMINA-517
> URL: https://issues.apache.org/jira/browse/DIRMINA-517
> Project: MINA
>  Issue Type: Bug
>  Components: Protocol - HTTP
>Affects Versions: 2.0.0-M1
> Environment: MINA from public repository revision 613995
>Reporter: Tuure Laurinolli
>Assignee: Trustin Lee
> Fix For: 2.0.0-M1
>
> Attachments: 100-continue.patch
>
>
> MINA HTTP codec assumes that HTTP/1.1 100 Continue responses can have a body, 
> and decodes the final response that follows the interim Continue response as 
> the body of the Continue response.
> This can be fixed by recognizing that 100 Continue responses MUST NOTt have a 
> body (end of section 4.3 of RFC 2616), skipping over their headers and 
> processing teh following final response as if no 100 Continue response had 
> ever existed. I will attach a patch with proof-of-concept implementation that 
> decodes the responses I originally encountered the problem with (I cannot 
> provide the responses as-is, but if needed, I can provide something).

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

[jira] Closed: (DIRMINA-513) get rid of IoSessionLogger


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

Emmanuel Lecharny closed DIRMINA-513.
-


> get rid of IoSessionLogger 
> ---
>
> Key: DIRMINA-513
> URL: https://issues.apache.org/jira/browse/DIRMINA-513
> Project: MINA
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.0.0-M1
>Reporter: Maarten Bosteels
>Assignee: Maarten Bosteels
>Priority: Minor
> Fix For: 2.0.0-M1
>
>
> It seems like the next version of SLF4J is going to support MDC for  
> java.util.logging 
> The users who use java.util.logging as their logging framework will have 
> access to MDC
> so that they can implement a formatter which prints out the MDC content. 
> This means we can get rid of IoSessionLogger completely and rely on 
> MdcInjectionFilter
> However, probably SLF4J won't provide a MDC-aware Formatter implementation 
> for java.util.logging, so we might need to include it
> in org.apache.mina.util package as an alternative solution.

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

[jira] Closed: (DIRMINA-503) NioProcessor.transferFile needs to catch IOException on Linux


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

Emmanuel Lecharny closed DIRMINA-503.
-


> NioProcessor.transferFile needs to catch IOException on Linux
> -
>
> Key: DIRMINA-503
> URL: https://issues.apache.org/jira/browse/DIRMINA-503
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.0.0-M1
> Environment: Linux 2.6.22 Sun JDK 1.6.0_03
>Reporter: Geoff Cadien
>Assignee: Mike Heath
>Priority: Critical
> Fix For: 2.0.0-M1
>
>
> Under Linux FileChannel.transferTo throws an IOException when the socket send 
> buffer is full.  This causes the sending of a FileRegion to fail.  Here is 
> the bug report http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5103988  
> Even though it is marked as fixed it continues to exist.

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

[jira] Closed: (DIRMINA-504) Allow ProtocolEncoder to generate non-IoBuffer objects


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

Emmanuel Lecharny closed DIRMINA-504.
-


> Allow ProtocolEncoder to generate non-IoBuffer objects
> --
>
> Key: DIRMINA-504
> URL: https://issues.apache.org/jira/browse/DIRMINA-504
> Project: MINA
>  Issue Type: Improvement
>  Components: Filter
>Reporter: Trustin Lee
>Assignee: Trustin Lee
> Fix For: 2.0.0-M1
>
>
> For now, ProtocolEncoderOutput.write() accepts only IoBuffer as a parameter, 
> and therefore a user cannot generate FileRegion or any other kind of object 
> for multi-layered protocols.  ProtocolEncoderOutput.write() should accept any 
> object to remove this limitation.  Additionally, 
> ProtocolEncoderOutput.mergeAll() should perform sanity check before merging 
> IoBuffers because the content of the queue might be mixed up with IoBuffers 
> and non-IoBuffers.

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

[jira] Closed: (DIRMINA-498) Incorrect Javadoc for IoServiceListener


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

Emmanuel Lecharny closed DIRMINA-498.
-


> Incorrect Javadoc for IoServiceListener
> ---
>
> Key: DIRMINA-498
> URL: https://issues.apache.org/jira/browse/DIRMINA-498
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.0.0-M1
>Reporter: Rich Dougherty
>Assignee: Trustin Lee
>Priority: Trivial
> Fix For: 2.0.0-M1
>
> Attachments: ioservicelistener-javadoc.patch
>
>
> The Javadoc for IoServiceListener is currently incorrect. It currently has 
> identical text to that of IoFutureListener.

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

[jira] Closed: (DIRMINA-524) ProtocolCodecFilter should pass FileRegion to nextFilter in addition to IoBuffer


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

Emmanuel Lecharny closed DIRMINA-524.
-


> ProtocolCodecFilter should pass FileRegion to nextFilter in addition to 
> IoBuffer
> 
>
> Key: DIRMINA-524
> URL: https://issues.apache.org/jira/browse/DIRMINA-524
> Project: MINA
>  Issue Type: Bug
>  Components: Filter
> Environment: jdk1.6.0_03 Linux x64
>Reporter: Geoff Cadien
> Fix For: 2.0.0-M1
>
>
> ProtocolCodecFilter.filterWrite calls nextFilter.filterWrite directly without 
> invoking the ProtocolEncoder if the WriteRequest message is an IoBuffer.  It 
> should do the same if the message is a FileRegion.
> Here is a quick patch:
> Index: ProtocolCodecFilter.java
> ===
> --- ProtocolCodecFilter.java(revision 617648)
> +++ ProtocolCodecFilter.java(working copy)
> @@ -25,6 +25,7 @@
>  import org.apache.mina.common.AttributeKey;
>  import org.apache.mina.common.DefaultWriteFuture;
>  import org.apache.mina.common.DefaultWriteRequest;
> +import org.apache.mina.common.FileRegion;
>  import org.apache.mina.common.IoBuffer;
>  import org.apache.mina.common.IoFilter;
>  import org.apache.mina.common.IoFilterAdapter;
> @@ -222,7 +223,7 @@
>  public void filterWrite(NextFilter nextFilter, IoSession session,
>  WriteRequest writeRequest) throws Exception {
>  Object message = writeRequest.getMessage();
> -if (message instanceof IoBuffer) {
> +if (message instanceof IoBuffer || message instanceof FileRegion) {
>  nextFilter.filterWrite(session, writeRequest);
>  return;
>  }

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

[jira] Closed: (DIRMINA-525) AbstractIoSession.increaseWrittenBytesAndMessages does not update writtenBytes for FileRegion


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

Emmanuel Lecharny closed DIRMINA-525.
-


> AbstractIoSession.increaseWrittenBytesAndMessages does not update 
> writtenBytes for FileRegion
> -
>
> Key: DIRMINA-525
> URL: https://issues.apache.org/jira/browse/DIRMINA-525
> Project: MINA
>  Issue Type: Bug
>  Components: Core
> Environment: jdk1.6.0_03 Linux x64
>Reporter: Geoff Cadien
>Assignee: Mike Heath
> Fix For: 2.0.0-M1
>
>
> AbstractIoSession.increaseWrittenBytesAndMessages only updates 
> writtenMessages and not writtenBytes for a FileRegion.  
> Below is a patch that fixes the problem but I'm not sure if it is correct.  
> When the WriteRequest contains an IoBuffer a check is made to see if the 
> IoBuffer has any remaining bytes and only updates writtenBytes if it does.  
> I've never seen this method called when only part of a FileRegion is sent and 
> I'm sure how it could be because it seems that 
> increaseWrittenBytesAndMessages is only called from fireMessageSent.
> Index: AbstractIoSession.java
> ===
> --- AbstractIoSession.java  (revision 616815)
> +++ AbstractIoSession.java  (working copy)
> @@ -541,6 +541,12 @@
>  } else {
>  increaseWrittenMessages(currentTime);
>  }
> +} else if (message instanceof FileRegion) {
> +FileRegion region = (FileRegion) message;
> +if (region.getCount() == 0) {
> +increaseWrittenBytes(region.getWrittenBytes(), currentTime);
> +increaseWrittenMessages(currentTime);
> +} 
>  } else {
>  increaseWrittenMessages(currentTime);
>  }

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

Re: [VOTE] Release MINA 2.0.0-M6


My vote ...

[X] +1: Yes, release MINA-2.0.0-M6
  

--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re : [VOTE] Release MINA 2.0.0-M6

2009-05-26 Thread Edouard De Oliveira


[X] +1: Yes, release MINA-2.0.0-M6

and +1 assembly plugin is deeply bugged ;(

 Cordialement, Regards,
-Edouard De Oliveira-
Blog: http://tedorgwp.free.fr
WebSite: http://tedorg.free.fr/en/main.php



- Message d'origine 
De : Ashish 
À : dev@mina.apache.org
Envoyé le : Mardi, 26 Mai 2009, 15h24mn 58s
Objet : Re: [VOTE] Release MINA 2.0.0-M6

[X ] +1: Yes, release MINA-2.0.0-M6

On Tue, May 26, 2009 at 6:38 PM, Emmanuel Lecharny  wrote:
> Hi,
>
> it was expected to be available last week, sorry for the delay.
>
> Here is an official vote for a 2.0.0-M6 mina release, which fixes a few but
> serious issues, including one major regression I injected in the code.
>
> The code has been moved to a branch, on revision 778682 :
> http://svn.apache.org/viewvc/mina/branches/mina-2.0.0-M6/
>
> I didn't produced any package, as the mavn assembly plugin is deeply bugged
> (http://mail-archives.apache.org/mod_mbox/maven-users/200709.mbox/%3c9ab4ff82-4097-4391-b1dc-9c7a7217d...@commonjava.org%3e)
>
> [ ] +1: Yes, release MINA-2.0.0-M6
> [ ] +/- 0 : I don't have any opinion
> [ ] -1  : No, it's not ready
>
>
>
> Thanks !
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>



-- 
thanks
ashish

Blog: http://www.ashishpaliwal.com/blog
My Photo Galleries: http://www.pbase.com/ashishpaliwal

Re: [VOTE] Release MINA 2.0.0-M6

2009-05-26 Thread Ashish

[X ] +1: Yes, release MINA-2.0.0-M6

On Tue, May 26, 2009 at 6:38 PM, Emmanuel Lecharny  wrote:
> Hi,
>
> it was expected to be available last week, sorry for the delay.
>
> Here is an official vote for a 2.0.0-M6 mina release, which fixes a few but
> serious issues, including one major regression I injected in the code.
>
> The code has been moved to a branch, on revision 778682 :
> http://svn.apache.org/viewvc/mina/branches/mina-2.0.0-M6/
>
> I didn't produced any package, as the mavn assembly plugin is deeply bugged
> (http://mail-archives.apache.org/mod_mbox/maven-users/200709.mbox/%3c9ab4ff82-4097-4391-b1dc-9c7a7217d...@commonjava.org%3e)
>
> [ ] +1    : Yes, release MINA-2.0.0-M6
> [ ] +/- 0 : I don't have any opinion
> [ ] -1      : No, it's not ready
>
>
>
> Thanks !
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>



-- 
thanks
ashish

Blog: http://www.ashishpaliwal.com/blog
My Photo Galleries: http://www.pbase.com/ashishpaliwal

Re: [VOTE] Release MINA 2.0.0-M6

Le Tue, 26 May 2009 15:08:54 +0200,
Emmanuel Lecharny  a écrit :

> Hi,
> 
> it was expected to be available last week, sorry for the delay.
> 
> Here is an official vote for a 2.0.0-M6 mina release, which fixes a
> few but serious issues, including one major regression I injected in
> the code.
> 
> The code has been moved to a branch, on revision 778682 :
> http://svn.apache.org/viewvc/mina/branches/mina-2.0.0-M6/
> 
> I didn't produced any package, as the mavn assembly plugin is deeply 
> bugged 
> (http://mail-archives.apache.org/mod_mbox/maven-users/200709.mbox/%3c9ab4ff82-4097-4391-b1dc-9c7a7217d...@commonjava.org%3e)
> 

[X] +1: Yes, release MINA-2.0.0-M6
[ ] +/- 0 : I don't have any opinion
[ ] -1  : No, it's not ready

Julien


signature.asc
Description: PGP signature

[VOTE] Release MINA 2.0.0-M6


Hi,

it was expected to be available last week, sorry for the delay.

Here is an official vote for a 2.0.0-M6 mina release, which fixes a few 
but serious issues, including one major regression I injected in the code.


The code has been moved to a branch, on revision 778682 :
http://svn.apache.org/viewvc/mina/branches/mina-2.0.0-M6/

I didn't produced any package, as the mavn assembly plugin is deeply 
bugged 
(http://mail-archives.apache.org/mod_mbox/maven-users/200709.mbox/%3c9ab4ff82-4097-4391-b1dc-9c7a7217d...@commonjava.org%3e)


[ ] +1: Yes, release MINA-2.0.0-M6
[ ] +/- 0 : I don't have any opinion
[ ] -1  : No, it's not ready



Thanks !

--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

[jira] Closed: (VYSPER-47) IP: update/adopt the existing Vysper crypto notice

2009-05-26 Thread Julien Vermillard (JIRA)


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

Julien Vermillard closed VYSPER-47.
---

Resolution: Fixed

Done, will show up at :
http://www.apache.org/licenses/exports/
when the mirrors are updated.

> IP: update/adopt the existing Vysper crypto notice
> --
>
> Key: VYSPER-47
> URL: https://issues.apache.org/jira/browse/VYSPER-47
> Project: VYSPER
>  Issue Type: Sub-task
>Reporter: Bernd Fondermann
>Assignee: Julien Vermillard
>


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

Re: [jira] Commented: (FTPSERVER-306) some clients won't transform NEW LINE characters to \r\n when sending in ASCII mode so after sending a file the new lines will be gone.

On Tue, May 26, 2009 at 12:38 PM, Sai Pullabhotla
 wrote:
>>> when FtpServer receives a file in ASCII mode our current code replaces \r
> for \r\n and ignores \n, but since it seems FileZilla
>>> doesn't transform new lines to \r\n  we will never find a \r and the new
> line characters will be silently ignored.
>
> Hmm... shouldn't it be just doing the following:
>
> 1. Replace \r\n with System.getProperty("line.separator");
> 2. Write everything else as is.

Agreed. However, that's not what we currently do since if the client
only sends \n we will strip out the line ending. This is a bug on our
side that we should fix. You can probably agrue that FileZilla is
doing the right thing as \r is probably not to be regarded as the
"internal character representation" (as described in the RFC) on
Windows.

Anyways, we should add a bunch of tests for this and fix.

/niklas

Re: [jira] Commented: (FTPSERVER-306) some clients won't transform NEW LINE characters to \r\n when sending in ASCII mode so after sending a file the new lines will be gone.

2009-05-26 Thread Sai Pullabhotla

>> when FtpServer receives a file in ASCII mode our current code replaces \r
for \r\n and ignores \n, but since it seems FileZilla
>> doesn't transform new lines to \r\n  we will never find a \r and the new
line characters will be silently ignored.

Hmm... shouldn't it be just doing the following:

1. Replace \r\n with System.getProperty("line.separator");
2. Write everything else as is.

Sai Pullabhotla
www.jMethods.com



On Tue, May 26, 2009 at 2:34 AM, David Latorre (JIRA) wrote:

>
>[
> https://issues.apache.org/jira/browse/FTPSERVER-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12712889#action_12712889]
>
> David Latorre commented on FTPSERVER-306:
> -
>
> Sending a file  with \n separated lines  in ASCII mode with FileZilla for
> windows will result in a file with no new lines:
>
>  when FtpServer receives a file in ASCII mode our current code replaces \r
> for \r\n and ignores \n, but since it seems FileZilla doesn't transform new
> lines to \r\n  we will never find a \r and the new line characters will be
> silently ignored.
>
> This is a bug in Filezilla (Might be because im sending "Unix" files from
> windows)   but I doubt every other client is performing this transformation.
> So, when we find a \n we should check if last character was \r and otherwise
> insert the new line sequence.
>
>
>
>
>
>
> > some clients won't  transform NEW LINE characters to \r\n when sending in
> ASCII mode so after sending a file the new lines will be gone.
> >
> -
> >
> > Key: FTPSERVER-306
> > URL: https://issues.apache.org/jira/browse/FTPSERVER-306
> > Project: FtpServer
> >  Issue Type: Improvement
> >Reporter: David Latorre
> >
>
>
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>
>

Re: [Vysper] Moving to the Maven build

On Tue, May 26, 2009 at 12:12 PM, Ashish  wrote:
> +1 to drop Ant build, if we are able to run the specs compliance from it.

Yes, it should be working (I've ran some basic tests of it).

> BTW, did the commons folks liked the proposal of spec package being
> moved to commons ??

I have not asked yet, let me get to that later today.

/niklas

Re: [Vysper] Moving to the Maven build

2009-05-26 Thread Ashish

+1 to drop Ant build, if we are able to run the specs compliance from it.

BTW, did the commons folks liked the proposal of spec package being
moved to commons ??

thanks
ashish

On Tue, May 26, 2009 at 3:38 PM, Julien Vermillard
 wrote:
> Le Tue, 26 May 2009 11:57:55 +0200,
> Emmanuel Lecharny  a écrit :
>
>> Niklas Gustavsson wrote:
>> > Hi
>> >
>> > Should we drop the Vysper Ant build in favour of the Maven build?
>> > Right now we have two build systems to maintain, which will cause
>> > confusion and end up being out of sync. Do we need a vote for this,
>> > or should we just svn del build.xml?
>> >
>> I don't think we need a vote, just an agreement from Bernd. I would
>> favor a maven build and a removal of the ant build. It will allow us
>> to remove the libs rom svn too.
>> My 2cts ...
>>
>
> +1
> Julien
>



-- 
thanks
ashish

Blog: http://www.ashishpaliwal.com/blog
My Photo Galleries: http://www.pbase.com/ashishpaliwal

Re: [Vysper] Moving to the Maven build

Le Tue, 26 May 2009 11:57:55 +0200,
Emmanuel Lecharny  a écrit :

> Niklas Gustavsson wrote:
> > Hi
> >
> > Should we drop the Vysper Ant build in favour of the Maven build?
> > Right now we have two build systems to maintain, which will cause
> > confusion and end up being out of sync. Do we need a vote for this,
> > or should we just svn del build.xml?
> >   
> I don't think we need a vote, just an agreement from Bernd. I would 
> favor a maven build and a removal of the ant build. It will allow us
> to remove the libs rom svn too.
> My 2cts ...
> 

+1
Julien


signature.asc
Description: PGP signature

Re: [Vysper] Moving to the Maven build


Niklas Gustavsson wrote:

Hi

Should we drop the Vysper Ant build in favour of the Maven build?
Right now we have two build systems to maintain, which will cause
confusion and end up being out of sync. Do we need a vote for this, or
should we just svn del build.xml?
  
I don't think we need a vote, just an agreement from Bernd. I would 
favor a maven build and a removal of the ant build. It will allow us to 
remove the libs rom svn too.

My 2cts ...

--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: Re : Preparing a 2.0.0-M6 release


Edouard De Oliveira wrote:

As i had some time this week end and was interested in testing the release 
process. I gave it a try ...
Under latest eclipse 3.5M7 + M2eclipse plugin : failure -> i thought it was 
probably due to the maven plugin ...

So I downloaded maven 2.1.0 and followed the instructions on the web site -> 
failure at the assembly step
as i was under winXP i thought it may have something with my OS.
So i downloaded an Ubuntu 9.0.4 and after some hours of 'Oh my gods where are 
my *Nix skills gone' i finally ran the build to end up with the same failure :

[ERROR] BUILD ERROR
[INFO] 
[INFO] Failed to create assembly: Artifact:
org.apache.mina:mina-core:bundle:2.0.0-M6-SNAPSHOT (included by module)
does not have an artifact with a file. Please ensure the package phase
is run before the assembly is generated.

So i'm doing something wrong ? 
  

No.  It's a referenced Mavn bug :
http://mail-archives.apache.org/mod_mbox/maven-users/200709.mbox/%3c9ab4ff82-4097-4391-b1dc-9c7a7217d...@commonjava.org%3e

Pretty painfull though ... I will try to create a new module to 
workaround the bug.


--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

[Vysper] Moving to the Maven build

Hi

Should we drop the Vysper Ant build in favour of the Maven build?
Right now we have two build systems to maintain, which will cause
confusion and end up being out of sync. Do we need a vote for this, or
should we just svn del build.xml?

/niklas

Re: [vysper] Any reason to still use an antic version of MINA?

Le Tue, 26 May 2009 11:34:17 +0200,
Bernd Fondermann  a écrit :

> Emmanuel Lecharny wrote:
> > Hi guys,
> > 
> > even if VYSPER is still based on 1.1 version instead of 2.0, can't
> > we bump up the version from 1.1.0 to 1.1.7?
> 
> +1, there you go... ;-)
> 
>   Bernd
> 
> 
Done
updated the build.xml & lib/ 
It's still used ?? Because the BCversion in lib & build.xml is not the
same as the pom.xml one (upgraded by Emm I think)
Julien


signature.asc
Description: PGP signature

Re: [vysper] Any reason to still use an antic version of MINA?

2009-05-26 Thread Bernd Fondermann

Emmanuel Lecharny wrote:
> Hi guys,
> 
> even if VYSPER is still based on 1.1 version instead of 2.0, can't we
> bump up the version from 1.1.0 to 1.1.7?

+1, there you go... ;-)

  Bernd

Re: [vysper] Any reason to still use an antic version of MINA?

Le Tue, 26 May 2009 11:13:22 +0200,
Emmanuel Lecharny  a écrit :

> Hi guys,
> 
> even if VYSPER is still based on 1.1 version instead of 2.0, can't we 
> bump up the version from 1.1.0 to 1.1.7?
> 
I tried modifying it in the pom, worked.
Since it's mainly bugfixe let's me commit the change.
Julien


signature.asc
Description: PGP signature

[vysper] Any reason to still use an antic version of MINA?


Hi guys,

even if VYSPER is still based on 1.1 version instead of 2.0, can't we 
bump up the version from 1.1.0 to 1.1.7?


--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

[jira] Commented: (VYSPER-47) IP: update/adopt the existing Vysper crypto notice