Re :Jenkins build became unstable: MINA-2.0.X-jdk1.5-ubuntu #323

2016-02-04 Thread Edouard De Oliveira


Envoyé depuis Yahoo Mail pour Android 
 
  Le mar. j févr. PM à 17:00, Apache Jenkins Server 
a écrit :   See 


  


Re :Jenkins build became unstable: MINA-2.0.X-jdk1.5-ubuntu #323

2016-02-04 Thread Edouard De Oliveira


Envoyé depuis Yahoo Mail pour Android 
 
  Le mar. j févr. PM à 17:00, Apache Jenkins Server 
a écrit :   See 


  


Re: Adding Monitoring to MINA 3.0

2013-07-25 Thread Edouard De Oliveira
Hi folks, 
i've been MIA for quite long but i regularly take a look at MINA threads from 
time to time

As for monitoring, i don't know if it's the best tool for this (need to 
investigate it when i'll have some spare time ...)

But what i know is that it is IMHO definitly a MUST HAVE
as it would allow to gather stats from within real world running instances 
instead of often quite simple junit tests

So big +1 for your idea Ashish
 

Cordialement, Regards,
-Edouard De Oliveira-


 De : Ashish paliwalash...@gmail.com
À : dev@mina.apache.org 
Envoyé le : Jeudi 25 juillet 2013 17h24
Objet : Adding Monitoring to MINA 3.0
 

Folks,

Since we have M1 release, we can think about adding Monitoring support to
MINA.

Yammer's Metrics package is quite widely used for this.

http://metrics.codahale.com/

I do not have a concrete idea on how to go about putting monitoring in
place. It would be worth discussing about it.

We can use to monitor

bytes in/out
Queue lengths
Protocol Messages in/out
# IO Listener
Events Connect/Idle etc
JVM stuff (http://metrics.codahale.com/manual/jvm/)

wdyt?

-- 
thanks
ashish

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

Re: New MINA committer : Jeff Maury

2013-01-26 Thread Edouard De Oliveira
Welcome aboard Jeff !
 
Cordialement, Regards,
-Edouard De Oliveira-




 De : Emmanuel Lecharny elecha...@apache.org
À : dev@mina.apache.org dev@mina.apache.org 
Envoyé le : Samedi 26 janvier 2013 11h42
Objet : New MINA committer : Jeff Maury
 
Welcome !

That's a pleasure to have you as a committer

On Saturday, January 26, 2013, Julien Vermillard wrote:

 Hi,
 Looks like we forgot to announce that.

 The MINA PMC has voted to invite Jeff Maury as a MINA committer for
 his contributions to MINA benchmark. Jeff has accepted.

 So let's warm welcome Jeff.

 On behalf of MINA PMC,
 Julien



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

[article] mina and http high perf frameworks

2011-11-09 Thread Edouard De Oliveira
French article which shows there's definitive room for improvement for next 
mina releases
http://blog.xebia.fr/2011/11/09/java-nio-et-framework-web-haute-performance/


 
Cordialement, Regards,
-Edouard De Oliveira-


Blog: http://blog.e-deoliveira.fr
WebSite: http://tedorg.free.fr/en/main.php

Re : Re : new benchmark results for mina1/mina2/grizzly/netty

2011-09-22 Thread Edouard De Oliveira
@ashish he already did like said in a previous mail but it didn't change much 
as well

@bluedavy i'd like to know what are exactly the parameters used to start the 
client and the server ? (timeout , concurrents, byte size etc ...)
also plz note that this link is broken 
: http://bluedavy.com/projects/nfs-rpc/benchmark-1.xslx
 
Cordialement, Regards,
-Edouard De Oliveira-


- Mail original -
De : Ashish paliwalash...@gmail.com
À : dev@mina.apache.org; Edouard De Oliveira doe_wan...@yahoo.fr
Cc : 
Envoyé le : Jeudi 22 Septembre 2011 15h24
Objet : Re: Re : new benchmark results for mina1/mina2/grizzly/netty

On Tue, Sep 20, 2011 at 7:33 PM, Edouard De Oliveira
doe_wan...@yahoo.fr wrote:
 First you could try enabling some socket options (like on the others 
 frameworks) to the mina2 test :

 server side add these before bind :

 ((NioSocketAcceptor) acceptor).setReuseAddress(true);
 ((NioSocketAcceptor) acceptor).getSessionConfig().setTcpNoDelay(true);

 client side add after the setTcpnodelay line :
 ioConnector.getSessionConfig().setReuseAddress(true);


 what are the new figures with these settings ?

 Cordialement, Regards,
 -Edouard De Oliveira-

@Edouard - updated the benchmark code with your suggestions. Did
marginally increased TPS on my laptop :(

@bluedavy - can you rerun the test again.

thanks
ashish



[jira] [Commented] (DIRMINA-379) setKeepAlive/setTcpNoDelay and exceptions in Windows Vista

2011-09-21 Thread Edouard De Oliveira (JIRA)

[ 
https://issues.apache.org/jira/browse/DIRMINA-379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13109520#comment-13109520
 ] 

Edouard De Oliveira commented on DIRMINA-379:
-

according to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7058336
it may be due to a jdk 1.5  1.6 bug it says jdk 1.7 has a rewritten Socket 
adaptator
maybe you can try jdk 1.7 to check if it solves the issue 
dirty hack would be to try to delay as much as possible the socket options 
setting to prevent options to be set on a non open socket  

please note we are not releasing 1.x versions anymore

 setKeepAlive/setTcpNoDelay and exceptions in Windows Vista
 --

 Key: DIRMINA-379
 URL: https://issues.apache.org/jira/browse/DIRMINA-379
 Project: MINA
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.3, 1.1.0, 2.0.0-M1
 Environment: Windows Vista Home Premium Italian
 Java SE 1.5.0_11, Java SE 1.6 Update 1, Java SE 1.4.2_12
Reporter: Stefano Bagnara

 When I ran my application under Vista I get this exception:
 Exception in thread Thread-4 org.apache.mina.common.RuntimeIOException: 
 java.net.SocketException: Invalid argument: sun.nio.ch.Net.setIntOption
   at 
 org.apache.mina.transport.socket.nio.SocketSessionImpl$SessionConfigImpl.setKeepAlive(SocketSessionImpl.java:252)
   at 
 org.apache.mina.transport.socket.nio.SocketSessionImpl.init(SocketSessionImpl.java:94)
   at 
 org.apache.mina.transport.socket.nio.SocketConnector.newSession(SocketConnector.java:350)
   at 
 org.apache.mina.transport.socket.nio.SocketConnector.processSessions(SocketConnector.java:290)
   at 
 org.apache.mina.transport.socket.nio.SocketConnector.access$900(SocketConnector.java:53)
   at 
 org.apache.mina.transport.socket.nio.SocketConnector$Worker.run(SocketConnector.java:395)
   at 
 org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:43)
   at java.lang.Thread.run(Thread.java:595)
 Caused by: java.net.SocketException: Invalid argument: 
 sun.nio.ch.Net.setIntOption
   at sun.nio.ch.Net.setIntOption0(Native Method)
   at sun.nio.ch.Net.setIntOption(Net.java:152)
   at sun.nio.ch.SocketChannelImpl$1.setInt(SocketChannelImpl.java:372)
   at sun.nio.ch.SocketOptsImpl.setBoolean(SocketOptsImpl.java:38)
   at sun.nio.ch.SocketOptsImpl.keepAlive(SocketOptsImpl.java:92)
   at sun.nio.ch.OptionAdaptor.setKeepAlive(OptionAdaptor.java:139)
   at sun.nio.ch.SocketAdaptor.setKeepAlive(SocketAdaptor.java:322)
   at 
 org.apache.mina.transport.socket.nio.SocketSessionImpl$SessionConfigImpl.setKeepAlive(SocketSessionImpl.java:248)
   ... 7 more
 I had to remove the following lines from the SocketSessionImpl constructor:
 this.config.setKeepAlive( cfg.isKeepAlive() );
 this.config.setTcpNoDelay( cfg.isTcpNoDelay() );
 and now it works.
 No matter if I change the configuration to let them return true or false, I 
 keep getting the exception if I don't remove the call at all.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira




Re : new benchmark results for mina1/mina2/grizzly/netty

2011-09-20 Thread Edouard De Oliveira
First you could try enabling some socket options (like on the others 
frameworks) to the mina2 test :

server side add these before bind :

((NioSocketAcceptor) acceptor).setReuseAddress(true);
((NioSocketAcceptor) acceptor).getSessionConfig().setTcpNoDelay(true);

client side add after the setTcpnodelay line :
ioConnector.getSessionConfig().setReuseAddress(true);


what are the new figures with these settings ?

Cordialement, Regards,
-Edouard De Oliveira-



De : BlueDavy Lin blued...@gmail.com
À : paliwalash...@gmail.com
Cc : dev@mina.apache.org
Envoyé le : Mardi 20 Septembre 2011 5h10
Objet : Re: new benchmark results for mina1/mina2/grizzly/netty

environment can be seen here: http://code.google.com/p/nfs-rpc

If u tuned,u can also give the code to me,or If u agree,I can add u to
nfs-rpc committer,so u can submit the code directly,after u tuned the
code,I'll run the benchmark test in the same environment again.

2011/9/20 Ashish paliwalash...@gmail.com:
 Thanks for sharing :)

 Can you share a bit more about the environment that you are using to
 run the tests

 I shall try to run the benchmark at my end and see if I can tune the
 implementation.

 thanks
 ashish

 On Tue, Sep 20, 2011 at 7:08 AM, BlueDavy Lin blued...@gmail.com wrote:
 hi!

     Alexey(the leader of grizzly) changed some grizzly 
 nfs-rpc-grizzly code,now the new benchmark results are:
     Mina: 123k
     Mina2: 65k
     Grizzly: 161k
     Netty: 160k

     All're runned in 100 concurrents,100 request  response byte
 size,single connection,protobuf serialize/deserialize.

     more details pls see: http://code.google.com/p/nfs-rpc

 --
 =
 |     BlueDavy                                      |
 |     http://www.bluedavy.com                |
 =




 --
 thanks
 ashish

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




-- 
=
|     BlueDavy                                      |
|     http://www.bluedavy.com                |
= 


Re : rpc benchmark result with mina/netty/grizzly

2011-09-16 Thread Edouard De Oliveira
Hi,

I don't know if you received any response but we sure have to take a look at 
your benchmark and tune your impl or try to understand where we may loose some 
perfs.
Although, this bench might be interesting to use in our current discussions 
around mina 3 not only to compare with others but also to demonstrate if our 
new choices are right.
 
Cordialement, Regards,
-Edouard De Oliveira-



De :
À : dev@mina.apache.org
Envoyé le : Jeudi 15 Septembre 2011 9h45
Objet : rpc benchmark result with mina/netty/grizzly

hi!

       I wrote an abstract java rpc framework to more quickly
intergrate network framework,now I intergrate mina  netty  grizzly,
serialize/deserialize with java/hessian/protobuf.

       In 100 concurrents,100 byte request  response,single
connection,protobuf serialize/deserialize situation,the benchmark
record is:
       Mina: 123k
       Netty: 160k
       Grizzly: 143k

       Are there some guys interested to tune the rpc based on mina
performance,if u have,pls goto http://code.google.com/p/nfs-rpc to see
more details.

-- 
=
|     BlueDavy                                      |
|     http://www.bluedavy.com                |
=

Re : [MINA 3.0] filter chains

2011-08-26 Thread Edouard De Oliveira
On Aug 26, 2011, at 6:40 AM, Julien Vermillard wrote:


 On Fri, Aug 26, 2011 at 3:24 PM, Alan D. Cabrera l...@toolazydogs.com wrote:
 
 On Aug 26, 2011, at 4:14 AM, Julien Vermillard wrote:
 
 I modified the API to remove IoFilterChain. Now you are supposed to
 give a list of filter to the service before starting it :
 
 // create the fitler chain for this service
 ListIoFilter filters = new ArrayListIoFilter();
 filters.add(new LoggingFilter(byte log filter));
 filters.add(new MyCodecFilter());
 filters.add(new LoggingFilter(pojo log filter));
 filters.add(newMyProtocolLogicFilter());
 
 acceptor.setFilters(filters);
 
 acceptor.bind(...);
 
 
 How do we make chains where two filters feed into one or one filter feeds 
 two filters?  If you look in my sandbox we can accommodate this via:
 
 static import a.m.util.Util. linkParentWithChild; // to be written
 
 IoFilter foo = new FooFilter();
 LinkStateFilter link = new LinkStateFilter();
 IoFilter checksum = new ChecksumFilter();
 IoFilter log = new LogFilter();
 
 link.addLinkStateListener(foo);
 linkParentWithChild(foo, checksum);
 linkParentWithChild(link, checksum);
 linkParentWithChild(checksum, log);
 
 acceptor.setFilters(foo);
 
 About the code in the sandbox :
 http://svn.apache.org/repos/asf/mina/sandbox/adc/ahc/mina3/src/main/java/org/apache/mina/core/IoFilter.java
 I see no IoFilter.addLinkStateListener(..) method, am I looking at the
 right place ?

Oops, it was meant to just be a sketch.  :)

 About the filters feed into one or one filter feeds two filters, do
 you have a concrete use case in mind for that ?


The above example does, Foo and the link state filter.  I'm sure that we've 
discussed this before.  Another example is a mux/demux situation.  How would 
all of this fit into the grand scheme of things?

Regards,
Alan

On my side, besides the @ fsm declaration api (which may be impossible to use 
as i think it fixes the position of a filter in the chain which is not 
universal) 
i wrote a simple api i'd like your thoughts on (using the type of syntax used 
in hibernate criteria) : 

FSMState init = getInitialState();
FSMState b = init.linksTo(FSMStateB.class);
b.linksTo(FSMStateZ.class);

FSMState d = b.linksTo(FSMStateC.class).linksTo(FSMStateD.class);
d.linksTo(FSMStateE.class);
d.linksTo(FSMStateF.class);

which represents obviously :

INIT - B - Z
      |- C - D - E
|- F
wdyt ?


Re : [MINA 3.0] filter chains

2011-08-26 Thread Edouard De Oliveira
De : Emmanuel Lecharny elecha...@gmail.com

À : dev@mina.apache.org
Envoyé le : Vendredi 26 Août 2011 17h12
Objet : Re: [MINA 3.0] filter chains

On 8/26/11 4:55 PM, Alan D. Cabrera wrote:
 On Aug 26, 2011, at 7:47 AM, Emmanuel Lecharny wrote:

 On 8/26/11 4:28 PM, Alan D. Cabrera wrote:
 On Aug 26, 2011, at 7:12 AM, Julien Vermillard wrote:

 On Fri, Aug 26, 2011 at 4:07 PM, Emmanuel 
 Lecharnyelecha...@gmail.com   wrote:
 On 8/26/11 3:44 PM, Alan D. Cabrera wrote:
 On Aug 26, 2011, at 6:40 AM, Julien Vermillard wrote:

 On Fri, Aug 26, 2011 at 3:24 PM, Alan D. Cabreral...@toolazydogs.com
   wrote:
 On Aug 26, 2011, at 4:14 AM, Julien Vermillard wrote:

 I modified the API to remove IoFilterChain. Now you are supposed to
 give a list of filter to the service before starting it :

 // create the fitler chain for this service
 ListIoFilter    filters = new ArrayListIoFilter();
 filters.add(new LoggingFilter(byte log filter));
 filters.add(new MyCodecFilter());
 filters.add(new LoggingFilter(pojo log filter));
 filters.add(newMyProtocolLogicFilter());

 acceptor.setFilters(filters);

 acceptor.bind(...);
 How do we make chains where two filters feed into one or one filter
 feeds two filters?  If you look in my sandbox we can accommodate this 
 via:

 static import a.m.util.Util. linkParentWithChild; // to be written

 IoFilter foo = new FooFilter();
 LinkStateFilter link = new LinkStateFilter();
 IoFilter checksum = new ChecksumFilter();
 IoFilter log = new LogFilter();

 link.addLinkStateListener(foo);
 linkParentWithChild(foo, checksum);
 linkParentWithChild(link, checksum);
 linkParentWithChild(checksum, log);

 acceptor.setFilters(foo);

 About the code in the sandbox :

 http://svn.apache.org/repos/asf/mina/sandbox/adc/ahc/mina3/src/main/java/org/apache/mina/core/IoFilter.java
 I see no IoFilter.addLinkStateListener(..) method, am I looking at the
 right place ?
 Oops, it was meant to just be a sketch.  :)

 About the filters feed into one or one filter feeds two filters, do
 you have a concrete use case in mind for that ?
 The above example does, Foo and the link state filter.  I'm sure that
 we've discussed this before.  Another example is a mux/demux situation.  
 How
 would all of this fit into the grand scheme of things?
 Yeah, it really should be a graph of filters, not a list of filters.

 Well if it's just for demuxing I proposed few mails ago this solution
 : http://s.apache.org/A9W
 I think we need to make graphing a 1st class citizen and not buried inside 
 another filter class.
 I do agree. The proposed solution on http://s.apache.org/A9W is what we 
 currently have, and it's tedious to manage.

 It would be way better to be able to let the controler call the next filter 
 based on an evaluation method based on the current state.


 Now, the question is : how do the controller knows which filter to call next 
 ? It must have the current state, and it must be able to make the connection.

 For instance, let's say that from filter F we can switch to either filter G 
 or filter H, depending on the state we transit to in F.

 F --(state1)--  G
 or
 F --(state2)--  H

 That means the controller has a map { (F, state1, G), (F, state2, H)} 
 somewhere. State should be passed to the controller too :

 ...
 controller.nextFilter( newState );
 ...

 Pretty theorical at this point... I'm sorry not to have a lot of time to 
 code this, I do realize that for you guys implementing ideas it's a PITA...
 I was thinking of a simple DAG some, or all, of the nodes can be FSMs.

 -  [FSM1] -  [Filter] -  [FSM2] -  [Filter]

 Inside the FSM there could be chains, but there would be one chain per state.
Not sure I grok what you say here. There is more than one state, and 
from each state, you may have more than one transition.

Maybe it's just a problem of vocabulary...

theory
In a FSM, you transit from Si to Sj, following a transition Ta, which 
depends on a context. You may also transit to a state Sk, following a 
different transition Tb, if the context is different.

Selection the transition to follow is all about knowing what's the 
context is, and in my sample, this was what I call the 'state', which 
was most certainly an error, as it's clearly a transition. I should have 
wrote :

F --(transition1)--  G
or
F --(transition2)--  H

where F, G, H are filters (ore states)

are we on the same page ?

/theory


The theory sounds ok but it also seems that Alan has something much more (too 
?) complex in mind 
for those who wandered what a DAG is i think it's 
this http://en.wikipedia.org/wiki/Directed_acyclic_graph do you confirm alan ?

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


Re : Re : [MINA 3.0] filter chains

2011-08-26 Thread Edouard De Oliveira


De : Emmanuel Lécharny elecha...@apache.org
À : dev@mina.apache.org
Cc : 
Envoyé le : Vendredi 26 Août 2011 18h10
Objet : Re: Re : [MINA 3.0] filter chains

On 8/26/11 6:02 PM, Edouard De Oliveira wrote:
 De : Emmanuel Lecharnyelecha...@gmail.com
 
 
 The theory sounds ok but it also seems that Alan has something much more (too 
 ?) complex in mind for those who wandered what a DAG is i think it's this 
 http://en.wikipedia.org/wiki/Directed_acyclic_graph do you confirm alan ?

DAG is just a restricted form of a FSM. It just forbid a loop, which is 
exactly what we need in our case (why would we cycle on a filter we already 
went through ?)


The concept is a basic it's just the acronym that may not be known ...

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


Re : Re : [MINA 3.0] filter chains

2011-08-25 Thread Edouard De Oliveira
On Wed, Aug 24, 2011 at 7:55 PM, Edouard De Oliveira

doe_wan...@yahoo.fr wrote:


 On 8/21/11 11:48 PM, Alan D. Cabrera wrote:
 On Aug 21, 2011, at 11:39 AM, Edouard De Oliveira wrote:


 But i'm feeling more and more confused by the fsm need : as you said some 
 management bits in the session can switch on/off some filters why do we 
 want to complicate the coder 's life using a two state FSM (in the case of 
 multiple filters it would generate  a much more complicated FSM that the 
 coder would have to describe with code ... better ?) ?

 Do you want the fsm to control the flow between filters (state=filter ?) or 
 do you want your fsm to control if a filter is active ?

 There's no reason why one could not have a chain of FSMs.  You get the exact 
 same behavior with less framework code.

The reason why MINA 1 and 2 has a chain is unclear. One possible 
explainaition is that MINA was supposed to implement the SEDA architecture 
(each filter communicate with the next filter using a queue, and as this 
architecture is supposed to spread filters on more than one computer, then 
it's easier to implement it using a chain. Well, that's my perception. One 
other reason was the lack of vision about the possible use cases. 6 years in 
restrospect, I do think that this need never surfaced...
 With the growing of the base code it's easier just by looking at what exists 
 to find some use case one would not have though of at this time

The more I think about this problem, the more I think that FSM is the way to 
go :
- we don't add filters dynamically on a created session


- we *always* know which filter we will call whatever state we are : it's a 
protocol we are handling, it's well defined !
 +1 : it's just that it will require much more preliminary toughts to start 
 coding a server - that's our good practices promoting thing

- debugging will be easier
 i won't be so categorical about this as whatever graph type you use to 
 describe your 'chain' it will still be session/data dependent

- we won't have to use some strange Mutiplexer filter in order to call one 
filter or another depending on the message we are dealing with, like it's 
currently the case in MINA 2
 not so strange as it is a well known design pattern (Command Pattern)

- coding a protocol will be easier
 we have to make basic servers easier (or as easy as before) too

- we can define @ to declare the FSM, making the developper's life easier (an 
idea that needs to be developed...)

i was also planning on some @ (like @unique to limit the presence of a filter 
in the chain or some more generic one that would provide the name and the 
unicity of the filter for Mina 2 obviously)

for mina 3 i indeed was wondering if somehow we could use @ to prevent 
bloated FSM declaration code and found this interesting article which could 
be a good base to start with :
http://weblogs.java.net/blog/carcassi/archive/2007/02/finite_state_ma_1.html


 You can find a fast hack at the following pastebin url which shows how i 
 changed the original code of the article to add data dependent transitions :
 http://pastebin.com/CjXjJ2Q1


Do we all agree on that ?
There's lot of momentum on this solution so it should be given at least a try 
obviously


+1
it's hard for me to figure if it's going to be the solution witout a
more complex example implementation


it's far from being an implementation it's just a basic poc that a fsm can be 
built with @



Re : [MINA 3.0] filter chains

2011-08-24 Thread Edouard De Oliveira


On 8/21/11 11:48 PM, Alan D. Cabrera wrote:
 On Aug 21, 2011, at 11:39 AM, Edouard De Oliveira wrote:
 
 
 But i'm feeling more and more confused by the fsm need : as you said some 
 management bits in the session can switch on/off some filters why do we want 
 to complicate the coder 's life using a two state FSM (in the case of 
 multiple filters it would generate  a much more complicated FSM that the 
 coder would have to describe with code ... better ?) ?
 
 Do you want the fsm to control the flow between filters (state=filter ?) or 
 do you want your fsm to control if a filter is active ?
 
 There's no reason why one could not have a chain of FSMs.  You get the exact 
 same behavior with less framework code.

The reason why MINA 1 and 2 has a chain is unclear. One possible explainaition 
is that MINA was supposed to implement the SEDA architecture (each filter 
communicate with the next filter using a queue, and as this architecture is 
supposed to spread filters on more than one computer, then it's easier to 
implement it using a chain. Well, that's my perception. One other reason was 
the lack of vision about the possible use cases. 6 years in restrospect, I do 
think that this need never surfaced...
With the growing of the base code it's easier just by looking at what exists to 
find some use case one would not have though of at this time

The more I think about this problem, the more I think that FSM is the way to 
go :
- we don't add filters dynamically on a created session


- we *always* know which filter we will call whatever state we are : it's a 
protocol we are handling, it's well defined !
+1 : it's just that it will require much more preliminary toughts to start 
coding a server - that's our good practices promoting thing

- debugging will be easier
i won't be so categorical about this as whatever graph type you use to describe 
your 'chain' it will still be session/data dependent

- we won't have to use some strange Mutiplexer filter in order to call one 
filter or another depending on the message we are dealing with, like it's 
currently the case in MINA 2
not so strange as it is a well known design pattern (Command Pattern) 

- coding a protocol will be easier
we have to make basic servers easier (or as easy as before) too

- we can define @ to declare the FSM, making the developper's life easier (an 
idea that needs to be developed...)

i was also planning on some @ (like @unique to limit the presence of a filter 
in the chain or some more generic one that would provide the name and the 
unicity of the filter for Mina 2 obviously)

for mina 3 i indeed was wondering if somehow we could use @ to prevent bloated 
FSM declaration code and found this interesting article which could be a good 
base to start with :
http://weblogs.java.net/blog/carcassi/archive/2007/02/finite_state_ma_1.html


You can find a fast hack at the following pastebin url which shows how i 
changed the original code of the article to add data dependent transitions :
http://pastebin.com/CjXjJ2Q1


Do we all agree on that ?
There's lot of momentum on this solution so it should be given at least a try 
obviously



Re : trunk as 3.0 ?

2011-08-24 Thread Edouard De Oliveira
Sounds ok
 
Cordialement, Regards,
-Edouard De Oliveira-


 On Aug 24, 2011, at 6:12 AM, Julien Vermillard wrote:
 Hi,
 Since 2.X dev are done in specific branches, I would like to move 3.0
 dev from the 3.0 branch to trunk for giving it more visibility.
 
 WDYT ?
 
 Julien


Re : [MINA 3.0] filter chains

2011-08-21 Thread Edouard De Oliveira


On Aug 20, 2011, at 11:47 PM, Emmanuel Lecharny wrote:

 On 8/21/11 2:09 AM, Alan D. Cabrera wrote:
 Wow, I totally forgot about these pages.
 
 There's been a fair bit of discussion on this topic on the mailing list 
 before, this being the need for dynamically modifying filter chains in a 
 session that's already being used.  It is my assertion that it is an 
 anti-pattern that signals the need for a state machine.  Getting a protocol 
 right on both network endpoints is very hard and dynamic chains make it even 
 more difficult and error prone.  APIs should promote good practices.
 
 There are implementation issues as well. Look how complicated the 
 implementation, sketched by Edouard, gets below.
 
 Normally I'm a let a thousand flowers bloom kind of guy.  But, as you know, 
 I've been a strong advocate of thinning Mina's bloated class library.  I 
 find it difficult justifying CoW chains in a library that people already 
 find bewildering.
 
 Just my 2 cents.  Let's get this finally resolved as this topic seems to pop 
 up on a regular basis.
 IMHO, we usually don't need a dynamic chain. There is little to no reason to 
 have it. One objection could be that one may want to inject a log filter on 
 the fly.

When one really thinks about it one never just james a log filter in on the 
fly.  Logging a network endpoint requires a fair bit of thought, where does it 
go in the chain, where does it log to, how chatty it is, etc.  Usually, it's 
always in the chain waiting to be turned on by management bits.  With that 
said, we're talking about a simple two state FSM, on/off.


Log is a bad filter example we know it from long ago we should use some 
instrumentation like tools to make it efficient but something configurable at 
runtime easily would be even better

But i'm feeling more and more confused by the fsm need : as you said some 
management bits in the session can switch on/off some filters why do we want to 
complicate the coder 's life using a two state FSM (in the case of multiple 
filters it would generate  a much more complicated FSM that the coder would 
have to describe with code ... better ?) ?

Do you want the fsm to control the flow between filters (state=filter ?) or do 
you want your fsm to control if a filter is active ?

 But first, designing a API just to allow such a purpose seems a bit an 
 overkill to me, and second, I wold rather prefer creating a new session, 
 copying an existing one, if we really need to do that.
 
 MINA 2.0 currently has a this functionality, and frankly, it kills when it 
 comes to debug an application. A debugging session becomes a pain in the 
 butt, as you have to step in an extra layer before going into the next filter.

 Modern IDEs can be configured to not step into code that resides in certain 
 packages.  Just an academic observation.

 If we could ditch this, I would be *very* happy !
 
 I'll do my Steve Ballmer here : FSM ! FSM ! FSM !

Go baby go!


Regards,
Alan


Re : [MINA 3.0] filter chains

2011-08-20 Thread Edouard De Oliveira
We shouldn't systematically copy the chain in the session as imho it's not so 
usual to dynamically add filters in one particular session (the first case that 
comes to my mind is dynamically protecting the session with ssl but it requires 
a new connection most of the time no ? maybe some dynamic compression or some 
negociation mechanism that will need a particular filter wrapping and 
unwrapping messages)

A copy on write strategy would improve memory footprint. So when would we copy 
the chain ? when some change happens : add/remove filter 
a chain controller could associate to the session it's alternative chain or use 
the default one.

So now what about threads coming into play ? using threadlocal seems a good 
idea Em

So to resume 
- copy when necessary
- custom chain should be searched in the following places : threadlocal - 
session - default chain of the controller

ChainController.getChain() will hide this whole complexity providing 
flexibility and efficiency wdyt ? 
 
Cordialement, Regards,
-Edouard De Oliveira-

De : Emmanuel Lecharny elecha...@gmail.com
À : dev@mina.apache.org
Envoyé le : Samedi 20 Août 2011 9h29
Objet : Re: [MINA 3.0] filter chains

On 8/20/11 8:49 AM, Julien Vermillard wrote:
 Hi,
 Because a filterchain can be shared across different sessions and
 threads, so you need to pass the local chain index because you can
 store it locally in the filter chain. Perhaps there is something
 smarter to do, because it's the dark point of this API.

The filter chain is copied into the session (at least, it was what was 
done for MINA 2). Assuming that two different sessions might use two 
different chains, and assumng that the chain might be dynamically 
changed, it makes sense to do this copy.

Now, if we can split the session (using an executor for instance), then 
the chain must be copied. It would make sense to store the chain into a 
ThreadLocal variable instead of storing it into a session object.

 Julien

 On Sat, Aug 20, 2011 at 12:41 AM, Alan D. Cabreral...@toolazydogs.com  
 wrote:
 Why do we pass the current position?  We also seem to pass it twice in the 
 method and the controller.


 Regards,
 Alan

 On Aug 19, 2011, at 1:10 PM, Julien Vermillard wrote:

 Ok I committed the modification, for passing a chain controller to the
 filter for delegating the call to next filter.

 First I did it only for read  write chaining because the other events
 (created,open,closed,idle) are fine like they are. They don't need to
 block an event or send it multiple time to the following filter.

 Here the modified IoFilter, some controller interface are passed to
 read  write events :
 http://svn.apache.org/repos/asf/mina/branches/3.0/core/src/main/java/org/apache/mina/api/IoFilter.java


 Here sample implementation of LoggingFilter :
 http://svn.apache.org/repos/asf/mina/branches/3.0/core/src/main/java/org/apache/mina/filter/logging/LoggingFilter.java

 Here the FilterChain implementation, still simple :
 http://svn.apache.org/repos/asf/mina/branches/3.0/core/src/main/java/org/apache/mina/filterchain/DefaultIoFilterChain.java

 Now I need to figure how to remove the current position argument of
 the filter call.

 Julien


 On Fri, Aug 19, 2011 at 2:46 PM, Julien Vermillard
 jvermill...@gmail.com  wrote:
 I half implemented the controller idea, it's looking like working,
 I'll finish that during the weekend or next week and commit it for
 review.
 Julien

 On Fri, Aug 19, 2011 at 2:39 PM, Steve Ulrichsteve.ulr...@proemion.com  
 wrote:
 Hi!

 Besides the points you mentioned, there are some other flaws:
 1) How do you handle post-message-forwarding logic?
 2) How do you handle filters that transparently push messages to the 
 underlying filters (e.g. keep alive)?

 So the filters should decide about what to do, the chain about the where.

 regards

 Steve

 There could be specific (empty, single-result, multi-result) 
 implementations that can be extended as needed.

 Julien Vermillard [mailto:jvermill...@gmail.com] wrote:

 Hi,
 I implemented some really simple chain for MINA 3 based on a list of
 chain processed by a filter chain.

 The implementation is very simple, sounded like a good idea :
 http://svn.apache.org/repos/asf/mina/branches/3.0/core/src/main/java/or
 g/apache/mina/filterchain/DefaultIoFilterChain.java

 But when i started implementing an HTTP codec  I started to see the
 real design issues.
 The problem is when you need to produce more than one object during a
 filter processing, like when you find more than one PDU in a
 ByteBuffer.

 We could change IoFilter method :
    Object messageReceived(IoSession session, Object message);
 To :
    ListObject  messageReceived(IoSession session, Object message);

 But starting to use collection here sound like an overkill and not
 really a nice idea if we want to keep the memory usage low enough.

 So I'm scraping the current implementation, I'm going to try something
 else suggested by Emmanuel

Re : [3.0.0] Acceptors/connectors

2010-09-30 Thread Edouard De Oliveira
Yup ashish it's exactly that althought i had terrible time with some other 
parts 
of the implementation which would be nice to improve in 3.0 (but it was a long 
time ago so i just have vague memories of it right now)
 Cordialement, Regards,
-Edouard De Oliveira-
WebSite: http://tedorg.free.fr/en/main.php



- Message d'origine 
De : Ashish paliwalash...@gmail.com
À : dev@mina.apache.org; elecha...@apache.org
Envoyé le : Mer 29 septembre 2010, 14h 45min 11s
Objet : Re: [3.0.0] Acceptors/connectors

On Wed, Sep 29, 2010 at 10:38 AM, Ashish paliwalash...@gmail.com wrote:
 On Wed, Sep 29, 2010 at 5:26 AM, Emmanuel Lecharny elecha...@gmail.com 
wrote:
  Hi,

 yesterday I reviewed the Service interface and the associated hierarchy.
 basically, we have either Acceptors or Connectors.

 From those two interfaces, we derive :
 (Acceptors) : NioDatagramAcceptor, AprSocketAcceptor, NioSocketAcceptor,
 VmPipeSocketAcceptor
 (Connectors) : NioDatagramConnector, AprSocketConnector, NioSocketConnector,
 VmPipeSocketConnector plus some extra connectors, SerialConnector and
 ProxyConnector

 I don't know why the VmPipeSocketConnector has 'socket' in it, because
 AFAIU, it has nothing to do with Socket. I don't know what the
 ProxyConnector is good for, but I must admit I didn't checked the code.
 Anyone has a clue?

 IMHO, just to have uniformity.
 I can look into ProxyConnector and find something.

Could not find VmPipeSocketConnector class, the code does have
VmPipeConnector :(

Had a quick look at ProxyConnector. It intercepts your connect
requests, and instead of connecting to intended destination,
connects to a Proxy. Its a nice way to implement a Proxy over various
transports :)

I liked it.







Re : MDC test error on windows

2010-05-04 Thread Edouard De Oliveira
It's been a while that this test is failing randomly under windows i'm quite 
sure that it already failed before RC1
 Cordialement, Regards,
-Edouard De Oliveira-


- Message d'origine 
De : Emmanuel Lecharny elecha...@apache.org
À : dev@mina.apache.org
Envoyé le : Mar 4 mai 2010, 16 h 44 min 45 s
Objet : Re: MDC test error on windows

On Mon, May 3, 2010 at 6:03 PM, Ashish paliwalash...@gmail.com wrote:

 I tried reproducing this locally, but haven't had any success so far :(

 Any suggestions how can I reproduce the same?

The test will fail only 1/3 of the time. You may have to run it many times
though.



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







Re : ConnectFuture confusion

2010-03-02 Thread Edouard De Oliveira
There are months i'm thinking the same without daring to say so ...
The problem is that 1.x branches have been abandonned long time ago and much 
people are indeed waiting for the release of this 2.0
how bad would it be to release it for the early adopters with a 'use it at your 
own risk' warning and invite new comers to wait for a 3.0 preview ?
would it be acceptable for the community to say that we won't support it 
extensively as our efforts will be concentrated on 3.0 ?

Maybe it's the right time to shake the anthill or maybe not ...
my 2 cents

 Cordialement, Regards,
-Edouard De Oliveira-




- Message d'origine 
De : Emmanuel Lecharny elecha...@gmail.com
À : dev@mina.apache.org
Envoyé le : Lun 1 Mars 2010, 18 h 45 min 02 s
Objet : Re: ConnectFuture confusion

On 3/1/10 6:30 PM, Alan D. Cabrera wrote:
 
 On Mar 1, 2010, at 9:20 AM, Emmanuel Lecharny wrote:
 
 On 3/1/10 6:10 PM, Alan D. Cabrera wrote:
 
 On Mar 1, 2010, at 8:04 AM, Emmanuel Lecharny wrote:
 
 On 3/1/10 4:38 PM, Alan D. Cabrera wrote:
 
 On Feb 26, 2010, at 9:03 AM, Ashish wrote:
 
 
 Thoughts ?
 
 Unless it breaks the system, i would say lets not loose our sleep over 
 this.
 
 While I share the same opinion about the IoFuture hierarchy as you I have 
 the same sentiments as Ashish.
 I'm afraid that we might have to fix the issue in 2.0 Trust me, i'm 
 not pleased with this !
 
 Fixing a bug is one thing.  Reorganizing a code base a few days after an 
 attempted vote on its initial release is another.
 
 I know :/ This is why I created a branch, in a desesperate attempt to get 
 rid of all those futures, instead of doing that in trunk. Now, it was the 
 end of a long and painful week, chasing many bugs in many places, and I was 
 turning in circle.
 
 I *wish* we can fix the bug, without having to rewrite this part.
 
 Another alternative is to totally abandon 2.x.  It was never officially 
 released.  Just leave it as it is and work on the new 2.x
I'm also considering this option...

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






Re : About CircularQueue

2010-02-15 Thread Edouard De Oliveira
If CircularQueue is a core class then we don't have to support anything 
external using it.
If someone needs it for own code, it can be extracted from svn history 

HashMap, HashSet :
as long as interfaces are used and performances are improved, i think it's 
pretty clearly
a good move IMHO
 Cordialement, Regards,
-Edouard De Oliveira-
Blog: http://tedorgwp.free.fr
WebSite: http://tedorg.free.fr/en/main.php



- Message d'origine 
De : Ashish paliwalash...@gmail.com
À : dev@mina.apache.org; elecha...@apache.org
Envoyé le : Lun 15 Février 2010, 11 h 54 min 51 s
Objet : Re: About CircularQueue

On Mon, Feb 15, 2010 at 4:12 PM, Emmanuel Lecharny elecha...@gmail.com wrote:
 Hi guys,

 yesterday I removed all references to the non-thread-safe CircularQueue data
 structure, and replaced it with a ConcurrentLinkedQueue.
 Not only this is a comparable data structure, but it's also thread safe, and
 tested.

 Now, the question : should we remove the CircularQueue data structure from
 the code base, assuming that it should only be used by MINA core, and not by
 user, or simply deprecate it ?


Will marking it as depreciated help anyone?
We have removed it from core :-). I think we need to ask this question
in User ML as well

 I also have some concern about the existence of HashMap in MINA. We have 149
 references to this data structure which is really slow when run on
 mlti-threaded environment. I suggest we replace all of those references in
 core by ConcurrentHashMap
 (http://www.javamex.com/tutorials/synchronization_concurrency_8_hashmap.shtml).
 The very same for HashSet which is also used a lot.

 Thoughts ?

hmm.. would love to get rid of them. I hope it doesn't break anything :-)

thanks
ashish







Re : [MINA 3.0] Acceptor/Connector

2010-02-15 Thread Edouard De Oliveira
Absolutely right here 
BIG +1

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



- Message d'origine 
De : Julien Vermillard jvermill...@archean.fr
À : dev@mina.apache.org
Envoyé le : Lun 15 Février 2010, 13 h 30 min 37 s
Objet : Re: [MINA 3.0] Acceptor/Connector

Le Mon, 15 Feb 2010 12:20:49 +0100,
Emmanuel Lecharny elecha...@gmail.com a écrit :

 Hi guys,
 
 since day one, I found that Acceptor/Connector are technical names,
 not user friendly names.
 
 Let's face the real world : we are not developping Acceptors, not 
 Connectors, but Servers and Clients. Can't we rename those two guys
 to IoServer and IoClient instead of IoAcceptor and IoConnector ?
 
 I know this is just cosmetic, but if it helps people to understand
 the kind of objects they are manipulating, I think it would worth the
 change
 
 thoughts ?
 

+1



-- 
Julien Vermillard

Archean Technologies
http://www.archean.fr







Re : Are we ready for MINA 2.0.0-RC2 ?

2010-01-25 Thread Edouard De Oliveira
deep purple one is very cool :)
 Cordialement, Regards,
-Edouard De Oliveira-



- Message d'origine 
De : Emmanuel Lcharny elecha...@gmail.com
À : dev@mina.apache.org
Envoyé le : Lun 25 Janvier 2010, 18 h 27 min 14 s
Objet : Re: Are we ready for MINA 2.0.0-RC2 ?

Julien Vermillard a écrit :
 Le Mon, 25 Jan 2010 06:09:41 -0700,
 Jeff Genender jgenen...@savoirtech.com a écrit :

  
 On Jan 25, 2010, at 1:23 AM, Julien Vermillard wrote:


 Hi,
 IMO it's  dot zero ready, the main effort is on the website and all
 the PR stuff implying the 2.0 release.
 it would be a shame to release 2.0 without good announcement and an
 updated/cleaned website.

  
 So lets do that ;-)

 Jeff



 I created a MINA2 space in confluence for preparing the new website
 (removing all the old 1.X references).
  

Here is the new mina 2 site :
http://mina.apache.org/mina2/

If you can't wait a few hours that the mirrors get updated, you can ook 
at it using a proxy :
140.211.11..10:80

There is no content yet, just a new design taken from ADS.

If you don't like the deep purple (shame on you ! The best 70's band !) 
header, I have a dark grey one.

Just let me now.







Re : [ANN] MINA PMC += Ashish Paliwal

2010-01-21 Thread Edouard De Oliveira
congrats





- Message d'origine 
De : Ashish paliwalash...@gmail.com
À : dev@mina.apache.org
Envoyé le : Jeu 21 Janvier 2010, 11 h 19 min 32 s
Objet : Re: [ANN] MINA PMC += Ashish Paliwal

Thanks !

On Thu, Jan 21, 2010 at 3:48 PM, Niklas Gustavsson nik...@protocol7.com wrote:
 On Thu, Jan 21, 2010 at 11:12 AM, Julien Vermillard
 jvermill...@archean.fr wrote:
 after a vote with no -1 or +0, Ashish Paliwal, a well known name here,
 joined the Project Management Committee (PMC).

 Very much deserved, congrats Ashish!

 /niklas




-- 
thanks
ashish

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







Re : Not sure why...

2010-01-19 Thread Edouard De Oliveira
The point is to react differently in case of different exceptions 
but exceptions must be sorted from specific exceptions to generic ones
it can also be done by catching exception and using instanceof statements

my 2 cents :)

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



- Message d'origine 
De : Alan D. Cabrera l...@toolazydogs.com
À : dev@mina.apache.org
Envoyé le : Mar 19 Janvier 2010, 16 h 12 min 41 s
Objet : Re: Not sure why...

org.apache.mina.transport.socket.apr.AprIoProcessor


Regards,
Alan

On Jan 19, 2010, at 6:44 AM, Ashish wrote:

 Where did u pulled this out from ?
 
 On Tue, Jan 19, 2010 at 8:11 PM, Alan D. Cabrera l...@toolazydogs.com wrote:
try {
doSomeStuff();
} catch (RuntimeException e) {
throw e;
} catch (Error e) {
throw e;
} catch (Exception e) {
throw new RuntimeIoException(Failed to create a pollset., e);
} finally {
   cleanUp();
}
 
 What's the point in catching and re-throwing RuntimeException and Error?
 
 
 Regards,
 Alan
 
 
 
 
 
 
 --thanks
 ashish
 
 Blog: http://www.ashishpaliwal.com/blog
 My Photo Galleries: http://www.pbase.com/ashishpaliwal






Re : What about releasing a 2.0-RC2/2.0.0 ?

2010-01-12 Thread Edouard De Oliveira
I'm sorry but after examining the remaining bug list i think 
https://issues..apache.org/jira/browse/DIRMINA-711 must be fixed before issuing 
2.0.0 the framework can't fail because we just add some logs otherwise we must 
make this mdc feature optionnal  

I'm really in favor of releasing 2.0.0 and creating dynamicity in the community 
let just fix 711

-1 (for a short moment i hope)
 Cordialement, Regards,
-Edouard De Oliveira-
Blog: http://tedorgwp.free.fr
WebSite: http://tedorg.free.fr/en/main.php



- Message d'origine 
De : Julien Vermillard jvermill...@archean.fr
À : dev@mina.apache.org
Envoyé le : Mar 12 Janvier 2010, 18 h 35 min 01 s
Objet : Re: What about releasing a 2.0-RC2/2.0.0 ?

Le Tue, 12 Jan 2010 18:02:41 +0100,
Emmanuel Lecharny elecha...@gmail.com a écrit :

 We have fixed some important issues lately in 2.0-RC1 :
 DIRMINA-749 : We cannot anymore inject more than one CODEC in the
 chain. DIRMINA-678 : NioProcessor 100% CPU usage on Linux (epoll
 selector bug) DIRMINA-650 : Mina server does not recieve all data
 sent by client using SSLSocketFactory
 
 Isn't it time for a new release ? Should we call it 2.0.0 ?
 

+1


-- 
Julien Vermillard

Archean Technologies
http://www.archean.fr







Re : Death to TRS80 coders

2009-11-29 Thread Edouard De Oliveira
my +1 

even if sometimes i write code on my 10 netbook 
 Cordialement, Regards,
-Edouard De Oliveira-
Blog: http://tedorgwp.free.fr
WebSite: http://tedorg.free.fr/en/main.php



- Message d'origine 
De : Ashish paliwalash...@gmail.com
À : dev@mina.apache.org
Envoyé le : Dim 29 Novembre 2009, 3 h 01 min 06 s
Objet : Re: Death to TRS80 coders

+1,

have been using 120. Now with higher screen resolutions, we can afford that :)

- ashish

On Sun, Nov 29, 2009 at 2:12 AM, Julien Vermillard
jvermill...@archean.fr wrote:
 Le Sat, 28 Nov 2009 09:06:59 -0800,
 Alan D. Cabrera l...@toolazydogs.com a écrit :

 May I suggest that for Mina 3.0 we refrain from arbitrarily wrapping
 the code when it passes 80 characters?  It makes it crazy hard to
 read the code.


 Regards,
 Alan


 +1,
 I like 120 char wrapping.







Re : 2 Tests failing in MINA trunk build

2009-07-02 Thread Edouard De Oliveira

This is tracked in DIRMINA-711

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



- Message d'origine 
De : Emmanuel Lecharny elecha...@apache.org
À : dev@mina.apache.org
Envoyé le : Jeudi, 2 Juillet 2009, 14h56mn 48s
Objet : Re: 2 Tests failing in MINA trunk build

Maarten Bosteels wrote:
 Will try to have a look asap.
  
/me Running mvn clean install atm.

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





[jira] Commented: (DIRMINA-188) All-in-one JAR

2009-07-01 Thread Edouard De Oliveira (JIRA)

[ 
https://issues.apache.org/jira/browse/DIRMINA-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12726230#action_12726230
 ] 

Edouard De Oliveira commented on DIRMINA-188:
-

this plugin has been deprecated, i'm just using assembly and trying to build a 
sort of mina-all.jar

 All-in-one JAR
 --

 Key: DIRMINA-188
 URL: https://issues.apache.org/jira/browse/DIRMINA-188
 Project: MINA
  Issue Type: Task
Reporter: Trustin Lee
Assignee: Edouard De Oliveira
Priority: Minor
 Fix For: 2.0.0-M7


 We need two kinds of all-in-one JARs:
 * A JAR file which contains all modules
 * A JAR file which contains all modules and dependencies
 Perhaps we could create two uberjar projects.

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



Re : MIA for a while

2009-06-30 Thread Edouard De Oliveira

You're welcome np

I've been fighting back OrderedThreadPool, ExecutorFilter for quite a moment 
and the more i digg the more i get lost ...
so few progress has been made these last days even if i hope some kind of holy 
light to show me the path through this mess ^^ 
Meanwhile i'm doing graphs and drawings to make my mind clear ...

Don't worry, if necessary we will go and save private Emmanuel ;p
 Cordialement, Regards,
-Edouard De Oliveira-
Blog: http://tedorgwp.free.fr
WebSite: http://tedorg.free.fr/en/main.php 



- Message d'origine 
De : Emmanuel Lecharny elecha...@apache.org
À : dev@mina.apache.org; us...@mina.apache.org
Envoyé le : Mardi, 30 Juin 2009, 9h47mn 27s
Objet : MIA for a while

Hi guys,

just to let you know that I'm not able to work on MINA issues until I get a 
damn bad bug fixed in Apache Directory Server. I have been MIA for more than 
one week now, not that I'm not interested by any bugs we have in MINA, but 
because I don't have time to dedicate to MINA bug fixing atm.

I have to thank Edouard who is squeezing the MINA bug list those days, quite 
efficiently, so I feel a bit less guilty :/

Fanti, I'm still having your problem pending in my mind, just I don't have time 
for it.

Many thanks !

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


  


[jira] Updated: (DIRMINA-659) AccessControlException when running MINA in a Applet: RuntimePermission modifyThread

2009-06-30 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira updated DIRMINA-659:


  Component/s: Web Site / Documentation
Fix Version/s: 2.0.0-M7
   Issue Type: Task  (was: Bug)

Added some doc on the wiki

 AccessControlException when running MINA in a Applet: RuntimePermission 
 modifyThread
 --

 Key: DIRMINA-659
 URL: https://issues.apache.org/jira/browse/DIRMINA-659
 Project: MINA
  Issue Type: Task
  Components: Web Site / Documentation
Affects Versions: 2.0.0-M4
 Environment: Java 5 Applet (using appletviewer)
Reporter: Jeff Mesnil
Assignee: Edouard De Oliveira
 Fix For: 2.0.0-M7


 I'm using MINA 2.0.0-M4 within a restricted environment (an Applet in my 
 case, could also be JNLP).
 When running the code in appletviewer, I need to add a permission for the 
 code to be executed successfully:
  permission java.lang.RuntimePermission modifyThread;
 If I don't add this permission, the code fails with the following stack trace:
 Exception in thread pool-2-thread-1 java.security.AccessControlException: 
 access denied (java.lang.RuntimePermission modifyThread)
   at 
 java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
   at 
 java.security.AccessController.checkPermission(AccessController.java:427)
   at 
 java.util.concurrent.ThreadPoolExecutor.shutdown(ThreadPoolExecutor.java:893)
   at 
 org.apache.mina.core.service.SimpleIoProcessorPool.dispose(SimpleIoProcessorPool.java:230)
   at 
 org.apache.mina.core.polling.AbstractPollingIoConnector$Connector.run(AbstractPollingIoConnector.java:512)
   at 
 org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:65)
   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:613)
 The exception occurs when I close the SocketConnector:
public synchronized void close()
{
   if (connector != null)
   {
  connector.dispose();
  connector = null;
   }
}

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



[jira] Closed: (DIRMINA-659) AccessControlException when running MINA in a Applet: RuntimePermission modifyThread

2009-06-30 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira closed DIRMINA-659.
---

Resolution: Fixed

 AccessControlException when running MINA in a Applet: RuntimePermission 
 modifyThread
 --

 Key: DIRMINA-659
 URL: https://issues.apache.org/jira/browse/DIRMINA-659
 Project: MINA
  Issue Type: Task
  Components: Web Site / Documentation
Affects Versions: 2.0.0-M4
 Environment: Java 5 Applet (using appletviewer)
Reporter: Jeff Mesnil
Assignee: Edouard De Oliveira
 Fix For: 2.0.0-M7


 I'm using MINA 2.0.0-M4 within a restricted environment (an Applet in my 
 case, could also be JNLP).
 When running the code in appletviewer, I need to add a permission for the 
 code to be executed successfully:
  permission java.lang.RuntimePermission modifyThread;
 If I don't add this permission, the code fails with the following stack trace:
 Exception in thread pool-2-thread-1 java.security.AccessControlException: 
 access denied (java.lang.RuntimePermission modifyThread)
   at 
 java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
   at 
 java.security.AccessController.checkPermission(AccessController.java:427)
   at 
 java.util.concurrent.ThreadPoolExecutor.shutdown(ThreadPoolExecutor.java:893)
   at 
 org.apache.mina.core.service.SimpleIoProcessorPool.dispose(SimpleIoProcessorPool.java:230)
   at 
 org.apache.mina.core.polling.AbstractPollingIoConnector$Connector.run(AbstractPollingIoConnector.java:512)
   at 
 org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:65)
   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:613)
 The exception occurs when I close the SocketConnector:
public synchronized void close()
{
   if (connector != null)
   {
  connector.dispose();
  connector = null;
   }
}

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



[jira] Resolved: (DIRMINA-714) Packet sequence is unordered in multi thread.

2009-06-30 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira resolved DIRMINA-714.
-

Resolution: Fixed

After much code crawling and testing, i came to the conclusion that the issue 
is now fixed.

If using the rewritten sequence test code provided as is it will probably fail 
because of the following tricky sequence

thread y / session S2 wants to write a message with seq=1 but it is stopped 
after getting the seq number
thread x / session S1 enter the messageReceived method and broadcasts a msg to 
all sessions (S1  S2)
when writing to S2 it gets the seq=2 sequence number and writes but seq=1 was 
expected so it fails

So the problem is in the logic not in the filter nor in the Executor
Removing the broadcast call makes the test run flawlessly

 Packet sequence is unordered in multi thread.
 -

 Key: DIRMINA-714
 URL: https://issues.apache.org/jira/browse/DIRMINA-714
 Project: MINA
  Issue Type: Bug
  Components: Filter
Affects Versions: 2.0.0-M5
 Environment: xp
Reporter: ncanis2
Assignee: Edouard De Oliveira
 Fix For: 2.0.0-M7

 Attachments: mina_m6_seq_test_src.zip, org.zip


 Hi.
 Packet sequence is unordered.
 = Server  Client = 
 chain.addLast(codec, new ProtocolCodecFilter(rcf));
 chain.addLast(executor, getExecuteFilter());= 
 OrderedThreadPoolExecutor c = new OrderedThreadPoolExecutor(20,100);
 If server send 1,2,3,4,5,6 , client receive 1,2,3,4,6  from server.
 Clients : 100.
 where I am wrong? 

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



Re : svn commit: r789164 - /mina/trunk/core/src/main/java/org/apache/mina/core/service/SimpleIoProcessorPool.java

2009-06-29 Thread Edouard De Oliveira

Yes 
in previous version each constructor type was tested again and again in the 
loop 
The new code is slightly more complex but it is based on the fact that we need 
at least one processor 
so we discover which constructor to use and then we loop and use the previously 
determined constructor.

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



- Message d'origine 
De : Julien Vermillard jvermill...@apache.org
À : dev@mina.apache.org
Envoyé le : Lundi, 29 Juin 2009, 11h13mn 24s
Objet : Re: svn commit: r789164 - 
/mina/trunk/core/src/main/java/org/apache/mina/core/service/SimpleIoProcessorPool.java

Hi,
Interesting optimization. The idea is to make SimpleIoPPool
instantiation faster ?
Julien

On Mon, Jun 29, 2009 at 12:30 AM, edeolive...@apache.org wrote:
 Author: edeoliveira
 Date: Sun Jun 28 22:30:02 2009
 New Revision: 789164

 URL: http://svn.apache.org/viewvc?rev=789164view=rev
 Log:
 Fix to do less reflection ops whilie initialising the pool

 Modified:

 mina/trunk/core/src/main/java/org/apache/mina/core/service/SimpleIoProcessorPool.java

 Modified: 
 mina/trunk/core/src/main/java/org/apache/mina/core/service/SimpleIoProcessorPool.java
 URL: 
 http://svn.apache.org/viewvc/mina/trunk/core/src/main/java/org/apache/mina/core/service/SimpleIoProcessorPool.java?rev=789164r1=789163r2=789164view=diff
 ==
 --- 
 mina/trunk/core/src/main/java/org/apache/mina/core/service/SimpleIoProcessorPool.java
  (original)
 +++ 
 mina/trunk/core/src/main/java/org/apache/mina/core/service/SimpleIoProcessorPool.java
  Sun Jun 28 22:30:02 2009
 @@ -19,6 +19,7 @@
  */
  package org.apache.mina.core.service;

 +import java.lang.reflect.Constructor;
  import java.util.concurrent.Executor;
  import java.util.concurrent.ExecutorService;
  import java.util.concurrent.Executors;
 @@ -73,44 +74,57 @@
  * @param T the type of the {...@link IoSession} to be managed by the 
 specified
  *{...@link IoProcessor}.
  */
 -public class SimpleIoProcessorPoolT extends AbstractIoSession implements 
 IoProcessorT {
 -
 -private static final int DEFAULT_SIZE = 
 Runtime.getRuntime().availableProcessors() + 1;
 -private static final AttributeKey PROCESSOR = new 
 AttributeKey(SimpleIoProcessorPool.class, processor);
 -
 -private final static Logger LOGGER = 
 LoggerFactory.getLogger(SimpleIoProcessorPool.class);
 +public class SimpleIoProcessorPoolT extends AbstractIoSession implements
 +IoProcessorT {
 +
 +private static final int DEFAULT_SIZE = Runtime.getRuntime()
 +.availableProcessors() + 1;
 +
 +private static final AttributeKey PROCESSOR = new AttributeKey(
 +SimpleIoProcessorPool.class, processor);
 +
 +private final static Logger LOGGER = LoggerFactory
 +.getLogger(SimpleIoProcessorPool.class);

 private final IoProcessorT[] pool;
 +
 private final AtomicInteger processorDistributor = new AtomicInteger();
 +
 private final Executor executor;
 +
 private final boolean createdExecutor;
 -
 +
 private final Object disposalLock = new Object();
 +
 private volatile boolean disposing;
 +
 private volatile boolean disposed;
 -
 +
 public SimpleIoProcessorPool(Class? extends IoProcessorT 
 processorType) {
 this(processorType, null, DEFAULT_SIZE);
 }
 -
 -public SimpleIoProcessorPool(Class? extends IoProcessorT 
 processorType, int size) {
 +
 +public SimpleIoProcessorPool(Class? extends IoProcessorT 
 processorType,
 +int size) {
 this(processorType, null, size);
 }

 -public SimpleIoProcessorPool(Class? extends IoProcessorT 
 processorType, Executor executor) {
 +public SimpleIoProcessorPool(Class? extends IoProcessorT 
 processorType,
 +Executor executor) {
 this(processorType, executor, DEFAULT_SIZE);
 }
 -
 +
 @SuppressWarnings(unchecked)
 -public SimpleIoProcessorPool(Class? extends IoProcessorT 
 processorType, Executor executor, int size) {
 +public SimpleIoProcessorPool(Class? extends IoProcessorT 
 processorType,
 +Executor executor, int size) {
 if (processorType == null) {
 throw new NullPointerException(processorType);
 }
 if (size = 0) {
 -throw new IllegalArgumentException(
 -size:  + size +  (expected: positive integer));
 +throw new IllegalArgumentException(size:  + size
 ++  (expected: positive integer));
 }
 -
 +
 if (executor == null) {
 this.executor = executor = Executors.newCachedThreadPool();
 this.createdExecutor = true;
 @@ -118,56 +132,72 @@
 this.executor = executor;
 this.createdExecutor = false;
 }
 -
 +
 pool = new IoProcessor[size];
 -
 +
 boolean success

Re : About MINA commits with some code refactoring

2009-06-29 Thread Edouard De Oliveira

+1 You're perfectly right to prefer spam instead of difficult commits to read ^^
 Cordialement, Regards,
-Edouard De Oliveira-
Blog: http://tedorgwp.free.fr
WebSite: http://tedorg.free.fr/en/main.php



- Message d'origine 
De : Julien Vermillard jvermill...@archean.fr
À : dev@mina.apache.org
Envoyé le : Lundi, 29 Juin 2009, 11h11mn 20s
Objet : Re: About MINA commits with some code refactoring

Le Mon, 29 Jun 2009 11:08:33 +0200,
Emmanuel Lecharny elecha...@apache.org a écrit :

 Hi guys,
 
 recently I saw some commits on MINA where some code has been
 refactored (like lines were limited to 80 caracters, stuff like that).
 
 I don't think it's a bad thing to do code refactoring, but the
 problem is that when it's mixed with some code addition, it buries
 the fixes into a lot of refactoring, and it's difficult for reviewers
 to check the fixes.
 
 My personal guess is that those who are committing such code are
 using some specific options on their favorite IDE, leading to such
 injection of code.
 
 It's not only about line splitting, it can be addition of windows
 style EOL, or even tabs. I'm not free from such injections, I must
 admit.
 
 There is a Eclipse formating file for those who are using Eclipse,
 that must be used in order to avoid such automatic refactoring :
 http://mina.apache.org/developer-guide.html#DeveloperGuide-CodingConvention
 
 If you are using another IDE, it could be cool to create the same
 kind of file.
 
 Last, not least, if you think the file need to be refactored, feel
 free to do so, but *please*, do that in a separate commit : first
 refactor the code, commit it and then fix the code and commit again.
 
 
 Many thanks !
 
+1
It's painful to decipher some commits.

Julien






Re : Re : About MINA commits with some code refactoring

2009-06-29 Thread Edouard De Oliveira

Eclipse and i do use the convention formatting file
usually i work under windows but in the past two weeks i've been using it in 
sun's virtualbox running latest ubuntu

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



- Message d'origine 
De : Emmanuel Lecharny elecha...@apache.org
À : dev@mina.apache.org
Envoyé le : Lundi, 29 Juin 2009, 15h08mn 18s
Objet : Re: Re : About MINA commits with some code refactoring

Edouard De Oliveira wrote:
 +1 You're perfectly right to prefer spam instead of difficult commits to read 
 ^^
  

Just for my information, which IDE are you using ?

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





[jira] Commented: (DIRMINA-714) Packet sequence is unordered in multi thread.

2009-06-25 Thread Edouard De Oliveira (JIRA)

[ 
https://issues.apache.org/jira/browse/DIRMINA-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12724002#action_12724002
 ] 

Edouard De Oliveira commented on DIRMINA-714:
-

I do not agree with you but id should have been more explanatory

as you can see your problem is not the same as described in the initial issue
so message ordering has been fixed

but on the other hand you now get the same problem as DIRMINA-679 (NPE in the 
ProtocolCodecFilter.filterWirte)
I may have a dirty fix ( i'm not 100% sure why for the moment) for this one:
in  ProtocolCodecFilter comment the following line in the onPostRemove method :
disposeCodec(parent.getSession());

After this you may get some logs throwing a WriteToClosedSessionException but 
these are catched logs and they don't hurt the logic.

Please confirm these assumptions. 
If so i will recheck this one as fixed and maybe try to investigate DIRMINA-679 
if i get time to do so.

Hint: you can also avoid this last problem by introducing a close ack on your 
protocol:
client sends a close command , server acks and closes the connection this would 
eliminate your problem which occurs because there's still some messages to 
write when server gets the session closed signal.


 Packet sequence is unordered in multi thread.
 -

 Key: DIRMINA-714
 URL: https://issues.apache.org/jira/browse/DIRMINA-714
 Project: MINA
  Issue Type: Bug
  Components: Filter
Affects Versions: 2.0.0-M5
 Environment: xp
Reporter: ncanis2
Assignee: Edouard De Oliveira
 Fix For: 2.0.0-M7

 Attachments: mina_m6_seq_test_src.zip, org.zip


 Hi.
 Packet sequence is unordered.
 = Server  Client = 
 chain.addLast(codec, new ProtocolCodecFilter(rcf));
 chain.addLast(executor, getExecuteFilter());= 
 OrderedThreadPoolExecutor c = new OrderedThreadPoolExecutor(20,100);
 If server send 1,2,3,4,5,6 , client receive 1,2,3,4,6  from server.
 Clients : 100.
 where I am wrong? 

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



[jira] Commented: (DIRMINA-714) Packet sequence is unordered in multi thread.

2009-06-24 Thread Edouard De Oliveira (JIRA)

[ 
https://issues.apache.org/jira/browse/DIRMINA-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12723745#action_12723745
 ] 

Edouard De Oliveira commented on DIRMINA-714:
-

in my last tests i used the following setup:

chain.addLast(codec, new ProtocolCodecFilter(rcf));
chain.addLast(executor, new ExecutorFilter(20, 100)); 

 Packet sequence is unordered in multi thread.
 -

 Key: DIRMINA-714
 URL: https://issues.apache.org/jira/browse/DIRMINA-714
 Project: MINA
  Issue Type: Bug
  Components: Filter
Affects Versions: 2.0.0-M5
 Environment: xp
Reporter: ncanis2
Assignee: Edouard De Oliveira
 Fix For: 2.0.0-M7

 Attachments: mina_m6_seq_test_src.zip, org.zip


 Hi.
 Packet sequence is unordered.
 = Server  Client = 
 chain.addLast(codec, new ProtocolCodecFilter(rcf));
 chain.addLast(executor, getExecuteFilter());= 
 OrderedThreadPoolExecutor c = new OrderedThreadPoolExecutor(20,100);
 If server send 1,2,3,4,5,6 , client receive 1,2,3,4,6  from server.
 Clients : 100.
 where I am wrong? 

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



[jira] Resolved: (DIRMINA-642) Disposing an IoConnector blocks forever

2009-06-24 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira resolved DIRMINA-642.
-

Resolution: Incomplete

After reviewing the pointed out code portion and as long as we don't have 
enough info we cannot process this issue.

 Disposing an IoConnector blocks forever
 ---

 Key: DIRMINA-642
 URL: https://issues.apache.org/jira/browse/DIRMINA-642
 Project: MINA
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0.0-M3
 Environment: Linux
Reporter: Thomas Berger
Assignee: Edouard De Oliveira

 nHandles in the class Worker (AbstractPollingIoConnector) gets negative: -1 
 in my case.  Then the dispose() method blocks forever as the while loop in 
 this worker class never breaks. Reproducing this error is pretty hard, as it 
 usually happens after several hours. I will do a quick fix and check if 
 nHandles=0. 
 I think it may be related to http://issues.apache.org/jira/browse/DIRMINA-632 
 as I never block for a write in my app. However, I get some 
 WriteToClosedSessionException. Is it possible that this causes nHandles to 
 become negative?

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



Re : [jira] Commented: (DIRMINA-188) All-in-one JAR

2009-06-23 Thread Edouard De Oliveira

My fix uses the already in use assembly plugin and will produce an all in one 
jar containaing all classes from all mina modules. Adding this produced jar to 
the existing distributions may be interesting.

Uberjar plugin seems to be deprecated according to the official page. 

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



- Message d'origine 
De : Bernd Fondermann (JIRA) j...@apache.org
À : dev@mina.apache.org
Envoyé le : Mardi, 23 Juin 2009, 13h42mn 07s
Objet : [jira] Commented: (DIRMINA-188) All-in-one JAR


[ 
https://issues.apache.org/jira/browse/DIRMINA-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12723048#action_12723048
 ] 

Bernd Fondermann commented on DIRMINA-188:
--

You mean, the uber-jar plugin? Works pretty well and it has its benefits. Also, 
takes practically no time maintaining.

 All-in-one JAR
 --

 Key: DIRMINA-188
 URL: https://issues.apache.org/jira/browse/DIRMINA-188
 Project: MINA
  Issue Type: Task
Reporter: Trustin Lee
Assignee: Edouard De Oliveira
Priority: Minor
 Fix For: 2.0.0-M7


 We need two kinds of all-in-one JARs:
 * A JAR file which contains all modules
 * A JAR file which contains all modules and dependencies
 Perhaps we could create two uberjar projects.

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





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

2009-06-23 Thread Edouard De Oliveira

We may have users out there using it so i think adding some doco, marking it as 
deprecated and coumenting the fact it isn't scalable should be enough for 2.0 

Should i also at the same time mark the netty2 package as deprecated as 
obviously we also won't delete it but won't support it for 2.0 ? 

These two will be removed later on for 2.1 or 3.0 ...

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



- Message d'origine 
De : Maarten Bosteels mbosteels@gmail.com
À : dev@mina.apache.org
Envoyé le : Mardi, 23 Juin 2009, 10h30mn 14s
Objet : Re: Re : [jira] Updated: (DIRMINA-612) Add documentation on  
SingleSessionIohandler

OK for me to remove SingleSessionIohandler

Maarten

On Mon, Jun 22, 2009 at 8:32 PM, Emmanuel Lecharny elecha...@apache.orgwrote:

 Edouard De Oliveira wrote:

 I would really like some comments on this one :)



 Commenting right now ;)

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









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

2009-06-23 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira resolved DIRMINA-612.
-

Resolution: Fixed

 Add documentation on SingleSessionIohandler
 ---

 Key: DIRMINA-612
 URL: https://issues.apache.org/jira/browse/DIRMINA-612
 Project: MINA
  Issue Type: Task
  Components: Handler
Affects Versions: 2.0.0-M2
Reporter: Geert Schuring
Assignee: Edouard De Oliveira
Priority: Minor
 Fix For: 2.0.0-M7

   Original Estimate: 1h
  Remaining Estimate: 1h

 A normal multi-session IoHandler can be added to the acceptor using the 
 addHandler method. However, when writing a single-session IoHandler I can't 
 find any information about how to register it with the acceptor. The 
 addHandler method doesn't accept single-session IoHandlers.

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



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

2009-06-23 Thread Edouard De Oliveira

done :)

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



- Message d'origine 
De : Emmanuel Lecharny elecha...@apache.org
À : dev@mina.apache.org
Envoyé le : Mardi, 23 Juin 2009, 22h19mn 00s
Objet : Re: Re : Re : [jira] Updated: (DIRMINA-612) Add documentation on  
SingleSessionIohandler

Edouard De Oliveira wrote:
 We may have users out there using it so i think adding some doco, marking it 
 as deprecated and coumenting the fact it isn't scalable should be enough for 
 2.0 
 Should i also at the same time mark the netty2 package as deprecated as 
 obviously we also won't delete it but won't support it for 2.0 ?  
yep. @deprecate those guys...
 These two will be removed later on for 2.1 or 3.0 ...
  
Maybe adding a JIRA about that for 3.0 can be usefull.

Thanks Edouard !

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





[jira] Created: (DIRMINA-721) Get rid of multiton iohandler and netty2 codec as proposed on ML

2009-06-23 Thread Edouard De Oliveira (JIRA)
Get rid of multiton iohandler and netty2 codec as proposed on ML


 Key: DIRMINA-721
 URL: https://issues.apache.org/jira/browse/DIRMINA-721
 Project: MINA
  Issue Type: Task
  Components: Filter, Handler
Reporter: Edouard De Oliveira
Priority: Trivial
 Fix For: 3.0.0-M1




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



[jira] Assigned: (DIRMINA-642) Disposing an IoConnector blocks forever

2009-06-23 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira reassigned DIRMINA-642:
---

Assignee: Edouard De Oliveira

 Disposing an IoConnector blocks forever
 ---

 Key: DIRMINA-642
 URL: https://issues.apache.org/jira/browse/DIRMINA-642
 Project: MINA
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0.0-M3
 Environment: Linux
Reporter: Thomas Berger
Assignee: Edouard De Oliveira

 nHandles in the class Worker (AbstractPollingIoConnector) gets negative: -1 
 in my case.  Then the dispose() method blocks forever as the while loop in 
 this worker class never breaks. Reproducing this error is pretty hard, as it 
 usually happens after several hours. I will do a quick fix and check if 
 nHandles=0. 
 I think it may be related to http://issues.apache.org/jira/browse/DIRMINA-632 
 as I never block for a write in my app. However, I get some 
 WriteToClosedSessionException. Is it possible that this causes nHandles to 
 become negative?

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



[jira] Updated: (DIRMINA-659) AccessControlException when running MINA in a Applet: RuntimePermission modifyThread

2009-06-23 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira updated DIRMINA-659:


Assignee: Edouard De Oliveira

Isn't some documentation the real solution here ? 
Maybe a special section for restricted envs like applets in the wiki
Jeff you can also sign your applet which will give your applet an unrestricted 
access to the system and thus eliminate the issue.

 AccessControlException when running MINA in a Applet: RuntimePermission 
 modifyThread
 --

 Key: DIRMINA-659
 URL: https://issues.apache.org/jira/browse/DIRMINA-659
 Project: MINA
  Issue Type: Bug
Affects Versions: 2.0.0-M4
 Environment: Java 5 Applet (using appletviewer)
Reporter: Jeff Mesnil
Assignee: Edouard De Oliveira

 I'm using MINA 2.0.0-M4 within a restricted environment (an Applet in my 
 case, could also be JNLP).
 When running the code in appletviewer, I need to add a permission for the 
 code to be executed successfully:
  permission java.lang.RuntimePermission modifyThread;
 If I don't add this permission, the code fails with the following stack trace:
 Exception in thread pool-2-thread-1 java.security.AccessControlException: 
 access denied (java.lang.RuntimePermission modifyThread)
   at 
 java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
   at 
 java.security.AccessController.checkPermission(AccessController.java:427)
   at 
 java.util.concurrent.ThreadPoolExecutor.shutdown(ThreadPoolExecutor.java:893)
   at 
 org.apache.mina.core.service.SimpleIoProcessorPool.dispose(SimpleIoProcessorPool.java:230)
   at 
 org.apache.mina.core.polling.AbstractPollingIoConnector$Connector.run(AbstractPollingIoConnector.java:512)
   at 
 org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:65)
   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:613)
 The exception occurs when I close the SocketConnector:
public synchronized void close()
{
   if (connector != null)
   {
  connector.dispose();
  connector = null;
   }
}

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



[jira] Resolved: (DIRMINA-632) WriteFuture.awaitUninterruptibly() or .join() hangs if write() throws Exceptions

2009-06-22 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira resolved DIRMINA-632.
-

   Resolution: Fixed
Fix Version/s: (was: 2.0.0-RC1)
   2.0.0-M7

Fixed and added a simpler non regression junit test

 WriteFuture.awaitUninterruptibly() or .join() hangs if write() throws 
 Exceptions
 

 Key: DIRMINA-632
 URL: https://issues.apache.org/jira/browse/DIRMINA-632
 Project: MINA
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.10, 1.1.7, 2.0.0-M3
Reporter: Barrie Treloar
Assignee: Edouard De Oliveira
 Fix For: 2.0.0-M7

 Attachments: mina-1.1-handle-write-exceptions-with-test.txt, 
 mina-2.0-handle-write-exceptions-test.txt, 
 mina-2.0-handle-write-exceptions.txt, 
 mina-2.0-memory_monitor-withExceptionNotifier.txt, mina-2.0-memory_monitor.txt


 This is best shown with UDP since TCP will cause a close session to occur.
 If channel.write() throws an exception, e.g. the host becomes unreachable 
 because of network connection is removed, then 
 WriteFuture.awaitUninterruptibly() will hang - as it will never have 
 setWritten(false) or setException() called.
 I have modified the MemoryMonitor example to show this happening.
 You must manually pull your network cable (or disable your Network Adapter) 
 while the client is running to see this happen.

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



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

2009-06-22 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira reassigned DIRMINA-612:
---

Assignee: Edouard De Oliveira

 Add documentation on SingleSessionIohandler
 ---

 Key: DIRMINA-612
 URL: https://issues.apache.org/jira/browse/DIRMINA-612
 Project: MINA
  Issue Type: Task
  Components: Web Site / Documentation
Affects Versions: 2.0.0-M2
Reporter: Geert Schuring
Assignee: Edouard De Oliveira
Priority: Minor
 Fix For: 2.0.0-RC1

   Original Estimate: 1h
  Remaining Estimate: 1h

 A normal multi-session IoHandler can be added to the acceptor using the 
 addHandler method. However, when writing a single-session IoHandler I can't 
 find any information about how to register it with the acceptor. The 
 addHandler method doesn't accept single-session IoHandlers.

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



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

2009-06-22 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira updated DIRMINA-612:


  Component/s: (was: Web Site / Documentation)
   Handler
Fix Version/s: (was: 2.0.0-RC1)
   2.0.0-M7

1 - These  classes are pretty well documented
2 - They're badly named as the 'real handler' is in fact the 
SingleSessionIoHandlerDelegate and not the SingleSessionIoHandler.
As we have freezed the API can we still rename these as it is the source of the 
confusion ?
3 - Is it really a good idea to provide this package as it goes against 
scalability principles ? should we remove it completly ? for 2.0 ? 3.0 ? or 
just document the fact that it can suffer scalability problems (which would be 
compliant with api freeze) and maybe even mark these as deprecated ?

WDYT ?

 Add documentation on SingleSessionIohandler
 ---

 Key: DIRMINA-612
 URL: https://issues.apache.org/jira/browse/DIRMINA-612
 Project: MINA
  Issue Type: Task
  Components: Handler
Affects Versions: 2.0.0-M2
Reporter: Geert Schuring
Assignee: Edouard De Oliveira
Priority: Minor
 Fix For: 2.0.0-M7

   Original Estimate: 1h
  Remaining Estimate: 1h

 A normal multi-session IoHandler can be added to the acceptor using the 
 addHandler method. However, when writing a single-session IoHandler I can't 
 find any information about how to register it with the acceptor. The 
 addHandler method doesn't accept single-session IoHandlers.

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



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

2009-06-22 Thread Edouard De Oliveira

I would really like some comments on this one :)
 Cordialement, Regards,
-Edouard De Oliveira-
Blog: http://tedorgwp.free.fr
WebSite: http://tedorg.free.fr/en/main.php 



- Message d'origine 
De : Edouard De Oliveira (JIRA) j...@apache.org
À : dev@mina.apache.org
Envoyé le : Lundi, 22 Juin 2009, 20h28mn 07s
Objet : [jira] Updated: (DIRMINA-612) Add documentation on 
SingleSessionIohandler


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

Edouard De Oliveira updated DIRMINA-612:


      Component/s:    (was: Web Site / Documentation)
                  Handler
    Fix Version/s:    (was: 2.0.0-RC1)
                  2.0.0-M7

1 - These  classes are pretty well documented
2 - They're badly named as the 'real handler' is in fact the 
SingleSessionIoHandlerDelegate and not the SingleSessionIoHandler.
As we have freezed the API can we still rename these as it is the source of the 
confusion ?
3 - Is it really a good idea to provide this package as it goes against 
scalability principles ? should we remove it completly ? for 2.0 ? 3.0 ? or 
just document the fact that it can suffer scalability problems (which would be 
compliant with api freeze) and maybe even mark these as deprecated ?

WDYT ?

 Add documentation on SingleSessionIohandler
 ---

                Key: DIRMINA-612
                URL: https://issues.apache.org/jira/browse/DIRMINA-612
            Project: MINA
          Issue Type: Task
          Components: Handler
    Affects Versions: 2.0.0-M2
            Reporter: Geert Schuring
            Assignee: Edouard De Oliveira
            Priority: Minor
            Fix For: 2.0.0-M7

  Original Estimate: 1h
  Remaining Estimate: 1h

 A normal multi-session IoHandler can be added to the acceptor using the 
 addHandler method. However, when writing a single-session IoHandler I can't 
 find any information about how to register it with the acceptor. The 
 addHandler method doesn't accept single-session IoHandlers.

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





[jira] Updated: (DIRMINA-188) All-in-one JAR

2009-06-22 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira updated DIRMINA-188:


Fix Version/s: 2.0.0-M7
 Assignee: Edouard De Oliveira

i have a simple solution for this packaging issue but do our users really need 
this ? 

 All-in-one JAR
 --

 Key: DIRMINA-188
 URL: https://issues.apache.org/jira/browse/DIRMINA-188
 Project: MINA
  Issue Type: Task
Reporter: Trustin Lee
Assignee: Edouard De Oliveira
Priority: Minor
 Fix For: 2.0.0-M7


 We need two kinds of all-in-one JARs:
 * A JAR file which contains all modules
 * A JAR file which contains all modules and dependencies
 Perhaps we could create two uberjar projects.

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



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

2009-06-21 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira resolved DIRMINA-616.
-

Resolution: Fixed

 New release.xml file
 

 Key: DIRMINA-616
 URL: https://issues.apache.org/jira/browse/DIRMINA-616
 Project: MINA
  Issue Type: Improvement
Reporter: Barend Garvelink
Assignee: Edouard De Oliveira
 Fix For: 2.0.0-M7

 Attachments: release.xml


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

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



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

2009-06-21 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira updated DIRMINA-616:


Assignee: Edouard De Oliveira  (was: Julien Vermillard)

Seems that there's finally a very simple fix to this :
instead of :
$ mvn -Pserial assembly:assembly
use
$ mvn -Pserial package assembly:assembly

Another major PITA fixed, this one really upset me ...

 New release.xml file
 

 Key: DIRMINA-616
 URL: https://issues.apache.org/jira/browse/DIRMINA-616
 Project: MINA
  Issue Type: Improvement
Reporter: Barend Garvelink
Assignee: Edouard De Oliveira
 Fix For: 2.0.0-M7

 Attachments: release.xml


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

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



[jira] Commented: (DIRMINA-679) NullPointerException in ProtocolCodecFilter.filterWrite

2009-06-21 Thread Edouard De Oliveira (JIRA)

[ 
https://issues.apache.org/jira/browse/DIRMINA-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12722357#action_12722357
 ] 

Edouard De Oliveira commented on DIRMINA-679:
-

John were you using an ExecutorFilter on your chain ?
Working on DIRMINA-714 made me discover that using it doesn't enqueue all 
events by default and can lead to this kind of issues.

 NullPointerException in ProtocolCodecFilter.filterWrite
 ---

 Key: DIRMINA-679
 URL: https://issues.apache.org/jira/browse/DIRMINA-679
 Project: MINA
  Issue Type: Bug
Affects Versions: 2.0.0-M4
Reporter: John J. Franey
 Fix For: 2.0.0-RC1


 Looks like filterWrite obtains a reference from the session's attributes, but 
 the desired attribute is not there.
 I am running max of 250 datagram sockets under load test for my application.  
 Connections last about 60 seconds and released.  A new connection is made to 
 keep the total number of active connections up to 250.
 Over a period of two hours running this load test, this exception occured 
 twice.
 org.apache.mina.filter.codec.ProtocolEncoderException: 
 java.lang.NullPointerException
   at 
 org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:312)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:506)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.access$7(DefaultIoFilterChain.java:501)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:814)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.filterWrite(DefaultIoFilterChain.java:740)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:506)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:498)
   at 
 org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:418)
   at 
 org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:359)
 
 Caused by: java.lang.NullPointerException
   at 
 org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:297)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:814)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.filterWrite(DefaultIoFilterChain.java:741)
   at 
 org.apache.mina.core.filterchain.DefaultIoFilterChain.fireFilterWrite(DefaultIoFilterChain.java:498)
   at 
 org.apache.mina.core.session.AbstractIoSession.write(AbstractIoSession.java:359)
 

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



[jira] Commented: (DIRMINA-714) Packet sequence is unordered in multi thread.

2009-06-21 Thread Edouard De Oliveira (JIRA)

[ 
https://issues.apache.org/jira/browse/DIRMINA-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12722377#action_12722377
 ] 

Edouard De Oliveira commented on DIRMINA-714:
-

I committed a fix which should solve your issue : basically it makes 
OrderedThreadPool enqueue all events except SESSION_CREATED and prevents the 
deoredering of writes. I also observed that this way as i expected the 
ExecutorFilter is only needed after the codec.

Please do a test and let us know if it also works for you.

 Packet sequence is unordered in multi thread.
 -

 Key: DIRMINA-714
 URL: https://issues.apache.org/jira/browse/DIRMINA-714
 Project: MINA
  Issue Type: Bug
  Components: Filter
Affects Versions: 2.0.0-M5
 Environment: xp
Reporter: ncanis2
Assignee: Edouard De Oliveira
 Fix For: 2.0.0-M7

 Attachments: mina_m6_seq_test_src.zip, org.zip


 Hi.
 Packet sequence is unordered.
 = Server  Client = 
 chain.addLast(codec, new ProtocolCodecFilter(rcf));
 chain.addLast(executor, getExecuteFilter());= 
 OrderedThreadPoolExecutor c = new OrderedThreadPoolExecutor(20,100);
 If server send 1,2,3,4,5,6 , client receive 1,2,3,4,6  from server.
 Clients : 100.
 where I am wrong? 

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



[jira] Resolved: (DIRMINA-714) Packet sequence is unordered in multi thread.

2009-06-21 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira resolved DIRMINA-714.
-

Resolution: Fixed

 Packet sequence is unordered in multi thread.
 -

 Key: DIRMINA-714
 URL: https://issues.apache.org/jira/browse/DIRMINA-714
 Project: MINA
  Issue Type: Bug
  Components: Filter
Affects Versions: 2.0.0-M5
 Environment: xp
Reporter: ncanis2
Assignee: Edouard De Oliveira
 Fix For: 2.0.0-M7

 Attachments: mina_m6_seq_test_src.zip, org.zip


 Hi.
 Packet sequence is unordered.
 = Server  Client = 
 chain.addLast(codec, new ProtocolCodecFilter(rcf));
 chain.addLast(executor, getExecuteFilter());= 
 OrderedThreadPoolExecutor c = new OrderedThreadPoolExecutor(20,100);
 If server send 1,2,3,4,5,6 , client receive 1,2,3,4,6  from server.
 Clients : 100.
 where I am wrong? 

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



[jira] Assigned: (DIRMINA-632) WriteFuture.awaitUninterruptibly() or .join() hangs if write() throws Exceptions

2009-06-21 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira reassigned DIRMINA-632:
---

Assignee: Edouard De Oliveira

 WriteFuture.awaitUninterruptibly() or .join() hangs if write() throws 
 Exceptions
 

 Key: DIRMINA-632
 URL: https://issues.apache.org/jira/browse/DIRMINA-632
 Project: MINA
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.10, 1.1.7, 2.0.0-M3
Reporter: Barrie Treloar
Assignee: Edouard De Oliveira
 Fix For: 2.0.0-RC1

 Attachments: mina-1.1-handle-write-exceptions-with-test.txt, 
 mina-2.0-handle-write-exceptions-test.txt, 
 mina-2.0-handle-write-exceptions.txt, 
 mina-2.0-memory_monitor-withExceptionNotifier.txt, mina-2.0-memory_monitor.txt


 This is best shown with UDP since TCP will cause a close session to occur.
 If channel.write() throws an exception, e.g. the host becomes unreachable 
 because of network connection is removed, then 
 WriteFuture.awaitUninterruptibly() will hang - as it will never have 
 setWritten(false) or setException() called.
 I have modified the MemoryMonitor example to show this happening.
 You must manually pull your network cable (or disable your Network Adapter) 
 while the client is running to see this happen.

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



[jira] Updated: (DIRMINA-714) Packet sequence is unordered in multi thread.

2009-06-18 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira updated DIRMINA-714:


Attachment: org.zip

Reworked the provided test

 Packet sequence is unordered in multi thread.
 -

 Key: DIRMINA-714
 URL: https://issues.apache.org/jira/browse/DIRMINA-714
 Project: MINA
  Issue Type: Bug
  Components: Filter
Affects Versions: 2.0.0-M5
 Environment: xp
Reporter: ncanis2
 Fix For: 2.0.0-M7

 Attachments: mina_m6_seq_test_src.zip, org.zip


 Hi.
 Packet sequence is unordered.
 = Server  Client = 
 chain.addLast(codec, new ProtocolCodecFilter(rcf));
 chain.addLast(executor, getExecuteFilter());= 
 OrderedThreadPoolExecutor c = new OrderedThreadPoolExecutor(20,100);
 If server send 1,2,3,4,5,6 , client receive 1,2,3,4,6  from server.
 Clients : 100.
 where I am wrong? 

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



[jira] Issue Comment Edited: (DIRMINA-714) Packet sequence is unordered in multi thread.

2009-06-18 Thread Edouard De Oliveira (JIRA)

[ 
https://issues.apache.org/jira/browse/DIRMINA-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12721548#action_12721548
 ] 

Edouard De Oliveira edited comment on DIRMINA-714 at 6/18/09 4:25 PM:
--

After some hours of debugging, i think the concurrency problem is located in 
the executor filters that need to be place before and after the codec . they 
must be interested on the IoEventType.WRITE using the right constructor which 
strangely is not the case by default.

I first thought that an Executor before the codec will be enough but it seems 
not and i'm not totally sure why 

As long as the IoBuffer or object message isn't queued in the OrderedThreadPool 
you could fall in the following situation :

Thread A gets a sequence number and then ctx is switched somewhere before write 
event is queued by the executor filter
Thread B gets seq+1 and runs till event is queued 

this will result in a wrong sequence

finally combining the two executor filters with adding a synchronization on the 
session when writing the packet should definetely solve the problem :
synchronized (session) {

seq = generateSeq();

session.write(buf);
...
}

The OrderedThreadPoolExecutor needs many conditions to do it's job correctly so 
maybe the solution to this issue is just a complete doco to avoid 
misunderstandings until the 3.0 branch which should bring a new chain that 
should allow ordering events more 
efficiently.

WDYT ?

  was (Author: ted_kods):
After some hours of debugging, i think the concurrency problem is located 
in the executor filters that need to be place before and after the codec . they 
must be interested on the IoEventType.WRITE using the right constructor which 
strangely is not the case by default.

I first thought that an Executor before the codec will be enough but it seems 
not and i'm not totally sure why 

As long as the IoBuffer or object message isn't queued in the OrderedThreadPool 
you could fall in the following situation :

Thread A gets a sequence number and then ctx is switched somewhere before write 
event is queued by the executor filter
Thread B gets seq+1 and runs till event is queued 

this will result in a wrong sequence

finally adding a synchronization on the session when writing the packet should 
definetely solve the problem :
synchronized (session) {

seq = generateSeq();

session.write(buf);
...
}

The OrderedThreadPoolExecutor needs many conditions to do it's job correctly so 
maybe the solution to this issue is just a complete doco to avoid 
misunderstandings until the 3.0 branch which should bring a new chain that 
should allow ordering events more 
efficiently.

WDYT ?
  
 Packet sequence is unordered in multi thread.
 -

 Key: DIRMINA-714
 URL: https://issues.apache.org/jira/browse/DIRMINA-714
 Project: MINA
  Issue Type: Bug
  Components: Filter
Affects Versions: 2.0.0-M5
 Environment: xp
Reporter: ncanis2
Assignee: Edouard De Oliveira
 Fix For: 2.0.0-M7

 Attachments: mina_m6_seq_test_src.zip, org.zip


 Hi.
 Packet sequence is unordered.
 = Server  Client = 
 chain.addLast(codec, new ProtocolCodecFilter(rcf));
 chain.addLast(executor, getExecuteFilter());= 
 OrderedThreadPoolExecutor c = new OrderedThreadPoolExecutor(20,100);
 If server send 1,2,3,4,5,6 , client receive 1,2,3,4,6  from server.
 Clients : 100.
 where I am wrong? 

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



[jira] Assigned: (DIRMINA-714) Packet sequence is unordered in multi thread.

2009-06-18 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira reassigned DIRMINA-714:
---

Assignee: Edouard De Oliveira

 Packet sequence is unordered in multi thread.
 -

 Key: DIRMINA-714
 URL: https://issues.apache.org/jira/browse/DIRMINA-714
 Project: MINA
  Issue Type: Bug
  Components: Filter
Affects Versions: 2.0.0-M5
 Environment: xp
Reporter: ncanis2
Assignee: Edouard De Oliveira
 Fix For: 2.0.0-M7

 Attachments: mina_m6_seq_test_src.zip, org.zip


 Hi.
 Packet sequence is unordered.
 = Server  Client = 
 chain.addLast(codec, new ProtocolCodecFilter(rcf));
 chain.addLast(executor, getExecuteFilter());= 
 OrderedThreadPoolExecutor c = new OrderedThreadPoolExecutor(20,100);
 If server send 1,2,3,4,5,6 , client receive 1,2,3,4,6  from server.
 Clients : 100.
 where I am wrong? 

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



[jira] Commented: (DIRMINA-714) Packet sequence is unordered in multi thread.

2009-06-18 Thread Edouard De Oliveira (JIRA)

[ 
https://issues.apache.org/jira/browse/DIRMINA-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12721548#action_12721548
 ] 

Edouard De Oliveira commented on DIRMINA-714:
-

After some hours of debugging, i think the concurrency problem is located in 
the executor filters that need to be place before and after the codec . they 
must be interested on the IoEventType.WRITE using the right constructor which 
strangely is not the case by default.

I first thought that an Executor before the codec will be enough but it seems 
not and i'm not totally sure why 

As long as the IoBuffer or object message isn't queued in the OrderedThreadPool 
you could fall in the following situation :

Thread A gets a sequence number and then ctx is switched somewhere before write 
event is queued by the executor filter
Thread B gets seq+1 and runs till event is queued 

this will result in a wrong sequence

finally adding a synchronization on the session when writing the packet should 
definetely solve the problem :
synchronized (session) {

seq = generateSeq();

session.write(buf);
...
}

The OrderedThreadPoolExecutor needs many conditions to do it's job correctly so 
maybe the solution to this issue is just a complete doco to avoid 
misunderstandings until the 3.0 branch which should bring a new chain that 
should allow ordering events more 
efficiently.

WDYT ?

 Packet sequence is unordered in multi thread.
 -

 Key: DIRMINA-714
 URL: https://issues.apache.org/jira/browse/DIRMINA-714
 Project: MINA
  Issue Type: Bug
  Components: Filter
Affects Versions: 2.0.0-M5
 Environment: xp
Reporter: ncanis2
 Fix For: 2.0.0-M7

 Attachments: mina_m6_seq_test_src.zip, org.zip


 Hi.
 Packet sequence is unordered.
 = Server  Client = 
 chain.addLast(codec, new ProtocolCodecFilter(rcf));
 chain.addLast(executor, getExecuteFilter());= 
 OrderedThreadPoolExecutor c = new OrderedThreadPoolExecutor(20,100);
 If server send 1,2,3,4,5,6 , client receive 1,2,3,4,6  from server.
 Clients : 100.
 where I am wrong? 

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



[jira] Updated: (DIRMINA-718) Sometimes AbstractIoSession.toString() invoked java.net.SocketException

2009-06-17 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira updated DIRMINA-718:


Fix Version/s: 2.0.0-M7

 Sometimes AbstractIoSession.toString() invoked java.net.SocketException
 ---

 Key: DIRMINA-718
 URL: https://issues.apache.org/jira/browse/DIRMINA-718
 Project: MINA
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0.0-M6
 Environment: xp
Reporter: ncanis2
Assignee: Emmanuel Lecharny
 Fix For: 2.0.0-M7


 Sometimes AbstractIoSession.toString() method invoked 
 java.net.SocketException.
 That was java.lang.Error. so my program was exited.
 I think this problem was continuing since 2.0M2 or 3 
 ===
 java.lang.Error: java.net.SocketException: Socket operation on nonsocket: 
 getsockname
  at sun.nio.ch.Net.localAddress(Net.java:125)
  at sun.nio.ch.SocketChannelImpl.localAddress(SocketChannelImpl.java:430)
  at sun.nio.ch.SocketAdaptor.getLocalAddress(SocketAdaptor.java:147)
  at java.net.Socket.getLocalSocketAddress(Socket.java:697)
  at 
 org.apache.mina.transport.socket.nio.NioSocketSession.getLocalAddress(NioSocketSession.java:158)
  at 
 org.apache.mina.transport.socket.nio.NioSocketSession.getLocalAddress(NioSocketSession.java:1)
  at 
 org.apache.mina.core.session.AbstractIoSession.toString(AbstractIoSession.java:1147)
  at java.lang.String.valueOf(String.java:2827)
  at java.lang.StringBuilder.append(StringBuilder.java:115)
  at 
 com.rontab.bake.net.ClientEventAbstract.sendServer(ClientEventAbstract.java:256)
  at com.rontab.bake.net.ClientEventAbstract.send(ClientEventAbstract.java:241)
  at 
 com.rontab.bake.net.protocols.room.PCreateRoom.sendMakeRoom(PCreateRoom.java:193)
  at 
 com.rontab.bake.bui.comp.roomlist.createroom.CreateRoomEventProcessor.makeRoom(CreateRoomEventProcessor.java:53)
  at 
 com.rontab.bake.bui.comp.roomlist.createroom.CreateRoomCont.roomSetting(CreateRoomCont.java:371)
  at 
 com.rontab.bake.bui.comp.roomlist.createroom.CreateRoomCont.createRoom(CreateRoomCont.java:383)
  at 
 com.rontab.bake.bui.comp.roomlist.createroom.CreateRoomCont$3.mouseReleased(CreateRoomCont.java:219)
  at com.jmex.bui.event.MouseEvent.dispatch(MouseEvent.java:209)
  at com.jmex.bui.BComponent.dispatchEvent(BComponent.java:789)
  at com.jmex.bui.BRootNode.dispatchEvent(BRootNode.java:469)
  at com.jmex.bui.PolledRootNode$2.dispatchEvent(PolledRootNode.java:268)
  at com.jmex.bui.PolledRootNode$2.onButton(PolledRootNode.java:237)
  at com.jme.input.lwjgl.LWJGLMouseInput.update(LWJGLMouseInput.java:233)
  at com.jme.input.InputSystem.update(InputSystem.java:67)
  at com.rontab.bim.app.RontabGame.start(RontabGame.java:78)
  at com.rontab.bake.Bake.main(Bake.java:177)
 Caused by: java.net.SocketException: Socket operation on nonsocket: 
 getsockname
  at sun.nio.ch.Net.localInetAddress(Native Method)
  at sun.nio.ch.Net.localAddress(Net.java:122)
  ... 24 more

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



[jira] Updated: (DIRMINA-718) Sometimes AbstractIoSession.toString() invoked java.net.SocketException

2009-06-16 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira updated DIRMINA-718:


Assignee: Edouard De Oliveira

Seems this issue has already been addressed in DIRMINA-677

https://issues.apache.org/jira/browse/DIRMINA-677

 Sometimes AbstractIoSession.toString() invoked java.net.SocketException
 ---

 Key: DIRMINA-718
 URL: https://issues.apache.org/jira/browse/DIRMINA-718
 Project: MINA
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0.0-M6
 Environment: xp
Reporter: ncanis2
Assignee: Edouard De Oliveira

 Sometimes AbstractIoSession.toString() method invoked 
 java.net.SocketException.
 That was java.lang.Error. so my program was exited.
 I think this problem was continuing since 2.0M2 or 3 
 ===
 java.lang.Error: java.net.SocketException: Socket operation on nonsocket: 
 getsockname
  at sun.nio.ch.Net.localAddress(Net.java:125)
  at sun.nio.ch.SocketChannelImpl.localAddress(SocketChannelImpl.java:430)
  at sun.nio.ch.SocketAdaptor.getLocalAddress(SocketAdaptor.java:147)
  at java.net.Socket.getLocalSocketAddress(Socket.java:697)
  at 
 org.apache.mina.transport.socket.nio.NioSocketSession.getLocalAddress(NioSocketSession.java:158)
  at 
 org.apache.mina.transport.socket.nio.NioSocketSession.getLocalAddress(NioSocketSession.java:1)
  at 
 org.apache.mina.core.session.AbstractIoSession.toString(AbstractIoSession.java:1147)
  at java.lang.String.valueOf(String.java:2827)
  at java.lang.StringBuilder.append(StringBuilder.java:115)
  at 
 com.rontab.bake.net.ClientEventAbstract.sendServer(ClientEventAbstract.java:256)
  at com.rontab.bake.net.ClientEventAbstract.send(ClientEventAbstract.java:241)
  at 
 com.rontab.bake.net.protocols.room.PCreateRoom.sendMakeRoom(PCreateRoom.java:193)
  at 
 com.rontab.bake.bui.comp.roomlist.createroom.CreateRoomEventProcessor.makeRoom(CreateRoomEventProcessor.java:53)
  at 
 com.rontab.bake.bui.comp.roomlist.createroom.CreateRoomCont.roomSetting(CreateRoomCont.java:371)
  at 
 com.rontab.bake.bui.comp.roomlist.createroom.CreateRoomCont.createRoom(CreateRoomCont.java:383)
  at 
 com.rontab.bake.bui.comp.roomlist.createroom.CreateRoomCont$3.mouseReleased(CreateRoomCont.java:219)
  at com.jmex.bui.event.MouseEvent.dispatch(MouseEvent.java:209)
  at com.jmex.bui.BComponent.dispatchEvent(BComponent.java:789)
  at com.jmex.bui.BRootNode.dispatchEvent(BRootNode.java:469)
  at com.jmex.bui.PolledRootNode$2.dispatchEvent(PolledRootNode.java:268)
  at com.jmex.bui.PolledRootNode$2.onButton(PolledRootNode.java:237)
  at com.jme.input.lwjgl.LWJGLMouseInput.update(LWJGLMouseInput.java:233)
  at com.jme.input.InputSystem.update(InputSystem.java:67)
  at com.rontab.bim.app.RontabGame.start(RontabGame.java:78)
  at com.rontab.bake.Bake.main(Bake.java:177)
 Caused by: java.net.SocketException: Socket operation on nonsocket: 
 getsockname
  at sun.nio.ch.Net.localInetAddress(Native Method)
  at sun.nio.ch.Net.localAddress(Net.java:122)
  ... 24 more

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



[jira] Resolved: (DIRMINA-680) PortUnreachableException ought not to schedule session shutdown

2009-06-14 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira resolved DIRMINA-680.
-

Resolution: Fixed

 PortUnreachableException ought not to schedule session shutdown
 ---

 Key: DIRMINA-680
 URL: https://issues.apache.org/jira/browse/DIRMINA-680
 Project: MINA
  Issue Type: Improvement
  Components: Core
Affects Versions: 2.0.0-M4
Reporter: John J. Franey
Assignee: Edouard De Oliveira
 Fix For: 2.0.0-M7

 Attachments: pure.txt


 I wonder if you would entertain the idea that the PortUnreachableException 
 should be handled in the IoHandler by the 'application', at least for 
 datagram applications.
 I'm working on an RTP implementation which is datagram based.   I'm still 
 naive about RTP, but it seems reasonable for media to be sent prematurely, or 
 the for the remote port to be down temporarily.  I would like to have the 
 option to temporarily suspend transmission on the socket, as opposed to have 
 to 'reconnect' the datagram socket.
 Thanks,
 John

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



[jira] Assigned: (DIRMINA-709) PENDING session is removed and added endlessly -- garbage allocation and high CPU usage problem

2009-06-14 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira reassigned DIRMINA-709:
---

Assignee: Edouard De Oliveira

 PENDING session is removed and added endlessly  -- garbage allocation and 
 high CPU usage problem
 

 Key: DIRMINA-709
 URL: https://issues.apache.org/jira/browse/DIRMINA-709
 Project: MINA
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0.0-M4
 Environment: Debian Linux, kernel 2.6.24
Reporter: Victor N
Assignee: Edouard De Oliveira
 Fix For: 2.0.0-M7


 (This problem was discussed in mail lists, I will copy it here).
 Seems I have found a bug with IoSession - I can see that a PREPARING 
 session is not removed correctly from queue.
 When some session is in PREPARING state, it is removed from 
 removingSessions queue but right after that it is added to this queue 
 again! So this session is added to the queue and removed from it until 
 forever.
 As a result, this give us significant garbage allocation, so CPU spends most 
 of time in garbage collector (I can see this is JConsole).
 I see comments there in AbstractPollingIoProcessor class:
 private int remove() {
 ...
 case PREPARING:
 // Retry later if session is not yet fully initialized.
 // (In case that Session.close() is called before  
 addSession() is processed)
 scheduleRemove(session);
 return removedSessions;
 ...
 }
 I have added logging to this code, and I can see that the SAME session is 
 removed and added again and again.
 Can somebody explain this logic please? Why don't we remove the PENDING  
 session? Or maybe is there a workaround for this.
 Sorry, I can not provide a test for this issue, but it is reproduced almost 
 every day at out production servers under some load. Maybe, you can reproduce 
 it by adding a delay in addSession() and then closing the session during this 
 delay.

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



[jira] Updated: (DIRMINA-709) PENDING session is removed and added endlessly -- garbage allocation and high CPU usage problem

2009-06-14 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira updated DIRMINA-709:



Hi i commited a slightly modified version of the fix that shouldfix the side 
effect you are pointing at
please let me know if it is indeed fixed

 PENDING session is removed and added endlessly  -- garbage allocation and 
 high CPU usage problem
 

 Key: DIRMINA-709
 URL: https://issues.apache.org/jira/browse/DIRMINA-709
 Project: MINA
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0.0-M4
 Environment: Debian Linux, kernel 2.6.24
Reporter: Victor N
Assignee: Edouard De Oliveira
 Fix For: 2.0.0-M7


 (This problem was discussed in mail lists, I will copy it here).
 Seems I have found a bug with IoSession - I can see that a PREPARING 
 session is not removed correctly from queue.
 When some session is in PREPARING state, it is removed from 
 removingSessions queue but right after that it is added to this queue 
 again! So this session is added to the queue and removed from it until 
 forever.
 As a result, this give us significant garbage allocation, so CPU spends most 
 of time in garbage collector (I can see this is JConsole).
 I see comments there in AbstractPollingIoProcessor class:
 private int remove() {
 ...
 case PREPARING:
 // Retry later if session is not yet fully initialized.
 // (In case that Session.close() is called before  
 addSession() is processed)
 scheduleRemove(session);
 return removedSessions;
 ...
 }
 I have added logging to this code, and I can see that the SAME session is 
 removed and added again and again.
 Can somebody explain this logic please? Why don't we remove the PENDING  
 session? Or maybe is there a workaround for this.
 Sorry, I can not provide a test for this issue, but it is reproduced almost 
 every day at out production servers under some load. Maybe, you can reproduce 
 it by adding a delay in addSession() and then closing the session during this 
 delay.

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



[jira] Resolved: (DIRMINA-709) PENDING session is removed and added endlessly -- garbage allocation and high CPU usage problem

2009-06-14 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira resolved DIRMINA-709.
-

Resolution: Fixed

 PENDING session is removed and added endlessly  -- garbage allocation and 
 high CPU usage problem
 

 Key: DIRMINA-709
 URL: https://issues.apache.org/jira/browse/DIRMINA-709
 Project: MINA
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0.0-M4
 Environment: Debian Linux, kernel 2.6.24
Reporter: Victor N
Assignee: Edouard De Oliveira
 Fix For: 2.0.0-M7


 (This problem was discussed in mail lists, I will copy it here).
 Seems I have found a bug with IoSession - I can see that a PREPARING 
 session is not removed correctly from queue.
 When some session is in PREPARING state, it is removed from 
 removingSessions queue but right after that it is added to this queue 
 again! So this session is added to the queue and removed from it until 
 forever.
 As a result, this give us significant garbage allocation, so CPU spends most 
 of time in garbage collector (I can see this is JConsole).
 I see comments there in AbstractPollingIoProcessor class:
 private int remove() {
 ...
 case PREPARING:
 // Retry later if session is not yet fully initialized.
 // (In case that Session.close() is called before  
 addSession() is processed)
 scheduleRemove(session);
 return removedSessions;
 ...
 }
 I have added logging to this code, and I can see that the SAME session is 
 removed and added again and again.
 Can somebody explain this logic please? Why don't we remove the PENDING  
 session? Or maybe is there a workaround for this.
 Sorry, I can not provide a test for this issue, but it is reproduced almost 
 every day at out production servers under some load. Maybe, you can reproduce 
 it by adding a delay in addSession() and then closing the session during this 
 delay.

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



[jira] Resolved: (DIRMINA- 640) 通过IOFilt erAdpater添加线程池

2009-06-14 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira resolved DIRMINA-640.
-

Resolution: Won't Fix

 通过IOFilterAdpater添加线程池
 --

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


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

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



[jira] Reopened: (DIRMINA-711) Adding some logs in the chain make the MDCFilter tests to fail

2009-06-12 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira reopened DIRMINA-711:
-


see my previous comment

 Adding some logs in the chain make the MDCFilter tests to fail
 --

 Key: DIRMINA-711
 URL: https://issues.apache.org/jira/browse/DIRMINA-711
 Project: MINA
  Issue Type: Bug
Affects Versions: 2.0.0-M5
Reporter: Emmanuel Lecharny
Assignee: Maarten Bosteels
 Fix For: 2.0.0-RC1


 For some unkown reason, adding some logs in the chain makes MDCFilter tests 
 to complain. *
 Here are the added logs (commented) :
 http://svn.apache.org/viewvc?rev=774589view=rev
 http://svn.apache.org/viewvc?rev=774591view=rev

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



[jira] Updated: (DIRMINA-680) PortUnreachableException ought not to schedule session shutdown

2009-06-12 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira updated DIRMINA-680:


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

I propose that we add an option to the AbstractDatagramSessionConfig class to 
set the way PortUnreachableException should be handled. If we keep closing the 
session by default it won't change anything for existing code.


 PortUnreachableException ought not to schedule session shutdown
 ---

 Key: DIRMINA-680
 URL: https://issues.apache.org/jira/browse/DIRMINA-680
 Project: MINA
  Issue Type: Improvement
  Components: Core
Affects Versions: 2.0.0-M4
Reporter: John J. Franey
Assignee: Edouard De Oliveira
 Fix For: 2.0.0-M7

 Attachments: pure.txt


 I wonder if you would entertain the idea that the PortUnreachableException 
 should be handled in the IoHandler by the 'application', at least for 
 datagram applications.
 I'm working on an RTP implementation which is datagram based.   I'm still 
 naive about RTP, but it seems reasonable for media to be sent prematurely, or 
 the for the remote port to be down temporarily.  I would like to have the 
 option to temporarily suspend transmission on the socket, as opposed to have 
 to 'reconnect' the datagram socket.
 Thanks,
 John

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



Re : [MINA 3.0] Preliminary thoughts.

2009-06-12 Thread Edouard De Oliveira

+1

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



- Message d'origine 
De : Julien Vermillard jvermill...@archean.fr
À : dev@mina.apache.org
Envoyé le : Vendredi, 12 Juin 2009, 15h51mn 10s
Objet : Re: [MINA 3.0] Preliminary thoughts.

Real blocker are to fix the remaining bugs in JIRA and we are done.
Julien

Le Fri, 12 Jun 2009 07:07:06 -0400,
Mark Webb elihusma...@gmail.com a écrit :

 Between work and school, I have been really busy.  I have been keeping
 up with the mailing list, but not doing much with the code.  Things
 are starting to shake loose for me, so I will be able to jump back in
 now.
 
 What do you see as the major roadblocks to releasing 2.0?
 
 
 On Fri, Jun 12, 2009 at 3:34 AM, Emmanuel
 Lecharnyelecha...@apache.org wrote:
  Mark Webb wrote:
 
  What are the plans for release of 2.0 and the migration to a 3.0
  development?  Is anyone prototyping any of these ideas in
  sandboxes?
 
 
  Hi Mark,
 
  those are just random thoughts I put down on the site after having
  posted them to the list. I wrote them during my long commute from
  house to my client's office.
 
  Right now, there is nothing started, except a few experiment in some
  branches
  (https://svn.apache.org/repos/asf/mina/branches/mina-new-chain2 )
  done a few months ago.
 
  The main target is still to get MINA 2.0 out asap, and it takes
  forever, because a few peeps are working on it, something I can
  understand. MINA 2.0 code is far from being perfect, and it's not
  very funny to try to fix bugs in it, as the inner documentation is
  pretty sparse, and you have to double guess what some portion of
  the code is supposed to do before trying to fix it.
 
  My idea, when I posted this 3.0 mail, was to try to get more
  excitation from all of the people musing around MINA. It's always
  fun to start a new version, and it's most certainly useful to see
  what people have in mind, instead of going forward, code and commit.
 
  It will take a couple of months before MINA 2.0 will be released
  (after a couple of RC), and I think we are close to the final
  version. Seems to be good timing to start thinking seriously about
  MINA 3.0 !
 
  --
  --
  cordialement, regards,
  Emmanuel Lécharny
  www.iktek.com
  directory.apache.org
 
 
 






[jira] Assigned: (DIRMINA-716) Get rid of finalize method in AbstractIoFilterChain.java

2009-06-11 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira reassigned DIRMINA-716:
---

Assignee: Edouard De Oliveira  (was: Emmanuel Lecharny)

 Get rid of finalize method in AbstractIoFilterChain.java
 --

 Key: DIRMINA-716
 URL: https://issues.apache.org/jira/browse/DIRMINA-716
 Project: MINA
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0.0-M5
Reporter: Yongxing Wang
Assignee: Edouard De Oliveira
 Fix For: 2.0.0-M7


 The finalize method in AbstractIoFilterChain.java can possibly cause OOM 
 error when the system is under very heavy load. The negative impact of 
 finalize method can be found at:
 http://www.fasterj.com/articles/finalizer1.shtml
 AbstractIoFilterChain holds a reference to Session object which can hold a 
 list of unwritten data. The deterministic run of Finalizer can very well 
 cause memory not fred up on time under heavy load. And it can certainly cause 
 very bad memory usage pattern and contribute to the overall heavy system load.

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



[jira] Commented: (DIRMINA-716) Get rid of finalize method in AbstractIoFilterChain.java

2009-06-11 Thread Edouard De Oliveira (JIRA)

[ 
https://issues.apache.org/jira/browse/DIRMINA-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12718669#action_12718669
 ] 

Edouard De Oliveira commented on DIRMINA-716:
-

Yes i tested. In our case the negative impact isn't as bad but after digging 
down the code i think i can conclude that the finalize method is useless as the 
method clear() will always be called when session is closed so i patched the 
file and removed it

 Get rid of finalize method in AbstractIoFilterChain.java
 --

 Key: DIRMINA-716
 URL: https://issues.apache.org/jira/browse/DIRMINA-716
 Project: MINA
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0.0-M5
Reporter: Yongxing Wang
Assignee: Edouard De Oliveira
 Fix For: 2.0.0-M7


 The finalize method in AbstractIoFilterChain.java can possibly cause OOM 
 error when the system is under very heavy load. The negative impact of 
 finalize method can be found at:
 http://www.fasterj.com/articles/finalizer1.shtml
 AbstractIoFilterChain holds a reference to Session object which can hold a 
 list of unwritten data. The deterministic run of Finalizer can very well 
 cause memory not fred up on time under heavy load. And it can certainly cause 
 very bad memory usage pattern and contribute to the overall heavy system load.

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



[jira] Resolved: (DIRMINA-716) Get rid of finalize method in AbstractIoFilterChain.java

2009-06-11 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira resolved DIRMINA-716.
-

Resolution: Fixed

 Get rid of finalize method in AbstractIoFilterChain.java
 --

 Key: DIRMINA-716
 URL: https://issues.apache.org/jira/browse/DIRMINA-716
 Project: MINA
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0.0-M5
Reporter: Yongxing Wang
Assignee: Edouard De Oliveira
 Fix For: 2.0.0-M7


 The finalize method in AbstractIoFilterChain.java can possibly cause OOM 
 error when the system is under very heavy load. The negative impact of 
 finalize method can be found at:
 http://www.fasterj.com/articles/finalizer1.shtml
 AbstractIoFilterChain holds a reference to Session object which can hold a 
 list of unwritten data. The deterministic run of Finalizer can very well 
 cause memory not fred up on time under heavy load. And it can certainly cause 
 very bad memory usage pattern and contribute to the overall heavy system load.

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



[jira] Commented: (DIRMINA-711) Adding some logs in the chain make the MDCFilter tests to fail

2009-06-11 Thread Edouard De Oliveira (JIRA)

[ 
https://issues.apache.org/jira/browse/DIRMINA-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12718671#action_12718671
 ] 

Edouard De Oliveira commented on DIRMINA-711:
-

Wanted to add some log on the DefaultIoFilterChain#clear() method and got the 
same issue

 Adding some logs in the chain make the MDCFilter tests to fail
 --

 Key: DIRMINA-711
 URL: https://issues.apache.org/jira/browse/DIRMINA-711
 Project: MINA
  Issue Type: Bug
Affects Versions: 2.0.0-M5
Reporter: Emmanuel Lecharny
Assignee: Maarten Bosteels
 Fix For: 2.0.0-RC1


 For some unkown reason, adding some logs in the chain makes MDCFilter tests 
 to complain. *
 Here are the added logs (commented) :
 http://svn.apache.org/viewvc?rev=774589view=rev
 http://svn.apache.org/viewvc?rev=774591view=rev

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



[jira] Assigned: (DIRMINA-680) PortUnreachableException ought not to schedule session shutdown

2009-06-11 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira reassigned DIRMINA-680:
---

Assignee: Edouard De Oliveira

 PortUnreachableException ought not to schedule session shutdown
 ---

 Key: DIRMINA-680
 URL: https://issues.apache.org/jira/browse/DIRMINA-680
 Project: MINA
  Issue Type: Improvement
  Components: Core
Affects Versions: 2.0.0-M4
Reporter: John J. Franey
Assignee: Edouard De Oliveira
 Fix For: 2.0.0-RC1

 Attachments: pure.txt


 I wonder if you would entertain the idea that the PortUnreachableException 
 should be handled in the IoHandler by the 'application', at least for 
 datagram applications.
 I'm working on an RTP implementation which is datagram based.   I'm still 
 naive about RTP, but it seems reasonable for media to be sent prematurely, or 
 the for the remote port to be down temporarily.  I would like to have the 
 option to temporarily suspend transmission on the socket, as opposed to have 
 to 'reconnect' the datagram socket.
 Thanks,
 John

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



[jira] Commented: (DIRMINA-716) Get rid of finalize method in AbstractIoFilterChain.java

2009-06-02 Thread Edouard De Oliveira (JIRA)

[ 
https://issues.apache.org/jira/browse/DIRMINA-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12715432#action_12715432
 ] 

Edouard De Oliveira commented on DIRMINA-716:
-

The finalize() catch is a good one i tried to see it for myself and i confirm 
the poor memory management it causes (you can look at 
http://tedorgwp.free.fr/?p=450 which contains graphs of the generated heap 
load).

I do also fully agree with the copy on change method as i think it only happens 
in specific implementations. Other implementations will gain some additionnal 
free memory from this tweak.

 Get rid of finalize method in AbstractIoFilterChain.java
 --

 Key: DIRMINA-716
 URL: https://issues.apache.org/jira/browse/DIRMINA-716
 Project: MINA
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0.0-M5
Reporter: Yongxing Wang
Assignee: Emmanuel Lecharny

 The finalize method in AbstractIoFilterChain.java can possibly cause OOM 
 error when the system is under very heavy load. The negative impact of 
 finalize method can be found at:
 http://www.fasterj.com/articles/finalizer1.shtml
 AbstractIoFilterChain holds a reference to Session object which can hold a 
 list of unwritten data. The deterministic run of Finalizer can very well 
 cause memory not fred up on time under heavy load. And it can certainly cause 
 very bad memory usage pattern and contribute to the overall heavy system load.

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



Re : [VOTE] Release MINA 2.0.0-M6

2009-05-26 Thread Edouard De Oliveira

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

and +1 assembly plugin is deeply bugged ;(

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



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

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

On Tue, May 26, 2009 at 6:38 PM, Emmanuel Lecharny elecha...@apache.org wrote:
 Hi,

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

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

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

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

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



 Thanks !

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






-- 
thanks
ashish

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






Re : Re : Re : Preparing a 2.0.0-M6 release

2009-05-25 Thread Edouard De Oliveira

Okay  (i tested the two ways last night but either failed ...)
Do i have to put some lines in my settings.xml file ?

here are the steps i followed :

svn co . branches/mina/2.0.0-M6 mina
cd mina
mvn -Pserial clean install
mvn -Pserial site
mvn -Pserial assembly:assembly  - fails here
 Cordialement, Regards,
-Edouard De Oliveira-
Blog: http://tedorgwp.free.fr
WebSite: http://tedorg.free.fr/en/main.php



- Message d'origine 
De : Emmanuel Lecharny elecha...@apache.org
À : dev@mina.apache.org
Envoyé le : Lundi, 25 Mai 2009, 8h18mn 52s
Objet : Re: Re : Re : Preparing a 2.0.0-M6 release

Edouard De Oliveira wrote:
 No i didn't i used mvn -Dwith-LGPL-dependencies clean install
  
Ok, it's equivalent. -Pserial defines a maven profile which defines  the 
with-LGPL-dependencies property. It's just shorter to type and easier to 
remember ;)

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





Re : Re : Preparing a 2.0.0-M6 release

2009-05-24 Thread Edouard De Oliveira

No i didn't i used mvn -Dwith-LGPL-dependencies clean install
as stated on the website
i was currently doing a test with maven 2.0.10 but it fails as under 2.1.0

do i need to run
mvn -Pserial -Dwith-LGPL-dependencies clean install
or just
mvn -Pserial clean install
?

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



- Message d'origine 
De : Emmanuel Lecharny elecha...@apache.org
À : dev@mina.apache.org
Envoyé le : Lundi, 25 Mai 2009, 1h34mn 25s
Objet : Re: Re : Preparing a 2.0.0-M6 release

Edouard De Oliveira wrote:
 As i had some time this week end and was interested in testing the release 
 process. I gave it a try ...
 Under latest eclipse 3.5M7 + M2eclipse plugin : failure - i thought it was 
 probably due to the maven plugin ...
 
 So I downloaded maven 2.1.0 and followed the instructions on the web site - 
 failure at the assembly step
 as i was under winXP i thought it may have something with my OS.
 So i downloaded an Ubuntu 9.0.4 and after some hours of 'Oh my gods where are 
 my *Nix skills gone' i finally ran the build to end up with the same failure :
 
 [ERROR] BUILD ERROR
 [INFO] 
 
 [INFO] Failed to create assembly: Artifact:
 org.apache.mina:mina-core:bundle:2.0.0-M6-SNAPSHOT (included by module)
 does not have an artifact with a file. Please ensure the package phase
 is run before the assembly is generated.
 
 So i'm doing something wrong ? I would be happy to complete the process and 
 launch the vote if someone can help me fix the problem
  

Thanks for that Edouard !

Just to be sure, have you run
mvn clean install -Pserial ?

(the -Pserial include the special packages for serial communication)

Thanks !

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


   


Re : Preparing a 2.0.0-M6 release

2009-05-23 Thread Edouard De Oliveira

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

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

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

So i'm doing something wrong ? 
I would be happy to complete the process and launch the vote if someone can 
help me fix the problem

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



- Message d'origine 
De : Emmanuel Lecharny elecha...@apache.org
À : dev@mina.apache.org
Envoyé le : Vendredi, 22 Mai 2009, 16h27mn 45s
Objet : Re: Preparing a 2.0.0-M6 release

Niklas Gustavsson wrote:
 On Fri, May 22, 2009 at 12:41 AM, Emmanuel Lecharny
 elecha...@apache.org wrote:
  
 Can someone give me instruction on how to do that, it seems that the site is
 not really up to date
 (http://mina.apache.org/developer-guide.html#DeveloperGuide-ReleasingaPointRelease%2528CommittersOnly%2529)

 
 When I released M5, I pretty much use the procedure we use for
 FtpServer (http://mina.apache.org/ftpserver/releasing.html). However,
 one problem with it is that we don't use the Maven deployment plugin
 to deploy to the Apache repo and thus screw up the Maven metadata. I
 will try having this fixed for 1.0.2, maybe we could look into having
 a common procedure for all MINA projects?
  

Ok, I'm running out of time for all the preparation, but so far, it's seem to 
be easy. What's missing is the jar gathering, the rat rapport generation. That 
would be great to complement the MINA release docu with what you have done.

If someone feel like preparing the release for MINA 2.0.0 M6, and launch a 
vote, that would be great. Otherwise, I'll be bacl on line on sunday evening.

Thanks !

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





Re : [MINA] purpose of filter-codec-netty package

2009-04-28 Thread Edouard De Oliveira

I remember there was a previous discution thread which seemed to get to a 
consensus on getting rid of it 
no ?
 Cordialement, Regards,
-Edouard De Oliveira-
Blog: http://tedorgwp.free.fr
WebSite: http://tedorg.free.fr/en/main.php 



- Message d'origine 
De : Emmanuel Lecharny elecha...@apache.org
À : dev@mina.apache.org
Envoyé le : Mardi, 28 Avril 2009, 10h22mn 15s
Objet : Re: [MINA] purpose of filter-codec-netty package

Ashish wrote:
 Why do we have filter-codec-netty in MINA?

 The Decoder seem to use some Netty constructs like Message and 
 MessageRecognizer

 I am not sure if I get the use of this package. Is it like a bridge
 between MINA and Netty
 or I am missing something?

 Has anyone used it before?
  
AFAIK, this has been there for historical reason. I'm not sure it's 
needed anymore.


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





Re : [MINA] purpose of filter-codec-netty package

2009-04-28 Thread Edouard De Oliveira

Two of us thinking the same ... hmmm ...can't be a coincidence :)
 Cordialement, Regards,
-Edouard De Oliveira-
Blog: http://tedorgwp.free.fr
WebSite: http://tedorg.free.fr/en/main.php 



- Message d'origine 
De : Julien Vermillard jvermill...@archean.fr
À : dev@mina.apache.org
Envoyé le : Mardi, 28 Avril 2009, 10h29mn 59s
Objet : Re: [MINA] purpose of filter-codec-netty package

Le Tue, 28 Apr 2009 10:22:15 +0200,
Emmanuel Lecharny elecha...@apache.org a écrit :

 Ashish wrote:
  Why do we have filter-codec-netty in MINA?
 
  The Decoder seem to use some Netty constructs like Message and
  MessageRecognizer
 
  I am not sure if I get the use of this package. Is it like a bridge
  between MINA and Netty
  or I am missing something?
 
  Has anyone used it before?
   
 AFAIK, this has been there for historical reason. I'm not sure it's 
 needed anymore.
 
 
Hi,
It was for use with netty2 (trustin project before mina, pretty old).
I thought we passed a vote for remove this module of MINA 2, but I
can't find it.
I'm pretty sure nobody use it. I think we should remove it.

Julien






Re : [Asyncweb] form-urlencoded

2009-04-28 Thread Edouard De Oliveira

Hi Anton,

Could you please fill some JIRA's to track the two issues you raised ?
 Cordialement, Regards,
-Edouard De Oliveira-
Blog: http://tedorgwp.free.fr
WebSite: http://tedorg.free.fr/en/main.php 



- Message d'origine 
De : Anton Tanasenko an...@jawilla.com
À : dev@mina.apache.org
Envoyé le : Vendredi, 24 Avril 2009, 15h57mn 25s
Objet : [Asyncweb] form-urlencoded

Hello again,

DefaultHttpRequest.setContent(IoBuffer) fails to read x-www-form-urlencoded 
data if content type header also contains charset.
Example: Content-type: application/x-www-form-urlencoded; charset=utf-8.
Patch with a fix included.

Form presence clears get parameters. Is that intentional? I didn't find 
anything that states get and post should be mutually exclusive.






Re : A new JIRA for VYSPER ?

2009-04-26 Thread Edouard De Oliveira

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



- Message d'origine 
De : Emmanuel Lecharny elecha...@apache.org
À : dev@mina.apache.org
Envoyé le : Dimanche, 26 Avril 2009, 18h28mn 57s
Objet : A new JIRA for VYSPER ?

Wouldn't be better to create a JIRA for VYSPER instead of creating
DIRMINA issues ?

Also, MINA jiraes are named DIRMINA for historic reasons. Can't we
rename that to MINA (dropping the DIR).

WDYT ?

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






Re : Bernd Fondermann is a new MINA commiter

2009-04-20 Thread Edouard De Oliveira

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



- Message d'origine 
De : Maarten Bosteels mbosteels@gmail.com
À : dev@mina.apache.org
Envoyé le : Lundi, 20 Avril 2009, 14h34mn 56s
Objet : Re: Bernd Fondermann is a new MINA commiter

Welcome Bernd !

Maarten

On Mon, Apr 20, 2009 at 10:52 AM, Julien Vermillard
jvermill...@archean.fr wrote:
 Le Mon, 20 Apr 2009 10:45:35 +0200,
 Niklas Gustavsson nik...@protocol7.com a écrit :

 All,

 as part of the move of Vysper from Apache Labs to MINA, the MINA PMC
 has voted Bernd Fondermann in as a MINA committer. Let's all welcome
 Bernd into the world of MINA!

 /niklas

 Welcome Bernd :)

 Julien







Re : Vysper Logo [WAS: Re: TODOs for moving Vysper]

2009-04-17 Thread Edouard De Oliveira

I like this one but i would make the feathers much smaller and place them on 
the left so that they would be a little bit taller than the two lines figured 
by the Vysper name and the mina logo.

\/
 \  /Apache mina

  \/ Vysper

or

\/  Vysper
 \  /

  \/   Mina

or another combination

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



- Message d'origine 
De : Michael Jakl jakl.mich...@gmail.com
À : dev@mina.apache.org
Envoyé le : Vendredi, 17 Avril 2009, 12h38mn 07s
Objet : Re: Vysper Logo [WAS: Re: TODOs for moving Vysper]

Hi!

On Fri, Apr 17, 2009 at 12:02, Julien Vermillard jvermill...@archean.fr wrote:
  1: http://stuff.interlinked.org/VysperLogos/vysper_xmpp_play.xcf

 +1 I like it :)

Thank you.

I've redone my favorite from the first batch using the new feathers:
http://stuff.interlinked.org/VysperLogos/vysper_xmpp_play_with_text.png

I hope you like the right-aligned text?

As usual the source file is included in the directory.

Cheers,
Michael

Ps: This time with helvetica ;)






Re : Re : Vysper Logo [WAS: Re: TODOs for moving Vysper]

2009-04-17 Thread Edouard De Oliveira

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



- Message d'origine 
De : Michael Jakl jakl.mich...@gmail.com
À : dev@mina.apache.org
Envoyé le : Vendredi, 17 Avril 2009, 14h01mn 23s
Objet : Re: Re : Vysper Logo [WAS: Re: TODOs for moving Vysper]

Hi!

On Fri, Apr 17, 2009 at 13:15, Edouard De Oliveira doe_wan...@yahoo.fr wrote:

 I like this one but i would make the feathers much smaller and place them on 
 the left so that they would be a little bit taller than the two lines figured 
 by the Vysper name and the mina logo.

 \/
  \  /Apache mina

  \/ Vysper

 or

 \/  Vysper
  \  /

  \/   Mina

 or another combination

Like this?
http://stuff.interlinked.org/VysperLogos/vysper_xmpp_play_with_text_horizontal.png

Cheers,
Michael






Re : Re : Vysper Logo [WAS: Re: TODOs for moving Vysper]

2009-04-17 Thread Edouard De Oliveira

i do agree if some remainder to mina is a wish maybe combining the V feathers 
with mina logo (replacing the mina text with Vysper) is the way
 Cordialement, Regards,
-Edouard De Oliveira-
Blog: http://tedorgwp.free.fr
WebSite: http://tedorg.free.fr/en/main.php 



- Message d'origine 
De : Julien Vermillard jvermill...@archean.fr
À : dev@mina.apache.org
Envoyé le : Vendredi, 17 Avril 2009, 14h11mn 26s
Objet : Re: Re : Vysper Logo [WAS: Re: TODOs for moving Vysper]

Le Fri, 17 Apr 2009 14:01:23 +0200,
Michael Jakl jakl.mich...@gmail.com a écrit :

 Hi!
 
 On Fri, Apr 17, 2009 at 13:15, Edouard De Oliveira
 doe_wan...@yahoo.fr wrote:
 
  I like this one but i would make the feathers much smaller and
  place them on the left so that they would be a little bit taller
  than the two lines figured by the Vysper name and the mina logo.
 
  \    /
   \  /Apache mina
 
   \/ Vysper
 
  or
 
  \    /  Vysper
   \  /
 
   \/               Mina
 
  or another combination
 
 Like this?
 http://stuff.interlinked.org/VysperLogos/vysper_xmpp_play_with_text_horizontal.png
 
 Cheers,
 Michael

I'm not sure adding the mina logo is a good idea, make the logo less
readable at small size.
Julien






Re : Re : Re : Vysper Logo [WAS: Re: TODOs for moving Vysper]

2009-04-17 Thread Edouard De Oliveira

IMHO the 4th is really cool ! exactly what i had i mind 
good job :)
 Cordialement, Regards,
-Edouard De Oliveira-
Blog: http://tedorgwp.free.fr
WebSite: http://tedorg.free.fr/en/main.php 



- Message d'origine 
De : Michael Jakl jakl.mich...@gmail.com
À : dev@mina.apache.org
Envoyé le : Vendredi, 17 Avril 2009, 14h55mn 57s
Objet : Re: Re : Re : Vysper Logo [WAS: Re: TODOs for moving Vysper]

On Fri, Apr 17, 2009 at 14:21, Edouard De Oliveira doe_wan...@yahoo.fr wrote:
 i do agree if some remainder to mina is a wish maybe combining the V feathers 
 with mina logo (replacing the mina text with Vysper) is the way

Good point!

Here a few ideas based on the Mina logo:

http://stuff.interlinked.org/VysperLogos/mina_vysper.png (first try,
click on your own risk :))
http://stuff.interlinked.org/VysperLogos/mina_vysper2.png
http://stuff.interlinked.org/VysperLogos/mina_vysper3.png
http://stuff.interlinked.org/VysperLogos/mina_vysper4.png (like 3 but
with shadows)

Cheers,
Michael






[jira] Assigned: (DIRMINA-648) Typo in LoggingFilter-API

2009-04-17 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira reassigned DIRMINA-648:
---

Assignee: Edouard De Oliveira

 Typo in LoggingFilter-API
 -

 Key: DIRMINA-648
 URL: https://issues.apache.org/jira/browse/DIRMINA-648
 Project: MINA
  Issue Type: Bug
  Components: Filter
Affects Versions: 2.0.0-M4, 2.0.0-M5
Reporter: Steve Ulrich
Assignee: Edouard De Oliveira
 Fix For: 2.0.0-M5


 The getters and setters at the LoggingFilter have slightly changed from M3 to 
 M4.
 setExceptionCaughtLog*L*evel(LogLevel) - 
 setExceptionCaughtLog*l*evel(LogLevel)
 setMessageReceivedLog*L*evel(LogLevel) - 
 setMessageReceivedLog*l*evel(LogLevel)
 ..

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



[jira] Resolved: (DIRMINA-648) Typo in LoggingFilter-API

2009-04-17 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira resolved DIRMINA-648.
-

Resolution: Fixed

Renamed all concerned methods to xxxLogLevel(...)

 Typo in LoggingFilter-API
 -

 Key: DIRMINA-648
 URL: https://issues.apache.org/jira/browse/DIRMINA-648
 Project: MINA
  Issue Type: Bug
  Components: Filter
Affects Versions: 2.0.0-M4, 2.0.0-M5
Reporter: Steve Ulrich
Assignee: Edouard De Oliveira
 Fix For: 2.0.0-M5


 The getters and setters at the LoggingFilter have slightly changed from M3 to 
 M4.
 setExceptionCaughtLog*L*evel(LogLevel) - 
 setExceptionCaughtLog*l*evel(LogLevel)
 setMessageReceivedLog*L*evel(LogLevel) - 
 setMessageReceivedLog*l*evel(LogLevel)
 ..

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



Re : svn commit: r766111 - /mina/trunk/core/src/main/java/org/apache/mina/filter/logging/LoggingFilter.java

2009-04-17 Thread Edouard De Oliveira

Shall we consider that this filter is part of the Core API ? We also could 
consider that this is a necessary change as Mina website states that 'All 
classes and methods follow camel notation strictly'.

No problem with rolling these changes back of course 
but my +1 on keeping these
 Cordialement, Regards,
-Edouard De Oliveira-
Blog: http://tedorgwp.free.fr
WebSite: http://tedorg.free.fr/en/main.php 



- Message d'origine 
De : Niklas Gustavsson nik...@protocol7.com
À : dev@mina.apache.org
Envoyé le : Vendredi, 17 Avril 2009, 21h04mn 33s
Objet : Re: svn commit: r766111 - 
/mina/trunk/core/src/main/java/org/apache/mina/filter/logging/LoggingFilter.java

On Fri, Apr 17, 2009 at 8:24 PM,  edeolive...@apache.org wrote:
 -    public LogLevel getExceptionCaughtLoglevel() {
 +    public LogLevel getExceptionCaughtLogLevel() {

This breaks the API, something we promised not to do after M4. Are we
still okay with this change?

/niklas






Re : What aout releasing a 2.0.0-M5 ?

2009-04-05 Thread Edouard De Oliveira

Obviously there were many changes and removing out of scope these may help our 
users concentrate on the possible remaining ones
instead of running into these fixed issues because we didn't made an official 
release.

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



- Message d'origine 
De : Emmanuel Lecharny elecha...@apache.org
À : dev@mina.apache.org
Envoyé le : Lundi, 6 Avril 2009, 0h16mn 12s
Objet : What aout releasing a 2.0.0-M5 ?

Hi guys,

since the last release (2.0.0-M4), many bugs have been fixed. 2.0.0-M4 has been 
released on dec. 10, 4 month ago...

Some bugs found and fixed are really important :
https://issues.apache.org/jira/browse/DIRMINA-653
https://issues.apache.org/jira/browse/DIRMINA-664
https://issues.apache.org/jira/browse/DIRMINA-665
https://issues.apache.org/jira/browse/DIRMINA-667
https://issues.apache.org/jira/browse/DIRMINA-675

We have some more bugs to fix before 2.0.0-RC1, and also a hell lot of doco and 
web-site addition to do.

In the mean-time, I think it mmight be a good idea to release an intermediate 
version without all the fixed bugs, so those who will use the version won't be 
hit by any of those problematic bugs. It does not mean we will differ 
2.0.0-RC1, but AFAICT, neither Julien or me will be available in april to work 
on 2.0.0-RC1. I know that we are not the only committers on the project, but 
that will most certainly slowdown the development, that's for sure !

So wdyt ? Just tell me so that I can launch a vote tomorrow, in order to be 
able to cut a release before leaving for well deserved holidays !

Thanks !

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





some words to buzz around our work

2009-04-05 Thread Edouard De Oliveira

A little mail, just to announce this very short article to enlight Emmanuel's 
presentation at ApacheCon
http://tedorgwp.free.fr/?p=280
 
Wish i was there with you pal :) 
 Cordialement, Regards,
-Edouard De Oliveira-
Blog: http://tedorgwp.free.fr
WebSite: http://tedorg.free.fr/en/main.php 





Re : Sai Pullabhotla is a new committer

2009-03-29 Thread Edouard De Oliveira

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



- Message d'origine 
De : Emmanuel Lecharny elecha...@apache.org
À : dev@mina.apache.org
Envoyé le : Lundi, 30 Mars 2009, 0h49mn 11s
Objet : Re: Sai Pullabhotla is a new committer

Niklas Gustavsson wrote:
 Hi

 I'm very glad to announce that the MINA PMC has voted in Sai
 Pullabhotla as a new MINA committer based on his contributions on the
 FtpServer subproject. Welcome Sai, hope you'll have fun around here!
 :-)
  
Congrat Sai ! And welcome !

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





Re : SingleSessionIoHandlerDelegate

2009-03-09 Thread Edouard De Oliveira

+1 ...

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



- Message d'origine 
De : Emmanuel Lecharny elecha...@apache.org
À : dev@mina.apache.org
Envoyé le : Lundi, 9 Mars 2009, 11h57mn 27s
Objet : Re: SingleSessionIoHandlerDelegate

Julien Vermillard wrote:
 Hi,
 someone use the SingleSessionIoHandlerDelegate and the
 org.apache.mina.handler.multiton package ?

 I feel like CTRL+A DELeting it, except someone use it.

 Julien
  
I don't even know what is this good for ...

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





Re : MINA trunk - Failed test - NTLMTest.testType1Message

2009-01-27 Thread Edouard De Oliveira
Hi guys,

it's indeed this is an ugly way but ntlm needs this info ...
i was thinking this be the place where it could fail. I'll try to get some time 
to work it around tonight.

THx for the report :)

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



- Message d'origine 
De : Ashish paliwalash...@gmail.com
À : dev@mina.apache.org
Envoyé le : Mardi, 27 Janvier 2009, 10h06mn 14s
Objet : Re: MINA trunk - Failed test - NTLMTest.testType1Message

Environment Details

java version 1.6.0_01
Java(TM) SE Runtime Environment (build 1.6.0_01-b06)
Java HotSpot(TM) Client VM (build 1.6.0_01-b06, mixed mode, sharing)

OS - Win XP - SP3


Got the problem. Problem is at Line 98 of
org.apache.mina.proxy.handlers.http.ntlm.NTLMUtilities

Since the out of command ver (Line 91) on my machine is Microsoft
Windows XP [Version 5.1.2600]

The code (Line 98) checks int pos = line.indexOf(version); which
fails and an exception is thrown and
we get the default properties in exception block.

Not sure of its a bug?






[jira] Updated: (DIRMINA-658) BufferedWriteFilter does not pass session closed or exception caught events up the filter chain

2009-01-27 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira updated DIRMINA-658:


Fix Version/s: 2.0.0-RC1
 Assignee: Edouard De Oliveira

i shall investigate  test this but I believe you're right 


 BufferedWriteFilter does not pass  session closed or exception caught events 
 up the filter chain
 

 Key: DIRMINA-658
 URL: https://issues.apache.org/jira/browse/DIRMINA-658
 Project: MINA
  Issue Type: Bug
  Components: Filter
Affects Versions: 2.0.0-M4
Reporter: John Costello
Assignee: Edouard De Oliveira
 Fix For: 2.0.0-RC1

 Attachments: Test.java


 BufferedWriteFilter does not pass along the session closed or exception 
 caught events up the filter chain. This will cause problems with any 
 application that needs to clean up resources on client disconnect or try to 
 reconnect to a server if it has been disconnected. From looking at the other 
 filters, it doesn't look like this omission was intentional
 Patch:
 Index: src/main/java/org/apache/mina/filter/buffer/BufferedWriteFilter.java
 ===
 --- src/main/java/org/apache/mina/filter/buffer/BufferedWriteFilter.java  
 (revision 738176)
 +++ src/main/java/org/apache/mina/filter/buffer/BufferedWriteFilter.java  
 (working copy)
 @@ -243,6 +243,7 @@
  public void exceptionCaught(NextFilter nextFilter, IoSession session,
  Throwable cause) throws Exception {
  free(session);
 +nextFilter.exceptionCaught(session, cause);
  }
  
  /**
 @@ -252,5 +253,6 @@
  public void sessionClosed(NextFilter nextFilter, IoSession session)
  throws Exception {
  free(session);
 +nextFilter.sessionClosed(session);
  }
  }
 \ No newline at end of file

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



[jira] Resolved: (DIRMINA-658) BufferedWriteFilter does not pass session closed or exception caught events up the filter chain

2009-01-27 Thread Edouard De Oliveira (JIRA)

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

Edouard De Oliveira resolved DIRMINA-658.
-

Resolution: Fixed

Fixed
Thx for the detailed report

 BufferedWriteFilter does not pass  session closed or exception caught events 
 up the filter chain
 

 Key: DIRMINA-658
 URL: https://issues.apache.org/jira/browse/DIRMINA-658
 Project: MINA
  Issue Type: Bug
  Components: Filter
Affects Versions: 2.0.0-M4
Reporter: John Costello
Assignee: Edouard De Oliveira
 Fix For: 2.0.0-RC1

 Attachments: Test.java


 BufferedWriteFilter does not pass along the session closed or exception 
 caught events up the filter chain. This will cause problems with any 
 application that needs to clean up resources on client disconnect or try to 
 reconnect to a server if it has been disconnected. From looking at the other 
 filters, it doesn't look like this omission was intentional
 Patch:
 Index: src/main/java/org/apache/mina/filter/buffer/BufferedWriteFilter.java
 ===
 --- src/main/java/org/apache/mina/filter/buffer/BufferedWriteFilter.java  
 (revision 738176)
 +++ src/main/java/org/apache/mina/filter/buffer/BufferedWriteFilter.java  
 (working copy)
 @@ -243,6 +243,7 @@
  public void exceptionCaught(NextFilter nextFilter, IoSession session,
  Throwable cause) throws Exception {
  free(session);
 +nextFilter.exceptionCaught(session, cause);
  }
  
  /**
 @@ -252,5 +253,6 @@
  public void sessionClosed(NextFilter nextFilter, IoSession session)
  throws Exception {
  free(session);
 +nextFilter.sessionClosed(session);
  }
  }
 \ No newline at end of file

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



  1   2   >