[jira] Assigned: (DIRMINA-299) innacurate JMX statistics

[Julien Vermillard (JIRA)]

 [ http://issues.apache.org/jira/browse/DIRMINA-299?page=all ]

Julien Vermillard reassigned DIRMINA-299:
-

Assignee: Julien Vermillard

> innacurate JMX statistics
> -
>
> Key: DIRMINA-299
> URL: http://issues.apache.org/jira/browse/DIRMINA-299
> Project: Directory MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.1
> Environment: Fedora Core 5, Eclipse 3.2 using Java 1.4 compiler 
> settings.
>Reporter: Mark Webb
> Assigned To: Julien Vermillard
>Priority: Minor
> Attachments: jmx.diff
>
>
> The  class org.apache.mina.integration.jmx.IoServiceManager computes the 
> bytes read/written using the service's managed sessions using the method 
> IoService.getManagedSessions().  This method returns a java.util.Set object, 
> which only contains the sessions currently active.  
> The IoServiceManager class uses org.apache.mina.management.StatCollector 
> class to assist with tracking data throughput.  The StatCollector class only 
> operates on active sessions.
> The problem is that the values returned from the managed bean interface is 
> computed only on the currently active sessions.  Based on the names of the 
> methods, the values returned should be running totals, to include sessions 
> that are no longer active.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DIRMINA-299) innacurate JMX statistics

[Julien Vermillard (JIRA)]

[ 
http://issues.apache.org/jira/browse/DIRMINA-299?page=comments#action_12449996 
] 

Julien Vermillard commented on DIRMINA-299:
---

good patch, fixing the problem with bytes not added to the stats when the 
session close, but it's also removing per session statistics which is used for  
 connected prtocols with long session lifetime.
I'm going to work on a compromise for keep per session stats.
It's definitively a bug affecting 1.0 and later versions.

> innacurate JMX statistics
> -
>
> Key: DIRMINA-299
> URL: http://issues.apache.org/jira/browse/DIRMINA-299
> Project: Directory MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.1
> Environment: Fedora Core 5, Eclipse 3.2 using Java 1.4 compiler 
> settings.
>Reporter: Mark Webb
> Assigned To: Julien Vermillard
>Priority: Minor
> Attachments: jmx.diff
>
>
> The  class org.apache.mina.integration.jmx.IoServiceManager computes the 
> bytes read/written using the service's managed sessions using the method 
> IoService.getManagedSessions().  This method returns a java.util.Set object, 
> which only contains the sessions currently active.  
> The IoServiceManager class uses org.apache.mina.management.StatCollector 
> class to assist with tracking data throughput.  The StatCollector class only 
> operates on active sessions.
> The problem is that the values returned from the managed bean interface is 
> computed only on the currently active sessions.  Based on the names of the 
> methods, the values returned should be running totals, to include sessions 
> that are no longer active.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (DIRMINA-299) innacurate JMX statistics

[Julien Vermillard (JIRA)]

 [ http://issues.apache.org/jira/browse/DIRMINA-299?page=all ]

Julien Vermillard resolved DIRMINA-299.
---

Fix Version/s: 1.0.1
   1.1
   Resolution: Fixed

the patch had a few bug, like not computing the time between last session 
polling and session closing and other issues but the idea was correct. A side 
effect, watching serivce average and total throughput will prolly be less CPU 
intensive.

Commited in 1.0, 1.2 and trunk branches

> innacurate JMX statistics
> -
>
> Key: DIRMINA-299
> URL: http://issues.apache.org/jira/browse/DIRMINA-299
> Project: Directory MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.1
> Environment: Fedora Core 5, Eclipse 3.2 using Java 1.4 compiler 
> settings.
>Reporter: Mark Webb
> Assigned To: Julien Vermillard
>Priority: Minor
> Fix For: 1.0.1, 1.1
>
> Attachments: jmx.diff
>
>
> The  class org.apache.mina.integration.jmx.IoServiceManager computes the 
> bytes read/written using the service's managed sessions using the method 
> IoService.getManagedSessions().  This method returns a java.util.Set object, 
> which only contains the sessions currently active.  
> The IoServiceManager class uses org.apache.mina.management.StatCollector 
> class to assist with tracking data throughput.  The StatCollector class only 
> operates on active sessions.
> The problem is that the values returned from the managed bean interface is 
> computed only on the currently active sessions.  Based on the names of the 
> methods, the values returned should be running totals, to include sessions 
> that are no longer active.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Reopened: (DIRMINA-299) innacurate JMX statistics

[Julien Vermillard (JIRA)]

 [ http://issues.apache.org/jira/browse/DIRMINA-299?page=all ]

Julien Vermillard reopened DIRMINA-299:
---

 
You got a test case so I can try to debug it ?


> innacurate JMX statistics
> -
>
> Key: DIRMINA-299
> URL: http://issues.apache.org/jira/browse/DIRMINA-299
> Project: Directory MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.1
> Environment: Fedora Core 5, Eclipse 3.2 using Java 1.4 compiler 
> settings.
>Reporter: Mark Webb
> Assigned To: Julien Vermillard
>Priority: Minor
> Fix For: 1.1, 1.0.1
>
> Attachments: jmx.diff
>
>
> The  class org.apache.mina.integration.jmx.IoServiceManager computes the 
> bytes read/written using the service's managed sessions using the method 
> IoService.getManagedSessions().  This method returns a java.util.Set object, 
> which only contains the sessions currently active.  
> The IoServiceManager class uses org.apache.mina.management.StatCollector 
> class to assist with tracking data throughput.  The StatCollector class only 
> operates on active sessions.
> The problem is that the values returned from the managed bean interface is 
> computed only on the currently active sessions.  Based on the names of the 
> methods, the values returned should be running totals, to include sessions 
> that are no longer active.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (DIRMINA-299) innacurate JMX statistics

[Julien Vermillard (JIRA)]

 [ http://issues.apache.org/jira/browse/DIRMINA-299?page=all ]

Julien Vermillard resolved DIRMINA-299.
---

Fix Version/s: 2.0
   Resolution: Fixed

fixed, 
note : average  fields for stateless IoService will display inccorect value, 
because the numer of opened session is nearly zero, all the time.

> innacurate JMX statistics
> -
>
> Key: DIRMINA-299
> URL: http://issues.apache.org/jira/browse/DIRMINA-299
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.1
> Environment: Fedora Core 5, Eclipse 3.2 using Java 1.4 compiler 
> settings.
>Reporter: Mark Webb
> Assigned To: Julien Vermillard
>Priority: Minor
> Fix For: 1.0.1, 1.1, 2.0
>
> Attachments: HttpProtocolHandler.java, jmx.diff, JmxTestMain.java
>
>
> The  class org.apache.mina.integration.jmx.IoServiceManager computes the 
> bytes read/written using the service's managed sessions using the method 
> IoService.getManagedSessions().  This method returns a java.util.Set object, 
> which only contains the sessions currently active.  
> The IoServiceManager class uses org.apache.mina.management.StatCollector 
> class to assist with tracking data throughput.  The StatCollector class only 
> operates on active sessions.
> The problem is that the values returned from the managed bean interface is 
> computed only on the currently active sessions.  Based on the names of the 
> methods, the values returned should be running totals, to include sessions 
> that are no longer active.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Reopened: (DIRMINA-16) org.apache.mina.common.TransportType

[Julien Vermillard (JIRA)]

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

Julien Vermillard reopened DIRMINA-16:
--


Well it's still problematic in trunk for creating a separate package for Serial 
communications

> org.apache.mina.common.TransportType
> 
>
> Key: DIRMINA-16
> URL: https://issues.apache.org/jira/browse/DIRMINA-16
> Project: MINA
>  Issue Type: Improvement
> Environment: Improve TransportType for permit to extend MINA 
> supported transport types
>Reporter: Julien Vermillard
> Assigned To: Trustin Lee
> Fix For: 0.7
>
>
> the TransportType define the differents TransportType in MINA 
> (Socket,Datagram, VM Pipe). The types are static and hardcoded. The 
> constructor of Transport type is private. It leave no room for new Transport.
> I propose : 
> 1st  : change the transportType constructor visibility to public
> 2snd : move the staticly defined TransportTypes to the different io.datagram, 
> io.socket, etc.. packages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DIRMINA-331) StatCollector is not thread safe and some stats are being mixed up

[Julien Vermillard (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464122
 ] 

Julien Vermillard commented on DIRMINA-331:
---

Thanks for this patch, I'm reviewing it now, 
first comments :

easly fixable :
- code style is not the good one for 1.X branch, I know it's annoying :o)
- it's using java.util.concurrent in place of the backport

more problematic :
- it's preventing HTTP like protocols to calculate an average session 
throughput  
- doesn't give per service instantaneous throughtput stats, but total values 
(service life wide total)
- adding ScheduledWrites and QueuedEvents is a good idea but doesn't give those 
stats for the polling period, but again a total value

> StatCollector is not thread safe and some stats are being mixed up
> --
>
> Key: DIRMINA-331
> URL: https://issues.apache.org/jira/browse/DIRMINA-331
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.0.1
>Reporter: Gaston Dombiak
> Fix For: 1.1
>
>
> The instance variable polledSessions is not thread-safe (i.e. uses ArrayList) 
> and its access is not always protected (e.g. StatCollector$Worker#run()). 
> Under  heavy load this is producing an error in the Worker.
> The bytesReadThroughput statistic is incorrectly being set. It is adding up 
> the throughput of written messages.
> Instance variables: msgWrittenThroughput, msgReadThroughput, 
> bytesWrittenThroughputand bytesReadThroughput could be corrupted and return 
> an unexpected value since they are not thread safe and 2 different threads 
> may be changing them.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DIRMINA-16) org.apache.mina.common.TransportType

[Julien Vermillard (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465404
 ] 

Julien Vermillard commented on DIRMINA-16:
--

so far I understand MINA's behaviour, it's looking like a good solution, and 
going to a simplify a little

> org.apache.mina.common.TransportType
> 
>
> Key: DIRMINA-16
> URL: https://issues.apache.org/jira/browse/DIRMINA-16
> Project: MINA
>  Issue Type: Improvement
> Environment: Improve TransportType for permit to extend MINA 
> supported transport types
>Reporter: Julien Vermillard
> Assigned To: Trustin Lee
> Fix For: 0.7
>
>
> the TransportType define the differents TransportType in MINA 
> (Socket,Datagram, VM Pipe). The types are static and hardcoded. The 
> constructor of Transport type is private. It leave no room for new Transport.
> I propose : 
> 1st  : change the transportType constructor visibility to public
> 2snd : move the staticly defined TransportTypes to the different io.datagram, 
> io.socket, etc.. packages

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[Julien Vermillard (JIRA)]

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

Work on DIRMINA-34 started by Julien Vermillard.

> 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
> Assigned To: Julien Vermillard
>
> 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] Assigned: (DIRMINA-34) New transport type: Java Communications API

[Julien Vermillard (JIRA)]

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

Julien Vermillard reassigned DIRMINA-34:


Assignee: Julien Vermillard

> 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
> Assigned To: Julien Vermillard
>
> 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] Updated: (DIRMINA-34) New transport type: Java Communications API

[Julien Vermillard (JIRA)]

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

Julien Vermillard updated DIRMINA-34:
-

Fix Version/s: 2.0.0-M1

> 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
> Assigned To: 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] Commented: (DIRMINA-34) New transport type: Java Communications API

[Julien Vermillard (JIRA)]

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

Julien Vermillard commented on DIRMINA-34:
--

A version working with MINA trunk and rxtx.org is on subversion repository on 
my sandbox : mina/sandbox/jvermillard/serial.
There is a SerialConnector for SerialAdress, wich provide SerialSession (with 
IDLEness managed).

Feedback are very welcome before starting merging to trunk !

> 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
> Assigned To: 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] Resolved: (DIRMINA-34) New transport type: Java Communications API

[Julien Vermillard (JIRA)]

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

Julien Vermillard resolved DIRMINA-34.
--

Resolution: Fixed

Just uploaded as a new module (transport-serial).
It's not building by default (you need to give "-Dwith-serial" to mvn command 
line), until rxtx libs are uploaded to maven repository.

> 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
> Assigned To: 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] Commented: (DIRMINA-372) Generics support for IoHandler

[Julien Vermillard (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491282
 ] 

Julien Vermillard commented on DIRMINA-372:
---

why not, but if some codec produce Object of different types without a common 
super-type ?

> Generics support for IoHandler
> --
>
> Key: DIRMINA-372
> URL: https://issues.apache.org/jira/browse/DIRMINA-372
> Project: MINA
>  Issue Type: Improvement
>Affects Versions: 1.1.0
>Reporter: Eero Nevalainen
>Priority: Minor
> Fix For: 1.1.1, 2.0.0-M1
>
>
> It would be nice to have generics support for IoHandler so that 
> messageReceived and messageSent would be called with the appropriate generic 
> types.

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

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

[Julien Vermillard (JIRA)]

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: Improvement
  Components: Core
Affects Versions: 1.1.2, 1.0.5, 1.1.1, 1.0.4, 1.1.0, 1.0.3, 1.0.2, 1.0.1, 
1.0.0, 0.9.5, 0.9.4, 0.9.3, 0.9.2, 0.9.1, 0.9.0, 0.8.4, 0.8.3, 0.8.2, 0.8.1, 
0.8.0, 0.7.4, 0.7.3, 0.7.2, 0.7.1, 0.7.0, 1.0.6, 1.1.3, 2.0.0-M1
Reporter: Julien Vermillard
Assignee: Julien Vermillard
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] Commented: (DIRMINA-432) IoService method for writing Object to all the managed IoSession

[Julien Vermillard (JIRA)]

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

Julien Vermillard commented on DIRMINA-432:
---

Why not simply 'write(..)' ?

So we can have :

WriteFuture write(Set sessions,Object message);

and a general broadcast (just a shortcut using the set of managed session as 
first paramaeter):
WriteFuture write(Object messsage);


> 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: Improvement
>  Components: Core
>Affects Versions: 0.7.0, 0.7.1, 0.7.2, 0.7.3, 0.7.4, 0.8.0, 0.8.1, 0.8.2, 
> 0.8.3, 0.8.4, 0.9.0, 0.9.1, 0.9.2, 0.9.3, 0.9.4, 0.9.5, 1.0.0, 1.0.1, 1.0.2, 
> 1.0.3, 1.1.0, 1.0.4, 1.1.1, 1.0.5, 1.1.2, 1.0.6, 1.1.3, 2.0.0-M1
>Reporter: Julien Vermillard
>Assignee: Julien Vermillard
>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] Commented: (DIRMINA-432) IoService method for writing Object to all the managed IoSession

[Julien Vermillard (JIRA)]

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

Julien Vermillard commented on DIRMINA-432:
---

The WriteFuture write(Object messsage); can be placed in IoService, but as 
Trustin thought  write(Set,Object message) need to go to a utility 
class because the set can be composed of session of different IoService.

> 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: Improvement
>  Components: Core
>Affects Versions: 0.7.0, 0.7.1, 0.7.2, 0.7.3, 0.7.4, 0.8.0, 0.8.1, 0.8.2, 
> 0.8.3, 0.8.4, 0.9.0, 0.9.1, 0.9.2, 0.9.3, 0.9.4, 0.9.5, 1.0.0, 1.0.1, 1.0.2, 
> 1.0.3, 1.1.0, 1.0.4, 1.1.1, 1.0.5, 1.1.2, 1.0.6, 1.1.3, 2.0.0-M1
>Reporter: Julien Vermillard
>Assignee: Julien Vermillard
>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] Commented: (DIRMINA-432) IoService method for writing Object to all the managed IoSession

[Julien Vermillard (JIRA)]

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

Julien Vermillard commented on DIRMINA-432:
---

WDYT of adding a class in o.a.mina.common called SessionWriter with the 
folowing static method :
public static WriteFuture write(Set sessions,Object message); 
public static WriteFuture write(IoSession[] sessions,Object message); 


> 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: Improvement
>  Components: Core
>Affects Versions: 0.7.0, 0.7.1, 0.7.2, 0.7.3, 0.7.4, 0.8.0, 0.8.1, 0.8.2, 
> 0.8.3, 0.8.4, 0.9.0, 0.9.1, 0.9.2, 0.9.3, 0.9.4, 0.9.5, 1.0.0, 1.0.1, 1.0.2, 
> 1.0.3, 1.1.0, 1.0.4, 1.1.1, 1.0.5, 1.1.2, 1.0.6, 1.1.3, 2.0.0-M1
>Reporter: Julien Vermillard
>Assignee: Julien Vermillard
>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] Created: (DIRMINA-438) Multicast support for MINA API

[Julien Vermillard (JIRA)]

Multicast support for MINA API 
---

 Key: DIRMINA-438
 URL: https://issues.apache.org/jira/browse/DIRMINA-438
 Project: MINA
  Issue Type: New Feature
  Components: Core
Reporter: Julien Vermillard
Priority: Critical
 Fix For: 2.0.0-M1


For supporting multicast over UDP we need to change the MINA API for
Set the multicast Time to Live (TTL) for a multicast transmission.
Joining a multicast group for a given session.
Leaving a multicast group.

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

[jira] Updated: (DIRMINA-442) high cpu load (50% cpu on dual core) with only one active connection

[Julien Vermillard (JIRA)]

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

Julien Vermillard updated DIRMINA-442:
--


Can you try with lastest trunk ? we messed some stuff in the IoProcessing.

> high cpu load (50% cpu on dual core) with only one active connection
> 
>
> Key: DIRMINA-442
> URL: https://issues.apache.org/jira/browse/DIRMINA-442
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.0.0-M1
> Environment: 1) Fresh mina built from trunk (revision 577654)
> 2) Windows XP SP2 (reproduced also on Win2k server)
> 3) java version "1.6.0_02"
> Java(TM) SE Runtime Environment (build 1.6.0_02-b06)
> Java HotSpot(TM) Client VM (build 1.6.0_02-b06, mixed mode, sharing)
>Reporter: Dmitry V. Zemnitskiy
>Priority: Critical
> Attachments: echo.hprof
>
>
> I've noticed that even single connection causes mina server to enter tight 
> loop in 
> sun.nio.ch.WindowsSelectorImpl$SubSelector.poll0
> This leads to immediately increase CPU load to 50% of my dual core cpu (Intel 
> core duo)
> on win2k with 1cpu process consumes even more (70%-80% CPU)
> Reproduction is very simple:
> 1) checkout mina from trunk and build it using maven
> 2) run echo server:
> java -agentlib:hprof=cpu=samples,file=echo.hprof -classpath 
> mina-core-2.0.0-M1-SNAPSHOT.jar;mina-example-2.0.0-M1-SNAPSHOT.jar;slf4j-api-1.4.3.jar;slf4j-log4j12-1.4.3.jar;log4j-1.2.14.jar
> org.apache.mina.example.echoserver.Main
> 3) telnet localhost 8080
> 4) type one character in telnet window
> 5) CPU load immediately increased to 50%
> I'll attach hprof dump to this issue

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

[jira] Updated: (DIRMINA-442) high cpu load (50% cpu on dual core) with only one active connection

[Julien Vermillard (JIRA)]

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

Julien Vermillard updated DIRMINA-442:
--


you tried a mvn clean ?
because I have test errors, but no compiling error

> high cpu load (50% cpu on dual core) with only one active connection
> 
>
> Key: DIRMINA-442
> URL: https://issues.apache.org/jira/browse/DIRMINA-442
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.0.0-M1
> Environment: 1) Fresh mina built from trunk (revision 577654)
> 2) Windows XP SP2 (reproduced also on Win2k server)
> 3) java version "1.6.0_02"
> Java(TM) SE Runtime Environment (build 1.6.0_02-b06)
> Java HotSpot(TM) Client VM (build 1.6.0_02-b06, mixed mode, sharing)
>Reporter: Dmitry V. Zemnitskiy
>Priority: Critical
> Attachments: echo.hprof
>
>
> I've noticed that even single connection causes mina server to enter tight 
> loop in 
> sun.nio.ch.WindowsSelectorImpl$SubSelector.poll0
> This leads to immediately increase CPU load to 50% of my dual core cpu (Intel 
> core duo)
> on win2k with 1cpu process consumes even more (70%-80% CPU)
> Reproduction is very simple:
> 1) checkout mina from trunk and build it using maven
> 2) run echo server:
> java -agentlib:hprof=cpu=samples,file=echo.hprof -classpath 
> mina-core-2.0.0-M1-SNAPSHOT.jar;mina-example-2.0.0-M1-SNAPSHOT.jar;slf4j-api-1.4.3.jar;slf4j-log4j12-1.4.3.jar;log4j-1.2.14.jar
> org.apache.mina.example.echoserver.Main
> 3) telnet localhost 8080
> 4) type one character in telnet window
> 5) CPU load immediately increased to 50%
> I'll attach hprof dump to this issue

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

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

[Julien Vermillard (JIRA)]

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

Julien Vermillard commented on DIRMINA-438:
---

Yes, but we need to modify IoSession API for add a generic multicast support

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

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

[jira] Commented: (DIRMINA-455) Add XBean tag to sources to enable XBean based configuration

[Julien Vermillard (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533973
 ] 

Julien Vermillard commented on DIRMINA-455:
---

I suppose it's need to be done on TRUNK ? if so we should re-open this issue.

> Add XBean tag to sources to enable XBean based configuration
> 
>
> Key: DIRMINA-455
> URL: https://issues.apache.org/jira/browse/DIRMINA-455
> Project: MINA
>  Issue Type: Improvement
>  Components: Core, Filter
>Reporter: Alex Karasulu
>Assignee: Alex Karasulu
> Fix For: 1.1.4
>
>
> The following tag when added to the javadocs enables XBean based 
> configuration of the MINA components with absolutely no effect on the 
> operation of MINA:
>  * @org.apache.xbean.XBean
> Adding this will enable MINA users that use the Spring integration classes to 
> optionally make their spring application configurations much more succinct.  
> For more information please see http://geronimo.apache.org/xbean/.

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

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

[Julien Vermillard (JIRA)]

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

Julien Vermillard updated DIRMINA-438:
--


I agree the API impact will be minimal, I think we can do it when I block some 
time for finishing APR support.

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

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

[jira] Created: (DIRMINA-506) Incomplete demelinter match can produce unseen token in TextLineDecoder

[Julien Vermillard (JIRA)]

Incomplete demelinter match can produce unseen token in TextLineDecoder
---

 Key: DIRMINA-506
 URL: https://issues.apache.org/jira/browse/DIRMINA-506
 Project: MINA
  Issue Type: Bug
  Components: Filter
Affects Versions: 1.1.5, 1.0.8, 1.1.4, 1.0.7, 1.1.3, 1.0.6, 1.1.2, 1.0.5, 
1.1.1, 1.0.4, 1.1.0, 1.0.3, 1.0.2, 1.0.1, 1.0.0, 0.9.5, 0.9.4, 0.9.3, 0.9.2, 
0.9.1, 0.9.0, 0.8.4, 0.8.3, 0.8.2, 0.8.1, 0.8.0, 0.7.4, 0.7.3, 0.7.2, 0.7.1, 
0.7.0, 1.0.9, 1.1.6, 2.0.0-M1, 2.0.0-M2
Reporter: Julien Vermillard
Assignee: Julien Vermillard
 Fix For: 1.0.9, 1.1.6, 2.0.0-M1


The following will not be correctly
interpreted by the decoder using \r\n as the LineDelimiter

This is some text\r\r\n

See : http://www.nabble.com/TextLineDecoder-bug-tp14563042s16868p14563042.html

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

[jira] Closed: (DIRMINA-506) Incomplete demelinter match can produce unseen token in TextLineDecoder

[Julien Vermillard (JIRA)]

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

Julien Vermillard closed DIRMINA-506.
-

Resolution: Fixed

fixed

> Incomplete demelinter match can produce unseen token in TextLineDecoder
> ---
>
> Key: DIRMINA-506
> URL: https://issues.apache.org/jira/browse/DIRMINA-506
> Project: MINA
>  Issue Type: Bug
>  Components: Filter
>Affects Versions: 0.7.0, 0.7.1, 0.7.2, 0.7.3, 0.7.4, 0.8.0, 0.8.1, 0.8.2, 
> 0.8.3, 0.8.4, 0.9.0, 0.9.1, 0.9.2, 0.9.3, 0.9.4, 0.9.5, 1.0.0, 1.0.1, 1.0.2, 
> 1.0.3, 1.1.0, 1.0.4, 1.1.1, 1.0.5, 1.1.2, 1.0.6, 1.1.3, 1.0.7, 1.1.4, 1.0.8, 
> 1.1.5, 1.0.9, 1.1.6, 2.0.0-M1, 2.0.0-M2
>Reporter: Julien Vermillard
>Assignee: Julien Vermillard
> Fix For: 1.0.9, 1.1.6, 2.0.0-M1
>
>
> The following will not be correctly
> interpreted by the decoder using \r\n as the LineDelimiter
> This is some text\r\r\n
> See : http://www.nabble.com/TextLineDecoder-bug-tp14563042s16868p14563042.html

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

[jira] Commented: (ASYNCWEB-11) HttpResponseDecoder not finishing decode process before some content is received

[Julien Vermillard (JIRA)]

[ 
https://issues.apache.org/jira/browse/ASYNCWEB-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591943#action_12591943
 ] 

Julien Vermillard commented on ASYNCWEB-11:
---

I tried decoding this response, It's producing an endless loop, it's looking 
serious.

Thanks for the report

> HttpResponseDecoder not finishing decode process before some content is 
> received
> 
>
> Key: ASYNCWEB-11
> URL: https://issues.apache.org/jira/browse/ASYNCWEB-11
> Project: Asyncweb
>  Issue Type: Bug
>  Components: Common
> Environment: FCGIHttpService
>Reporter: Daniel Wirtz
>Priority: Trivial
>
> Basically I transform FastCGI responses into HTTP responses using the 
> HttpResponseDecoder in conjunction with AsyncFCGI (0.9.0 CVS):
> public void onReceive(FCGIRequest request, FCGIResponse response) {
>   HttpServiceContext context = (HttpServiceContext) request.getAttachment();
>   HttpResponseDecoder decoder = new HttpResponseDecoder();
>   DecoderOutput output = new DecoderOutput(context); // Custom output 
> implementing a write() method
>   decoder.decode(null, IoBuffer.wrap("HTTP/1.1 200 OK\r\n".getBytes()), 
> output);
>   decoder.decode(null, response.getStdout(), output);
>   decoder.finishDecode(null, output); // HttpResonse is produced and sent to 
> DecoderOutput
>   decoder.dispose(null);
> }
> This works fine so far, but when an empty response (in this case produced by 
> PHP is received), no write() to DecoderOutput occurs even though the 
> finishDecode() method was called. The response looks like this:
> Content-Type: text/html\r\n
> \r\n
> As a result of this, I'm not able to use the decoder in this particular case 
> to produce HttpResponse objects for further asyncweb processing originating 
> from a FastCGI backend. The connection just times out because no response is 
> produced. However, if Content-Length: 0 is provided, it works fine (but PHP 
> does not produce this header by default, it is added by the webserver, in 
> this case this would be asyncweb).
> The reason that I don't want to preparse the output by myself is that this 
> results in unneccessary double checking (converting the IoBuffer to something 
> parseable and checking headers twice).

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

[jira] Commented: (ASYNCWEB-11) HttpResponseDecoder not finishing decode process before some content is received

[Julien Vermillard (JIRA)]

[ 
https://issues.apache.org/jira/browse/ASYNCWEB-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591962#action_12591962
 ] 

Julien Vermillard commented on ASYNCWEB-11:
---

heh I'm idiot the endless loop is my buggy test code ;)

What I understand on how the decoder work, it's waiting the session 
disconnection to know where the content finish.


> HttpResponseDecoder not finishing decode process before some content is 
> received
> 
>
> Key: ASYNCWEB-11
> URL: https://issues.apache.org/jira/browse/ASYNCWEB-11
> Project: Asyncweb
>  Issue Type: Bug
>  Components: Common
> Environment: FCGIHttpService
>Reporter: Daniel Wirtz
>Priority: Trivial
>
> Basically I transform FastCGI responses into HTTP responses using the 
> HttpResponseDecoder in conjunction with AsyncFCGI (0.9.0 CVS):
> public void onReceive(FCGIRequest request, FCGIResponse response) {
>   HttpServiceContext context = (HttpServiceContext) request.getAttachment();
>   HttpResponseDecoder decoder = new HttpResponseDecoder();
>   DecoderOutput output = new DecoderOutput(context); // Custom output 
> implementing a write() method
>   decoder.decode(null, IoBuffer.wrap("HTTP/1.1 200 OK\r\n".getBytes()), 
> output);
>   decoder.decode(null, response.getStdout(), output);
>   decoder.finishDecode(null, output); // HttpResonse is produced and sent to 
> DecoderOutput
>   decoder.dispose(null);
> }
> This works fine so far, but when an empty response (in this case produced by 
> PHP is received), no write() to DecoderOutput occurs even though the 
> finishDecode() method was called. The response looks like this:
> Content-Type: text/html\r\n
> \r\n
> As a result of this, I'm not able to use the decoder in this particular case 
> to produce HttpResponse objects for further asyncweb processing originating 
> from a FastCGI backend. The connection just times out because no response is 
> produced. However, if Content-Length: 0 is provided, it works fine (but PHP 
> does not produce this header by default, it is added by the webserver, in 
> this case this would be asyncweb).
> The reason that I don't want to preparse the output by myself is that this 
> results in unneccessary double checking (converting the IoBuffer to something 
> parseable and checking headers twice).

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

[jira] Commented: (ASYNCWEB-12) AsyncWeb does not understand the Status-Header e.g. sent by FastCGI backends.

[Julien Vermillard (JIRA)]

[ 
https://issues.apache.org/jira/browse/ASYNCWEB-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12592296#action_12592296
 ] 

Julien Vermillard commented on ASYNCWEB-12:
---

To make things clear : you parse this fast-cgi reply message with the 
HttpRequestDecoder ?
Is it a usual http server behaviour ? Perhaps  lighthttpd/apache parse it only 
when receiving from fast cgi backend ?


> AsyncWeb does not understand the Status-Header e.g. sent by FastCGI backends.
> -
>
> Key: ASYNCWEB-12
> URL: https://issues.apache.org/jira/browse/ASYNCWEB-12
> Project: Asyncweb
>  Issue Type: Bug
>  Components: Common
> Environment: AsyncWeb 0.9.0 CVS used in AsyncFCGI
>Reporter: Daniel Wirtz
>Priority: Trivial
>
> When a Status header is provided, AsyncWeb does not transform it into the 
> equivalent HTTPStatus in a HttpResponse.
> A response from a FastCGI backend could look like this:
> Content-Type: text/html\r\n
> Status: 404\r\n
> \r\n
> File not found!
> or
> Content-Type: text/html\r\n
> Status: 404 Some Custom Message\r\n
> \r\n
> File not found!
> in PHP this looks like:
> header("404: Some Custom Message"); or
> header("HTTP/1.1 404 Not Found"); etc.
> -> both produce the Status-Header.
> As far as I know the webserver (this would be asyncweb in this case) converts 
> the status header into the correct http status (e.g. "HTTP/1.1 404 Not 
> Found"). I'm using PHP a lot, the status header is the default behaviour and 
> Apache / Lighttpd handle it this way (even with mod_php instead of FastCGI). 
> I don't want to preparse the response because of unneccessary double checking 
> instead of simply feeding it into a HttpResponseDecoder. However, I think the 
> status header is not part of the http specification but since it's used a 
> lot, it would make sence.

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

[jira] Assigned: (ASYNCWEB-13) No possibility to determine server socket in HttpService

[Julien Vermillard (JIRA)]

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

Julien Vermillard reassigned ASYNCWEB-13:
-

Assignee: Julien Vermillard

> No possibility to determine server socket in HttpService
> 
>
> Key: ASYNCWEB-13
> URL: https://issues.apache.org/jira/browse/ASYNCWEB-13
> Project: Asyncweb
>  Issue Type: Improvement
>  Components: Server
> Environment: AsyncWeb 0.9.0-CVS
>Reporter: Daniel Wirtz
>Assignee: Julien Vermillard
>
> I cannot find a possibility to get the server socket's address from a 
> HttpContext object, but a method to get the remote address is present. 
> FastCGI (in this particular case FCGIHttpService) depends on this information 
> for inclusion in the protocol specific SERVER_ADDR and SERVER_PORT parameters.
> public void handleRequest(HttpServiceContext context) throws Exception {
> ...impossible to determine the server socket address on which the request 
> came in to send it with a fastcgi request
> }
> Of course it could be manually set within the HttpService's constructor each 
> time, but when a server listens on more than one address, it will not suffice.
> A solution would be to add a getLocalAddress() (similar to the already 
> existing getRemoteAddress()) method to the HttpContext.

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

[jira] Updated: (ASYNCWEB-13) No possibility to determine server socket in HttpService

[Julien Vermillard (JIRA)]

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

Julien Vermillard updated ASYNCWEB-13:
--

Attachment: patch-ASYNCWEB-13.txt

Due tu current problem with ASF SVN server, here a patch to apply to last 
asyncweb-server module.

ift's adding a getLocalAddress()  to HttpServiceContext

> No possibility to determine server socket in HttpService
> 
>
> Key: ASYNCWEB-13
> URL: https://issues.apache.org/jira/browse/ASYNCWEB-13
> Project: Asyncweb
>  Issue Type: Improvement
>  Components: Server
> Environment: AsyncWeb 0.9.0-CVS
>Reporter: Daniel Wirtz
>Assignee: Julien Vermillard
> Attachments: patch-ASYNCWEB-13.txt
>
>
> I cannot find a possibility to get the server socket's address from a 
> HttpContext object, but a method to get the remote address is present. 
> FastCGI (in this particular case FCGIHttpService) depends on this information 
> for inclusion in the protocol specific SERVER_ADDR and SERVER_PORT parameters.
> public void handleRequest(HttpServiceContext context) throws Exception {
> ...impossible to determine the server socket address on which the request 
> came in to send it with a fastcgi request
> }
> Of course it could be manually set within the HttpService's constructor each 
> time, but when a server listens on more than one address, it will not suffice.
> A solution would be to add a getLocalAddress() (similar to the already 
> existing getRemoteAddress()) method to the HttpContext.

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

[jira] Closed: (ASYNCWEB-12) AsyncWeb does not understand the Status-Header e.g. sent by FastCGI backends.

[Julien Vermillard (JIRA)]

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

Julien Vermillard closed ASYNCWEB-12.
-


> AsyncWeb does not understand the Status-Header e.g. sent by FastCGI backends.
> -
>
> Key: ASYNCWEB-12
> URL: https://issues.apache.org/jira/browse/ASYNCWEB-12
> Project: Asyncweb
>  Issue Type: Bug
>  Components: Common
> Environment: AsyncWeb 0.9.0 CVS used in AsyncFCGI
>Reporter: Daniel Wirtz
>Priority: Trivial
>
> When a Status header is provided, AsyncWeb does not transform it into the 
> equivalent HTTPStatus in a HttpResponse.
> A response from a FastCGI backend could look like this:
> Content-Type: text/html\r\n
> Status: 404\r\n
> \r\n
> File not found!
> or
> Content-Type: text/html\r\n
> Status: 404 Some Custom Message\r\n
> \r\n
> File not found!
> in PHP this looks like:
> header("404: Some Custom Message"); or
> header("HTTP/1.1 404 Not Found"); etc.
> -> both produce the Status-Header.
> As far as I know the webserver (this would be asyncweb in this case) converts 
> the status header into the correct http status (e.g. "HTTP/1.1 404 Not 
> Found"). I'm using PHP a lot, the status header is the default behaviour and 
> Apache / Lighttpd handle it this way (even with mod_php instead of FastCGI). 
> I don't want to preparse the response because of unneccessary double checking 
> instead of simply feeding it into a HttpResponseDecoder. However, I think the 
> status header is not part of the http specification but since it's used a 
> lot, it would make sence.

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

[jira] Created: (DIRMINA-579) ConsumeToEndOfSessionDecodingState not finish decode if the buffer is empty

[Julien Vermillard (JIRA)]

ConsumeToEndOfSessionDecodingState not finish decode if the buffer is empty
---

 Key: DIRMINA-579
 URL: https://issues.apache.org/jira/browse/DIRMINA-579
 Project: MINA
  Issue Type: Bug
  Components: Filter
Affects Versions: 2.0.0-M1, 2.0.0-M2
 Environment: related to issue ASYNCWEB-11
Reporter: Julien Vermillard
Assignee: Julien Vermillard
 Fix For: 2.0.0-M2


ConsumeToEndOfSessionDecodingState wont finish decoding if no data was gathered 
and the internal buffer is null (will produce a NPE exception while 
finishDecode(PrococolDecoderOutput ..) and the NPE will be ignored by 
DecodingStateMachine finishDecode(PrococolDecoderOutput ..).

First : fix the ConsumeToEndOfSessionDecodingState behaviour
Second : investigate why DecodingStateMachine is shallowing important 
exceptions.


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

[jira] Commented: (ASYNCWEB-11) HttpResponseDecoder not finishing decode process before some content is received

[Julien Vermillard (JIRA)]

[ 
https://issues.apache.org/jira/browse/ASYNCWEB-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593749#action_12593749
 ] 

Julien Vermillard commented on ASYNCWEB-11:
---

After some debugging, look like the problem in in the state machine codec 
(ConsumeToEndOfSessionDecodingState), I'm going to open a MINA specific issue 
for that

> HttpResponseDecoder not finishing decode process before some content is 
> received
> 
>
> Key: ASYNCWEB-11
> URL: https://issues.apache.org/jira/browse/ASYNCWEB-11
> Project: Asyncweb
>  Issue Type: Bug
>  Components: Common
> Environment: FCGIHttpService
>Reporter: Daniel Wirtz
>Priority: Trivial
>
> Basically I transform FastCGI responses into HTTP responses using the 
> HttpResponseDecoder in conjunction with AsyncFCGI (0.9.0 CVS):
> public void onReceive(FCGIRequest request, FCGIResponse response) {
>   HttpServiceContext context = (HttpServiceContext) request.getAttachment();
>   HttpResponseDecoder decoder = new HttpResponseDecoder();
>   DecoderOutput output = new DecoderOutput(context); // Custom output 
> implementing a write() method
>   decoder.decode(null, IoBuffer.wrap("HTTP/1.1 200 OK\r\n".getBytes()), 
> output);
>   decoder.decode(null, response.getStdout(), output);
>   decoder.finishDecode(null, output); // HttpResonse is produced and sent to 
> DecoderOutput
>   decoder.dispose(null);
> }
> This works fine so far, but when an empty response (in this case produced by 
> PHP is received), no write() to DecoderOutput occurs even though the 
> finishDecode() method was called. The response looks like this:
> Content-Type: text/html\r\n
> \r\n
> As a result of this, I'm not able to use the decoder in this particular case 
> to produce HttpResponse objects for further asyncweb processing originating 
> from a FastCGI backend. The connection just times out because no response is 
> produced. However, if Content-Length: 0 is provided, it works fine (but PHP 
> does not produce this header by default, it is added by the webserver, in 
> this case this would be asyncweb).
> The reason that I don't want to preparse the output by myself is that this 
> results in unneccessary double checking (converting the IoBuffer to something 
> parseable and checking headers twice).

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

[jira] Commented: (ASYNCWEB-11) HttpResponseDecoder not finishing decode process before some content is received

[Julien Vermillard (JIRA)]

[ 
https://issues.apache.org/jira/browse/ASYNCWEB-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593756#action_12593756
 ] 

Julien Vermillard commented on ASYNCWEB-11:
---

DIRMINA-579 is the key for fixing this issue

> HttpResponseDecoder not finishing decode process before some content is 
> received
> 
>
> Key: ASYNCWEB-11
> URL: https://issues.apache.org/jira/browse/ASYNCWEB-11
> Project: Asyncweb
>  Issue Type: Bug
>  Components: Common
> Environment: FCGIHttpService
>Reporter: Daniel Wirtz
>Priority: Trivial
>
> Basically I transform FastCGI responses into HTTP responses using the 
> HttpResponseDecoder in conjunction with AsyncFCGI (0.9.0 CVS):
> public void onReceive(FCGIRequest request, FCGIResponse response) {
>   HttpServiceContext context = (HttpServiceContext) request.getAttachment();
>   HttpResponseDecoder decoder = new HttpResponseDecoder();
>   DecoderOutput output = new DecoderOutput(context); // Custom output 
> implementing a write() method
>   decoder.decode(null, IoBuffer.wrap("HTTP/1.1 200 OK\r\n".getBytes()), 
> output);
>   decoder.decode(null, response.getStdout(), output);
>   decoder.finishDecode(null, output); // HttpResonse is produced and sent to 
> DecoderOutput
>   decoder.dispose(null);
> }
> This works fine so far, but when an empty response (in this case produced by 
> PHP is received), no write() to DecoderOutput occurs even though the 
> finishDecode() method was called. The response looks like this:
> Content-Type: text/html\r\n
> \r\n
> As a result of this, I'm not able to use the decoder in this particular case 
> to produce HttpResponse objects for further asyncweb processing originating 
> from a FastCGI backend. The connection just times out because no response is 
> produced. However, if Content-Length: 0 is provided, it works fine (but PHP 
> does not produce this header by default, it is added by the webserver, in 
> this case this would be asyncweb).
> The reason that I don't want to preparse the output by myself is that this 
> results in unneccessary double checking (converting the IoBuffer to something 
> parseable and checking headers twice).

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

[jira] Updated: (DIRMINA-579) ConsumeToEndOfSessionDecodingState not finish decode if the buffer is empty

[Julien Vermillard (JIRA)]

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

Julien Vermillard updated DIRMINA-579:
--

Attachment: DIRMINA-579.patch

due to current SVN fubar state, here a patch to apply to mina trunk core 
component 


> ConsumeToEndOfSessionDecodingState not finish decode if the buffer is empty
> ---
>
> Key: DIRMINA-579
> URL: https://issues.apache.org/jira/browse/DIRMINA-579
> Project: MINA
>  Issue Type: Bug
>  Components: Filter
>Affects Versions: 2.0.0-M1, 2.0.0-M2
> Environment: related to issue ASYNCWEB-11
>Reporter: Julien Vermillard
>Assignee: Julien Vermillard
> Fix For: 2.0.0-M2
>
> Attachments: DIRMINA-579.patch
>
>
> ConsumeToEndOfSessionDecodingState wont finish decoding if no data was 
> gathered and the internal buffer is null (will produce a NPE exception while 
> finishDecode(PrococolDecoderOutput ..) and the NPE will be ignored by 
> DecodingStateMachine finishDecode(PrococolDecoderOutput ..).
> First : fix the ConsumeToEndOfSessionDecodingState behaviour
> Second : investigate why DecodingStateMachine is shallowing important 
> exceptions.

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

[jira] Closed: (DIRMINA-579) ConsumeToEndOfSessionDecodingState not finish decode if the buffer is empty

[Julien Vermillard (JIRA)]

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

Julien Vermillard closed DIRMINA-579.
-

Resolution: Fixed

fix commited

> ConsumeToEndOfSessionDecodingState not finish decode if the buffer is empty
> ---
>
> Key: DIRMINA-579
> URL: https://issues.apache.org/jira/browse/DIRMINA-579
> Project: MINA
>  Issue Type: Bug
>  Components: Filter
>Affects Versions: 2.0.0-M1, 2.0.0-M2
> Environment: related to issue ASYNCWEB-11
>Reporter: Julien Vermillard
>Assignee: Julien Vermillard
> Fix For: 2.0.0-M2
>
> Attachments: DIRMINA-579.patch
>
>
> ConsumeToEndOfSessionDecodingState wont finish decoding if no data was 
> gathered and the internal buffer is null (will produce a NPE exception while 
> finishDecode(PrococolDecoderOutput ..) and the NPE will be ignored by 
> DecodingStateMachine finishDecode(PrococolDecoderOutput ..).
> First : fix the ConsumeToEndOfSessionDecodingState behaviour
> Second : investigate why DecodingStateMachine is shallowing important 
> exceptions.

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

[jira] Commented: (ASYNCWEB-13) No possibility to determine server socket in HttpService

[Julien Vermillard (JIRA)]

[ 
https://issues.apache.org/jira/browse/ASYNCWEB-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12597909#action_12597909
 ] 

Julien Vermillard commented on ASYNCWEB-13:
---

commited a fix in Asyncweb trunk server module. can you confirm it's ok for you 
?

> No possibility to determine server socket in HttpService
> 
>
> Key: ASYNCWEB-13
> URL: https://issues.apache.org/jira/browse/ASYNCWEB-13
> Project: Asyncweb
>  Issue Type: Improvement
>  Components: Server
> Environment: AsyncWeb 0.9.0-CVS
>Reporter: Daniel Wirtz
>Assignee: Julien Vermillard
> Attachments: patch-ASYNCWEB-13.txt
>
>
> I cannot find a possibility to get the server socket's address from a 
> HttpContext object, but a method to get the remote address is present. 
> FastCGI (in this particular case FCGIHttpService) depends on this information 
> for inclusion in the protocol specific SERVER_ADDR and SERVER_PORT parameters.
> public void handleRequest(HttpServiceContext context) throws Exception {
> ...impossible to determine the server socket address on which the request 
> came in to send it with a fastcgi request
> }
> Of course it could be manually set within the HttpService's constructor each 
> time, but when a server listens on more than one address, it will not suffice.
> A solution would be to add a getLocalAddress() (similar to the already 
> existing getRemoteAddress()) method to the HttpContext.

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

[jira] Commented: (ASYNCWEB-11) HttpResponseDecoder not finishing decode process before some content is received

[Julien Vermillard (JIRA)]

[ 
https://issues.apache.org/jira/browse/ASYNCWEB-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12597908#action_12597908
 ] 

Julien Vermillard commented on ASYNCWEB-11:
---

commited the fix in MINA trunk, can you confirm it's fixed for you ?

> HttpResponseDecoder not finishing decode process before some content is 
> received
> 
>
> Key: ASYNCWEB-11
> URL: https://issues.apache.org/jira/browse/ASYNCWEB-11
> Project: Asyncweb
>  Issue Type: Bug
>  Components: Common
> Environment: FCGIHttpService
>Reporter: Daniel Wirtz
>Priority: Trivial
>
> Basically I transform FastCGI responses into HTTP responses using the 
> HttpResponseDecoder in conjunction with AsyncFCGI (0.9.0 CVS):
> public void onReceive(FCGIRequest request, FCGIResponse response) {
>   HttpServiceContext context = (HttpServiceContext) request.getAttachment();
>   HttpResponseDecoder decoder = new HttpResponseDecoder();
>   DecoderOutput output = new DecoderOutput(context); // Custom output 
> implementing a write() method
>   decoder.decode(null, IoBuffer.wrap("HTTP/1.1 200 OK\r\n".getBytes()), 
> output);
>   decoder.decode(null, response.getStdout(), output);
>   decoder.finishDecode(null, output); // HttpResonse is produced and sent to 
> DecoderOutput
>   decoder.dispose(null);
> }
> This works fine so far, but when an empty response (in this case produced by 
> PHP is received), no write() to DecoderOutput occurs even though the 
> finishDecode() method was called. The response looks like this:
> Content-Type: text/html\r\n
> \r\n
> As a result of this, I'm not able to use the decoder in this particular case 
> to produce HttpResponse objects for further asyncweb processing originating 
> from a FastCGI backend. The connection just times out because no response is 
> produced. However, if Content-Length: 0 is provided, it works fine (but PHP 
> does not produce this header by default, it is added by the webserver, in 
> this case this would be asyncweb).
> The reason that I don't want to preparse the output by myself is that this 
> results in unneccessary double checking (converting the IoBuffer to something 
> parseable and checking headers twice).

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

[jira] Created: (DIRMINA-600) IoFuture::isReady need to be renamed

[Julien Vermillard (JIRA)]

IoFuture::isReady need to be renamed


 Key: DIRMINA-600
 URL: https://issues.apache.org/jira/browse/DIRMINA-600
 Project: MINA
  Issue Type: Improvement
  Components: Core
Affects Versions: 2.0.0-M1
Reporter: Julien Vermillard
Assignee: Julien Vermillard
 Fix For: 2.0.0-M2


in Iofuture.java :


/**
 * Returns if the asynchronous operation is finished.
 */
boolean isReady();

I think isReady is not the good term, I propose isCompleted (or isFinished) 

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

[jira] Closed: (DIRMINA-599) Lack of ASL 2.0 license header, and generally speaking, Javadoc lacking

[Julien Vermillard (JIRA)]

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

Julien Vermillard closed DIRMINA-599.
-

   Resolution: Fixed
Fix Version/s: 2.0.0-M2

look fixed now, thanks

> Lack of ASL 2.0 license header, and generally speaking, Javadoc lacking
> ---
>
> Key: DIRMINA-599
> URL: https://issues.apache.org/jira/browse/DIRMINA-599
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 2.0.0-M2
>Reporter: Emmanuel Lecharny
>Priority: Blocker
> Fix For: 2.0.0-M2
>
>
> Some files added back in 2007 have been committed without any header, 
> javadoc, comment, nothing.
> Here is an exemple :
> http://svn.apache.org/repos/asf/mina/tags/2.0.0-M1/transport-apr/src/main/java/org/apache/mina/transport/socket/apr/AprDatagramSession.java
> Basically, after having auditing the seven first classes in common, the total 
> lack of Javadoc and comment make it really difficult to help users if you 
> didn't wrote the code. Typically, almost all the protected methods are 
> javadoc-less, and pretty much no fields are documented.

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

[jira] Closed: (ASYNCWEB-13) No possibility to determine server socket in HttpService

[Julien Vermillard (JIRA)]

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

Julien Vermillard closed ASYNCWEB-13.
-


closing

> No possibility to determine server socket in HttpService
> 
>
> Key: ASYNCWEB-13
> URL: https://issues.apache.org/jira/browse/ASYNCWEB-13
> Project: Asyncweb
>  Issue Type: Improvement
>  Components: Server
> Environment: AsyncWeb 0.9.0-CVS
>Reporter: Daniel Wirtz
>Assignee: Julien Vermillard
> Attachments: patch-ASYNCWEB-13.txt
>
>
> I cannot find a possibility to get the server socket's address from a 
> HttpContext object, but a method to get the remote address is present. 
> FastCGI (in this particular case FCGIHttpService) depends on this information 
> for inclusion in the protocol specific SERVER_ADDR and SERVER_PORT parameters.
> public void handleRequest(HttpServiceContext context) throws Exception {
> ...impossible to determine the server socket address on which the request 
> came in to send it with a fastcgi request
> }
> Of course it could be manually set within the HttpService's constructor each 
> time, but when a server listens on more than one address, it will not suffice.
> A solution would be to add a getLocalAddress() (similar to the already 
> existing getRemoteAddress()) method to the HttpContext.

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

[jira] Commented: (DIRMINA-600) IoFuture::isReady need to be renamed

[Julien Vermillard (JIRA)]

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

Julien Vermillard commented on DIRMINA-600:
---

+1 for isDone()

> IoFuture::isReady need to be renamed
> 
>
> Key: DIRMINA-600
> URL: https://issues.apache.org/jira/browse/DIRMINA-600
> Project: MINA
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.0.0-M1
>Reporter: Julien Vermillard
>Assignee: Julien Vermillard
> Fix For: 2.0.0-M2
>
>
> in Iofuture.java :
> /**
>  * Returns if the asynchronous operation is finished.
>  */
> boolean isReady();
> I think isReady is not the good term, I propose isCompleted (or isFinished) 

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

[jira] Commented: (DIRMINA-601) Add sendfile support to transport-apr

[Julien Vermillard (JIRA)]

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

Julien Vermillard commented on DIRMINA-601:
---

Nice patch !
I think your SendableFile is a good abstraction for providing sendFile() 
implementation for transports.

As I understand if you want to send a file using sendFile of an IoService, you 
need to instantiate the good SendableFile concrete class ? like AprSendable 
file if you use an AprIoacceptor.

We need to be able to change from Nio IoService to Apr based IoService without 
changing the code.
So I think it miss a per IoService SendableFile factory for creating 
SendableFile independently of the used transport.

WDYT ?

> Add sendfile support to transport-apr
> -
>
> Key: DIRMINA-601
> URL: https://issues.apache.org/jira/browse/DIRMINA-601
> Project: MINA
>  Issue Type: Improvement
>  Components: Core, Transport
>Affects Versions: 2.0.0-M2
>Reporter: Geoff Cadien
> Attachments: sendfile-patches.zip
>
>
> I've take a shot at adding support for sendfile to transport-apr.  I've had 
> to make several changes because in the current code FileRegion is NIO 
> specific because of it's reliance on FileChannel.  I've made the following 
> changes:
> I've created an interface called SendableFile to take the place of using 
> FileChannel in FileRegion.  I've also created two implementations of this 
> interface, AprSendableFile and NioSendableFile.  The method of interest is 
> send(long position, long length) which is used to send the file.  Notice it 
> doesn't take an IoSession or a Channel as a parameter.  I tried using 
> generics to include  the proper subclass of IoSession but that didn't work 
> out very well. :-)
> There are still a couple of problems that need to be dealt with.  First and 
> foremost is that AbstractIoSession will create instances of DefaultFileRegion 
> in the write method when passed either a File or a FileChannel.  This causes 
> a problem because FileRegion is no longer NIO specific.  I don't have a 
> solution right now other than removing the code.
> The other problem is with FileRegionWriteFilter (and unit test), again 
> because FileRegion is NIO specific and exposes a FileChannel.  
> I'm hoping somebody can take a look at the code and provide some feedback if 
> they believe this is headed in the right direction or have a better idea.  
> I'll attach the patches shortly.

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

[jira] Commented: (DIRMINA-584) Using apr-transport crashes jvm on Linux

[Julien Vermillard (JIRA)]

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

Julien Vermillard commented on DIRMINA-584:
---

Thanks, pushed the patch

> Using apr-transport crashes jvm on Linux
> 
>
> Key: DIRMINA-584
> URL: https://issues.apache.org/jira/browse/DIRMINA-584
> Project: MINA
>  Issue Type: Bug
>  Components: Transport
>Affects Versions: 2.0.0-M1
> Environment: Linux jellikit 2.6.24-16-generic #1 SMP Thu Apr 10 
> 13:23:42 UTC 2008 i686 GNU/Linux
> java version "1.6.0_06"
> Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
> Java HotSpot(TM) Server VM (build 10.0-b22, mixed mode)
> tomcat-native-1.1.13
> apr-1.2.11
>Reporter: Geoff Cadien
>Assignee: Trustin Lee
> Fix For: 2.0.0-M2
>
>
> To reproduce you can simply run the EchoServer from mina-example and use 
> AprIoAcceptor instead of NioAcceptor.  I used the EchoClient from Julien 
> Vermillard's sandbox here: 
> https://svn.apache.org/repos/asf/mina/sandbox/jvermillard/ and used 20 or 30 
> concurrent connections.
> AprIoProcessor.destroy() is called multiple times when an exception is 
> generated in AbstractPollingIoProcessor (RST, etc.) and either epoll or apr 
> doesn't like to remove a closed fd from the pollset.  I believe that destroy 
> is called twice because AprIoProcessor.state() returns SessionState.OPEN when 
> the native fd is > 0.  I don't believe once open it will ever be 0 again.
> I was able to fix the problem by explicitly settion AprSession.descriptor to 
> 0 after the socket was closed although I'm not sure this is the correct 
> 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-584) Using apr-transport crashes jvm on Linux

[Julien Vermillard (JIRA)]

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

Julien Vermillard closed DIRMINA-584.
-

Resolution: Fixed
  Assignee: Julien Vermillard  (was: Trustin Lee)

closing and crossing finger

> Using apr-transport crashes jvm on Linux
> 
>
> Key: DIRMINA-584
> URL: https://issues.apache.org/jira/browse/DIRMINA-584
> Project: MINA
>  Issue Type: Bug
>  Components: Transport
>Affects Versions: 2.0.0-M1
> Environment: Linux jellikit 2.6.24-16-generic #1 SMP Thu Apr 10 
> 13:23:42 UTC 2008 i686 GNU/Linux
> java version "1.6.0_06"
> Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
> Java HotSpot(TM) Server VM (build 10.0-b22, mixed mode)
> tomcat-native-1.1.13
> apr-1.2.11
>Reporter: Geoff Cadien
>Assignee: Julien Vermillard
> Fix For: 2.0.0-M2
>
>
> To reproduce you can simply run the EchoServer from mina-example and use 
> AprIoAcceptor instead of NioAcceptor.  I used the EchoClient from Julien 
> Vermillard's sandbox here: 
> https://svn.apache.org/repos/asf/mina/sandbox/jvermillard/ and used 20 or 30 
> concurrent connections.
> AprIoProcessor.destroy() is called multiple times when an exception is 
> generated in AbstractPollingIoProcessor (RST, etc.) and either epoll or apr 
> doesn't like to remove a closed fd from the pollset.  I believe that destroy 
> is called twice because AprIoProcessor.state() returns SessionState.OPEN when 
> the native fd is > 0.  I don't believe once open it will ever be 0 again.
> I was able to fix the problem by explicitly settion AprSession.descriptor to 
> 0 after the socket was closed although I'm not sure this is the correct 
> solution.

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

[jira] Resolved: (DIRMINA-602) Socket.destroy should be called when AprSession is destroyed

[Julien Vermillard (JIRA)]

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

Julien Vermillard resolved DIRMINA-602.
---

Resolution: Duplicate
  Assignee: Julien Vermillard

Duplicate of DIRMINA-584

> Socket.destroy should be called when AprSession is destroyed
> 
>
> Key: DIRMINA-602
> URL: https://issues.apache.org/jira/browse/DIRMINA-602
> Project: MINA
>  Issue Type: Bug
>  Components: Transport
>Affects Versions: 2.0.0-M2
> Environment: Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
> Java HotSpot(TM) Server VM (build 10.0-b22, mixed mode)
> Linux jellikit 2.6.24-17-generic #1 SMP Thu May 1 14:31:33 UTC 2008 i686 
> GNU/Linux
> MINA Trunk
>Reporter: Geoff Cadien
>Assignee: Julien Vermillard
>
> I believe that Socket.destroy should be called when a session is destroyed.  
> It looks like Socket.accept creates a pool and it should be destroyed.  I may 
> be incorrect but it seemed to solve some issues I was having.
> Index: src/main/java/org/apache/mina/transport/socket/apr/AprIoProcessor.java
> ===
> --- src/main/java/org/apache/mina/transport/socket/apr/AprIoProcessor.java
>   (revision 656872)
> +++ src/main/java/org/apache/mina/transport/socket/apr/AprIoProcessor.java
>   (working copy)
> @@ -43,7 +43,6 @@
>   * @author The Apache MINA Project (dev@mina.apache.org)
>   * @version $Rev$, $Date$
>   */
> -
>  public final class AprIoProcessor extends 
> AbstractPollingIoProcessor {
>  private static final int POLLSET_SIZE = 1024;
> @@ -239,6 +238,11 @@
>  }
>  } finally {
>  ret = Socket.close(session.getDescriptor());
> +// I think socket needs to be destroyed.  When a connection is 
> accepted
> +// a pool is allocated for the socket and I don't see how else 
> it will
> +// get destroyed.
> +Socket.destroy(session.getDescriptor());
> +session.setDescriptor(0);
>  if (ret != Status.APR_SUCCESS) {
>  throwException(ret);
>  }

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

[jira] Closed: (DIRMINA-603) AprIoProcessor.state should check for file descriptor != 0 instead of > 0

[Julien Vermillard (JIRA)]

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

Julien Vermillard closed DIRMINA-603.
-

Resolution: Fixed
  Assignee: Julien Vermillard

never thought fd could be negatives
thanks for the patch !

> AprIoProcessor.state should check for file descriptor != 0 instead of > 0
> -
>
> Key: DIRMINA-603
> URL: https://issues.apache.org/jira/browse/DIRMINA-603
> Project: MINA
>  Issue Type: Bug
>  Components: Transport
> Environment: Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
> Java HotSpot(TM) Server VM (build 10.0-b22, mixed mode)
> Linux jellikit 2.6.24-17-generic #1 SMP Thu May 1 14:31:33 UTC 2008 i686 
> GNU/Linux
> MINA trunk
>Reporter: Geoff Cadien
>Assignee: Julien Vermillard
> Fix For: 2.0.0-M2
>
>
> AprIoSession.state only returns SessionState.OPEN if the file descriptor for 
> the socket is > 0.  I belive the fd can be < 0 (I have see values < 0) and if 
> value is < 0 the incorrect SessionState is returned.
> Index: src/main/java/org/apache/mina/transport/socket/apr/AprIoProcessor.java
> ===
> --- src/main/java/org/apache/mina/transport/socket/apr/AprIoProcessor.java
>   (revision 656872)
> +++ src/main/java/org/apache/mina/transport/socket/apr/AprIoProcessor.java
>   (working copy)
> @@ -248,7 +252,7 @@
>  @Override
>  protected SessionState state(AprSession session) {
>  long socket = session.getDescriptor();
> -if (socket > 0) {
> +if (socket != 0) {
>  return SessionState.OPEN;
>  } else if (allSessions.get(socket) != null) {
>  return SessionState.PREPARING; // will occur ?

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

[jira] Commented: (DIRMINA-603) AprIoProcessor.state should check for file descriptor != 0 instead of > 0

[Julien Vermillard (JIRA)]

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

Julien Vermillard commented on DIRMINA-603:
---

thanks for the precision, I think I need to check if I didn't made the same 
mistake somewhere else in this code.

> AprIoProcessor.state should check for file descriptor != 0 instead of > 0
> -
>
> Key: DIRMINA-603
> URL: https://issues.apache.org/jira/browse/DIRMINA-603
> Project: MINA
>  Issue Type: Bug
>  Components: Transport
> Environment: Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
> Java HotSpot(TM) Server VM (build 10.0-b22, mixed mode)
> Linux jellikit 2.6.24-17-generic #1 SMP Thu May 1 14:31:33 UTC 2008 i686 
> GNU/Linux
> MINA trunk
>Reporter: Geoff Cadien
>Assignee: Julien Vermillard
> Fix For: 2.0.0-M2
>
>
> AprIoSession.state only returns SessionState.OPEN if the file descriptor for 
> the socket is > 0.  I belive the fd can be < 0 (I have see values < 0) and if 
> value is < 0 the incorrect SessionState is returned.
> Index: src/main/java/org/apache/mina/transport/socket/apr/AprIoProcessor.java
> ===
> --- src/main/java/org/apache/mina/transport/socket/apr/AprIoProcessor.java
>   (revision 656872)
> +++ src/main/java/org/apache/mina/transport/socket/apr/AprIoProcessor.java
>   (working copy)
> @@ -248,7 +252,7 @@
>  @Override
>  protected SessionState state(AprSession session) {
>  long socket = session.getDescriptor();
> -if (socket > 0) {
> +if (socket != 0) {
>  return SessionState.OPEN;
>  } else if (allSessions.get(socket) != null) {
>  return SessionState.PREPARING; // will occur ?

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

[jira] Closed: (DIRMINA-591) Javadoc & documentation for org/apache/mina/filter/codec/statemachine/

[Julien Vermillard (JIRA)]

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

Julien Vermillard closed DIRMINA-591.
-

Resolution: Fixed

Just read the javadoc  it's much better now. Thanks Niklas

> Javadoc & documentation for org/apache/mina/filter/codec/statemachine/
> --
>
> Key: DIRMINA-591
> URL: https://issues.apache.org/jira/browse/DIRMINA-591
> Project: MINA
>  Issue Type: Improvement
>  Components: Filter, Web Site / Documentation
>Affects Versions: 2.0.0-M1
>Reporter: Julien Vermillard
> Fix For: 2.0.0-M2
>
>
> The statemachine codec utilities (used in Asyncweb codec) isn't documented.

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

[jira] Closed: (DIRMINA-583) NioSocketAcceptor.reuseAddress should be false by default.

[Julien Vermillard (JIRA)]

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

Julien Vermillard closed DIRMINA-583.
-


> NioSocketAcceptor.reuseAddress should be false by default.
> --
>
> Key: DIRMINA-583
> URL: https://issues.apache.org/jira/browse/DIRMINA-583
> Project: MINA
>  Issue Type: Bug
>  Components: Transport
>Affects Versions: 2.0.0-M1
>Reporter: Trustin Lee
>Assignee: Trustin Lee
>Priority: Minor
> Fix For: 2.0.0-M2
>
>
> In NioSocketAcceptor.java:
> private boolean reuseAddress = true;
> should be:
> private boolean reuseAddress = false;
> because that's the default expected behavior.

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

[jira] Commented: (DIRMINA-411) Create a ChannelWriteFilter

[Julien Vermillard (JIRA)]

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

Julien Vermillard commented on DIRMINA-411:
---

this issue need to be closed ?  because it's marked "fixed" I'm not sure it's 
correct

> Create a ChannelWriteFilter
> ---
>
> Key: DIRMINA-411
> URL: https://issues.apache.org/jira/browse/DIRMINA-411
> Project: MINA
>  Issue Type: New Feature
>  Components: Filter
>Affects Versions: 2.0.0-M1
>Reporter: Mike Heath
>Assignee: Mike Heath
>Priority: Minor
> Fix For: 2.0.0-M2
>
>
> Create a ChannelWriteFilter as described in DIRMINA-282

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

[jira] Closed: (DIRMINA-568) Improve KeepAliveFilter to provide customizable timeout handler.

[Julien Vermillard (JIRA)]

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

Julien Vermillard closed DIRMINA-568.
-


> Improve KeepAliveFilter to provide customizable timeout handler.
> 
>
> Key: DIRMINA-568
> URL: https://issues.apache.org/jira/browse/DIRMINA-568
> Project: MINA
>  Issue Type: Improvement
>  Components: Filter
>Affects Versions: 2.0.0-M1
>Reporter: Trustin Lee
>Assignee: Trustin Lee
>Priority: Minor
> Fix For: 2.0.0-M2
>
>
> A user can specify a KeepAlivePolicy for a KeepAliveFilter to tell 
> KeepAliveFilter what to do when ping timeout occurs.  However, what the user 
> can choose is limited to very simple operations because KeepAlivePolicy is 
> not extendable but an enum.  We need to replace it with 
> KeepAliveRequestTimeoutHandler interface which is much more flexible.

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

[jira] Closed: (DIRMINA-571) SocketConnectorTest.testConnectFutureSuccessTiming() fails

[Julien Vermillard (JIRA)]

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

Julien Vermillard closed DIRMINA-571.
-


> SocketConnectorTest.testConnectFutureSuccessTiming() fails
> --
>
> Key: DIRMINA-571
> URL: https://issues.apache.org/jira/browse/DIRMINA-571
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.0.0-M2
>Reporter: Sangjin Lee
>Priority: Minor
> Fix For: 2.0.0-M2
>
>
> The test fails because the connect future gets completed as part of 
> sessionCreated().  The same failure exists with DatagramConnectorTest as 
> well.  The problem is reproduced intermittently on some platforms (mostly 
> windows) but not 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-564) Make KeepAliveFilter to work with other IdleStatuses then READER_IDLE

[Julien Vermillard (JIRA)]

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

Julien Vermillard closed DIRMINA-564.
-


> Make KeepAliveFilter to work with other IdleStatuses then READER_IDLE
> -
>
> Key: DIRMINA-564
> URL: https://issues.apache.org/jira/browse/DIRMINA-564
> Project: MINA
>  Issue Type: Improvement
>  Components: Filter
>Affects Versions: 2.0.0-M1
>Reporter: Trustin Lee
>Assignee: Trustin Lee
>Priority: Minor
> Fix For: 2.0.0-M2
>
>
> Current KeepAliveFilter implementation is interested only in 
> IdleStatus.READER_IDLE, but some users seem to want to make the 
> KeepAliveFilter listens to IdleStatus.WRITER_IDLE or IdleStatus.BOTH_IDLE.
> We could add interestedIdleStatus property to KeepAliveFilter.

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

[jira] Closed: (DIRMINA-521) VmPipeAddressEditor does not return equivalent values in defaultText and defaultValue

[Julien Vermillard (JIRA)]

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

Julien Vermillard closed DIRMINA-521.
-


> VmPipeAddressEditor does not return equivalent values in defaultText and 
> defaultValue
> -
>
> Key: DIRMINA-521
> URL: https://issues.apache.org/jira/browse/DIRMINA-521
> Project: MINA
>  Issue Type: Bug
>  Components: Integration
>Affects Versions: 2.0.0-M1
>Reporter: Kevin Koltzau
>Assignee: Trustin Lee
>Priority: Minor
> Fix For: 2.0.0-M2
>
> Attachments: vmpipedefault.diff
>
>
> defaultText returns ":1" and defaultValue returns essentially ":0"

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

[jira] Closed: (DIRMINA-560) SocketSessionConfigImpl IPv4 localhost TEST_ADDRESS causes server to hang

[Julien Vermillard (JIRA)]

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

Julien Vermillard closed DIRMINA-560.
-


> SocketSessionConfigImpl  IPv4 localhost TEST_ADDRESS causes server to hang
> --
>
> Key: DIRMINA-560
> URL: https://issues.apache.org/jira/browse/DIRMINA-560
> Project: MINA
>  Issue Type: Bug
>  Components: Transport
>Affects Versions: 1.0.9, 1.1.6, 2.0.0-M1
> Environment: Linux bash ... westhost.com 'business hosting'
>Reporter: David Karam
>Assignee: Trustin Lee
>Priority: Minor
> Fix For: 1.0.10, 1.1.7, 2.0.0-M2
>
>
> Hi
> I had to remove the following test address from 
> SocketSessionConfigImpl.initializeTestAddresses
> It causes my cheap hosting agreement server to hang forever! Even with the 10 
> sec timeout!
> // IPv4 localhost
> TEST_ADDRESSES.put(new InetSocketAddress(InetAddress
> .getByAddress(new byte[] { 127, 0, 0, 1 }), 0), 
> InetAddress
> .getByAddress(new byte[] { 127, 0, 0, 1 }));
> Why?
> I am using Rev: 575240
> Thanks for your time!

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

[jira] Closed: (DIRMINA-582) IoService.getManagedSession() should return a Map instead of a Set.

[Julien Vermillard (JIRA)]

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

Julien Vermillard closed DIRMINA-582.
-


> IoService.getManagedSession() should return a Map instead of a Set.
> ---
>
> Key: DIRMINA-582
> URL: https://issues.apache.org/jira/browse/DIRMINA-582
> Project: MINA
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.0.0-M1
>Reporter: Trustin Lee
>Assignee: Trustin Lee
>Priority: Minor
> Fix For: 2.0.0-M2
>
>
> IoSession already has a getId() method which returns a unique ID of the 
> session.  Therefore, it would save a lot of time to search for a session with 
> a certain ID if IoService.getManagedSessions() returns Map 
> instead of Set.
> Related discussion is found here: http://markmail.org/message/tbr3wuk42auvnty2

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

[jira] Closed: (DIRMINA-529) use isPrimitive() instead of comparing the string to a list of primitives

[Julien Vermillard (JIRA)]

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

Julien Vermillard closed DIRMINA-529.
-


> use isPrimitive() instead of comparing the string to a list of primitives
> -
>
> Key: DIRMINA-529
> URL: https://issues.apache.org/jira/browse/DIRMINA-529
> Project: MINA
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.0.0-M1
>Reporter: Stefan Ackermann
>Assignee: Trustin Lee
>Priority: Minor
> Fix For: 2.0.0-M2
>
> Attachments: mina-patch.txt, Primitive.java, Primitive.java, 
> Primitive.java
>
>
> isPrimitive is a native function and should be used to determine whether a 
> class is primitive instead of comparing to a list of known primitive class 
> names

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

[jira] Closed: (DIRMINA-530) Compression filter - trivial bug fix and fix for use with SSL

[Julien Vermillard (JIRA)]

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

Julien Vermillard closed DIRMINA-530.
-


> Compression filter - trivial bug fix and fix for use with SSL
> -
>
> Key: DIRMINA-530
> URL: https://issues.apache.org/jira/browse/DIRMINA-530
> Project: MINA
>  Issue Type: Bug
>  Components: Filter
>Affects Versions: 1.0.9, 1.1.6, 2.0.0-M1
> Environment: N/A?  But Mac OS X Leopard (Java 1.5) does display the 
> issue.
>Reporter: Justin SB
>Assignee: Trustin Lee
> Fix For: 1.0.10, 1.1.7, 2.0.0-M2
>
> Attachments: patch-compression.diff
>
>
> The compression filter has a simple bug, where it uses limit() instead of 
> remaining(). Where position != 0, this causes reads to exceed available data:
> -byte[] inBytes = new byte[inBuffer.limit()];
> +byte[] inBytes = new byte[inBuffer.remaining()];
>  inBuffer.get(inBytes).flip();
>  
> Also, when the compression filter is chained with the SSL filter, and SSL 
> status notification is enabled, the SSL filter sends state messages through 
> the chain.  These are not IoBuffers, but the compression filter treats them 
> as if they were:
> +public void messageReceived(NextFilter nextFilter, IoSession session, 
> Object message) throws Exception {
> + // Ignore control messages e.g. from SSL filter
> + boolean compress = compressInbound && (message instanceof IoBuffer);
> + 
> +if (!compress)  {
> Patch file will be 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-526) Expose getCurrentWriteRequest() via IoSession

[Julien Vermillard (JIRA)]

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

Julien Vermillard closed DIRMINA-526.
-


> Expose getCurrentWriteRequest() via IoSession
> -
>
> Key: DIRMINA-526
> URL: https://issues.apache.org/jira/browse/DIRMINA-526
> Project: MINA
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.0.0-M1
> Environment: jdk1.6.0_03 Linux x64
>Reporter: Geoff Cadien
>Assignee: Trustin Lee
> Fix For: 2.0.0-M2
>
>
> It would be helpful is the protected method getCurrentWriteRequest() was 
> exposed in the IoSession interface.  Currently when a client closes a 
> connection before the message is completely sent there is no way to find out 
> how much data was acutally sent before the connection was closed.  If 
> getCurrentWriteRequest was exposed via IoSession it could be checked in 
> sessionClosed to see if it is non-null and how many bytes are were actually 
> sent could be determined.

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

[jira] Closed: (DIRMINA-515) DatagramConnectorTest breaks in XP SP2

[Julien Vermillard (JIRA)]

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

Julien Vermillard closed DIRMINA-515.
-


> DatagramConnectorTest breaks in XP SP2
> --
>
> Key: DIRMINA-515
> URL: https://issues.apache.org/jira/browse/DIRMINA-515
> Project: MINA
>  Issue Type: Test
>  Components: Core
>Affects Versions: 2.0.0-M1
> Environment: XP SP2, JDK 1.6.0_03
>Reporter: Lian Cheng
>Assignee: Trustin Lee
> Fix For: 2.0.0-M2
>
>
> Related forum thread:
> http://www.nabble.com/DatagramConnectorTest-in-trunk-breaks-on-XP-SP2-box.-to14992789s16868.html
> DatagramConnectorTest breaks on XP SP2 boxes. The NioDatagramAcceptor is 
> correctly set up and bound to corresponding UDP port, while the 
> NioDatagramConnector fails to connect to the UDP port.
> This bug can be always reproduced.

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

[jira] Closed: (DIRMINA-544) ConcurrentModificationException in MdcInjectionFilter

[Julien Vermillard (JIRA)]

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

Julien Vermillard closed DIRMINA-544.
-


> ConcurrentModificationException in MdcInjectionFilter
> -
>
> Key: DIRMINA-544
> URL: https://issues.apache.org/jira/browse/DIRMINA-544
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.0.0-M1
>Reporter: Maarten Bosteels
>Assignee: Maarten Bosteels
> Fix For: 2.0.0-M2
>
>
> When doing some load testing on FtpServer, I ran into a threading
> issue in MdcInjectionFilter. When adding some load, I frequently get a
> ConcurrentModificationException on removing the MDC properties. Here's
> the stacktrace:
> java.util.ConcurrentModificationException
>at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)
>at java.util.HashMap$KeyIterator.next(HashMap.java:828)
>at 
> org.apache.mina.filter.logging.MdcInjectionFilter.filter(MdcInjectionFilter.java:140)
>at 
> org.apache.mina.filter.util.CommonEventFilter.messageReceived(CommonEventFilter.java:67)
>at 
> org.apache.mina.common.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:401)
>at 
> org.apache.mina.common.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:38)
>at 
> org.apache.mina.common.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:820)
>at 
> org.apache.mina.common.DefaultIoFilterChain$HeadFilter.messageReceived(DefaultIoFilterChain.java:604)
>at 
> org.apache.mina.common.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:401)
>at 
> org.apache.mina.common.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:395)
>at 
> org.apache.mina.common.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:425)
>at 
> org.apache.mina.common.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:387)
>at 
> org.apache.mina.common.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:379)
>at 
> org.apache.mina.common.AbstractPollingIoProcessor.access$400(AbstractPollingIoProcessor.java:43)
>at 
> org.apache.mina.common.AbstractPollingIoProcessor$Worker.run(AbstractPollingIoProcessor.java:676)
>at 
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
>at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
>at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
>at java.lang.Thread.run(Thread.java:619)
> The cause of the problem is a call to setProperty() from
> org.apache.ftpserver.command.USER. I'm not familiar enough with the
> MDC filter to identify the culprit. Simply synchronizing the context
> Map does not help. The test I'm running is quite simple:
> package org.apache.ftpserver.clienttests;
> public class MdcThreadingTest extends ClientTestTemplate {
>public void testLoginMulti() throws Exception {
>tearDown();
>for(int i = 0; i<1; i++) {
>setUp();
>assertTrue(client.login(ADMIN_USERNAME, 
> ADMIN_PASSWORD));
>tearDown();
>}
>System.out.println("All done!");
>}
> }

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

[jira] Closed: (DIRMINA-528) NioSocketConnector has a public constructor that takes a package scoped argument

[Julien Vermillard (JIRA)]

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

Julien Vermillard closed DIRMINA-528.
-


> NioSocketConnector has a public constructor that takes a package scoped 
> argument
> 
>
> Key: DIRMINA-528
> URL: https://issues.apache.org/jira/browse/DIRMINA-528
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 2.0.0-M1
>Reporter: Mike Heath
>Assignee: Trustin Lee
> Fix For: 2.0.0-M2
>
>
> NioSocketConnector has the public constructors:
> NioSocketConnector(IoProcessor processor)
> and
> NioSocketConnector(Executor executor, IoProcessor processor)
> however NioSession and the two classes that extend it are all package scoped. 
>  This makes it impossible to pass in an IoProcessor implementation without 
> getting a warning.

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

[jira] Closed: (DIRMINA-533) NPE in OrderedThreadPoolExecutor and UnorderedThreadPoolExecutor

[Julien Vermillard (JIRA)]

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

Julien Vermillard closed DIRMINA-533.
-


> NPE in OrderedThreadPoolExecutor and UnorderedThreadPoolExecutor
> 
>
> Key: DIRMINA-533
> URL: https://issues.apache.org/jira/browse/DIRMINA-533
> Project: MINA
>  Issue Type: Bug
>  Components: Filter
>Affects Versions: 2.0.0-M1
>Reporter: Trustin Lee
>Assignee: Trustin Lee
> Fix For: 2.0.0-M2
>
>
> Quoted from the mailing list:
> 2008-02-20 (수), 20:36 +0900, 이희승 (Trustin Lee) 쓰시길:
> > 2008-02-20 (수), 08:23 +0100, Niklas Therning 쓰시길:
> > > Wilson Yeung wrote:
> > > > After sending a bunch of UDP datagrams, sleep for 30 seconds, then
> > > > this gets printed to console:
> > > >
> > > >  [java] Exception in thread "pool-1-thread-1" 
> > > > java.lang.NullPointerException
> > > >  [java]   at
> > > > org.apache.mina.filter.executor.OrderedThreadPoolExecutor.getSessionBuffer(OrderedThreadPoolExecutor.java:447)
> > > >  [java]   at
> > > > org.apache.mina.filter.executor.OrderedThreadPoolExecutor.access$900(OrderedThreadPoolExecutor.java:52)
> > > >  [java]   at
> > > > org.apache.mina.filter.executor.OrderedThreadPoolExecutor$Worker.run(OrderedThreadPoolExecutor.java:492)
> > > >  [java]   at java.lang.Thread.run(Thread.java:613)
> > > >
> > > > And then no more messages are ever sent despite how I might try.
> > > >
> > > > If I modify OrderedThreadPoolExecutor like so:
> > > >
> > > > clara:executor wilson$ svn diff OrderedThreadPoolExecutor.java
> > > > Index: OrderedThreadPoolExecutor.java
> > > > ===
> > > > --- OrderedThreadPoolExecutor.java(revision 627903)
> > > > +++ OrderedThreadPoolExecutor.java(working copy)
> > > > @@ -489,7 +489,9 @@
> > > >  }
> > > >
> > > >  try {
> > > > -runTasks(getSessionBuffer(session));
> > > > +   if (session != null) {
> > > > +runTasks(getSessionBuffer(session));
> > > > +}
> > > >  } finally {
> > > >  idleWorkers.incrementAndGet();
> > > >  }
> > > >
> > > > Then all is well.  Any ideas?  Am I abusing Mina, or is it an honest
> > > > to goodness Mina bug?
> > > >
> > > > Wilson
> > > >   
> > > 
> > > Do you have a test case which triggers this problem? You should open up 
> > > a JIRA issue and attach your test case and we will have a look at it.
> > 
> > The stack trace Wilson provided is very weird.  According to the trace,
> > it seems like OrderedThreadPoolExecutor.getSessionBuffer() throws a NPE
> > because the specified session is null.  The specified session is get
> > from IoEvent object.  Now if you look into the IoEvent class, its
> > constructor throws NPE if the specified session is null.  This means
> > that the session parameter that is passed to
> > OrderedThreadPoolExecutor.getSessionBuffer() cannot be null at all.
> > 
> > So.. any clue? :(
> Ugh... my reasoning was wrong.  It's
> OrderedThreadPoolExecutor.fetchSession() that returns null, and it's
> possible.  Wilson's patch looks reasonable.  Let me fix it soon...

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

[jira] Closed: (DIRMINA-570) NullPointerException in NioProcessor.transferFile

[Julien Vermillard (JIRA)]

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

Julien Vermillard closed DIRMINA-570.
-


> NullPointerException in NioProcessor.transferFile
> -
>
> Key: DIRMINA-570
> URL: https://issues.apache.org/jira/browse/DIRMINA-570
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.0.0-M1
> Environment: Linux 2.6.21.6 #1 SMP Wed Jul 25 20:22:10 MST 2007 
> x86_64 Intel(R) Xeon(R) CPU
>  
> java version "1.6.0_03"
> Java(TM) SE Runtime Environment (build 1.6.0_03-b05)
> Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_03-b05, mixed mode)
> MINA trunk
>Reporter: Geoff Cadien
>Assignee: Trustin Lee
> Fix For: 2.0.0-M2
>
>
> A NullPointerException exception is thrown from NioProcessor.transferFile 
> when an IOException thrown from transferTo and for some reason 
> Exception.getMessage() returns null so when attempting 
> e.getMessage().contains("Resource temporarily unavailable") a 
> NullPointerException is thrown.  Patch is below:
> Index: NioProcessor.java
> ===
> --- NioProcessor.java   (revision 648768)
> +++ NioProcessor.java   (working copy)
> @@ -192,7 +192,7 @@
>  return (int) 
> region.getFileChannel().transferTo(region.getPosition(), length, 
> session.getChannel());
>  } catch (IOException e) {
>  // Check to see if the IOException is being thrown due to 
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5103988
> -if (e.getMessage().contains("Resource temporarily unavailable")) 
> {
> +   if ("Resource temporarily unavailable".equals(e.getMessage())) {
>  return 0;
>  } else {
>  throw e;

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

[jira] Closed: (DIRMINA-25) Overload prevention

[Julien Vermillard (JIRA)]

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

Julien Vermillard closed DIRMINA-25.



> Overload prevention
> ---
>
> Key: DIRMINA-25
> URL: https://issues.apache.org/jira/browse/DIRMINA-25
> Project: MINA
>  Issue Type: New Feature
>Affects Versions: 0.7.0, 0.8.0
>Reporter: Trustin Lee
>Assignee: Trustin Lee
> Fix For: 2.0.0-M2
>
>
> Let's improve thread pool filter to enable users can control overload 
> situation.

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

[jira] Closed: (DIRMINA-538) Rename FileRegion.setPosition() to something more descriptive of what it is doing

[Julien Vermillard (JIRA)]

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

Julien Vermillard closed DIRMINA-538.
-


> Rename FileRegion.setPosition() to something more descriptive of what it is 
> doing
> -
>
> Key: DIRMINA-538
> URL: https://issues.apache.org/jira/browse/DIRMINA-538
> Project: MINA
>  Issue Type: Improvement
>Affects Versions: 2.0.0-M1
>Reporter: Mike Heath
>Assignee: Mike Heath
> Fix For: 2.0.0-M2
>
>
> FileRegion.setPosition() is poorly named because invoking this method updates 
> FileRegion.getPosition(), FileRegion.getCount(), and 
> FileRegion.getWrittenBytes().  I suggest we rename it to update(long) and 
> document what should happen when it's invoked.
> Also, FileRegion.getCount() isn't descriptive of what the method is 
> returning.  Something like FileRegion.getRemainingBytes() is more descriptive.

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

[jira] Closed: (DIRMINA-567) NPE in AbstractIoSession after getWaitingReadFutures

[Julien Vermillard (JIRA)]

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

Julien Vermillard closed DIRMINA-567.
-


> NPE in AbstractIoSession after getWaitingReadFutures
> 
>
> Key: DIRMINA-567
> URL: https://issues.apache.org/jira/browse/DIRMINA-567
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.0.0-M1
>Reporter: Dennis Sieben
>Assignee: Trustin Lee
> Fix For: 2.0.0-M2
>
> Attachments: patch.diff
>
>
> There seems to be a race condition in AbstractIoSession. The following NPE 
> appears sometimes:
> java.lang.NullPointerException
>   at 
> org.apache.mina.common.AbstractIoSession.newReadFuture(AbstractIoSession.java:227)
>   at 
> org.apache.mina.common.AbstractIoSession.offerFailedReadFuture(AbstractIoSession.java:212)
>   at 
> org.apache.mina.common.DefaultIoFilterChain$TailFilter.exceptionCaught(DefaultIoFilterChain.java:727)
>   at 
> org.apache.mina.common.DefaultIoFilterChain.callNextExceptionCaught(DefaultIoFilterChain.java:446)
>   at 
> org.apache.mina.common.DefaultIoFilterChain.access$1100(DefaultIoFilterChain.java:40)
>   at 
> org.apache.mina.common.DefaultIoFilterChain$EntryImpl$1.exceptionCaught(DefaultIoFilterChain.java:818)
>   at 
> org.apache.mina.common.DefaultIoFilterChain$HeadFilter.exceptionCaught(DefaultIoFilterChain.java:601)
>   at 
> org.apache.mina.common.DefaultIoFilterChain.callNextExceptionCaught(DefaultIoFilterChain.java:446)
>   at 
> org.apache.mina.common.DefaultIoFilterChain.fireExceptionCaught(DefaultIoFilterChain.java:437)
>   at 
> org.apache.mina.common.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:408)
>   at 
> org.apache.mina.common.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:40)
>   at 
> org.apache.mina.common.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:823)
>   at 
> org.apache.mina.common.DefaultIoFilterChain$HeadFilter.messageReceived(DefaultIoFilterChain.java:607)
>   at 
> org.apache.mina.common.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:405)
>   at 
> org.apache.mina.common.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:399)
>   at 
> org.apache.mina.common.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:425)
>   at 
> org.apache.mina.common.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:387)
>   at 
> org.apache.mina.common.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:379)
>   at 
> org.apache.mina.common.AbstractPollingIoProcessor.access$400(AbstractPollingIoProcessor.java:43)
>   at 
> org.apache.mina.common.AbstractPollingIoProcessor$Worker.run(AbstractPollingIoProcessor.java:678)
>   at 
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
>   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-527) should be able to set connect timeout in milliseconds

[Julien Vermillard (JIRA)]

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

Julien Vermillard closed DIRMINA-527.
-


> should be able to set connect timeout in milliseconds
> -
>
> Key: DIRMINA-527
> URL: https://issues.apache.org/jira/browse/DIRMINA-527
> Project: MINA
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 1.0.8, 1.1.5, 2.0.0-M1
>Reporter: Sangjin Lee
>Assignee: Mark Webb
> Fix For: 2.0.0-M2
>
> Attachments: DIRMINA-527.patch
>
>
> Currently, IoConnector allows setting connect timeouts only in seconds.  The 
> minimum value of allowed connect timeout is 1 second.  There are cases where 
> one needs to have a shorter connect timeout than 1 second and will finer 
> granularity than seconds.
> I suggest introducing the ability to set connect timeout in milliseconds and 
> deprecating the getter/setter in seconds in favor of the ms getter/setter.
> See the discussion thread at 
> http://www.nabble.com/connect-timeout-to15281787s16868.html.

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

[jira] Closed: (DIRMINA-514) Session closing problem on Mac OS X

[Julien Vermillard (JIRA)]

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

Julien Vermillard closed DIRMINA-514.
-


> Session closing problem on Mac OS X
> ---
>
> Key: DIRMINA-514
> URL: https://issues.apache.org/jira/browse/DIRMINA-514
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.0.0-M1
> Environment: Mac OS X 10.4 with Java 1.5.0_07 -87
>Reporter: Matteo Merli
>Assignee: Trustin Lee
> Fix For: 2.0.0-M2
>
> Attachments: Echo1_1.java, Echo2_0.java, mina-close.patch
>
>
> A call to session.close() does not send a FIN packet althought MINA will 
> considers the session as closed.
> I've attached two test cases, one that works with MINA 1.1 (and works fine) 
> and other with MINA 2.0 that doesn't close connections.
> This is a simple echo server that receives a message, writes it back to the 
> client and (should) close the connection. 
> This problem is *NOT* ocurring on Linux where the same test case works fine. 
> It only shows up on Mac OS X.

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

[jira] Closed: (DIRMINA-561) Socket.setReceiveBufferSize() called after bind preventing correct TCP receive window scaling

[Julien Vermillard (JIRA)]

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

Julien Vermillard closed DIRMINA-561.
-


> Socket.setReceiveBufferSize() called after bind preventing correct TCP 
> receive window scaling
> -
>
> Key: DIRMINA-561
> URL: https://issues.apache.org/jira/browse/DIRMINA-561
> Project: MINA
>  Issue Type: Bug
>  Components: Transport
>Affects Versions: 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.1.0, 1.0.4, 1.1.1, 1.0.5, 
> 1.1.2, 1.0.6, 1.1.3, 1.0.7, 1.1.4, 1.0.8, 1.1.5, 1.0.9, 1.1.6, 2.0.0-M1
> Environment: Head of the 1.1 branch
>Reporter: Greg Dhuse
>Assignee: Trustin Lee
> Fix For: 1.0.10, 1.1.7, 2.0.0-M2
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> Socket.setReceiveBufferSize() must be called before bind() on a ServerSocket 
> in order to allow TCP receive window scaling up to the configured buffer size 
> (http://java.sun.com/j2se/1.5.0/docs/api/java/net/Socket.html#setReceiveBufferSize(int)).
>   Currently, socket options are set after bind() is called.  This results in 
> the correct Java receive buffer size, but does not allow the TCP stack to 
> scale receive windows above 64k.  Severe performance degradation can occur on 
> high-latency high-bandwidth connections.
> The following patch is a possible solution to this issue, though there may be 
> a cleaner way to implement a fix within the framework.
> Best regards,
>  Greg
> Index: 
> core/src/main/java/org/apache/mina/transport/socket/nio/SocketConnector.java
> ===
> --- 
> core/src/main/java/org/apache/mina/transport/socket/nio/SocketConnector.java  
> (revision 642333)
> +++ 
> core/src/main/java/org/apache/mina/transport/socket/nio/SocketConnector.java  
> (working copy)
> @@ -163,6 +163,16 @@
>  try {
>  ch = SocketChannel.open();
>  ch.socket().setReuseAddress(true);
> +
> + // Receive buffer size must be set BEFORE the socket is 
> connected
> + // in order for the TCP window to be sized accordingly
> + if (config instanceof SocketConnectorConfig) {
> + SocketSessionConfig sessionConfig = 
> + ((SocketConnectorConfig) config).getSessionConfig();
> + ch.socket().setReceiveBufferSize(
> + sessionConfig.getReceiveBufferSize());
> + }
> +
>  if (localAddress != null) {
>  ch.socket().bind(localAddress);
>  }

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

[jira] Closed: (DIRMINA-535) Session creation/opened callbacks are not called at logical times

[Julien Vermillard (JIRA)]

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

Julien Vermillard closed DIRMINA-535.
-


> Session creation/opened callbacks are not called at logical times
> -
>
> Key: DIRMINA-535
> URL: https://issues.apache.org/jira/browse/DIRMINA-535
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.0.0-M1
>Reporter: David M. Lloyd
>Assignee: Trustin Lee
> Fix For: 2.0.0-M2
>
>
> The IoHandler.sessionCreated and IoHandler.sessionOpened methods are not 
> called at useful times.  The sessionCreated method should be called *after* 
> the session is constructed but before anything else is done.  The 
> sessionOpened method should be called immediately after the connection is 
> established, but *before* any messages are received (in other words, before 
> the selectionkey is added to the selector).
> From the look of the code in AbstractPollingIoProcessor, it looks like 
> sessionOpened is simply called immediately after sessionCreated (see 
> IoServiceListenerSupport.fireSessionCreated()), rendering the separate 
> methods useless.  In addition, it seems that there is nothing preventing a 
> message from coming in before this initialization is complete, unless I am 
> misunderstanding what threads are operating on these constructs.

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

[jira] Commented: (DIRMINA-415) Proxy support

[Julien Vermillard (JIRA)]

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

Julien Vermillard commented on DIRMINA-415:
---

First comments : formatting is wrong you can get our formatting rules for 
eclipse here :
http://mina.apache.org/developer-guide.data/ImprovedJavaConventions.xml
No tabs, 4 whitespaces in place.

you don't need to add
if (logger.isDebugEnabled()) {
Because slf4j will do string concatenation only when the log level is suffisant.

Anyway, nice contribution !! I'll try to say more as soon I can run it.


> Proxy support
> -
>
> Key: DIRMINA-415
> URL: https://issues.apache.org/jira/browse/DIRMINA-415
> Project: MINA
>  Issue Type: New Feature
>  Components: Transport
>Reporter: Trustin Lee
> Fix For: 2.0.0-M2
>
> Attachments: mina-connector-proxy-1.1.0-mina2.zip, 
> mina-connector-proxy-1.1.0.zip, minaproxy-2.0.0-M1.zip
>
>
> There has been enourmous demand for supporting proxy such as simple port 
> forwarding and SOCKS.  We need to investigate what the best way is to provide 
> an extension point for proxies.
> IoFilters are not adequate for proxies because proxies needs changes in the 
> socket addresses (both local and remote) of IoSession.

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

[jira] Closed: (DIRMINA-595) Javadoc for AbstractPollingIo*.java

[Julien Vermillard (JIRA)]

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

Julien Vermillard closed DIRMINA-595.
-

Resolution: Fixed

> Javadoc for AbstractPollingIo*.java
> ---
>
> Key: DIRMINA-595
> URL: https://issues.apache.org/jira/browse/DIRMINA-595
> Project: MINA
>  Issue Type: Improvement
>  Components: Core, Web Site / Documentation
>Affects Versions: 2.0.0-M1
>Reporter: Julien Vermillard
> Fix For: 2.0.0-M2
>
>
> The base class for creating polled transports miss Javadoc so implemented 
> transport can't inherit it. It'll ease transport implementation too.

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

[jira] Updated: (DIRMINA-600) IoFuture::isReady need to be renamed

[Julien Vermillard (JIRA)]

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

Julien Vermillard updated DIRMINA-600:
--

Fix Version/s: (was: 2.0.0-M2)
   2.0.0-M3

> IoFuture::isReady need to be renamed
> 
>
> Key: DIRMINA-600
> URL: https://issues.apache.org/jira/browse/DIRMINA-600
> Project: MINA
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.0.0-M1
>Reporter: Julien Vermillard
>Assignee: Julien Vermillard
> Fix For: 2.0.0-M3
>
>
> in Iofuture.java :
> /**
>  * Returns if the asynchronous operation is finished.
>  */
> boolean isReady();
> I think isReady is not the good term, I propose isCompleted (or isFinished) 

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

[jira] Updated: (DIRMINA-586) Dynamic delimiter support for TextLineCodecFactory

[Julien Vermillard (JIRA)]

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

Julien Vermillard updated DIRMINA-586:
--

Fix Version/s: (was: 2.0.0-M2)
   2.0.0-M3

> Dynamic delimiter support for TextLineCodecFactory
> --
>
> Key: DIRMINA-586
> URL: https://issues.apache.org/jira/browse/DIRMINA-586
> Project: MINA
>  Issue Type: Improvement
>  Components: Filter
>Affects Versions: 2.0.0-M1
>Reporter: Trustin Lee
>Priority: Minor
> Fix For: 2.0.0-M3
>
>
> TextLineCodecFactory supports static delimiters only.  For some cases, users 
> need to switch the delimiter dynamically depending on context.  Related 
> discussion is found here:
> http://markmail.org/message/loiqoej35evt2yvv

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

[jira] Updated: (DIRMINA-605) Add support for serial port connection

[Julien Vermillard (JIRA)]

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

Julien Vermillard updated DIRMINA-605:
--

Fix Version/s: (was: 2.0.0-M2)
   2.0.0-M3

> Add support for serial port connection
> --
>
> Key: DIRMINA-605
> URL: https://issues.apache.org/jira/browse/DIRMINA-605
> Project: MINA
>  Issue Type: New Feature
>Affects Versions: 2.0.0-M1
> Environment: Windows XP
>Reporter: john wang
> Fix For: 2.0.0-M3
>
>
> Need to able to connect to a serial port (like we are able to connect to a 
> TCP/IP port now).

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

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

[Julien Vermillard (JIRA)]

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

Julien Vermillard updated DIRMINA-594:
--

Fix Version/s: (was: 2.0.0-M2)
   2.0.0-M3

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

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

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

[Julien Vermillard (JIRA)]

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

Julien Vermillard updated DIRMINA-593:
--

Fix Version/s: (was: 2.0.0-M2)
   2.0.0-M3

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

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

[jira] Updated: (DIRMINA-556) Allow blocking CIDR subnets in BlacklistFilter

[Julien Vermillard (JIRA)]

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

Julien Vermillard updated DIRMINA-556:
--

Fix Version/s: (was: 2.0.0-M2)
   2.0.0-M3

> Allow blocking CIDR subnets in BlacklistFilter
> --
>
> Key: DIRMINA-556
> URL: https://issues.apache.org/jira/browse/DIRMINA-556
> Project: MINA
>  Issue Type: Improvement
>  Components: Filter
>Affects Versions: 2.0.0-M1
>Reporter: Niklas Gustavsson
>Priority: Minor
> Fix For: 2.0.0-M3
>
>
> For FtpServer, we need support for blocking entire subnets from opening 
> sessions, BlacklistFilter only support individual IP addresses.

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

[jira] Updated: (DIRMINA-500) Cache for encoded messages.

[Julien Vermillard (JIRA)]

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

Julien Vermillard updated DIRMINA-500:
--

Fix Version/s: (was: 2.0.0-M2)
   2.0.0-M3

> Cache for encoded messages.
> ---
>
> Key: DIRMINA-500
> URL: https://issues.apache.org/jira/browse/DIRMINA-500
> Project: MINA
>  Issue Type: New Feature
>  Components: Filter
>Reporter: Trustin Lee
>Priority: Minor
> Fix For: 2.0.0-M3
>
>
> There's unnecessary overhead of encoding when a user sends the same message 
> to multiple sessions.  We could implement a caching filter so it can reuse 
> the encoded IoBuffer instead of encoding every time.
> I'm not sure it should be implemented as a separate filter or should be part 
> of ProtocolCodecFilter yet though.

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

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

[Julien Vermillard (JIRA)]

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

Julien Vermillard updated DIRMINA-489:
--

Fix Version/s: (was: 2.0.0-M2)
   2.0.0-M3

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

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

[jira] Updated: (DIRMINA-585) Visibility issue in various configuration properties and a few critical counters.

[Julien Vermillard (JIRA)]

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

Julien Vermillard updated DIRMINA-585:
--

Fix Version/s: (was: 2.0.0-M2)
   2.0.0-M3

> Visibility issue in various configuration properties and a few critical 
> counters.
> -
>
> Key: DIRMINA-585
> URL: https://issues.apache.org/jira/browse/DIRMINA-585
> Project: MINA
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 2.0.0-M1, 1.0.10, 1.1.7
>Reporter: Trustin Lee
>Priority: Minor
> Fix For: 2.0.0-M3, 1.0.11, 1.1.8
>
>
> Configuration properties such as idleTimeForRead, readBufferSize and 
> useReadOperation have visibility issue because they are mutable and 
> non-volatile.  All configuration propeties should be declared as volatile and 
> some critical counter properties such as idleCount should be an AtomicInteger 
> or something similar.  Detailed discussion is here:
> http://markmail.org/message/h4rcitkfit4bdcpl

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

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

[Julien Vermillard (JIRA)]

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

Julien Vermillard updated DIRMINA-577:
--

Fix Version/s: (was: 2.0.0-M2)
   2.0.0-M3

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

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

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

[Julien Vermillard (JIRA)]

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

Julien Vermillard updated DIRMINA-574:
--

Fix Version/s: (was: 2.0.0-M2)
   2.0.0-M3

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

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

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

[Julien Vermillard (JIRA)]

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

Julien Vermillard updated DIRMINA-477:
--

Fix Version/s: (was: 2.0.0-M2)
   2.0.0-M3

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

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

[jira] Updated: (DIRMINA-539) NioDatagramConnector doesn't takes the TrafficClass value set to his DatagramSessionConfig

[Julien Vermillard (JIRA)]

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

Julien Vermillard updated DIRMINA-539:
--

Fix Version/s: (was: 2.0.0-M2)
   2.0.0-M3

> NioDatagramConnector doesn't takes the TrafficClass value set to his 
> DatagramSessionConfig 
> ---
>
> Key: DIRMINA-539
> URL: https://issues.apache.org/jira/browse/DIRMINA-539
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 2.0.0-M1
> Environment: WinXP, RHEL5 (probably not important)
>Reporter: martin krivosik
>Assignee: Trustin Lee
> Fix For: 2.0.0-M3
>
>   Original Estimate: 0.33h
>  Remaining Estimate: 0.33h
>
> client sending datagrams without taking care to the trafficClas set in the 
> config, so the ToS byte is not set in the packet sent from client.
> client code:
>   NioDatagramAcceptor acceptor = new NioDatagramAcceptor();
>   DatagramSessionConfig dcfg = 
> ((NioDatagramAcceptor)acceptor).getSessionConfig();
>   dcfg.setTrafficClass(tosByte);
>   InetSocketAddress bindAddrPort  = new InetSocketAddress(originatingIP, 
> port);
>   acceptor.bind(bindAddrPort);
> -> connecting to another computer with NioDatagramConnector.
> for me it looks like in the newHandle method of NioDatagramConnector is not 
> cared about TrafficClass (like it is done in NioDatagramAcceptor.open())
> The server part with the accceptor is OK and the correct ToS byte is set in 
> the packet.
> (the same problem may be in the socket, i have to check it)

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

[jira] Updated: (DIRMINA-519) BufferingFilter

[Julien Vermillard (JIRA)]

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

Julien Vermillard updated DIRMINA-519:
--

Fix Version/s: (was: 2.0.0-M2)
   2.0.0-M3

> BufferingFilter
> ---
>
> Key: DIRMINA-519
> URL: https://issues.apache.org/jira/browse/DIRMINA-519
> Project: MINA
>  Issue Type: New Feature
>  Components: Filter
>Reporter: Trustin Lee
>Priority: Minor
> Fix For: 2.0.0-M3
>
>
> As JDK provides BufferedOutputStream, we could provide BufferingFilteer which 
> does the same thing, which buffers encoded data and flushes it out when the 
> buffer becomes full or the flush operation is explicitly requested.  This 
> kind of filter is sometimes useful when a session is generating very small 
> messages too frequently and consequently generates unnecessary traffic 
> overhead.

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

[jira] Updated: (DIRMINA-518) Support gathering writes

[Julien Vermillard (JIRA)]

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

Julien Vermillard updated DIRMINA-518:
--

Fix Version/s: (was: 2.0.0-M2)
   2.0.0-M3

> Support gathering writes
> 
>
> Key: DIRMINA-518
> URL: https://issues.apache.org/jira/browse/DIRMINA-518
> Project: MINA
>  Issue Type: New Feature
>  Components: Core
>Reporter: David M. Lloyd
>Priority: Minor
> Fix For: 2.0.0-M3
>
>
> It may be worthwhile to enhance the various processor implementations to 
> accept a Collection or IoBuffer[] and perform a gathering write 
> across all the collection members.  For datagram protocols, this would allow 
> messages to be composed without copying.  For stream protocols, this might 
> simply improve performance.  In addition, stream protocols could benefit from 
> doing gathering writes in general when there are many buffers queued up.

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

[jira] Updated: (DIRMINA-520) DemuxingIoHandler for SingleSessionIoHandlers

[Julien Vermillard (JIRA)]

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

Julien Vermillard updated DIRMINA-520:
--

Fix Version/s: (was: 2.0.0-M2)
   2.0.0-M3

> DemuxingIoHandler for SingleSessionIoHandlers
> -
>
> Key: DIRMINA-520
> URL: https://issues.apache.org/jira/browse/DIRMINA-520
> Project: MINA
>  Issue Type: New Feature
>  Components: Handler
>Reporter: Trustin Lee
>Priority: Minor
> Fix For: 2.0.0-M3
>
>
> It will be nice if we implement DemuxingIoHandler which is integrated with 
> org.apache.mina.handler.multiton.

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

[jira] Updated: (DIRMINA-478) GzipFilter

[Julien Vermillard (JIRA)]

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

Julien Vermillard updated DIRMINA-478:
--

Fix Version/s: (was: 2.0.0-M2)
   2.0.0-M3

> GzipFilter
> --
>
> Key: DIRMINA-478
> URL: https://issues.apache.org/jira/browse/DIRMINA-478
> Project: MINA
>  Issue Type: New Feature
>  Components: Filter
>Affects Versions: 1.1.4
>Reporter: Matthew Giedt
>Priority: Trivial
> Fix For: 2.0.0-M3
>
> Attachments: gzip.zip.rename
>
>
> Hi Matt, 
> On Nov 14, 2007 4:47 AM, mgiedt <[EMAIL PROTECTED]> wrote: 
> > 
> > I did some poking around and couldn't find a protocol handler for GZip so I 
> > created this one. Would very much welcome the communities feedback; MINA 
> > team the code is yours to do whatever you wish. (rename the file to 
> > 'gzip.zip', bob's your uncle.) 
> Thank you very much for your contribution first of all! :D 
> However, would you mind if you can create a JIRA issue and attach that 
> file there?  You have to grant license to the ASF for your work 
> (gzip.zip) when you attach a file.  I know it's pain in the butt, but 
> that's the way how legal stuff works. 
> Thanks in advance and best regards, 
> Trustin 

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

[jira] Updated: (DIRMINA-415) Proxy support

[Julien Vermillard (JIRA)]

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

Julien Vermillard updated DIRMINA-415:
--

Fix Version/s: (was: 2.0.0-M2)
   2.0.0-M3

> Proxy support
> -
>
> Key: DIRMINA-415
> URL: https://issues.apache.org/jira/browse/DIRMINA-415
> Project: MINA
>  Issue Type: New Feature
>  Components: Transport
>Reporter: Trustin Lee
> Fix For: 2.0.0-M3
>
> Attachments: mina-connector-proxy-1.1.0-mina2.zip, 
> mina-connector-proxy-1.1.0.zip, minaproxy-r2-2.0.0-M1.zip
>
>
> There has been enourmous demand for supporting proxy such as simple port 
> forwarding and SOCKS.  We need to investigate what the best way is to provide 
> an extension point for proxies.
> IoFilters are not adequate for proxies because proxies needs changes in the 
> socket addresses (both local and remote) of IoSession.

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

[jira] Updated: (DIRMINA-554) A hook between bind() and accept()

[Julien Vermillard (JIRA)]

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

Julien Vermillard updated DIRMINA-554:
--

Fix Version/s: (was: 2.0.0-M2)
   2.0.0-M3

> A hook between bind() and accept()
> --
>
> Key: DIRMINA-554
> URL: https://issues.apache.org/jira/browse/DIRMINA-554
> Project: MINA
>  Issue Type: New Feature
>  Components: Core
>Affects Versions: 2.0.0-M1
>Reporter: Trustin Lee
>Priority: Minor
> Fix For: 2.0.0-M3
>
>
> Related discussion: http://markmail.org/message/2yzhbttmen22gida
> The typical use case is to run a server with a regular user which binds to a 
> previledged port (i.e. 1~1024).  To implement this kind of server, there 
> needs to be a hook after ServerSocket.bind() and before ServerSocket.accept().
> The first suggested solution was to provide a listener method to 
> IoServiceListener, but it's not optimal because IoServiceListener is used for 
> both acceptor and connector.  Any better idea is appreciated.

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

[jira] Updated: (DIRMINA-250) Provide a test suite for a transport implementor.

[Julien Vermillard (JIRA)]

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

Julien Vermillard updated DIRMINA-250:
--

Fix Version/s: (was: 2.0.0-M2)
   2.0.0-M3

> Provide a test suite for a transport implementor.
> -
>
> Key: DIRMINA-250
> URL: https://issues.apache.org/jira/browse/DIRMINA-250
> Project: MINA
>  Issue Type: Task
>Reporter: Trustin Lee
>Priority: Minor
> Fix For: 2.0.0-M3
>
>
> The expected behaviors of all scenarios should be tested for all transport 
> implementations to keep consistency between different transport 
> implementations.  This has to be done at least before we implement a new 
> transport.

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

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

[Julien Vermillard (JIRA)]

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

Julien Vermillard updated DIRMINA-605:
--

Component/s: Transport
Description: Add the documentation for building serial-transport and use it 
in your MINA application  (was: 
Need to able to connect to a serial port (like we are able to connect to a 
TCP/IP port now).)
   Assignee: Julien Vermillard
 Issue Type: Improvement  (was: New Feature)
Summary: Add documentation for using and building serial port 
connection  (was: Add support for serial port connection)

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

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

[jira] Closed: (DIRMINA-600) IoFuture::isReady need to be renamed

[Julien Vermillard (JIRA)]

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

Julien Vermillard closed DIRMINA-600.
-

Resolution: Fixed

> IoFuture::isReady need to be renamed
> 
>
> Key: DIRMINA-600
> URL: https://issues.apache.org/jira/browse/DIRMINA-600
> Project: MINA
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 2.0.0-M1
>Reporter: Julien Vermillard
>Assignee: Julien Vermillard
> Fix For: 2.0.0-M3
>
>
> in Iofuture.java :
> /**
>  * Returns if the asynchronous operation is finished.
>  */
> boolean isReady();
> I think isReady is not the good term, I propose isCompleted (or isFinished) 

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

[jira] Resolved: (DIRMINA-473) ReadThrottleFilter throws IllegalStateException

[Julien Vermillard (JIRA)]

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

Julien Vermillard resolved DIRMINA-473.
---

Resolution: Invalid

ReadThrottle filter was removed . 
Look at this thread for alternative solutions :
http://www.nabble.com/Dropping-traffic-throttling-from-2.0-td16092085.html


> ReadThrottleFilter throws IllegalStateException
> ---
>
> Key: DIRMINA-473
> URL: https://issues.apache.org/jira/browse/DIRMINA-473
> Project: MINA
>  Issue Type: Bug
>  Components: Core
> Environment: Linux, Java 6, Box with 8 cores
>Reporter: Roger Kapsi
>Assignee: Trustin Lee
>
> The new ReadThrottleFilter from trunk throws an IlleganStateException.
> NioSocketAcceptor acceptor;
> DefaultIoFilterChainBuilder filterChain = acceptor.getFilterChain();
> // Adding other Filters and ReadThrottleFilter as the last one
> ReadThrottleFilter throttle = new ReadThrottleFilter();
> filterChain.addLast("read-throttle", throttle);
> Exception:
> java.lang.IllegalStateException: sessionBufferSize < 0
>at 
> org.apache.mina.filter.traffic.ReadThrottleFilter.exit(ReadThrottleFilter.java:455)
>at 
> org.apache.mina.filter.traffic.ReadThrottleFilter.messageReceived(ReadThrottleFilter.java:316)
>at 
> org.apache.mina.common.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:399)
>at 
> org.apache.mina.common.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:38)
>at 
> org.apache.mina.common.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:791)
>at org.apache.mina.common.IoFilterEvent.fire(IoFilterEvent.java:54)
>at org.apache.mina.common.IoEvent.run(IoEvent.java:62)
>at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
>at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
>at java.lang.Thread.run(Thread.java:619)

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

[jira] Assigned: (DIRMINA-539) NioDatagramConnector doesn't takes the TrafficClass value set to his DatagramSessionConfig

[Julien Vermillard (JIRA)]

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

Julien Vermillard reassigned DIRMINA-539:
-

Assignee: Julien Vermillard  (was: Trustin Lee)

> NioDatagramConnector doesn't takes the TrafficClass value set to his 
> DatagramSessionConfig 
> ---
>
> Key: DIRMINA-539
> URL: https://issues.apache.org/jira/browse/DIRMINA-539
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 2.0.0-M1
> Environment: WinXP, RHEL5 (probably not important)
>Reporter: martin krivosik
>Assignee: Julien Vermillard
> Fix For: 2.0.0-M3
>
>   Original Estimate: 0.33h
>  Remaining Estimate: 0.33h
>
> client sending datagrams without taking care to the trafficClas set in the 
> config, so the ToS byte is not set in the packet sent from client.
> client code:
>   NioDatagramAcceptor acceptor = new NioDatagramAcceptor();
>   DatagramSessionConfig dcfg = 
> ((NioDatagramAcceptor)acceptor).getSessionConfig();
>   dcfg.setTrafficClass(tosByte);
>   InetSocketAddress bindAddrPort  = new InetSocketAddress(originatingIP, 
> port);
>   acceptor.bind(bindAddrPort);
> -> connecting to another computer with NioDatagramConnector.
> for me it looks like in the newHandle method of NioDatagramConnector is not 
> cared about TrafficClass (like it is done in NioDatagramAcceptor.open())
> The server part with the accceptor is OK and the correct ToS byte is set in 
> the packet.
> (the same problem may be in the socket, i have to check it)

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

[jira] Resolved: (DIRMINA-606) Downloaded file signatures are incorrect

[Julien Vermillard (JIRA)]

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

Julien Vermillard resolved DIRMINA-606.
---

Resolution: Invalid

Yes the download page is a bit confusing, I added a little 'mirrored' but it's 
probably not enough. It'll need to be reworked as the whole website.

> Downloaded file signatures are incorrect
> 
>
> Key: DIRMINA-606
> URL: https://issues.apache.org/jira/browse/DIRMINA-606
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 1.0.10, 1.1.7, 2.0.0-M1
>Reporter: Emmanuel Lecharny
>Priority: Blocker
>
> The asc files does not match the downloaded files :
> Visit the Mina download site: http://mina.apache.org/downloads
> right-click and save mina-2.0.0-M1.tar.bz2.  Now do the same for the
> "asc" file just to the right.  In another window run gpg on the asc
> file, and it will inform you: BAD signature from "Mike Heath
> <[EMAIL PROTECTED]>"
> Here are the links that I see from the home page (right-click
> copy-link-location for both the .bz2 and the .asc files):
>  http://mina.apache.org/dyn/closer.cgi/mina/2.0.0-M1/mina-2.0.0-M1.tar.bz2
>  http://www.apache.org/dist/mina/2.0.0-M1/mina-2.0.0-M1.tar.bz2.asc

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