Re: MIA for a while...

[Maarten Bosteels]

Dear Emmanuel,

Félicitations pour vous trois !
I think she will be your number one priority for the rest of your life ;-)

Maarten

On Tue, Mar 7, 2017 at 9:00 PM, Bernd Fondermann  wrote:

> Emmanual,
>
> Toutes mes félicitations!
>
> All the best for your baby, your wife and yourself!
>
> Enjoy,
>
>Bernd
>
>
>
> On Thu, Mar 2, 2017 at 3:15 PM, Emmanuel Lécharny 
> wrote:
> > Hi !
> >
> >
> > just for you to know, I may be MIA for a while, or at least way less
> > responsive : My wife just gave birth to our wonderful daughter today,
> > and I'm afraid it's going to be our priority number one in the next few
> > weeks :-)
> >
> >
> > Thanks !
> >
> > --
> > Emmanuel Lecharny
> >
> > Symas.com
> > directory.apache.org
> >
>

Re: final keyword : can we get rid of it when it's not necessary ?

[Maarten Bosteels]

I think
a) that all instance fields that *can* be immutable *should* be immutable
(helps a lot in making sure the code is thread-safe)
b) that all instance fields that are supposed to be immutable should be
declared as final, IMO it makes the code *more* readable

I usually don't declare local variables as final but it would not disturb
me at all if someone did.

But I didn't contribute any code to Mina code for years, so it's not very
relevant what I think ;-)

Regards
Maarten

On Wed, Jan 30, 2013 at 2:08 PM, Emmanuel Lécharny elecha...@gmail.comwrote:

 Le 1/30/13 10:29 AM, Steve Ulrich a écrit :
  Hi!
  Sorry, can't resist to respond on this, since i'm paranoid at
 programming ;-)
 
  Emmanuel Lécharny [mailto:elecha...@gmail.com] wrote
 
  there are a lot of methods which have parameters with a 'final'
  keyword.
  It's most certaibly a IDE configuration, but it's really annoying.
  It looks ugly, true. But I have seen so many method like:
 
  myMethod (Param parameter) {
  ...
  parameter = new Param();
  ...
  }

 Yes, me too, and I told the junior to review there code and lecture them
 so that they don't do the same mistake again.

 We aren't junior developpers, and I don't want to have to add such
 finals all over - even if the IDE does that for me - : t's just a waste
 of time, and makes the code ugly, so more painful to read, and I favor
 my own comfort over a potential error that never occurs in the code we
 write.
 
  IMHO Oracle should make parameter implicit final!
 Ys, and many other things that SUN - not Oracle - have missed would be
 great to have in Java. But it's not really a problem in this case.
  I don't mark my parameters as final, because it makes the parameter list
 hard to read. But I can understand anyone who does so!
 Same for me, but I don't understand why people does so. This is a dead
 stupid idea pushed by people who aren't confident with the code they
 have outsourced somewhere in asia for 5$ an hour...
 
  Can those who have this configuration set in their IDE change it so
  that
  the committed code does not anymore contain the final keyword
  everywhere ?
 
  I personnaly think that the final keyword is useful in two cases :
  - for static fields, like in private statif final int CONSTANT = xxx
  - for variable thet are to be accessed by inner classes
  - for (class/object) variables that are not expected to change anymore.
 
  Declaring an AtomicInteger as non-final is a potential threading issue!
 Anyone could replace it with a new object, rendering the synchronisation
 useless.
  The same is true for concurrent collections, locks, monitors, etc. If
 you don't expect (or want) it to change - make it final.
  The use of local variables shouldn't be that complex, that they need a
 final statement.
 This is a third case, I forgt about it, but this is a perfectly valid one.
 
  Side note :
  I know that some may consider that using final for method parameters is
  a way to protect a stupid coder against a modification of a variable.
  Yeah, sure... But we are not stupid coders, are we ?
  I'm writing perfect code, but somehow the code changes over time. When
 I'm looking into my code a year later, it looks like a drunken monkey hit
 on a keyboard ;-)
 I'm writing crappy code, and I know that, so I'm extra cautious. But I'm
 not relying on stupid rules as a safety belt...

 But this is just me :)


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

[jira] [Commented] (DIRMINA-925) Unresponsive I/O once file limit is reached

[Maarten Bosteels (JIRA)]

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

Maarten Bosteels commented on DIRMINA-925:
--

We have had similar issues. It's logical that MINA cannot accept more 
connections once the file limit is reached, so no point in trying to fix that.
But the problem was that the Acceptor became totally unresponsive, even when 
the number of open file descriptors dropped significantly below the limit.

For now we have 'fixed' it by increasing the max open files limit.
One day I will test (and report) how MINA 3 (and other libs) behave in this 
case. One day, for sure ;-)

 Unresponsive I/O once file limit is reached
 ---

 Key: DIRMINA-925
 URL: https://issues.apache.org/jira/browse/DIRMINA-925
 Project: MINA
  Issue Type: Bug
  Components: Transport
Affects Versions: 2.0.4, 2.0.5, 2.0.7
 Environment: Linux
Reporter: Paul Gregoire

 I had this issue reported to the red5 issues list and it reminded me of an 
 issue on an internal company project that uses Mina but has nothing to do 
 with red5 itself. So the common part in these two cases now is Mina, so I am 
 posting this here.
 The gist of both situations is that once the file limit is reached on the os, 
 mina still attempts to do its work but an exception occurs which eventually 
 runs the box of resources.
 What steps will reproduce the problem?
 1. Use telnet to connect to a servlet's socket until no more connections are 
 allowed (open files limit is reached)
 2. Use telnet to connect to the tomcat port (5080)
 3. Observe red5.logs shown below will repeat until the hard drive fills
 java.io.IOException: Too many open files
 at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method) 
 ~[na:1.6.0_22]
 at 
 sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:163) 
 ~[na:1.6.0_22]
 at 
 org.apache.mina.transport.socket.nio.NioSocketAcceptor.accept(NioSocketAcceptor.java:170)
  ~[mi
 na-core-2.0.4.jar:na]
 at 
 org.apache.mina.transport.socket.nio.NioSocketAcceptor.accept(NioSocketAcceptor.java:51)
  ~[min
 a-core-2.0.4.jar:na]
 at 
 org.apache.mina.core.polling.AbstractPollingIoAcceptor$Acceptor.processHandles(AbstractPolling
 IoAcceptor.java:501) ~[mina-core-2.0.4.jar:na]
 at 
 org.apache.mina.core.polling.AbstractPollingIoAcceptor$Acceptor.run(AbstractPollingIoAcceptor.
 java:442) ~[mina-core-2.0.4.jar:na]
 at 
 org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:64)
  [mina-core-2.0
 .4.jar:na]
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
  [na:1.6.0_22]
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
  [na:1.6.0_22]
 at java.lang.Thread.run(Thread.java:679) [na:1.6.0_22]
 2012-12-13 15:42:28,521 [NioSocketAcceptor-2] WARN  
 o.a.m.util.DefaultExceptionMonitor - Unexpected exception.
 Red5 issue #315 - Red5 gets into a tight loop writing error messages if file 
 open limit is exceeded
 https://code.google.com/p/red5/issues/detail?id=315

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: ApacheCon 2011 meetup

[Maarten Bosteels]

Hello Julien,

Is this meetup cancelled ?
I will be in Vancouver and would like to chat about MINA 3.

Best regards
Maarten

On Tue, Oct 4, 2011 at 12:49 PM, Julien Vermillard jvermill...@gmail.comwrote:

 Hi !
 I created a meetup for apachecon north america 2011.

 The idea is to gather all the MINA users around for chatting about
 MINA (and possibly MINA 3).

 It's free, even if you didn't subscribed the conference (so if you
 live in Vancouver, just come-in).

 If you would like to attend, you just need to increment the counter here :
 http://wiki.apache.org/apachecon/ApacheMeetupsNa11

 Hoping to see you in Vancouver,

 Julien

Re: Welcome Sebastian Bazley as a MINA committer

[Maarten Bosteels]

Welcome !

Maarten

On Mon, Mar 28, 2011 at 2:04 PM, Ashish paliwalash...@gmail.com wrote:
 Welcome :)

 On Mon, Mar 28, 2011 at 1:07 AM, Niklas Gustavsson nik...@protocol7.com 
 wrote:
 Hi

 The MINA PMC has voted to invite Sebastian Bazley (apache ID sebb) as
 a MINA committer due to his great bug reports and patches for
 FtpServer.

 Welcome Sebb!

 /niklas




 --
 thanks
 ashish

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

Re: [VOTE] MINA 2.0.0 take 3 !

[Maarten Bosteels]

+1

Maarten

On Wed, Sep 22, 2010 at 9:52 AM, Emmanuel Lecharny elecha...@gmail.comwrote:


  [X] +1 | Release MINA 2.0.0


 my vote, btw.


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

Re: [VOTE] MINA 2.0.0 take 2

[Maarten Bosteels]

I did a quick smoke-test : created a maven quickstart with a simple client +
server using the maven repo url
https://repository.apache.org/content/repositories/orgapachemina-040/url
Seems fine. Thanks Emmanuel !

+1

One question though :  the distribution on [1] contains sources but no
binaries ?

Maarten

[1]
https://repository.apache.org/content/repositories/orgapachemina-040/org/apache/mina/mina-parent/2.0.0/



2010/9/19 Bernd Fondermann bf_...@brainlounge.de

 On 19.09.10 15:26, Alex Karasulu wrote:

 I don't have the ability to validate the release so I'll just +0 here.


 +0 for the release from me, too.


  Good
 job Emmanuel, thanks for struggling with this release and all that it
 entailed.


 +1 for fighting all mavens, Emmanuel! Thanks a lot!

  Bernd

Re: [VOTE] MINA 2.0.0

[Maarten Bosteels]

I think we should also try to make the tests stable. Hudson builds on
windows seem to be failing more than they pass.
It took us a very long time to reach 2.0.0. That's why I wonder if we
shouldn't spend just a little more time to get these things right ?

Hmm, on the other hand, we could start applying the release early, release
often philosophy from now on ;-)

I am well aware of the fact that I have contributed near to nothing for far
too long, and I hope my comments are not offending anyone.

regards,
Maarten

On Mon, Sep 13, 2010 at 11:08 PM, Emmanuel Lécharny elecha...@apache.orgwrote:

  On 9/13/10 10:54 PM, Niklas Gustavsson wrote:

 On Mon, Sep 13, 2010 at 5:13 PM, Emmanuel Lecharnyelecha...@gmail.com
  wrote:

 [X] +1 | Release MINA 2.0.0

 I got some minor issues with the distribution packages, but nothing
 stopping this release. Otherwise, I think it's looking good.

 yes, we could do better. Like Niklas suggested, releasing a source packaged
 separated from the bin package would be way better.

 I think we can go on with the current release, and fix things in a 2.0.1
 asap.



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

Re: Ready for MINA 2.0 release (almost)

[Maarten Bosteels]

Hi,

Now that 2.0. is coming so close, I tried to get a cleaner fix for the
MdcInjectionFilterTest that used to be failing.
Sorry that I didn't get to it sooner.

The problem lies not so much in that test-case.
IMO, the problem is basically that since revision=900163 [1] we no longer
have an API to block until an AbstractIoService is completely disposed.
I am afraid that we have a lot of test-cases that leave threads behind, when
finished.

I have just added an overloaded dispose method :  public final void
dispose(boolean awaitTermination) that resurrects the previous behaviour.
To be safe I didn't change the default behaviour : dispose() =
dispose(false) = do not wait for termination.
Out of curiosity, I ran all tests with dispose() = dispose(true) and they
all passed.

I also added the attachment for DIRMINA-755 as a test-case.
Note that you should run the main-method instead of the test-case : running
the test-case from my IDE (Intellij IDEA) just resulted in All Tests
Passed instead of blocking until all threads finish.

The weird thing is that the behaviour is unpredictable.
When you run the test several times, most often the call to dispose is done
by NioProcessor-6, but sometimes it's done by the main thread !?
(it's always run by main when  you uncomment the call to Thread.sleep)

The following questions remain :
* should we support calling connector.dispose from the closeFuture callback
?  I don't think so.
* If we don't support it, should we try to detect it, and log a warning
about is ? I don't think so.

Trying to detect if people are shooting themselves in the foot is not easy
in this case (or at least not elegant).

Maarten

[1]  http://svn.apache.org/viewvc?view=revisionrevision=900163
[2] https://issues.apache.org/jira/browse/DIRMINA-755


On Fri, Sep 10, 2010 at 4:13 PM, Emmanuel Lecharny elecha...@gmail.comwrote:

  Hi guys,

 today we worked on a vast cleanup on MINA build (pom.xml and distribution
 module).

 I think we are ready for a release, but I have to run for the week-end, and
 I can't create the branch.

 The distribution module is now completed and is creating the needed sources
 package, so it's just a matter of creating the branch and launch the vote.

 If someone want to do that this week-end, that would be fine. Otherwise,
 i'll do it on monday.

 Have fun !

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

Re: MINA coding conventions

[Maarten Bosteels]

+1

On Sun, May 30, 2010 at 11:03 PM, Niklas Gustavsson nik...@protocol7.comwrote:

 Hi

 In our current coding conventions, we use maximum line widths of 80
 chars. I personally find this somewhat limited on modern displays and
 tend to prefer 120 chars. How about changing this in our coding
 conventions?

 /niklas

cancel a build on hudson

[Maarten Bosteels]

Hello,

In a naive attempt to temporarily fix DIRMINA-784, I created an infinite
loop and now hudson has fell victim of that.

Can someone with the needed privileges, cancel
http://hudson.zones.apache.org/hudson/job/MINA-trunk-jdk1.6-windows/21/

I (think I) have fixed the infinite loop.

And maybe we should specify a timeout for the tests in the pom ?

regards,
Maarten

[jira] Commented: (DIRMINA-784) Error with MDCInjectionFilter on Windows

[Maarten Bosteels (JIRA)]

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

Maarten Bosteels commented on DIRMINA-784:
--

Hello Ashish,

I was also able to reproduce the problem on my machine, without changing any 
timeouts.

And I think I have found the cause(s) of the test failure. I will try to commit 
a fix tonight.

Problems:
* the test uses a custom appender to collect logging events, these logging 
events are checked for MDC values at the end of every test
* but this list of events is never cleared = the events from test1 are still 
present when test2 starts
* but just clearing the events at the end of every test is not enough to solve 
the issue
  because the tests don't wait until all thread pools are completey shut down 
= sometimes events from test1 are generated when test2 is already running

After a quick search I couldn't find an easy way to wait until threadpools are 
shut down.
The NioSocketConnector is disposed on line 226, but this method does not block 
until executor is shut down:  
AbstractIoService.dispose() calls executor.shutdownNow but is used to wait 
until termination


 Error with MDCInjectionFilter on Windows
 

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


 One test is randomly failing on Windows only :
 http://hudson.zones.apache.org/hudson/job/MINA-trunk-jdk1.6-windows/lastBuild/org.apache.mina$mina-core/testReport/org.apache.mina.filter.logging/MdcInjectionFilterTest/testOnlyRemoteAddress/
 It may be the test which is broken, or something we added since the last 
 version, as it was working in 2.0.0-RC1

-- 
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-784) Error with MDCInjectionFilter on Windows

[Maarten Bosteels (JIRA)]

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

Maarten Bosteels edited comment on DIRMINA-784 at 5/10/10 3:28 AM:
---

Hello Ashish,

I was also able to reproduce the problem on my machine, without changing any 
timeouts.

And I think I have found the cause(s) of the test failure. I will try to commit 
a fix tonight.

Problems:
* the test uses a custom appender to collect logging events, these logging 
events are checked for MDC values at the end of every test
* but this list of events is never cleared = the events from test1 are still 
present when test2 starts
* but just clearing the events at the end of every test is not enough to solve 
the issue
  because the tests don't wait until all thread pools are completey shut down 
= sometimes events from test1 are generated when test2 is already running
* the session-closed event that you see are generated by a previous test 

After a quick search I couldn't find an easy way to wait until threadpools are 
shut down.
The NioSocketConnector is disposed on line 226, but this method does not block 
until executor is shut down:  
AbstractIoService.dispose() calls executor.shutdownNow but is used to wait 
until termination


  was (Author: mbosteels):
Hello Ashish,

I was also able to reproduce the problem on my machine, without changing any 
timeouts.

And I think I have found the cause(s) of the test failure. I will try to commit 
a fix tonight.

Problems:
* the test uses a custom appender to collect logging events, these logging 
events are checked for MDC values at the end of every test
* but this list of events is never cleared = the events from test1 are still 
present when test2 starts
* but just clearing the events at the end of every test is not enough to solve 
the issue
  because the tests don't wait until all thread pools are completey shut down 
= sometimes events from test1 are generated when test2 is already running

After a quick search I couldn't find an easy way to wait until threadpools are 
shut down.
The NioSocketConnector is disposed on line 226, but this method does not block 
until executor is shut down:  
AbstractIoService.dispose() calls executor.shutdownNow but is used to wait 
until termination

  
 Error with MDCInjectionFilter on Windows
 

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


 One test is randomly failing on Windows only :
 http://hudson.zones.apache.org/hudson/job/MINA-trunk-jdk1.6-windows/lastBuild/org.apache.mina$mina-core/testReport/org.apache.mina.filter.logging/MdcInjectionFilterTest/testOnlyRemoteAddress/
 It may be the test which is broken, or something we added since the last 
 version, as it was working in 2.0.0-RC1

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

Re: MDC test error on windows

[Maarten Bosteels]

I (as the author of the test and the MDC filter itself) don't mind removing
or disabling the test, but I think we should try to find out WHY the test
fails randomly. The test did work in the past.

I am currently on vacation, so can't look at it during the next few days.
Will have a look when I am back.

Regards,
Maarten

On Thu, Apr 29, 2010 at 9:28 PM, Emmanuel Lecharny elecha...@gmail.comwrote:

 Hi guys,

 I had an hour to install the whole bunch of needed tools on a old Windows
 XP computer (yukkk), and running the tests, I can say that the MDCFilter
 test whih is failing does so randomly : ie, in eclipse, it fails 1/3 of the
 times.

 Just FYI.

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

Re: Re : ConnectFuture confusion

[Maarten Bosteels]

I totally agree with Niklas.

Maarten

On Tue, Mar 2, 2010 at 1:50 PM, Niklas Gustavsson nik...@protocol7.comwrote:

 On Tue, Mar 2, 2010 at 1:30 PM, Emmanuel Lecharny elecha...@gmail.com
 wrote:
  Ok, MINA 2.0 is far from being perfect, there are some issues, but so
 far,
  it's usable.

 Agreed. I think not getting 2.0 out would be bikeshedding. I think we
 should release and support a 2.0 release, then put our main focus on
 3.0 (rather than a 2.1) were we can break stuff. Not releasing 2.0
 would be a disservice to our users who's been waiting for a final
 release. I think most users rather take a good-but-not-perfect 2.0
 over waiting for 3.0 even further.

 My 2 öre as a developer mostly working on the subprojects :-)

 /niklas

Re: 2 Tests failing in MINA trunk build

[Maarten Bosteels]

Will try to have a look asap.

Maarten

On Thu, Jul 2, 2009 at 12:36 PM, Ashish paliwalash...@gmail.com wrote:

 Build MINA from trunk and saw these 2 test cases failing

 Failed tests:

  
 testExecutorFilterAtTheEnd(org.apache.mina.filter.logging.MdcInjectionFilterTest)

  testTwoExecutorFilters(org.apache.mina.filter.logging.MdcInjectionFilterTest)

 Tests run: 185, Failures: 2, Errors: 0, Skipped: 0

 This is the error (same for both failures), removed unwanted traces

 java.lang.AssertionError: MDC[remoteAddress] not set for [encode]
at org.junit.Assert.fail(Assert.java:74)
at org.junit.Assert.assertTrue(Assert.java:37)
at org.junit.Assert.assertNotNull(Assert.java:356)
at
 org.apache.mina.filter.logging.MdcInjectionFilterTest.test(MdcInjectionFilterTest.java:241)
at
 org.apache.mina.filter.logging.MdcInjectionFilterTest.testExecutorFilterAtTheEnd(MdcInjectionFilterTest.java:116)

 ==
 at
 org.apache.mina.filter.logging.MdcInjectionFilterTest.test(MdcInjectionFilterTest.java:241)
 at
 org.apache.mina.filter.logging.MdcInjectionFilterTest.testTwoExecutorFilters(MdcInjectionFilterTest.java:166)

 ==
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)


 --
 thanks
 ashish

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

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

[Maarten Bosteels]

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

Re: [VOTE] Release MINA 2.0.0-M6

[Maarten Bosteels]

+1

Maarten

On Tue, May 26, 2009 at 8:58 PM, Jeff Genender jgenen...@apache.org wrote:

 +1



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

  On Tue, May 26, 2009 at 3:08 PM, Emmanuel Lecharny elecha...@apache.org
 wrote:

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


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

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


 /niklas

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

[Maarten Bosteels (JIRA)]

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

Maarten Bosteels reassigned DIRMINA-711:


Assignee: Maarten Bosteels

 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] Resolved: (DIRMINA-711) Adding some logs in the chain make the MDCFilter tests to fail

[Maarten Bosteels (JIRA)]

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

Maarten Bosteels resolved DIRMINA-711.
--

Resolution: Fixed

 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.

Re: What about a quick 2.0.0-M6 release ?

[Maarten Bosteels]

+1

On Thu, May 14, 2009 at 2:34 PM, Ashish paliwalash...@gmail.com wrote:

 On Thu, May 14, 2009 at 1:30 PM, Emmanuel Lecharny elecha...@apache.org
 wrote:
  Hi guys,
 
  2.0.0-M5 released introduced two regressions, one in the API (a method
 has
  been removed by mistake) and another in the OrderedThreadPool, which is a
  bad one.
 
  What about releasing a quick 2.0.0-M6 to solve those two issues ?
 

 +1

 --
 thanks
 ashish

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

Re: Header stuff

[Maarten Bosteels]

On Wed, May 6, 2009 at 12:34 AM, Emmanuel Lecharny elecha...@apache.org wrote:
 Michael Jakl wrote:

 Hi!

  Even though I've brought this up in JIRA, I don't see any benefit from
 these tags either - so I'd second the drop them.

 What's the possible benefits from adding the revision and change-date
 to a file in the first place?


 In an ancient age, when geeks where trying to get most of their Sinclair ZX
 81, counting CPU cycles, and using undocumented assembly instructions, it
 was useful to have those tags, as network was a luxury.

Funny enough, you don't need network to do svn info pom.xml  ;-)
so +1 for removing

Maarten


 But most of you guys were probably having milk on your chin back then ;)

 Right now, if I want to get the version of a file, I do :

 elecha...@elecharny-laptop:~/apacheds/new-trunk$ svn info pom.xml
 Path: pom.xml
 Name: pom.xml
 URL:
 https://svn.apache.org/repos/asf/directory/apacheds/trunk-with-dependencies/pom.xml
 Repository Root: https://svn.apache.org/repos/asf
 Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
 Revision: 770457
 Node Kind: file
 Schedule: normal
 Last Changed Author: elecharny
 Last Changed Rev: 577391
 Last Changed Date: 2007-09-19 19:23:55 +0200 (Wed, 19 Sep 2007)
 Text Last Updated: 2009-04-27 14:07:58 +0200 (Mon, 27 Apr 2009)
 Checksum: d4508878a4ef6be8ce3722325652eb0f

 If I don't have the file under SVN locally, I go on
 http://svn.apache.org/viewvc/mina, and I look at the file I'm interested in,
 to get all the needed info.

 Btw, I *never* do both of those operations, because it's useless...

 So I think those tags are injected into the source file because someone has
 some Maxtor(tm)/Seagate(tm) stocks :)

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

Re: Bernd Fondermann is a new MINA commiter

[Maarten Bosteels]

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: [VOTE] Vysper as MINA subproject

[Maarten Bosteels]

+1
Maarten

On Mon, Apr 13, 2009 at 12:31 PM, Ashish paliwalash...@gmail.com wrote:
 Hi
 Let's that vote run for at least 72h please.
 Julien

 Summary was not to stop the Vote. It was just to give the status :-)

 - ashish

Re: Codec Factories

[Maarten Bosteels]

On Tue, Mar 31, 2009 at 10:24 AM, Emmanuel Lecharny
elecha...@apache.org wrote:
 Maarten Bosteels wrote:

 The codecfactory in the tutorial is stateless :
 http://mina.apache.org/tutorial-on-protocolcodecfilter-for-mina-2x.html


 Well, if you create new instances of encoder/decoder per session, it doesn't
 matter too much that the factory is stateless or not. In fact, the factory
 being statefull or stateless is irrelevant.

I was talking about the encoder/decoder of course.
But it's the codecfactory that has to know whether the decoder is
stateless or not.

(I think encoder will almost always be stateless because all data is
already available)

It's the encoder/decoder state
 which is important. As soon as you have new instances of those guys for each
 new session, and as soon as you have a guarantee that you can't enter the
 encoder/decoder in two different threads for the same session, then you are
 safe.

 FWIK, if you encoder/decoder are stateless, you should never instanciate
 them for each session. If they are statefull, then again, you have to think
 about the consequences. I don't think it's a good idea to design a stateful
 codec by storing data into the encoder/decoder. I would rather store those
 data in a context object, stores within the session. This is what we do for
 the LDAP protocol. So at the end of the day, I don't think it make any sense
 to instanciate encoder/decoder at all ...

That is/was my opinion as well, but in that thread other people
expressed their preference to use stateful decoders...


 Thanks Marteen for the pointers !

You do it on purpose ! ;-)

Maarten

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

Re: [FtpServer] Suspend problem on OSX (was Re: [VOTE] Releasing FtpServer 1.0.0)

[Maarten Bosteels]

Works fine on Fedora 10, ext2, ext3 and ntfs mounted with ntfs-3g (fuseblk)
For the mounted ntfs partition I had to use CaseSensitive.

Maarten

On Thu, Mar 5, 2009 at 10:39 AM, Emmanuel Lecharny elecha...@apache.orgwrote:

 Works fine on my Mac OS X 10.4/Java 5

 On Wed, Mar 4, 2009 at 11:13 PM, Niklas Gustavsson nik...@protocol7.com
 wrote:
  On Mon, Mar 2, 2009 at 4:54 PM, Niklas Gustavsson nik...@protocol7.com
 wrote:
  Let me whip up a prototype and we can test it on the available
 platforms.
 
  Alright, here's a prototype that I would much appreciate if all of you
  would take the time to test. First of all, you need to set the
  FILE_SYSTEM_TYPE to the correct value (this is only used for
  verification in the tests). On case sensitive file systems (most of
  the *nix file systems), this should be set to
  FileSystemType.CaseSensitive. On NTFS it should be set to
  CaseInsensitiveMissingAsTrue, and on case-insensitive HFS to
  CaseInsensitiveMissingAsFalse. It would be very interesting to have
  this code tested on other file systems. If you do, please report the
  file system and the test results.
 
  /niklas
 
  package org.apache.ftpserver.filesystem.nativefs.impl;
 
  import java.io.File;
  import java.io.FilenameFilter;
  import java.io.IOException;
 
  import junit.framework.TestCase;
 
  public class FileEqualsTest extends TestCase {
 
 private enum FileSystemType {
 CaseSensitive,
 // non-existing files with different casing are equal
 // e.g. NTFS
 CaseInsensitiveMissingAsTrue,
 // non-existing files with different casing are non-equal
 // e.g. HFS
 CaseInsensitiveMissingAsFalse
 };
 
 private static final FileSystemType FILE_SYSTEM_TYPE =
  FileSystemType.CaseSensitive;
 
 private boolean isCaseSensitive() {
 return FILE_SYSTEM_TYPE == FileSystemType.CaseSensitive;
 }
 
 private boolean isCaseInsensitive() {
 return FILE_SYSTEM_TYPE != FileSystemType.CaseSensitive;
 }
 
 @Override
 protected void setUp() throws Exception {
 System.out.println(File system type:  + FILE_SYSTEM_TYPE);
 super.setUp();
 }
 
 public void testSimple() throws IOException {
 File f1 = new File(foo);
 assertTrue(f1.createNewFile());
 File f2 = new File(foo);
 
 assertTrue(equals(f1, f2));
 }
 
 public void testNonExistingButSimple() {
 File f1 = new File(foo);
 File f2 = new File(foo);
 
 assertTrue(equals(f1, f2));
 }
 
 public void testDifferentCase() throws IOException {
 File f1 = new File(foo);
 assertTrue(f1.createNewFile());
 File f2 = new File(FOO);
 
 // if this succeeds, we have two different files
 assertEquals(isCaseSensitive(), f2.createNewFile());
 
 assertEquals(isCaseInsensitive(), equals(f1, f2));
 }
 
 public void testDifferentCaseNonExisting() throws IOException {
 File f1 = new File(foo);
 File f2 = new File(FOO);
 
 assertEquals(FILE_SYSTEM_TYPE ==
  FileSystemType.CaseInsensitiveMissingAsTrue, equals(f1, f2));
 }
 
 public void testSameNameDifferentParent() throws IOException {
 File f1 = new File(foo);
 assertTrue(f1.createNewFile());
 File dir2 = new File(dir);
 assertTrue(dir2.mkdir());
 File f2 = new File(dir2, foo);
 assertTrue(f2.createNewFile());
 
 assertFalse(equals(f1, f2));
 }
 
 public boolean equals(final File f1, final File f2) {
 if (f1 == null || f2 == null) {
 return false;
 }
 
 if (f1.equals(f2)) {
 // file equals, valid on all file systems
 return true;
 } else {
 boolean f1Exists = f1.exists();
 boolean f2Exists = f2.exists();
 
 if (f1.getName().equalsIgnoreCase(f2.getName())) {
 // same name, do both exist?
 if (f1Exists  f2Exists) {
 // both files exists, do they have the same parent?
 
 // TODO should we use canonical or absolute path?
 File f1Parent = f1.getAbsoluteFile().getParentFile();
 File f2Parent = f2.getAbsoluteFile().getParentFile();
 
 if (f1Parent != null  f2Parent != null) {
 if (equals(f1Parent, f2Parent)) {
 // okay, if we got here, the parents are the
 same,
 // the file names are the same and both files
 exists
 // let's check if there are multiple files
  or only one in the parent
 // with that name
 
 
 // choosing either parent should be fine,
  they are equal
 String[] files = f1Parent
 .list(new FilenameFilter() {
 

Re: FtpServer 1.0.0 released

[Maarten Bosteels]

Congratulations !

Maarten

On Sun, Mar 1, 2009 at 9:11 PM, Niklas Gustavsson nik...@protocol7.comwrote:

 The Apache MINA project is pleased to announce the release of FtpServer
 1.0.0.

 This is the first major, production ready, release of Apache
 FtpServer. We consider the code to be very stable and well performing.
 The project has been under development for a long time with many
 contributors, all of which has made valuable improvements to the code
 base.

 We have started development towards the 1.1.0 release with some great
 new features and will also be providing bug fixes to the 1.0 branch.
 Feedback on feature requests, bugs or questions are most welcome at
 our mailing lists.

 We welcome you to try it out. We have tried to make it simple both to
 embed within your application as well as running it standalone.

 The latest release is now available here:
 http://mina.apache.org/ftpserver/downloads.html

 A list of all the resolved issues for this this release is available here :

 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10571styleName=Htmlversion=12312283

 Thanks for helping us get this far and welcome to follow us along with
 our future releases!

 /niklas

Re: [FtpServer] Suspend problem on OSX (was Re: [VOTE] Releasing FtpServer 1.0.0)

[Maarten Bosteels]

But even when it's not fixed in java 6...
When it's a JVM bug on OS X, and there is no clean work-around, then IMO we
shouldn't jumpt through too many hoops trying to solve it.

Maarten

On Mon, Mar 2, 2009 at 11:01 AM, Emmanuel Lecharny elecha...@apache.orgwrote:

 Niklas Gustavsson wrote:

 On Sun, Mar 1, 2009 at 11:06 PM, Emmanuel Lecharny elecha...@apache.org
 wrote:


  I'm not
 really happy with this but I can't figure out a better way, besides
 someone fixing the JVM.


 Btw, it's fixed in Java 6 on Mac OSX, AFAICT. The biggest issue is that
 you
 can't run this JVM on OS X 10.4.



 Really? If so, I'll be happy to declare this a known issue with Java
 1.5 on OS X (like the problem we had with NIO) and closing it from out
 point of view.


 Nah, i'm wrong. I'm confusing the two issues : the socket error and the
 case sensitive directory error.

 The first one is fixed on Java 6, but not the second one...


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

Re: [FtpServer] Suspend problem on OSX (was Re: [VOTE] Releasing FtpServer 1.0.0)

[Maarten Bosteels]

Would it be a viable option to let users of FtpServer define which
mount-points use a case-insensitive file-system ?
I mean an out-of-the-box FtpServer config that works for 95% of the
user-base and the other 5% would have to do some extra configuration.

Maarten


On Mon, Mar 2, 2009 at 6:12 PM, Niklas Gustavsson nik...@protocol7.comwrote:

 On Mon, Mar 2, 2009 at 6:01 PM, Sai Pullabhotla
 sai.pullabho...@jmethods.com wrote:
  Does this help at all?
 
  http://lists.apple.com/archives/java-dev/2004/Feb/msg00331.html

 I've posted this previously in this thread, however they do not seem
 to reach any conclusion beyond this being more complex that you might
 think :-)

 /niklas

Re: [VOTE] Releasing FtpServer 1.0.0-RC2

[Maarten Bosteels]

[X]: +1, Release FtpServer 1.0.0-RC2

On Mon, Jan 26, 2009 at 11:12 AM, Emmanuel Lecharny elecha...@gmail.comwrote:

 Oops, I meant :

 [X]: +1, Release FtpServer 1.0.0-RC2

 On Mon, Jan 26, 2009 at 11:11 AM, Emmanuel Lecharny elecha...@gmail.com
 wrote:
  [X ]: +1, Don't release FtpServer 1.0.0-RC2
 
  Instead of waiting a bit, as some bugs have been fixed since RC1, I
  would rather see this version released, and wait a bit before
  releasing the final version. It's not really a problem to have many
  RC, as soon as we move forward a GA !
 
  --
  Regards,
  Cordialement,
  Emmanuel Lécharny
  www.iktek.com
 



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

Re: IntelliJ IDEA for development

[Maarten Bosteels]

In my experience it's enough to send a mail to sa...@jetbrains.com and

a) tell them you are an Apache Committer.
b) include a reference to http://mina.apache.org/contributors.html

Maarten

On Wed, Jan 21, 2009 at 3:57 PM, Emmanuel Lecharny elecha...@gmail.comwrote:

 Hi Ashish,

 On Wed, Jan 21, 2009 at 12:58 PM, Ashish paliwalash...@gmail.com wrote:
  JetBrains supports open source community, including ASF, by providing
  individual licenses.
  I was thinking for applying for Open Source License for MINA project

 We already have open licences. It's available somwhere in the
 committers directory on people.apache.org.

 Gimme a few hours until I come back home, I will then point you to the
 correct location.



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

Re: [jira] Created: (DIRMINA-645) SslFilter should start initiating handshake from sesionCreated() rather than from onPostAdd()

[Maarten Bosteels]

Have you tried adding the SSLFilter to the filter chain of the session
_AFTER_ proxyFilter is initialised ?

Maarten

On Wed, Dec 10, 2008 at 5:00 PM, Dan Mihai Dumitriu (JIRA)
[EMAIL PROTECTED]wrote:

 SslFilter should start initiating handshake from sesionCreated() rather
 than from onPostAdd()

 -

 Key: DIRMINA-645
 URL: https://issues.apache.org/jira/browse/DIRMINA-645
 Project: MINA
  Issue Type: Bug
  Components: Filter
Affects Versions: 2.0.0-M3
Reporter: Dan Mihai Dumitriu
 Fix For: 2.0.0-M4


 Here's the situation I needed to get working.  We want to make a secure
 connection through a SOCKS 5 proxy.  So, one would think that just using the
 SslFilter and and the ProxyConnector (which adds the ProxyFilter at the
 bottom of the stack) would just do it.  Unfortunately, it does not work
 quite right out of the box.  The ProxyFilter only fully initializes itself
 after the sessionCreated() method is called.  Meanwhile, the SslFilter tries
 to start the handshake (i.e. calls initiateHandshake()) from the onPostAdd()
 method, which occurs before the sessionCreated() is called.

 Moving the initiateHandshake() from onPostAdd() to sessionCreated() in
 SslFilter, as shown below, seems to fix the problem.

@Override
public void onPostAdd(IoFilterChain parent, String name,
NextFilter nextFilter) throws SSLException {
 //if (autoStart) {
 //initiateHandshake(nextFilter, parent.getSession());
 //}
}

@Override
public void sessionCreated(NextFilter nextFilter, IoSession session)
throws Exception {
super.sessionCreated(nextFilter, session);

if (autoStart) {
initiateHandshake(nextFilter, session);
}
}


 --
 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-M4

[Maarten Bosteels]

[X] +1, let's release 2.0.0-M4 and freeze the API

Maarten

On Fri, Dec 5, 2008 at 2:49 AM, Jeff Genender [EMAIL PROTECTED] wrote:

 +1


 On Dec 4, 2008, at 4:49 PM, Emmanuel Lecharny wrote:

  Hi guys,

 we have released 2.0.0-M3 a few weeks ago (nov, 8th). I think it's time
 for the last milestone before RC1 now.

 We still have a few issues to fix (7), but so far, the API won't change
 now. I would call this release the API freeze release. Once release, we
 should work on 2.0-RC1, fixing the last bugs, and more important, adding
 documentation to the project. Hopefully, we can get a 2.0-RC1 by the very
 beginning of 2009, and a 2.0-GA a few weeks later, if everything goes right.

 So now, let's open the vote :

 [] +1, let's release 2.0.0-M4 and freeze the API
 [] +/- 0, abstain
 [] -1 : we are not ready, let's wait a bit more.

 Thanks !

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

Re: 2.0-RC1 road to success ...

[Maarten Bosteels]

On Sat, Nov 22, 2008 at 2:23 AM, Emmanuel Lecharny [EMAIL PROTECTED]wrote:

 Sorry if I missed some binding votes ...


No worries.


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


AFAIK,  [EMAIL PROTECTED] = Mark Webb = PMC member

Maarten



 On Fri, Nov 21, 2008 at 8:54 PM, Maarten Bosteels
 [EMAIL PROTECTED] wrote:
  On Fri, Nov 21, 2008 at 7:18 PM, Emmanuel Lecharny [EMAIL PROTECTED]
 wrote:
 
  Hi guys,
 
  the vote for the 2.0-RC1 code freeze is now closed. the result :
  +1 : 3 binding votes (mine included), 6 non binding
 
 
  Hello,
 
  My apologies for nitpicking, but according to
  http://www.nabble.com/-Votes--MINA-2.0-RC1-to20557460.html
  I see 5 binding votes: Emmanuel, Maarten, Julien, Niklas G, Marc
  and 5 non-binding: Eero, Edouard, Steve, Jeff, Ashish
 
  Maarten
 
 
 
  So we will freeze the API now, and move to RC1 as soon as the doco is
 ok. I
  suggest that 2.0.0-M4 should be the API freeze, and that we move to RC1
 as
  soon as we reach a decent level of documentation (Javadoc, site and
  tutorial).
 
  I will also create a 3.0-M1 version, so those who want to move JIRAs to
  this version can do it.
 
  However, we still have a bunch of open issues, some of them being
  associated with 2.0.0-M4 and a lot more being unscheduled. Here are all
 the
  open issues :
 
  Scheduled for 2.0.0-M4 :
  
 
  | Bug  | DIRMINA-539  | Major | NioDatagramConnector doesn't takes the
  TrafficClass value set to his DatagramSessionConfig
  | Bug  | DIRMINA-585  | Minor | Visibility issue in various
 configuration
  properties and a few critical counters
  | Bug  | DIRMINA-574  | Block | ClassCastException when a message is
  written on a closed session
  | Bug  | DIRMINA-639  | Block | WriteFuture are updated long after a
  session.write() is done
  | Impr | DIRMINA-593  | Major | Javadoc  documentation for
  org/apache/mina/filter/reqres
  | Impr | DIRMINA-594  | Major | Javadoc  documentation for APR
 transport
  | Impr | DIRMINA-577  | Major | Implement a Selector pool
  | Impr | DIRMINA-586  | Minor | Dynamic delimiter support for
  TextLineCodecFactory
  | Impr | DIRMINA-605  | Major | Add documentation for using and building
  serial port connection
  | Impr | DIRMINA-629  | Minor | The IoServiceStatistics methods are
 called
  for every new session creation
  | NewF | DIRMINA-415  | Major | Proxy support
  | NewF | DIRMINA-489  | Major | Composite IoBuffer
  | NewF | DIRMINA-518  | Minor | Support gathering writes
  | NewF | DIRMINA-520  | Minor | DemuxingIoHandler for
  SingleSessionIoHandlers
  | NewF | DIRMINA-554  | Minor | A hook between bind() and accept()
  | Task | DIRMINA-477  | Major | Update page about differences between
 1.x
  and 2.x
  | Task | DIRMINA-612  | Minor | Add documentation on
 SingleSessionIohandler
 
 
  Unscheduled :
  -
 
  | Bug  | DIRMINA-618  | Block | Latest MINA won't work with glassfish as
  JCA inbound connector
  | Bug  | DIRMINA-604  | Criti | Deadlock occurs when implementing two
 mina
  StateMachine
  | Bug  | DIRMINA-419  | Major | about the Proxy example
  | Bug  | DIRMINA-588  | Major | High CPU Usage in AprIoProcessor
  | Bug  | DIRMINA-597  | Major | AbstractIoAcceptor.toString() blocks
 when
  invoked from IoServiceListener.serviceActivated()
  | Bug  | DIRMINA-598  | Major | ByteBuffer passed to
  ProtocolEncoderOutput.write(ByteBuffer) does not get released back to
 the
  pool
  | Bug  | DIRMINA-617  | Major | JMX - IoServiceMBean doesn't expose
  IoService statistics
  | Bug  | DIRMINA-627  | Major | ByteBuffer.getObject() doesn't support
  Class objects for non-serializable classes
  | Bug  | DIRMINA-379  | Major | setKeepAlive/setTcpNoDelay and
 exceptions
  in Windows Vista
  | Bug  | DIRMINA-632  | Major | WriteFuture.awaitUninterruptibly() or
  .join() hangs if write() throws Exceptions
  | Bug  | DIRMINA-634  | Major | IllegalStateException: Already released
  Buffer in SSLFilter messageSent()
  | Bug  | DIRMINA-596  | Major | Sessions generated by NioSocketConnector
  cannot be closed in time (within MINA2.0 M1,M2)
  | Bug  | DIRMINA-625  | Major | How to use the function
  awaitUninterruptibly or await
  | Impr | DIRMINA-301  | Major | New Multi threaded SocketIOProcessor to
  improve fairness of socket reads/writes
  | Impr | DIRMINA-210  | Major | Investigate removal of static methods in
  ByteBuffer
  | Impr | DIRMINA-509  | Major | DatagramConnector.connect() is slow
  compared to connect() with java.net.DatagramSocket
  | Impr | DIRMINA-572  | Major | Add Spring support for Mina statemachine
  | Impr | DIRMINA-601  | Major | Add sendfile support to transport-apr
  | Impr | DIRMINA-616  | Major | New release.xml file
  | Impr | DIRMINA-624  | Major | Message handlers selection is not
 efficient
  in the DemuxingIoHandler
  | Impr | DIRMINA-631  | Major | AbstractIoFilter: increment writen

Re: 2.0-RC1 road to success ...

[Maarten Bosteels]

On Fri, Nov 21, 2008 at 7:18 PM, Emmanuel Lecharny [EMAIL PROTECTED]wrote:

 Hi guys,

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


Hello,

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

Maarten



 So we will freeze the API now, and move to RC1 as soon as the doco is ok. I
 suggest that 2.0.0-M4 should be the API freeze, and that we move to RC1 as
 soon as we reach a decent level of documentation (Javadoc, site and
 tutorial).

 I will also create a 3.0-M1 version, so those who want to move JIRAs to
 this version can do it.

 However, we still have a bunch of open issues, some of them being
 associated with 2.0.0-M4 and a lot more being unscheduled. Here are all the
 open issues :

 Scheduled for 2.0.0-M4 :
 

 | Bug  | DIRMINA-539  | Major | NioDatagramConnector doesn't takes the
 TrafficClass value set to his DatagramSessionConfig
 | Bug  | DIRMINA-585  | Minor | Visibility issue in various configuration
 properties and a few critical counters
 | Bug  | DIRMINA-574  | Block | ClassCastException when a message is
 written on a closed session
 | Bug  | DIRMINA-639  | Block | WriteFuture are updated long after a
 session.write() is done
 | Impr | DIRMINA-593  | Major | Javadoc  documentation for
 org/apache/mina/filter/reqres
 | Impr | DIRMINA-594  | Major | Javadoc  documentation for APR transport
 | Impr | DIRMINA-577  | Major | Implement a Selector pool
 | Impr | DIRMINA-586  | Minor | Dynamic delimiter support for
 TextLineCodecFactory
 | Impr | DIRMINA-605  | Major | Add documentation for using and building
 serial port connection
 | Impr | DIRMINA-629  | Minor | The IoServiceStatistics methods are called
 for every new session creation
 | NewF | DIRMINA-415  | Major | Proxy support
 | NewF | DIRMINA-489  | Major | Composite IoBuffer
 | NewF | DIRMINA-518  | Minor | Support gathering writes
 | NewF | DIRMINA-520  | Minor | DemuxingIoHandler for
 SingleSessionIoHandlers
 | NewF | DIRMINA-554  | Minor | A hook between bind() and accept()
 | Task | DIRMINA-477  | Major | Update page about differences between 1.x
 and 2.x
 | Task | DIRMINA-612  | Minor | Add documentation on SingleSessionIohandler


 Unscheduled :
 -

 | Bug  | DIRMINA-618  | Block | Latest MINA won't work with glassfish as
 JCA inbound connector
 | Bug  | DIRMINA-604  | Criti | Deadlock occurs when implementing two mina
 StateMachine
 | Bug  | DIRMINA-419  | Major | about the Proxy example
 | Bug  | DIRMINA-588  | Major | High CPU Usage in AprIoProcessor
 | Bug  | DIRMINA-597  | Major | AbstractIoAcceptor.toString() blocks when
 invoked from IoServiceListener.serviceActivated()
 | Bug  | DIRMINA-598  | Major | ByteBuffer passed to
 ProtocolEncoderOutput.write(ByteBuffer) does not get released back to the
 pool
 | Bug  | DIRMINA-617  | Major | JMX - IoServiceMBean doesn't expose
 IoService statistics
 | Bug  | DIRMINA-627  | Major | ByteBuffer.getObject() doesn't support
 Class objects for non-serializable classes
 | Bug  | DIRMINA-379  | Major | setKeepAlive/setTcpNoDelay and exceptions
 in Windows Vista
 | Bug  | DIRMINA-632  | Major | WriteFuture.awaitUninterruptibly() or
 .join() hangs if write() throws Exceptions
 | Bug  | DIRMINA-634  | Major | IllegalStateException: Already released
 Buffer in SSLFilter messageSent()
 | Bug  | DIRMINA-596  | Major | Sessions generated by NioSocketConnector
 cannot be closed in time (within MINA2.0 M1,M2)
 | Bug  | DIRMINA-625  | Major | How to use the function
 awaitUninterruptibly or await
 | Impr | DIRMINA-301  | Major | New Multi threaded SocketIOProcessor to
 improve fairness of socket reads/writes
 | Impr | DIRMINA-210  | Major | Investigate removal of static methods in
 ByteBuffer
 | Impr | DIRMINA-509  | Major | DatagramConnector.connect() is slow
 compared to connect() with java.net.DatagramSocket
 | Impr | DIRMINA-572  | Major | Add Spring support for Mina statemachine
 | Impr | DIRMINA-601  | Major | Add sendfile support to transport-apr
 | Impr | DIRMINA-616  | Major | New release.xml file
 | Impr | DIRMINA-624  | Major | Message handlers selection is not efficient
 in the DemuxingIoHandler
 | Impr | DIRMINA-631  | Major | AbstractIoFilter: increment writen- and
 receivedMessages statistics on application end of filter chain
 | Impr | DIRMINA-166  | Minor | Common internal messages that can be shared
 by filters and transport implementations
 | Impr | DIRMINA-237  | Minor | Improve Spring integration
 | Impr | DIRMINA-371  | Trivi | Annotations to document concurrency
 | Impr | DIRMINA-622  | Trivi | Initialise return ByteBuffer from
 PoolByteBufferAllokator with 0
 | NewF | DIRMINA-453  | Major | Multiple IoServices for one
 java.nio.Selector
 | NewF | DIRMINA-68   | Major | Automatic reconnect 

Re: [Vote] Create a MINA subproject to implement a SSH server based on Mina

[Maarten Bosteels]

[X] +1 Yes, accept the SSH server as a sub-project

Maarten

Re: Re : Re : [Votes] MINA 2.0-RC1

[Maarten Bosteels]

[x] Freeze the code, move to MINA 2.0-RC1

But I agree with Julien, that the docs should improve before going to RC

-1 for using a N.5 for unstable versions, and N.0 for stable versions.

I really dislike conventions based on numbers. We already discussed this in
the past : http://mina.markmail.org/message/hymzddmoteiatcwq
Milestone - Release Candidate - General Availability is a well know
version naming scheme
It's described here: http://mina.apache.org/downloads.html

I really don't see why we would change the version naming scheme again.
Of course it's a matter of taste so we can have long discussions about it
... (not sure that it would be productive though)

regards,
Maarten


On Tue, Nov 18, 2008 at 2:53 PM, Emmanuel Lecharny [EMAIL PROTECTED]wrote:

 Edouard De Oliveira wrote:

 By drawing aside N.1 and N.2 do you mean we will only do bug fixes on the
 2.0 branch and new features will only go to 2.5 branch ? I'm not saying i
 disagree i just want to make your statement more clear.


 This is exactly what I have in mind. However, it's just a convention. It's
 all about the message we want to carry to our users.


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

Re: Re : David Latorre is a new MINA commiter

[Maarten Bosteels]

Welcome David !

Maarten

On Fri, Nov 14, 2008 at 9:28 PM, Edouard De Oliveira [EMAIL PROTECTED]wrote:

 Welcome David :)

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




 
 De : David Latorre [EMAIL PROTECTED]
 À : dev@mina.apache.org
 Envoyé le : Vendredi, 14 Novembre 2008, 18h04mn 59s
 Objet : Re: David Latorre is a new MINA commiter

 2008/11/14 Julien Vermillard [EMAIL PROTECTED]

  On Fri, 14 Nov 2008 08:17:25 +0100
  Niklas Gustavsson [EMAIL PROTECTED] wrote:
 
   Hi
  
   Let me welcome David Latorre as a new MINA commiter. David has been
   doing great contributions to the FtpServer subproject and has now been
   voted in as a new commiter so that he gets to mess up on his own :-)
  
   Welcome David, happy hacking!
  
   /niklas
 
  Nice to see more commiters involved in ftpserver.
 
  Warm welcome !
 
  Julien


 Hello everyone,

 Thanks for the welcome. I hope I can be of help with FtpServer and all the
 MINA projects :-) -  I'm quite interested in SFTP  but eventually I'll try
 to mess errr help with Mina. People in this mailing list seem really
 involved and enthusiastic which is is inspiring and quite refreshing too.
 This is the liveliest project I've visited lately. And from the discussions
 in the list I've been following, I would say one of the most well-thought
 as
 well.

 If I can figure out how to and I don't break anything,  I'm gonna  make my
 first commit in a moment. A question: is there any guidelines for the
 project I can read?

 Cheers,
 David

Re: Re : [MessageSent] let's remove it...

[Maarten Bosteels]

+1

On Tue, Nov 11, 2008 at 11:59 AM, Edouard De Oliveira
[EMAIL PROTECTED]wrote:

 lol
 Emm did you pay Rajeshwari just to support your proposal ? DIRMINA-634
 should also be resolved by removing messageSent event
 which seems to be an unnecessary event that makes code even more cloudy.

 so +1

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




 
 De : Mark Webb [EMAIL PROTECTED]
 À : dev@mina.apache.org
 Envoyé le : Mardi, 11 Novembre 2008, 4h18mn 53s
 Objet : Re: [MessageSent] let's remove it...

 spot on.  +1.  remove it.



 On Mon, Nov 10, 2008 at 7:11 PM, Emmanuel Lecharny [EMAIL PROTECTED]
 wrote:
  Hi guys,
 
  a few days ago, Julien suggested that we should remove this event. I
 never
  used it, found it a bit cumbersome, but didn't had time to double check
  what's doing.
 
  Let's go back to the mailing list...
 
  Back in july, I posted a mail where I questionned some code :
 
  ProtocolCodecFilter.filterWrite() {
 
...
ProtocolEncoder encoder = getEncoder(session);
ProtocolEncoderOutputImpl encoderOut = getEncoderOut(session,
nextFilter, writeRequest);
 
try {
encoder.encode(session, message, encoderOut);
 
// Here, the encoded message is sent.
encoderOut.flush();
 
// Here an empty message is sent...
nextFilter.filterWrite(session, new WriteRequest(
new MessageByteBuffer(writeRequest.getMessage()),
writeRequest.getFuture(),
  writeRequest.getDestination()));
 
  There are two places in this code where the message is written : in the
  encoderOut.flush()  and in the filterWrote() call.
 
  Trustin replied saying :
 
  The two code blocks above are effectively same. The reason we call
  filterWrite once more with an empty buffer (MessageByteBuffer or
  MessageWriteRequest) is to generate a proper messageSent event which
  corresponds to the written message. Let me know if there's more efficient
  way to take care of messageSent events.
 
  There is an obvious way to be more efficient here : simply not sending
 this
  messageSent event !
 
 
  But this is not a good enough reason to remove it. Let's dig another
 mail.
 
  https://issues.apache.org/jira/browse/DIRMINA-574
 
  Steps to reproduce:
  1) Connection is closed at the socket level.
  2) A user writes a message.
  3) the message is encoded by a ProtocolCodecFilter.
  4) MINA notices the closed socket and fires a sessionClosed event.
  5) After the sessionClosed event is fired, IoFilterChain.clear() is
 called.
  6) MINA tries to write the user write request, but the session is closed
  already - all write requests are discarded.
  7) Before MINA discards all write requests, MINA checks if the first item
 in
  the queue is an empty buffer, which means a special separator which is
  handled by ProtocolCodecFilter.
  8) If there's an empty buffer in the head of the queue, MINA fires a
  messageSent event with the empty buffer in the hope that
 ProtocolCodecFilter
  will catch it.
  9) However, the filter chain is empty and therefore IoHandler
 implementation
  gets ClassCastException.
 
 
  At step 8, we send a MessageSent event, which leads to an Exception.
  Clearly, this is not good. Removing the MessageSent event will immediatly
  solve this blocker issue.
 
  Last, not least, another mail states that :
 
  Also, I'd like to make a plug for removing messageSent() callbacks and
  having the end-user API rely on WriteFutures instead. It's a hassle to
  write new filters when you have to worry about passing back the correct
  object.
 
  Using WriteFuture will clearly be a better way to get the message as it
 has
  been posted to the chain, instead to having to encode it back, as it's
  currently done.
 
  Anyone disagree ? Anything I missed ?
 
  Thanks !
 
  --
  --
  cordialement, regards,
  Emmanuel Lécharny
  www.iktek.com
  directory.apache.org
 
 
 

Re: Re : [VOTE] Merging some simplifications

[Maarten Bosteels]

simplicity++

On Wed, Nov 12, 2008 at 6:52 PM, Mark Webb [EMAIL PROTECTED] wrote:

 simple is all I understand.   +1

 On Wed, Nov 12, 2008 at 11:36 AM, Edouard De Oliveira
 [EMAIL PROTECTED] wrote:
  +1 for merging
   Cordialement, Regards,
  -Edouard De Oliveira-
  http://tedorg.free.fr/en/main.php
 
 
 
 
  
  De : Julien Vermillard [EMAIL PROTECTED]
  À : dev@mina.apache.org
  Envoyé le : Mercredi, 12 Novembre 2008, 10h22mn 28s
  Objet : [VOTE] Merging some simplifications
 
  Hi,
  Since it's cutting some feature, I would like a vote before merging
  my branch from sandbox to trunk.
 
  The branch :
  http://svn.apache.org/repos/asf/mina/sandbox/jvermillard/mina-cleaning/
 
  The list of changes :
 
 http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fmina%2Fsandbox%2Fjvermillard%2Fmina-cleaning
 
  * Removed IoService idle event, you still have IoSession idle.
  * Reworked IdleStatusChecker for make the code easier to understand.
  * Removed setTrafficMask and keeped suspendWrite / suspendRead methods.
  * Removed trafficMask event from the IoFilter chain.
  * Applied http://issues.apache.org/jira/browse/DIRMINA-620 by
removing superfluous IoSession close() methods. When you close a
session, you need to use session.close(boolean); and say explicitly
if you want to flush the write queue or no.
 
  [ ]: +1, Merge to trunk
  [ ]: 0, Abstain
  [ ]: -1, Don't merge
 
  Julien
 
 
 

Re: onPreAdd, onPostAdd, onPreRemove, onPostRemove : are they useful ?

[Maarten Bosteels]

never used them.

On Sat, Nov 8, 2008 at 11:35 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote:
 Hi guys,

 while working on the chain refactoring, I found that those four methods are
 never invoked into the core (invocation for these methods can only be found
 in tests, and always by explicit calls).

 Do we really needs them ? Has someone already uase them ?

 Thanks !

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

Re: poll VmPipe

[Maarten Bosteels]

I haven't used it either.

Our app has a service layer (independant of MINA) and a network layer
(based on MINA obviously).
When I want to test service layer, I don't need MINA at all.
And when I want to test the network layer, I prefer to use the real
stuff (ie using real sockets).

Maarten

On Thu, Nov 6, 2008 at 10:49 PM, Mark Webb [EMAIL PROTECTED] wrote:
 I have never used it.  I could see it having a utility for unit
 testing, but that is it.


 On Thu, Nov 6, 2008 at 11:05 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote:
 peter royal wrote:

 On Nov 6, 2008, at 7:28 AM, Dan Creswell wrote:

 Hmmm, if VmPipe is done right it should allow me to build an app/service
 on
 top of MINA that can easily be tested all inside of a single JVM (good
 for
 unit testing amongst other things) or deployed fully networked with
 minimum
 code disruption.

 Is it intended to be used in such a fashion?  If not possibly it can be
 dropped.

 I am using it for exactly this purpose.

 We have two services that can either be deployed as separate VMs, or
 inside of the same VM. WHen its inside the same VM, we cull out the protocol
 filters and just use a VmPipe. Minimal code disruption to support both
 configurations.

 Interesting. Edouard's proposal then makes sense : implementing the
 underlying communication using Queues and removing a lot of the current code
 could help.

 You will still have the same API (IoAcceptor/IoConnector), and won't be
 disruptive.

 This has to be evaluated.


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

Re: New branch for clearing features

[Maarten Bosteels]

Hello all,

I am using IntelliJ IDEA (on linux) and I love it:

* it has excellent subversion support out-of-the-box.
* excellent maven support out-of-the-box.
* no problem opening multiple projects
* still no proper multi-monitor support :-(
* free license for Open Source developers

Maarten

On Fri, Nov 7, 2008 at 5:43 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote:
 Kiran Ayyagari wrote:

 I don't know much about Subversive but have had a *bad* experience with
 Subclipse while performing operations other than simple checkout/checkin.
 ( had to manually move all the resources later using 'svn' to fix )

 IMHO managing the classpath is a breeze in IDE if we use mvn
 eclipse:eclipse else its a pretty laborious task

 I have tested M2eclipse for ADS, which is way bigger than MINA, and I must
 say that it was pretty unusable, to to the time the build takes. But it was
 on a W$ machine, so ... :) Also, the fact is that we have a more complex
 build too...

 I have to give it a try on my linux box for MINA, it may worth the try.

 Thanks !

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

Re: [FTPSERVER] Midnight Commander (Linux) behaviour

[Maarten Bosteels]

Hello Jiří,

Thanks for your suggestion and patch.
But it would be better to create a JIRA issue and attach your patch to it.

Don't forget the tick the checkbox about licensing.

Maarten

On Fri, Nov 7, 2008 at 3:35 PM, Jiří Kuhn [EMAIL PROTECTED] wrote:
 Hello,

 Midnight Commander (mc) is text-based file manager used mainly on Linux/unix
 and is capable to work with FTPs. After uploading file it issues a command
 SITE CHMOD x which is not supported by Apache FtpServer. Mc reaction is
 displaying red error dialog. This happens after each upload even during
 multiple files uploading. It is quite uncomfortable pressing Ok button each
 time (especially during multiupload).

 My opinion is - if absence of SITE CHMOD command has such a consequence it
 would be better to support the command to be there but to do nothing (and
 send a note about it to an user). What do you mean?

 My solution is attached.

 Regards,
 Jiří Kuhn

Re: [proposal] Was : Re: setTrafficMask poll again

[Maarten Bosteels]

+1

On Wed, Nov 5, 2008 at 3:01 PM, Julien Vermillard [EMAIL PROTECTED]wrote:

 I would like to propose :
  - ignore setTrafficMask events in the filter chain (looks like Mark is
   already agreeing)

  - remove setTrafficMask(..) and keep the following IoSession methods :
   suspendRead(), suspendWrite(), resumeRead(), resumeWrite()
   which naming is much better and add methods isWriteSuspended()
   isReadSuspended()
 Kill the TrafficMask class and clear all the filters of references to
 TrafficMas, and of course fix transport classes.

 That would reduce the complexity of the thingy and make the API for
 pausing traffic a bit more user-friendly.

 WDYT ?

 Julien


 On Tue, 4 Nov 2008 18:38:15 +0100
 Julien Vermillard [EMAIL PROTECTED] wrote:

  It was used by Read/WriteThrottlingFilter wich was removed of 2.0 :
 
 http://www.nabble.com/Dropping-traffic-throttling-from-2.0-td16092085.html
  as said by Emm look like it's used nowhere is MINA codebase.
 
 
  As said by Trustin in this mail the remplacement is supposed to be
  o.a.m.f.executor.* and no references to setTrafficMask();
 
  Frankly I don't understand how you can throttle read, without using
  setTrafficMask and disabling OP_READ on the low level socket.
 
  Julien
 
  On Tue, 4 Nov 2008 18:01:58 +0100 Maarten Bosteels
  [EMAIL PROTECTED] wrote:
 
   Wasn't it an attempt to implement throttling ?
  
   When requests are coming in faster than they're being processed
   = set TrafficMask to block reading
   = TCP buffers will fill up (OS level)
   = TCP will tell sender to slow down
   = OOM prevented
  
   when queue of incoming messages gets smaller = resume reading
  
   I haven't tried this yet, so I could be totally wrong.
  
   Maarten
  
   On Tue, Nov 4, 2008 at 5:50 PM, Julien Vermillard
   [EMAIL PROTECTED]wrote:
  
Hi,
   
There is something in MINA who has hook everywhere in the core,
it's traffic mask. As far I understand the concept, the idea is
to be able to block read and/or writes using
session.setTrafficMask(...), I never needed it, and I wonder who
use it and for what exactly ?
   
Julien
   

Re: setTrafficMask poll again

[Maarten Bosteels]

Wasn't it an attempt to implement throttling ?

When requests are coming in faster than they're being processed
= set TrafficMask to block reading
= TCP buffers will fill up (OS level)
= TCP will tell sender to slow down
= OOM prevented

when queue of incoming messages gets smaller = resume reading

I haven't tried this yet, so I could be totally wrong.

Maarten

On Tue, Nov 4, 2008 at 5:50 PM, Julien Vermillard [EMAIL PROTECTED]wrote:

 Hi,

 There is something in MINA who has hook everywhere in the core, it's
 traffic mask. As far I understand the concept, the idea is to be able
 to block read and/or writes using session.setTrafficMask(...), I never
 needed it, and I wonder who use it and for what exactly ?

 Julien

Re: Some questions about NioSocketConnector

[Maarten Bosteels]

Adding an executor filter before the decoder should work.
Please create a JIRA issue when it's not working.

Thanks,
Maarten

2008/10/18 Stanley Ding [EMAIL PROTECTED]


 Because decoding messages is a heavy job in my system:
 decryption,validation. It's good if I can use a thread pool to do
 decoding job.

 I added a thread pool before codec filter and tested it very carefully, but
 it works correctly, no problem.  I just worry about the thread conflict
 problem and want to know why it does not happen.

 If executor filter is not allowed to add before the codec filter, I'll try
 to do the decryption, validation job in a new filter.



  Date: Fri, 17 Oct 2008 14:38:38 +0200 To: dev@mina.apache.org Subject:
 Re: Some questions about NioSocketConnector From: [EMAIL PROTECTED] 
 Stanley Ding wrote:  1、Can I add an executor filter before the codec
 filter?2、When I add the executor before the codec filter, some times
 mina creates more than one Decoder instances for only one session
 [CodecFactory.getDecoder() is called more than once]. Why?   3、When I add
 the executor before the codec filter, and there're many messages to decode,
 all threads in the pool are used to decode the messages, but I found that
 the Decoders are called in regular sequence: 1-start -〉1-end - 2-start -
 2-end - 3-start - 3-end, never found 1-start - 2-start -1-end -
 2-end... How can you do that?Why would you do that for a Connector?
 You are supposed to be a client, not a server. Any special needs ?  -- 
 -- cordialement, regards, Emmanuel Lécharny www.iktek.com
 directory.apache.org 
 _
 Discover the new Windows Vista
 http://search.msn.com/results.aspx?q=windows+vistamkt=en-USform=QBRE

Re: Mina web site modified

[Maarten Bosteels]

On Sun, Sep 7, 2008 at 9:46 AM, Niklas Gustavsson [EMAIL PROTECTED] wrote:
 On Sun, Sep 7, 2008 at 8:54 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote:
 (Guys, don't 'reply all' ! When you do that, AFAIK, we can't anymore
 do a simple 'reply', as it selects the original sender, instead of the
 dev-list)

 That's weird. I just tried and using reply seems to work as expected
 for me (in GMail).

Emmanuel,

I don't think it's because we do reply all but because of your value
for reply-to.

For most posts to the mailing-list the reply-to is just dev@mina.apache.org
but your posts have dev@mina.apache.org, [EMAIL PROTECTED] as reply-to.

= even when we do a simple Reply the message is send do both addresses.

Maarten


 /niklas

Re: Web site refactoring proposal

[Maarten Bosteels]

+1

On Wed, Sep 3, 2008 at 1:16 PM, Mark Webb [EMAIL PROTECTED] wrote:
 Seems like a very good move to me...

 On Tue, Sep 2, 2008 at 10:25 AM, Emmanuel Lecharny [EMAIL PROTECTED]wrote:

 Niklas Gustavsson wrote:

 On Sat, Jun 7, 2008 at 3:24 PM, Emmanuel Lecharny [EMAIL PROTECTED]
 wrote:


 Otherwise, I would also suggest some refactoring of the main site. Here
 is
 some proposal :



 While we're at it, why not get a similar download page as ActiveMQ
 got, it's a beaty:
 http://activemq.apache.org/activemq-510-release.html

 /niklas



 Any objection if I whip a quick refactoring of MINA web site, just to get
 something like this :

 *Latest Downloads*
  Mina 2.0.0-M3
  Mina 1.1.7
  Mina 1.0.10
  FtpServer 1.0.0-M2
  AsyncWeb-unstable

 * Projects
  Mina
  FtpServer
  AsyncWeb
  Downloads
  Roadmap

 * Documentation
  MINA 1.0
  MINA 1.1
  MINA 2.0
  FtpServer
  AsyncWeb
  FAQ

 * Resources
  Mailing lists  IRC
  Issue tracking
  Sources
  Performances
  Testimonies
  Articles/conferences

 * Community
  Team
  License
  Contributing
  Thanks
  ASF sponsors
  Sponsorship program

 * Upcoming
 ApacheCon US logo

 wdyt ?

 PS: this will be just a first step.


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

Re: PorotocolCodecFilter potential pbs and improvement

[Maarten Bosteels]

Hello,

On Wed, Sep 3, 2008 at 8:08 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote:
 Hi,

 while adding some Javadoc into this class, I have found that the
 encoder/decoder instances creation might be not thread safe. We are using a
 getDecoder0() where we have such a code :

   private ProtocolDecoder getDecoder0(IoSession session) throws Exception {
   ProtocolDecoder decoder = (ProtocolDecoder) session
   .getAttribute(DECODER);
   if (decoder == null) {
   decoder = factory.getDecoder(session);
   session.setAttribute(DECODER, decoder);
   }
   return decoder;
   }


AFAICS there is indeed a chance that we call factory.getDecoder()
twice for the same session.
Normally this shouldn't cause too much harm. But people might expect
that getDecoder is only called once per session; not sure that is
documented somewhere.

Side note:  I think it would be great if we had a list with such
guarantees made by MINA.
An example of another guarantee that should be in that list:
 ProtocolDecoder.decoder(IoSession session, IoBuffer in,
ProtocolDecoderOutput out)
 will NEVER be called simultaneously for the same IoSession



 This method is called for every messageReceived() invocation :

   public void messageReceived(NextFilter nextFilter, IoSession session,
   Object message) throws Exception {
   if (!(message instanceof IoBuffer)) {
   nextFilter.messageReceived(session, message);
   return;
   }

   IoBuffer in = (IoBuffer) message;
   ProtocolDecoder decoder = getDecoder0(session);
   ...

 I know it's very unlikely that we receive two messages on the same session
 at the same time, but this can be a possibility, AFAIK. I suggest we
 synchronize this portion of the code this way :


   private ProtocolDecoder getDecoder0(IoSession session) throws Exception {
   // We have to synchronize this section as we may have to create the
 decoder
   // here on the first invocation.
   synchronized (factory) {
   ProtocolDecoder decoder = (ProtocolDecoder)
 session.getAttribute(DECODER);

   if ( decoder == null ) {
   // No existing instance ? Create it and stores it into the
 session
   decoder = factory.getDecoder(session);
   session.setAttribute(DECODER, decoder);
   }
 return decoder;
   }


But why synchronize on the factory instead of on the session ?

 Now, I think we can d something slightly better : we have two methods -
 getDecoder0(IoSession) and getDecoder(IoSession) - doing the exact same
 thing (returning the session decoder), except the fact that getDecoder0()
 inject the decoder into the session, if it was not already done. It makes me
 think that we might want to do taht during the createSession() event
 processing, instead of doing it while processing  the first message
 received.

 We will just have to implement the sessionCreated() method, and then we can
 remove the getDecoder0() method, using the getDecoder() method instead,
 without any synchronization.

 thoughts ?

I think that will be a nice improvement: simpler and more thread-safe,
don't see any downsides.

Regards,
Maarten


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

Fwd: PorotocolCodecFilter potential pbs and improvement

[Maarten Bosteels]

message from Emmanuel

-- Forwarded message --
From: Emmanuel Lécharny [EMAIL PROTECTED]
Date: Fri, Sep 5, 2008 at 3:07 PM
Subject: Re: PorotocolCodecFilter potential pbs and improvement
To: Maarten Bosteels [EMAIL PROTECTED]


Hi Maarten,

mor einline

Maarten Bosteels wrote:

 Side note:  I think it would be great if we had a list with such
 guarantees made by MINA.
 An example of another guarantee that should be in that list:
  ProtocolDecoder.decoder(IoSession session, IoBuffer in,
 ProtocolDecoderOutput out)
  will NEVER be called simultaneously for the same IoSession


That would imply some kind of synchornization on the session, I guess.
Something we can add.

  synchronized (factory) {
  ProtocolDecoder decoder = (ProtocolDecoder)
 session.getAttribute(DECODER);

  if ( decoder == null ) {
  // No existing instance ? Create it and stores it into the
 session
  decoder = factory.getDecoder(session);
  session.setAttribute(DECODER, decoder);
  }
return decoder;
  }



 But why synchronize on the factory instead of on the session ?


Well, because it would imply we synchronize all the other part of the
server where we access the session, a little bit overkilling, IMHO.



 Now, I think we can d something slightly better : we have two methods -
 getDecoder0(IoSession) and getDecoder(IoSession) - doing the exact same
 thing (returning the session decoder), except the fact that getDecoder0()
 inject the decoder into the session, if it was not already done. It makes me
 think that we might want to do taht during the createSession() event
 processing, instead of doing it while processing  the first message
 received.

 We will just have to implement the sessionCreated() method, and then we can
 remove the getDecoder0() method, using the getDecoder() method instead,
 without any synchronization.

 thoughts ?


 I think that will be a nice improvement: simpler and more thread-safe,
 don't see any downsides.


Here is a proposal :

  /**
   * Associate a decoder and encoder instances to the newly created session.
   *
   * @param nextFilter The next filter to invoke when having processed
the current
   * method
   * @param session The newly created session
   * @throws Exception if we can't create instances of the decoder or encoder
   */
  @Override
  public void sessionCreated(NextFilter nextFilter, IoSession session)
throws Exception {
  // Creates the decoder and stores it into the newly created session
  ProtocolDecoder decoder = factory.getDecoder(session);
  session.setAttribute(DECODER, decoder);

  // Creates the encoder and stores it into the newly created session
  ProtocolEncoder encoder = factory.getEncoder(session);
  session.setAttribute(ENCODER, encoder);

  // Call the next filter
  nextFilter.sessionCreated(session);
  }

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

Re: PorotocolCodecFilter potential pbs and improvement

[Maarten Bosteels]

On Fri, Sep 5, 2008 at 3:13 PM, Maarten Bosteels
[EMAIL PROTECTED] wrote:
 message from Emmanuel

 -- Forwarded message --
 From: Emmanuel Lécharny [EMAIL PROTECTED]
 Date: Fri, Sep 5, 2008 at 3:07 PM
 Subject: Re: PorotocolCodecFilter potential pbs and improvement
 To: Maarten Bosteels [EMAIL PROTECTED]


 Hi Maarten,

 mor einline

 Maarten Bosteels wrote:

 Side note:  I think it would be great if we had a list with such
 guarantees made by MINA.
 An example of another guarantee that should be in that list:
  ProtocolDecoder.decoder(IoSession session, IoBuffer in,
 ProtocolDecoderOutput out)
  will NEVER be called simultaneously for the same IoSession


 That would imply some kind of synchornization on the session, I guess.
 Something we can add.

In fact, that one is a guarantee we already have. At least when using
an OrderedThreadPoolExecutor (or no executorfilter at all)
see  
http://mina.apache.org/report/trunk/apidocs/org/apache/mina/filter/executor/ExecutorFilter.html




  synchronized (factory) {
  ProtocolDecoder decoder = (ProtocolDecoder)
 session.getAttribute(DECODER);

  if ( decoder == null ) {
  // No existing instance ? Create it and stores it into the
 session
  decoder = factory.getDecoder(session);
  session.setAttribute(DECODER, decoder);
  }
return decoder;
  }



 But why synchronize on the factory instead of on the session ?


 Well, because it would imply we synchronize all the other part of the
 server where we access the session, a little bit overkilling, IMHO.

Sorry, I don't understand what you are saying. Why would we have to
change other parts of the code ?

Synchronizing on the factory (which is shared by all sessions) creates
a portential contention problem while IMO it's enough to synchronize
on the session : we just have to ensure that we don't call
factory.getDecoder(session) twice for one session.

But ok, this discussion is not really relevant because it's probably
better to move this initialization to sessionCreated.




 Now, I think we can d something slightly better : we have two methods -
 getDecoder0(IoSession) and getDecoder(IoSession) - doing the exact same
 thing (returning the session decoder), except the fact that getDecoder0()
 inject the decoder into the session, if it was not already done. It makes me
 think that we might want to do taht during the createSession() event
 processing, instead of doing it while processing  the first message
 received.

 We will just have to implement the sessionCreated() method, and then we can
 remove the getDecoder0() method, using the getDecoder() method instead,
 without any synchronization.

 thoughts ?


 I think that will be a nice improvement: simpler and more thread-safe,
 don't see any downsides.


 Here is a proposal :

  /**
   * Associate a decoder and encoder instances to the newly created session.
   *
   * @param nextFilter The next filter to invoke when having processed
 the current
   * method
   * @param session The newly created session
   * @throws Exception if we can't create instances of the decoder or encoder
   */
  @Override
  public void sessionCreated(NextFilter nextFilter, IoSession session)
 throws Exception {
  // Creates the decoder and stores it into the newly created session
  ProtocolDecoder decoder = factory.getDecoder(session);
  session.setAttribute(DECODER, decoder);

  // Creates the encoder and stores it into the newly created session
  ProtocolEncoder encoder = factory.getEncoder(session);
  session.setAttribute(ENCODER, encoder);

  // Call the next filter
  nextFilter.sessionCreated(session);
  }

Don't know whether it's documented somewhere, but looking at
ExecutorFilter code, I think it's safe to say that sessionCreated will
always be called BEFORE messageReceived.   (That's another promise to
add to the list of framework guarantees, I guess.)

So your proposal looks OK to me.

Regards,
Maarten


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

Re: Adapter vs Abstract classes

[Maarten Bosteels]

I fully agree with Christian.

regards,
Maarten

On Wed, Aug 27, 2008 at 4:27 PM, Christian Migowski
[EMAIL PROTECTED] wrote:
 2008/8/27, Emmanuel Lecharny [EMAIL PROTECTED]:

 Hi guys,

 while looking at the filters, I found a class name IoFilterAdapter. The
 javadoc says that this is an abstract class (but the class is _not_ avstract
 ;).

 So I have done some research in the code, and I found that we are using
 either AbstractXXX.java classes and XXXAdapter.java classes. I think this
 should be normalized in order to always use the same prefix or postfix.


 I wouldn't do so. Even from only reading the Javadoc you can see they have
 very distinct purposes:

 The *Adapter classes are convenience wrappers meant to be extended by the
 user if he only wants to use a subset of the interfaces they implement.
 Oh, and i use some of them and could imagine others as well, so it would be
 an API breakage without a useful reason.

 The Abstract* classes are typical abstract classes providing common
 functionality for Mina internal classes that branch later on to specific
 implementations.


 Applying a different naming scheme for the two purposes is logical and
 useful - and should be in your good documentation over everything spirit.
 The only thing i would change is to make all the adapter classes abstract
 since they only implement NOOP actions for their purposes and are
 therefore not very useful to instanciate from.


 christian

Re: LogFilter questions

[Maarten Bosteels]

I agree: the current LoggingFilter is pretty complicated.  I looked at it in
the past but found it too complex to use it.
I even think we could just get rid of it and let our users write a
customized LoggingFilter when they need one.

But what Julien suggest also looks OK to me.

Regards,
Maarten

On Mon, Aug 25, 2008 at 9:39 AM, Julien Vermillard
[EMAIL PROTECTED]wrote:

 Hi,

 Comments inline.

 On Fri, 22 Aug 2008 22:47:32 +0200
 Emmanuel Lecharny [EMAIL PROTECTED] wrote:

  Hi guys,
 
  I think there is something wrong with the current implementation of
  the LogFilter.

 Sure it's a bit over complicated, specially that Map for IoEvent, due
 to the fact we aren't adding an event every days.

 
  The idea is to be able to log something _if_ a specific event is set
  to a certain level. For instance, one may log as debug when a
  MessageReceived event is received, but only log errors when a
  MessageSent event is received.
 
  So when you initialize a logLevel, you inject two arguments :
  - the eventType
  - the desired log level
 
  public void setLogLevel(IoEventType eventType, LogLevel logLevel)
  {
 
  The problem with this approach is that the way it's implemented,

 Really ? I start to think  after chatting with you a little , that the
 problem is trying to set log level with MINA. It's obviously log
 framework job.

  there is no way to get some logs for two different event with two
  different log level, simply because there is only one Logger which is
  used globally, and set to a level globally, too.
 
  So we ned to fix that, and I'm wondering which is the best approach.
  - we can simply consider that this is totally useless to tie an event
  to a log level, and just log all events to the same level (pretty
  much what we currently have right now).
  - or we consider that the original idea is ok, but then we have to
  create a logger per event.
 
  In both case, I think that the utter complexity of the current
  implementation need to be simplified a lot. We don't need a map to
  store the relation between an event and a logLevel, as the log level
  will be implicit if we have one logger per event (or implicitly set
  to the global logger if we chose option #1), we don't need a LogLevel
  enum either, as the implementation is straightforward in both case :
 
  Option #1 :
 
  public void messageSent(NextFilter nextFilter, IoSession session,
  WriteRequest writeRequest) throws Exception {
  if (logger.isDebugEnabled()) {
  logger.debug(SENT: {}, writeRequest.getMessage());
  } else if (logger.isInfoEnabled()) {
  logger.info(SENT: {}, writeRequest.getMessage());
  } else if (logger.isTraceEnabled()) {
  logger.trace(SENT: {}, writeRequest.getMessage());
  } else if (logger.isWarnEnabled()) {
  logger.warn(SENT: {}, writeRequest.getMessage());
  } else if (logger.isErrorEnabled()) {
  logger.error(SENT: {}, writeRequest.getMessage());
  }
 
  nextFilter.messageSent(session, writeRequest);
  }
 
  Option #2 :
 
  public void messageSent(NextFilter nextFilter, IoSession session,
  WriteRequest writeRequest) throws Exception {
  if (logger.isDebugEnabled()) {
  loggerMessageSent.debug(SENT: {},
  writeRequest.getMessage()); } else if (logger.isInfoEnabled()) {
  loggerMessageSent.info(SENT: {},
  writeRequest.getMessage()); } else if (logger.isTraceEnabled()) {
  loggerMessageSent.trace(SENT: {},
  writeRequest.getMessage()); } else if (logger.isWarnEnabled()) {
  loggerMessageSent.warn(SENT: {},
  writeRequest.getMessage()); } else if (logger.isErrorEnabled()) {
  loggerMessageSent.error(SENT: {},
  writeRequest.getMessage()); }
 
  nextFilter.messageSent(session, writeRequest);
  }

 loggerSent.trace(writeRequest.getMessage());
 no need SENT because it's already the sending logger.

 
  FYI, the current implemention is :
 [..snip..]
 Can you paste that somewhere else for my poor eyes ;)
 LoggingFilter is a debug tool, in no production application you will
 log all the sent/rcvd message.

 The only usage could be exception  connec/disconnet

 So I think we could :

 hardcode created/sent/rcvd log level to trace/debug which is always
 used for debug

 hardcode close/connect to info

 hardcode exception to error

 use a logger per event type, so the final user use log4j/wathever
 facilities to change the log level for hide/show messages, and not
 configure the LoggingFilter for changing the loglevel to the hidden
 one :)

  pretty complicated, IMHO :)
 
  Thoughts ?
 

 and with that we provide a LogLevel class, sound pretty weirdo :)

 Those changes are pretty radical, let's wait for some feedback on how
 other users (ab)use the current implementation.

 Julien

[jira] Assigned: (DIRMINA-610) ByteBuffer.getString() performance issues

[Maarten Bosteels (JIRA)]

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

Maarten Bosteels reassigned DIRMINA-610:


Assignee: Sangjin Lee

 ByteBuffer.getString() performance issues
 -

 Key: DIRMINA-610
 URL: https://issues.apache.org/jira/browse/DIRMINA-610
 Project: MINA
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.10, 1.1.7
Reporter: Sangjin Lee
Assignee: Sangjin Lee
Priority: Minor
 Attachments: DIRMINA-610-1.0.patch, DIRMINA-610-1.1.patch


 ByteBuffer.getString() in 1.1  1.0 underperforms IoBuffer.getString() in the 
 trunk, because it's missing some optimizations that were done on the trunk.
 - Default of heap buffers vs. direct buffers
 - further optimization using the indexOf method
 These changes need to be backported.  See 
 http://markmail.org/message/j76kbfbie62ixrtd for the discussion thread.

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

Re: [1.1.x] ByteBuffer.getString() performance

[Maarten Bosteels]

Hello Sangjin,

I have added you to the group of Committers in JIRA, so from now on
you should be able to assign JIRA issues to yourself.
As you have probably seen, I have already assigned DIRMINA-610 to you.

regards,
Maarten

On Tue, Jul 22, 2008 at 6:45 PM, Sangjin Lee [EMAIL PROTECTED] wrote:
 I have updated the JIRA issue for this with a suggested patch:
 https://issues.apache.org/jira/browse/DIRMINA-610.  If someone could take a
 quick look and review the changes I would greatly appreciate it.
 The changes are essentially backporting a couple of fixes that were made on
 the trunk with little modifications:
 - useDirectBuffers defaults to false
 - introduced the indexOf() method and the related optimization in finding
 the zero byte

 The only change I made from the original fix is that on the trunk the
 indexOf() method is part of the interface, but it is not on the 1.x
 branches.  So I made it a private method not to cause any changes in the
 API.  Also, there is a call to hasArray() in the indexOf() method
 implementation, but since the 1.x branches do not have this method, I used
 the equivalent, which is buf().hasArray().

 I'd love to commit the changes myself, but somehow I cannot assign the bug
 to myself.  If someone could take a look at the JIRA permissions and/or
 assign it to me, I could go ahead and commit it.  If someone would be nice
 enough to commit it for me, that would be fine too...  Thanks!

 Regards,
 Sangjin


 On Thu, Jul 17, 2008 at 4:27 PM, Sangjin Lee [EMAIL PROTECTED] wrote:

 The second change was this:
 http://svn.apache.org/viewvc?view=revrevision=477482.
 Regards,
 Sangjin


 On Thu, Jul 17, 2008 at 4:11 PM, Sangjin Lee [EMAIL PROTECTED] wrote:

 I see two differences between the trunk and the 1.1 branch that are
 relevant to this.
 (1) direct buffer vs. heap buffer
 It seems that a direct buffer performs much more poorly in this regard
 than a heap buffer.  The trunk creates a heap buffer by default but the 1.1
 branch creates a direct buffer by default.  It is perhaps related to this
 issue: https://issues.apache.org/jira/browse/DIRMINA-289.

 The question is, if the heap buffer default is good enough for the trunk,
 then shouldn't it be good for the 1.1 branch as well?

 (2) There is one more piece of optimization that's done in the trunk
 version.  Namely, if the backing buffer has an associated byte array, then
 the algorithm of identifying the first zero byte is done by iterating over
 the array instead of repeated hasRemaining() and get() calls.

 This optimization applies only to heap buffers.

 I think these changes are worth backporting to the 1.1 branch (and perhaps
 the 1.0 branch?).  Thoughts?  If you agree, I'll open a JIRA issue to track
 this.

 Sangjin


 On Thu, Jul 17, 2008 at 3:51 PM, Sangjin Lee [EMAIL PROTECTED] wrote:

 2.0 performs pretty close to the NIO level.
 Here's a quick test you can compare the performance with...

 Sangjin


 On Thu, Jul 17, 2008 at 2:19 PM, Emmanuel Lecharny [EMAIL PROTECTED]
 wrote:

 Hi guys,

 this is interesting.

 If you have some code with those performance tests, that could also
 help.

 Otherwise, did you made some tests on 2.0 ?


 Julien Vermillard wrote:

 On Thu, 17 Jul 2008 09:52:38 -0700
 Sangjin Lee [EMAIL PROTECTED] wrote:



 Forgot to add that this is a pretty crucial method.  Any text based
 decoder would need to use it to decode messages...  Thanks!
 Sangjin

 On Thu, Jul 17, 2008 at 9:51 AM, Sangjin Lee [EMAIL PROTECTED]
 wrote:



 I've been looking at some performance characteristics of
 ByteBuffer.getString() in 1.1.x, and noticed that it is
 considerably slower than its NIO counterpart.  I tested it with a
 few JVMs, and ByteBuffer.getString() performs anywhere between 3 -
 5 times poorer than the NIO version.  NIO does not have the
 getString() method, and one would use CharsetDecoder.decode().
 I also checked the trunk version (IoBuffer.getString()), and it
 seems much faster and pretty close to the NIO performance.

 How is a performance issue with 1.1.x like this normally handled?
 Are we open to investigate and fix performance problems like this
 in 1.1.x as long as it does not entail API changes?  If a simple
 change for IoBuffer resulted in this performance enhancement,
 perhaps we can backport that change?

 Thanks,
 Sangjin





 Hi Sangjin,

 I don't see any problem in patching 1.X for perfs. It's some kind of
 bugfix ;)

 Julien




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

Re: added o.a.asyncweb.common.codec and Mutable interfaces

[Maarten Bosteels]

Hi,


On Thu, Jul 3, 2008 at 11:28 PM, [EMAIL PROTECTED] wrote:

 Hi,

 I moved some class related to HTTP message encoding/decoding from
 o.a.asyncweb.common to o.a.asynweb.common.codec. So there is less crowd in
 the package.

 I thought about another simplification :

 for a simple Http Message you have this heritance tree :

 DefaultHttpResponse extends DefaultHttpMessage
   implements MutableHttpResponse

 DefaultHttpMessage implements MutableHttpMessage
 MutableHttpMessage extends HttpMessage

 MutableHttpResponse extends MutableHttpMessage, HttpResponse
 HttpResponse extends HttpMessage
 MutableHttpMessage extends HttpMessage

 As far as I understand it, fr http messages the interfaces was splited in
 two, the getters and the setters (mutable part). After looking around I
 see no real utilisation for that since all the conrecte implemenations are
 Mutables.


Firts, I must admit that I have zero experience with these classes, and
haven't looked at the code.
But in general, the distinction between mutable and immutable can have a big
documenting benefit.

When a method takes an immutable parameter, you can assume that the method
won't change the state of the object (of course, the method could cast the
parameter to the Mutable concrete class, but that would be a total
disgrace).

Maarten




 By removing the Mutable interface we will greatly simplify the structure
 of those messages.

 WDYT ?

 Julien

Re: Failure during AsyncWeb build

[Maarten Bosteels]

On Fri, Jun 20, 2008 at 6:02 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote:
 harbhanu wrote:

 Hi,


 Hi,

 I have downloaded the code present at
 http://svn.apache.org/repos/asf/mina/asyncweb/


 But I am getting some errors while building it. Please let me know where
 the
 issue is. Or is it something to do with the testcase.

 Difficult to tell. May be you have a service using port 8383 on your
 machine.

 Can you paste the logs you get in the
 D:\JWork\CXF\ProductDiscussions\AsyncWebLatest\asyncweb\trunk\client\target\surefire-reports
 directory ?


 Also, since it's a test failure even in tried to skip those while passing
 option for maven, but its ignoring it.
 -Dmaven.test.skip.exec=true /

 -Dmaven.test.skip =true... but both didn't work. Any comment on this?


 -Dmaven.test.skip=true, without space, might work.

Hi,

since sure-fire 2.4 it can be even shorter :mvn -DskipTests

see 
http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#skipTests

Maarten


 Just let us know !

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

Re: [New Committer] Welcome to Rich Dougherty

[Maarten Bosteels]

Welcome Rich !

Maarten

On Fri, Jun 20, 2008 at 9:41 PM, Rich Dougherty [EMAIL PROTECTED] wrote:
 On Sat, Jun 21, 2008 at 3:30 AM, Julien Vermillard
 [EMAIL PROTECTED] wrote:
 Rich Dougherty was voted as a new Apache MINA committer with 7 +1 vote
 and no abstain nor -1.

 He's well know here for the MINA Scala binding and his overall interest
 for MINA internals.

 Welcome aboard Rich !

 Thanks everyone, I'm pleased to join the team!

 Rich

Re: [2.0 refactoring] What about splitting mina-core ?

[Maarten Bosteels]

Hi,

I fail to see strong advantages of having multiple jars.
Having more packages seems like a good idea though.

Maarten.

On Sun, Jun 8, 2008 at 9:45 PM, Niklas Gustavsson [EMAIL PROTECTED] wrote:
 On Sun, Jun 8, 2008 at 9:26 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote:
 Niklas Gustavsson wrote:
 My feeling is that the cons outweigh the pros. Having multiple JARs
 commonly turns out to confuse users, especially with a setup where you
 can even get the very basic functionality working without choosing
 your combination of JARs.

 With Maven, this is not really a big issue, IMHO. Consider that it's a one
 time burden...

 My worry is not around how to perform the actual work setting things
 up, but rather how much a potential consumer would have to understand
 about MINA before she can get going.

 But even if we keep only one jar, I think we still have to create some new
 packages, because we have a big bag of classes in common, which make it
 quite difficult to find what are the relations between each classes.

 I certainly agree.

 /niklas

Re: AW: IoSession.write() without WriteFuture

[Maarten Bosteels]

On Fri, Jun 6, 2008 at 12:12 AM, Alex Karasulu [EMAIL PROTECTED] wrote:
 On Thu, Jun 5, 2008 at 5:59 PM, Emmanuel Lecharny [EMAIL PROTECTED]
 wrote:

 Maarten Bosteels wrote:

 On Wed, Jun 4, 2008 at 3:45 PM, Emmanuel Lecharny [EMAIL PROTECTED]
 wrote:


 Steve Ulrich wrote:




 Julien Vermillard wrote

 On Wed, 04 Jun 2008 10:37:57 +0200
 Emmanuel Lecharny [EMAIL PROTECTED] wrote:




 Julien Vermillard wrote:



 I propose :
 void write(..) as default
 and a
 WriteFuture writeWithFuture(..);
 or something else if someone got a better idea because I'm not sure
 to have the best wording here ;)

 WDYT ?
 Julien




 Why not simply

 void write( ... )

 and

 WriteFuture writeFuture( ... ) ?




 damn I'm an idiot ;) how I can missed this solution.



 If you don't want to break backward compatibility, perhaps something
 like:
 WriteFuture write(...)
 void writeAndForget(...)



 We are targeting a 2.0 release, any version before a RC may be changed.
 But
 in order to avoid being stoned by users :), I would suggest to @deprecate
 the previously used methods.



 I don't see how we can do that :

 before:
 WriteFuture write (Object message);

 after:
 void write (Object message);
 WriteFuture writeFuture (Object message);

 When we go for these method names, we can't keep the old (deprecated)
 signature since it only differs in return type.

 Or am I missng something ?


 No, this was my mistake :)

 Do we care about breaking backward compatibility ?


 I don't think it's that big of a deal going from 1.X - 2.0.  Things change.
 I'd just focus on making the API as coherent as possible.

+1


 Alex

Re: Issues with client reconnection

[Maarten Bosteels]

As long as your not using the connection, TCP will not notify about an
unplugged network cable (this seems strange to most people at first
but it can have advantages too).
If you want early detection of a broken link, you should use some kind
of heartbeat.

I think there is a HeartbeatFilter somewhere.
Search the mailing list archive or JIRA for this.

Hope that helps,
Maarten


On Fri, Jun 6, 2008 at 8:10 AM, Eric LeVin [EMAIL PROTECTED] wrote:

 Thanks in advance to anyone that has any input on this.  I might be doing 
 something very simple wrong as I am a NOOB to Mina.  I am using the following 
 mina version:


org.apache.mina
mina-core
2.0.0-M1


 I have been testing things with getting filters setup appropriately, and 
 really like the way Mina is setup.  The problem I have discovered in my 
 configuration is when I pull the network out from under my client connection 
 (i.e. un-plug my network connection) I don't get any disconnection exceptions 
 in the HandlerAdapter or a SessionClosed event (or anything for that matter). 
  Here are my major adapter methods-as you will see I implement the 
 reconnection logic as stated in the FAQ; however, I am still seeing the issue.

 @Override
public void exceptionCaught(IoSession session, Throwable t) throws 
 Exception
{
log.error(Session: + session +  :: Exception: + t);
}

 ...
@Override
public void sessionClosed(IoSession session) throws Exception
{
// Wait for five seconds before reconnecting.
Thread.sleep( 5000 );

if(session.getService() instanceof IoConnector)
{
((IoConnector)session.getService()).connect( 
 session.getRemoteAddress() );
}
}

 Here is my client connection code:

 SocketAddress address = new InetSocketAddress(X.X.X.X,2000);

NioSocketConnector ioConnector = new NioSocketConnector();

//Add the price stream filter that will separate out the messages...

ioConnector.getFilterChain().addLast( binary-logger, new 
 LoggingFilter() );
ioConnector.getFilterChain().addLast( protocolCodecFilter, 
 (IoFilter)getBean(protocolCodecFilter) );
ioConnector.getFilterChain().addLast( authenticationFilter, 
 (IoFilter)getBean(authenticationFilter) );

ioConnector.setHandler( (IoHandler)getBean(ioHandler) );

ConnectFuture cf = ioConnector.connect(address);
cf.join();

 ioHandler, the codec filter, and the authentication are all filters defined 
 in my spring context.  The protocol filter is a custom implementation based 
 off of the filters in source.  I am hoping this is a simple configuration 
 thing I am going wrong, if not I will try to make a full example and 
 replicate it.  Thanks so much for any help you may have!

 -Eric

Re: AW: IoSession.write() without WriteFuture

[Maarten Bosteels]

On Wed, Jun 4, 2008 at 3:45 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote:
 Steve Ulrich wrote:



 Julien Vermillard wrote

 On Wed, 04 Jun 2008 10:37:57 +0200
 Emmanuel Lecharny [EMAIL PROTECTED] wrote:



 Julien Vermillard wrote:


 I propose :
 void write(..) as default
 and a
 WriteFuture writeWithFuture(..);
 or something else if someone got a better idea because I'm not sure
 to have the best wording here ;)

 WDYT ?
 Julien



 Why not simply

 void write( ... )

 and

 WriteFuture writeFuture( ... ) ?



 damn I'm an idiot ;) how I can missed this solution.


 If you don't want to break backward compatibility, perhaps something like:
 WriteFuture write(...)
 void writeAndForget(...)


 We are targeting a 2.0 release, any version before a RC may be changed. But
 in order to avoid being stoned by users :), I would suggest to @deprecate
 the previously used methods.

I don't see how we can do that :

before:
WriteFuture write (Object message);

after:
void write (Object message);
WriteFuture writeFuture (Object message);

When we go for these method names, we can't keep the old (deprecated)
signature since it only differs in return type.

Or am I missng something ?

Maarten


 And add a decent documentation + howto + FAQ ;)

 Any help warmly welcome !


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

Re: Serial Transport reintegration in TRUNK or not

[Maarten Bosteels]

Hi Julien,

I'd prefer solution #2 but I could also live with #1

regards
Maarten

On Wed, May 21, 2008 at 8:58 AM, Julien Vermillard
[EMAIL PROTECTED] wrote:
 Hi,

 The serial transport module, a transport implementation, using serial
 port (RS232) was moved to sandbox due to licences issues.

 Here a simple resume : the serial transport use the RXTX, a
 java serial communication lib. The problem is that RXTX is LGPL
 licensed. You would may so ask so what's the matter ?.

 Well as our build is automated, when you try to build whole MINA trnuk,
 it's pulling the needed libs in your local repository and will
 automatically download the LGPL dependency. as far as I can understand
 it's it's a problem for some users and ASF, for grabbing LGPL licensed
 jar automatic fashion.

 That why the serial transport was moved temporary to sandbox, well as
 we say in France : the temporary is made for duration.. :) and the
 situation is here for few month.

 After discussing around with other commiters, here the possible two
 solutions :

 1# keep serial transport outside of MINA, make it a separate project due
 to his LGPL dependency nature

 2# or as suggested  by Emmanuel, make the building of serial transport
 optional (passing some arguments to mvn during the building) so the
 user can choose to build the LGPL depended or not module. apparently
 some Apache projects already do that for javamail.

 My preference go for 2# because it will be easier to maintain
 up-to-date with MINA trunk, and even it's the audioence is small, it's
 making MINa the only Java netroking lib with easy serial comm :)

 WDYT ?

 Julien

Re: Should all configuration properties be volatile? (Was: Re: Visibility of idle time changes in BaseIoSession)

[Maarten Bosteels]

On Thu, May 15, 2008 at 12:40 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
 Yes.  I was actually talking about the configuration properties which meets
 the two criteria.

  Of course, counters, which were originally mentioned by Dmirty, should use
 AtomicIntegers.

  So.. basically we were mixing up two kinds of properties in our discussion.
 To sum up:

   * Use volatile for simple configuration properties
   * Use AtomicInteger for other counters (except for performance counters
 which doesn't need to be accurate)

  Does this make sense to you guys?

Yes, I think that makes sense. I just think that in general, we have
to be very careful when using volatile instead of locking.
For the reasons explained by Brian Goetz in the article mentioned
below, and also because it might be premature optimization
(or even no optimization at all).

When I see a method like below, I wonder if that should be an atomic operation ?
It's probably not really necessary, I don't know the code well enough to judge.

public void increaseReadBytes(int increment) {
 if (increment  0) {
 readBytes += increment;
 lastReadTime = System.currentTimeMillis();
 idleCountForBoth = 0;
 idleCountForRead = 0;
 }
 }

Maarten




  On Thu, 15 May 2008 03:08:58 +0900, Maarten Bosteels
 [EMAIL PROTECTED] wrote:


  Hello,
 
  Brian Goetz [1] writes:
 
  You can use volatile variables instead of locks only under a
  restricted set of circumstances. Both of the following criteria must
  be met for volatile variables to provide the desired thread-safety:
 
 * Writes to the variable do not depend on its current value.
 * The variable does not participate in invariants with other variables.
  ...
  However, if you can arrange that the value is only ever written from a
  single thread, then you can ignore the first condition.)
 
  But at line 445 of BaseIoSession.java I see:
 
  idleCountForRead++;
 
  (in a public method called increaseIdleCount so I don't think we can
  guarantee that only one thread will ever call it)
 
  So it's pretty obvious to me that volatile IS NOT good enough if you
  want a thread-safe solution.
 
  [1] http://www.ibm.com/developerworks/java/library/j-jtp06197.html
  [2]
 http://mina.apache.org/report/1.1/xref/org/apache/mina/common/support/BaseIoSession.html#445
 
  regards,
  Maarten
 
  On Wed, May 14, 2008 at 7:44 PM, David M. Lloyd [EMAIL PROTECTED]
 wrote:
 
   On 05/14/2008 12:22 PM, Emmanuel Lecharny wrote:
  
   
David M. Lloyd wrote:
   

 On 05/14/2008 11:57 AM, Emmanuel Lecharny wrote:

 
  David M. Lloyd wrote:
 
  
   On 05/14/2008 11:20 AM, Emmanuel Lecharny wrote:
  
  
   
 What I can tell at least though is that the session
 configuration
 properties provided by IoService should be volatile, because
 they are
 accessed in a different thread (I/O processor) almost
 always.

   
Use synchronization, not volatile. it's too dangerous. When we
 are
sure that it works fine, we _may_ switch to volatile.
   
  
   I don't understand this?  Volatile isn't dangerous at all.  It's
   clearly defined and well-specified, and using it to make fields
 have
   multi-thread visibility is a perfectly fine usage for them.
  
 
  The problem is not that volatile is dangerous by itself. Its
 semantic is
  really clear, assuming that you _know_ what you can and can't do.
 This is
  what scared me : mis-used of volatile.
 
  Before of using it, I would rather prefer that we expose the clear
  benefits we will get from it (and please, bring the numbers with
 you ;)
  before using it all over the code.
 

 Well, if you don't use it, then when someone calls a setter on the
 property, the change may not be propagated to any other threads,
 meaning
 that different threads could read different values for those
 properties. If
 you do add volatile, then this doesn't happen - a change in one
 thread is
 visible immediately thereafter from another thread.

   
Synchronise the access to this property.
   
  
   Why?  Synchronization is not needed.
  
  
Synchronized getter and setter should be ok. Of course, you may have
 to
copy the property before sending it to the user. Using volatile does
 not
protect more than synchronize, so I see no reason to use it in this
 case.
   
  
   The values don't need more protection.
  
  
You will have the very same problem in both case, except that volatile
 is
only meant to protect the visibility.
   
  
   Visibility is the only problem here that needs to be solved.
  
  
  
The fact that volatile does not guarantee atomicity is enough a risk
 to
justify my assertion.
   
  
   I don't understand.  Atomicity is not a requirement here!  The only
   requirement is that when the values are changed

Re: Should all configuration properties be volatile? (Was: Re: Visibility of idle time changes in BaseIoSession)

[Maarten Bosteels]

Hello,

Brian Goetz [1] writes:

You can use volatile variables instead of locks only under a
restricted set of circumstances. Both of the following criteria must
be met for volatile variables to provide the desired thread-safety:

* Writes to the variable do not depend on its current value.
* The variable does not participate in invariants with other variables.
...
However, if you can arrange that the value is only ever written from a
single thread, then you can ignore the first condition.)

But at line 445 of BaseIoSession.java I see:

idleCountForRead++;

(in a public method called increaseIdleCount so I don't think we can
guarantee that only one thread will ever call it)

So it's pretty obvious to me that volatile IS NOT good enough if you
want a thread-safe solution.

[1] http://www.ibm.com/developerworks/java/library/j-jtp06197.html
[2] 
http://mina.apache.org/report/1.1/xref/org/apache/mina/common/support/BaseIoSession.html#445

regards,
Maarten

On Wed, May 14, 2008 at 7:44 PM, David M. Lloyd [EMAIL PROTECTED] wrote:
 On 05/14/2008 12:22 PM, Emmanuel Lecharny wrote:

 David M. Lloyd wrote:

 On 05/14/2008 11:57 AM, Emmanuel Lecharny wrote:

 David M. Lloyd wrote:

 On 05/14/2008 11:20 AM, Emmanuel Lecharny wrote:

 What I can tell at least though is that the session configuration
 properties provided by IoService should be volatile, because they are
 accessed in a different thread (I/O processor) almost always.

 Use synchronization, not volatile. it's too dangerous. When we are
 sure that it works fine, we _may_ switch to volatile.

 I don't understand this?  Volatile isn't dangerous at all.  It's
 clearly defined and well-specified, and using it to make fields have
 multi-thread visibility is a perfectly fine usage for them.

 The problem is not that volatile is dangerous by itself. Its semantic is
 really clear, assuming that you _know_ what you can and can't do. This is
 what scared me : mis-used of volatile.

 Before of using it, I would rather prefer that we expose the clear
 benefits we will get from it (and please, bring the numbers with you ;)
 before using it all over the code.

 Well, if you don't use it, then when someone calls a setter on the
 property, the change may not be propagated to any other threads, meaning
 that different threads could read different values for those properties. If
 you do add volatile, then this doesn't happen - a change in one thread is
 visible immediately thereafter from another thread.

 Synchronise the access to this property.

 Why?  Synchronization is not needed.

 Synchronized getter and setter should be ok. Of course, you may have to
 copy the property before sending it to the user. Using volatile does not
 protect more than synchronize, so I see no reason to use it in this case.

 The values don't need more protection.

 You will have the very same problem in both case, except that volatile is
 only meant to protect the visibility.

 Visibility is the only problem here that needs to be solved.


 The fact that volatile does not guarantee atomicity is enough a risk to
 justify my assertion.

 I don't understand.  Atomicity is not a requirement here!  The only
 requirement is that when the values are changed, the changes are immediately
 visible to other threads.  Volatile solves this issue, and in fact was
 designed for this.  What additional semantics does synchronization provide
 that are not solved by volatile?

 The 'performance' word was used in Trustin's answer to Dmitry mail. If it
 does not work, then first synchronize the code in order to make it thread
 safe. Volatile is just a weaker way to 'fix the code', not a solution.

 Dmitry first mail was about the problem he founds, and he suggested to use
 volatile. I suggest we don't and that we synchronize first, until we have
 fixed the problem.

 This makes no sense.  Fear is not a reason to use or not use something. The
 problem is the lack of visibility, and the solution is volatile.

 - DML

Re: JIRA for documentation ?

[Maarten Bosteels]

Hi,

Non-committers who want to contribute documentation via the wiki just have
to sign the CLA and fax it.
No big deal, it only took me 5 minutes. Writing good documentation is harder
IMO :-)

I agree that having two wiki's would be a very bad idea.

regards,
Maarten

On Sat, May 3, 2008 at 1:30 PM, [EMAIL PROTECTED] wrote:


  이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:
  It's writable by all committers + asf-clas group for non-committing
  documentation contributors who've sent CLAs.
  Ok. Just wanted to be sure ...
  I talked about a dedicated
  separate CWiki because we can't open the gate for the Cwiki space for
  auto-exporting.  Using the old wiki is also a problem because of the
  different syntax.
 
  Yep.
 
  So I think that for users who want to provide documentation, the best
  (and only way, I guess) is currently to submit patches through JIRA.
 
 
  Isn't it inconvenient to use JIRA to attract more people in
  documentation effort?  We already have a documentation component in our
  JIRA, so we could promote it in our web site anyway.
 
  This is also an option. The problem with the way we work is that as
  karma is granted on merit, it's hard to establish merit from people who
  have not submitted any material :) So, yes, it's not convenient, but
  this is the way we work.
 
  Anyway, even a pdf proposal attached in a JIRA is ok, as soon as we can
  inject it on our site. The idea is that writing doco does not depend on
  the container. What is important is the content :)
 
 
 Hi,

 I think we should multiply JIRA issues for documentation, so it's easier
 to attach patch and it's probblly more easy to contribute to a small doco
 issues than a big overall tutorial.

 my 2 cents,

 Julien (back in 2 weeks)

Re: Big refactoring in MINA 2 or 3?

[Maarten Bosteels]

Hello,

I do agree with everyone who says anyone using a pre-release is taking a
risk
but I also I agree with Trustin that we should try to avoid hurting our
users.

In principle:  yes, just do these radical changes in 2.0 since we haven't
gone to RC yet.
BUT in practice it's a trade-off:
* how much trouble would we inflict on users that are already using MINA 2.0
* how much trouble would it cause us to maintain 2.0 and 3.0

I guess we can stop supporting 1.x as soon as 2.0 GA is released ?

AFAICS, work on mina 2.0 started in October 2006 or maybe even earlier
and a new versioning scheme was defined in November 2006. [1] and [2]

I always thought the idea was of the milestones was release early, release
often
but 17 months later we have released only one milestone
(note that I am not blaming anyone for this, except myself for not helping
out more).

Recently Trustin wrote [3] about the possibility to reach 2.0 RC1 in the
near future.
I think we should go for it because :
* it would please a lot of users
* supporting them might be easier when we have an RC (or a GA)
* we would get more feedback from people using 2.0
* which could lead to more ideas for improving 3.0
* less time pressure when we can work on these 'big changes in 3.0

[1] http://markmail.org/message/iup4sfwyecalsdyd
[2] http://markmail.org/message/hymzddmoteiatcwq
[3] http://www.nabble.com/Issues-to-resolve-for-2.0.0-(GA)-td16872513.html

regards,
Maarten

On Wed, Apr 30, 2008 at 7:28 PM, Kevin Williams [EMAIL PROTECTED] wrote:

 On Wed, Apr 30, 2008 at 9:18 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED]
 wrote:
   .  However, I
   realized it can be somewhat irresponsible action to our users who
   already are using MINA 2 in their production system.  If they are going
   to spend many sleepless nights because of the radical changes, we're
   likely to lose a part of our precious community.

 Frankly, anyone using a pre-release product in their production code
 is accepting some risk of it changing, whether they know it or not. I
 wouldn't worry about it.

Re: MINA v2.0 Quick Start Guide

[Maarten Bosteels]

Hi,

2008/4/10 Mark Webb [EMAIL PROTECTED]:

 Sorry for the mis-typing of your name

no worries.




 The more I think about this, the more I think that each step should be a
 stand-alone program.  Step 2 should include all the code from step 1 and
 the
 code that was introduced in step 2.  For instance, in step 1 you might
 have
 :

 IoAcceptor acceptor = new NioSocketAcceptor();
 acceptor.setHandler( new MyHandler() );
 acceptor.bind( new InetSocketAddress(PORT));

 Then when you introduce step 2, you will add in an ExecutorFilter to all
 the
 code above.


That's what I meant: in step2 you have another main, that builds the
IoFilter chain all by itself.
So that would be copy-paste from step1 with an ExecutorFilter added.
But I see no point, in copying for example the custom encoder/decoder from
step1 to step2 ?

When entire classes from step-n are reused in step-(n+1), there is IMO no
reason to copy them.


 Then when you introduce step 3, you will add JMX code to the code that
 includes steps 1 and 2.  So by the time you reach the end, the code in
 step
 1 (above) will contain much more code and not be so simple and
 understandable and the person reading the tutorial might get confused.


I agree.
After adding step2, the code in step1 shouldn't have changed.
That's the reason I called it step1 :-)

regards,
Maarten



 --Mark



 On Wed, Apr 9, 2008 at 4:23 PM, Maarten Bosteels [EMAIL PROTECTED]
 wrote:

  Hello Mark,
 
  Great to hear you will have some time to work on the examples.
 
  2008/4/9 Mark Webb [EMAIL PROTECTED]:
 
   I hit the send button much too quickly.  Maartin, what is your plan
 for
   how
   the codebase will look?  I see that in the examples subproject there
 is
  a
   package called imagine.step1.  For step 2, will you take a copy of
 all
   the
   code from step 1 and add more functionality (like ExecutorFilter)?
 
 
  I think most of the code from step1 can be reused by step2 etc, so there
  would be no need to copy code.
  IMO, the imagine.step2 package should only contain the code that needs
 to
  be
  added or changed compared to step1. Probably only the main method where
  the
  filterChain is built.
 
  But feel free to disagree :-)
 
  regards,
  Maarten (not Maartin)
 
 
  
   How do you see all this coming together?
  
   --Mark
  
   2008/4/9 Mark Webb [EMAIL PROTECTED]:
  
I have some free time coming up.  I will give it a shot.
   
   
   
On Wed, Apr 9, 2008 at 1:29 PM, Maarten Bosteels 
   [EMAIL PROTECTED]
wrote:
   
 On Wed, Apr 9, 2008 at 6:08 PM, 이희승 (Trustin Lee) 
  [EMAIL PROTECTED]
 wrote:

  I think it's good time for someone to write a MINA curriculum
 and
 revamp
  all examples to follow the curriculum.  Maarten once started an
  'imagine' example but he ended up with stage1.  He might have
 something
  in his mind about setting up the MINA curriculum.  ;)


 :-)
 Yes, my plan was to build upon the ImageServer and add extra
 functionality
 step-by-step
 * step1: what is now in the protocol-codec tutorial (and in svn)
 * step2 : add an ExecutorFilter
 * step3 : add some JMX stuff
 * step4 : show how to cleanly shut down the server
 * step5 : add a throttle filter
 ...
 (the order doesn't really matter)

 Unfortunately, until now I didn't get further than step1 ...
 I still have the intention though, just can't promise when I will
  find
 that
 scarce resource called  time.

 I'd welcome anyone who wants to work on this.

 Maarten


 
  Cheers,
 
  Mark Webb wrote:
   that is the funniest description of one's software I ever
 heard.
  bravo...
  
   On Wed, Apr 9, 2008 at 10:25 AM, Niklas Gustavsson 
 [EMAIL PROTECTED]
  
   wrote:
  
   2008/4/9 Mark Webb [EMAIL PROTECTED]:
   sounds like that is the direction we want to go.  My only
   concern
 is
   that we
start getting apps in the examples directory that overlap.
There
 is
currently a chat program in examples, but maybe your's is
  more
   feature-rich
or more robust.  One think I do like about the current chat
 example
  is
   that
it is the only example that uses Spring.
   No it's certainly not more feature rich, it's probably the
 stupidest
   chat server ever built. The purpose was to make it as simple
 as
   possible to be able to communicate it during a talk.
  
   /niklas
  
  
  
  
 
  --
  Trustin Lee - Principal Software Engineer, JBoss, Red Hat
  --
  what we call human nature is actually human habit
  --
  http://gleamynode.net/
 
 

   
   
   
--

Talent hits a target no one else can hit; Genius hits a target no
 one
   else
can see.
   
  
  
  
   --
   
   Talent

Re: MINA v2.0 Quick Start Guide

[Maarten Bosteels]

On Wed, Apr 9, 2008 at 6:08 PM, 이희승 (Trustin Lee) [EMAIL PROTECTED]
wrote:

 I think it's good time for someone to write a MINA curriculum and revamp
 all examples to follow the curriculum.  Maarten once started an
 'imagine' example but he ended up with stage1.  He might have something
 in his mind about setting up the MINA curriculum.  ;)


:-)
Yes, my plan was to build upon the ImageServer and add extra functionality
step-by-step
* step1: what is now in the protocol-codec tutorial (and in svn)
* step2 : add an ExecutorFilter
* step3 : add some JMX stuff
* step4 : show how to cleanly shut down the server
* step5 : add a throttle filter
...
(the order doesn't really matter)

Unfortunately, until now I didn't get further than step1 ...
I still have the intention though, just can't promise when I will find that
scarce resource called  time.

I'd welcome anyone who wants to work on this.

Maarten



 Cheers,

 Mark Webb wrote:
  that is the funniest description of one's software I ever heard.
 bravo...
 
  On Wed, Apr 9, 2008 at 10:25 AM, Niklas Gustavsson [EMAIL PROTECTED]
 
  wrote:
 
  2008/4/9 Mark Webb [EMAIL PROTECTED]:
  sounds like that is the direction we want to go.  My only concern is
  that we
   start getting apps in the examples directory that overlap.  There is
   currently a chat program in examples, but maybe your's is more
  feature-rich
   or more robust.  One think I do like about the current chat example
 is
  that
   it is the only example that uses Spring.
  No it's certainly not more feature rich, it's probably the stupidest
  chat server ever built. The purpose was to make it as simple as
  possible to be able to communicate it during a talk.
 
  /niklas
 
 
 
 

 --
 Trustin Lee - Principal Software Engineer, JBoss, Red Hat
 --
 what we call human nature is actually human habit
 --
 http://gleamynode.net/

Re: IoService API growth

[Maarten Bosteels]

On Mon, Apr 7, 2008 at 2:52 PM, Julien Vermillard [EMAIL PROTECTED]
wrote:

 On Mon, 7 Apr 2008 21:39:03 +0900 (KST)
 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:

  After looking into IoSession and IoService, I ended up with the
  conclusion that we can use the same statistics type instead of
  providing different types for IoSession and IoService.
 
  The following is the list of common methods in IoSession and IoService
  (please note that getLargestXXX() methods are not present in IoSession
  yet, but I think we can add it trivially.):
 
  boolean isBothIdle();
  boolean isIdle(IdleStatus status);
  boolean isReaderIdle();
  boolean isWriterIdle();
  double getLargestReadBytesThroughput();
  double getLargestReadMessagesThroughput();
  double getLargestWrittenBytesThroughput();
  double getLargestWrittenMessagesThroughput();
  double getReadBytesThroughput();
  double getReadMessagesThroughput();
  double getWrittenBytesThroughput();
  double getWrittenMessagesThroughput();
  int getBothIdleCount();
  int getIdleCount(IdleStatus status);
  int getReaderIdleCount();
  int getScheduledWriteBytes();
  int getScheduledWriteMessages();
  int getWriterIdleCount();
  long getLastBothIdleTime();
  long getLastIdleTime(IdleStatus status);
  long getLastIoTime();
  long getLastReaderIdleTime();
  long getLastReadTime();
  long getLastWriterIdleTime();
  long getLastWriteTime();
  long getReadBytes();
  long getReadMessages();
  long getWrittenBytes();
  long getWrittenMessages();
 
  Should we move all these methods to the statistics class or exclude
  some?  I think idleness properties are in the gray area.  isXXXIdle()
  sounds like a non-statistics property, but getXXXIdleCount() sounds
  like a statistics property.  And what about getLastXXXIdleTime?
 
  Any lights?
 
  Cheers,
  Hi
 Hi


Hi,


 I 'm ok for keeping isXXXIdle,getLastXXXIdleTime in main class, but
 move getXXXIdleCount to stats.


I agree.

Maarten



 Julien

Re: Time for another milestone?

[Maarten Bosteels]

+1 for M2

On Tue, Mar 18, 2008 at 8:52 PM, Mike Heath [EMAIL PROTECTED] wrote:

 +1 for an M2 release.

 Emmanuel Lecharny wrote:
  이희승 (Trustin Lee) wrote:
  Hi,
 
  We have fixed 26 issues since 2.0.0-M1.  Although we have 13 more
  issues to resolve in M2, I think we can slide to M3 considering the
  number of resolved issue so far.
  I think that releasing milestones frequently is not a bad idea, but if
  it only contains bugs fixes, I'm not sure they should be named
  milestone. I would suggest something slightly different :
 
  - Milestones should mark a progression toward a complet functionnal
  version. So between Mx and M(x+1), you should see new functionalities
  and some bugfixes

 I think an M2 release would fall under this definition.  We've fixed
 bugs and added features but there's still work to be done.


I agree.



  - when you think that all the new functions have been added, then you
  switch to a RCx scheme.

 RC stands for 'release candidate' so in my mind, an RC release means
 that the RC release will become the final release unless a major bug is
 found.  I hate RC releases that are actually beta releases.

  However, I think :
  - it's too late to adopt this new scheme now, as we already have a M2
  running
  - and I should have propose that before in order to be discussed and
  possibly adopted :)
 
  That being said, yeah, sure, with 26 fixed issues, it deserve a new
  milestone !

 Perhaps we should come up with a better defined road map in JIRA so that
 our milestone release are actually reaching a predetermined milestone.
 We should schedule out the remaining milestone(s) and any feature
 request not scheduled for a specific milestone will get pushed to a
 future release.  This would give us a clear target for a beta release
 and eventually a final 2.0 release.


Sounds good.

Maarten



 WDYT?

 -Mike

Re: TCP no Delay problem

[Maarten Bosteels]

hi Brenno,

see http://mina.apache.org/tutorial-on-protocolcodecfilter-for-mina-2x.html

Maarten

On Fri, Mar 14, 2008 at 4:15 PM, Emmanuel Lecharny [EMAIL PROTECTED]
wrote:

 Brenno Hayden wrote:
  Then, I have to make parser? To separate?
 Like any protocol, if you can't distinguish the end of a message from
 the beginning of a message, you are dead. So basically, yes, you have to
 do something to separate your messages. It can be a special tag at the
 end of your message, or by passing the length of your message, or by
 defining definite length for your message. it's up to you.


 ItslikespacescommaanddotsinasentenceIfyoudonthavethemdontexpecttheunderlyingprotocoltoaddthemforyou

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

Re: [GSoC] MINA performance tuning platform

[Maarten Bosteels]

Hello Alex,

Have been dreaming of such tool as well ...
I just wish I was still a student, with an ocean of time :-)

You clearly wrote the description with a lot of enthusiasm.
I really hope someone accepts the challenge.

Maarten

On Wed, Mar 12, 2008 at 2:10 AM, Alex Karasulu [EMAIL PROTECTED] wrote:

 Hi students and potential MINA mentors,

 I had a couple conversations with a few peeps that wished they had a month
 or two to write a slick new framework for load testing MINA based
 applications while using MINA itself to write the framework.  My
 experiences
 with MINA and various crappy tools out there make me realize that
 performance tuning a network application is half the battle.  I know
 others
 probably feel the same.

 Then all this GSoC stuff is going on and the idea occurs to one of us (not
 me it was Emmanuel's idea) that we can make this a nice tight discrete
 project where a student can accomplish this task while learning about MINA
 and getting involved in our community.  This is just a win win situation.

 The idea is simple.  We have a set of load injecting worker processes that
 are coordinated by managers on each load injecting host.  The managers
 simply control the life cycle of worker processes and get their orders to
 do
 so from a data collecting and collating server with a management console.
 This requires some kind of simple control protocol which can be written
 using MINA.  For the console I dream of a slick GWT interface where you
 can
 launch tests and control injector hosts.  Oh the fun you can have with
 statistics etc ... anyways back from dream land ... Ideally separate
 managers reside in a set of load injecting machines and the system under
 test resides on yet another.  Likewise the console server can run on a
 separate machine as well.  The clients funnel data to the collating server
 for jobs and are network applications that likewise can be written using
 MINA.  Regardless of the topology used this is the general model presented
 by may performance testing frameworks like Grinder and SLAMD.

 The neat thing is some frameworks can even start running optimizations
 where
 parameters are varied to find optimal running conditions.  I'd like to do
 this too but perhaps also have an agent in the tested application as a
 Filter probably to both monitor and influence the application.  This makes
 the server more of a white box than a black box undergoing testing from
 the
 outside.  It could for example vary standard MINA server parameters to
 find
 optimal settings while monitoring server process information like memory
 and
 thread usage etc.  There are many possibilities here.  We could even use
 Genetic Algorithms and Optimization Algorithms to control and influence
 the
 optimization process - ok getting carried away.  For starters of course
 this
 feature may not be present :D.  However the idea is the student can take
 this as far as they like.

 The bottom line is this is a great project for a student interested in
 using
 MINA to tune MINA while getting their feet wet and involved in this
 community.  MINA users will now have a framework they can use and
 hopefully
 contribute back to.  Everyone is happy.

 Thoughts?

 Anyone interested in mentoring or taking on this project as a student in
 GSoC?

 Thanks,
 Alex

Re: Threading problem in MdcInjectionFilter

[Maarten Bosteels]

mina 2.0 depends heavily on java 5
I am working on the fix.

Maarten


On Mon, Mar 10, 2008 at 9:24 AM, Niklas Gustavsson [EMAIL PROTECTED]
wrote:

 On Mon, Mar 10, 2008 at 9:03 AM, Emmanuel Lecharny [EMAIL PROTECTED]
 wrote:
   Just check that this change is compatible with the JVM version we are
 using.
 
   I don't remember if MINA should still be compatible with 1.4, and if
   ConcurrentHashMap is avaialable in 1.4...

 ConcurrentHashMap came with the concurrency classes in 1.5. Since the
 bug manifests itself inside of a enhanced for loop I think we should
 be fine :-)

 /niklas

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

[Maarten Bosteels (JIRA)]

ConcurrentModificationException in MdcInjectionFilter
-

 Key: DIRMINA-544
 URL: https://issues.apache.org/jira/browse/DIRMINA-544
 Project: MINA
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0.0-M1
Reporter: Maarten Bosteels
 Fix For: 2.0.0-M2


When doing some load testing on FtpServer, I ran into a threading
issue in MdcInjectionFilter. When adding some load, I frequently get a
ConcurrentModificationException on removing the MDC properties. Here's
the stacktrace:

java.util.ConcurrentModificationException
   at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)
   at java.util.HashMap$KeyIterator.next(HashMap.java:828)
   at 
org.apache.mina.filter.logging.MdcInjectionFilter.filter(MdcInjectionFilter.java:140)
   at 
org.apache.mina.filter.util.CommonEventFilter.messageReceived(CommonEventFilter.java:67)
   at 
org.apache.mina.common.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:401)
   at 
org.apache.mina.common.DefaultIoFilterChain.access$1200(DefaultIoFilterChain.java:38)
   at 
org.apache.mina.common.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:820)
   at 
org.apache.mina.common.DefaultIoFilterChain$HeadFilter.messageReceived(DefaultIoFilterChain.java:604)
   at 
org.apache.mina.common.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:401)
   at 
org.apache.mina.common.DefaultIoFilterChain.fireMessageReceived(DefaultIoFilterChain.java:395)
   at 
org.apache.mina.common.AbstractPollingIoProcessor.read(AbstractPollingIoProcessor.java:425)
   at 
org.apache.mina.common.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:387)
   at 
org.apache.mina.common.AbstractPollingIoProcessor.process(AbstractPollingIoProcessor.java:379)
   at 
org.apache.mina.common.AbstractPollingIoProcessor.access$400(AbstractPollingIoProcessor.java:43)
   at 
org.apache.mina.common.AbstractPollingIoProcessor$Worker.run(AbstractPollingIoProcessor.java:676)
   at 
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
   at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
   at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
   at java.lang.Thread.run(Thread.java:619)

The cause of the problem is a call to setProperty() from
org.apache.ftpserver.command.USER. I'm not familiar enough with the
MDC filter to identify the culprit. Simply synchronizing the context
Map does not help. The test I'm running is quite simple:

package org.apache.ftpserver.clienttests;


public class MdcThreadingTest extends ClientTestTemplate {

   public void testLoginMulti() throws Exception {
   tearDown();
   for(int i = 0; i1; i++) {
   setUp();
   assertTrue(client.login(ADMIN_USERNAME, ADMIN_PASSWORD));
   tearDown();
   }
   System.out.println(All done!);
   }
}

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

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

[Maarten Bosteels (JIRA)]

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

Maarten Bosteels reassigned DIRMINA-544:


Assignee: Maarten Bosteels

 ConcurrentModificationException in MdcInjectionFilter
 -

 Key: DIRMINA-544
 URL: https://issues.apache.org/jira/browse/DIRMINA-544
 Project: MINA
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0.0-M1
Reporter: Maarten Bosteels
Assignee: Maarten Bosteels
 Fix For: 2.0.0-M2


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

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

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

[Maarten Bosteels (JIRA)]

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

Maarten Bosteels resolved DIRMINA-544.
--

Resolution: Fixed

use ConcurrentHashMap instead of HashMap

 ConcurrentModificationException in MdcInjectionFilter
 -

 Key: DIRMINA-544
 URL: https://issues.apache.org/jira/browse/DIRMINA-544
 Project: MINA
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0.0-M1
Reporter: Maarten Bosteels
Assignee: Maarten Bosteels
 Fix For: 2.0.0-M2


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

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

Re: How to receive the large size package?

[Maarten Bosteels]

Hello Lenney,

Could you maybe show us the code for your encoder/decoder ?
And which transport are you using ?

8 minutes for 6 MB seems rather slow :-)

Maarten

On Fri, Mar 7, 2008 at 9:13 AM, Lenney [EMAIL PROTECTED] wrote:


 Hi, everybody.

 Maybe it's a stupid question, but I have spent about tow months to
 struggle
 with this problem.

 About tow months ago, I started to use Mina to develope a client program
 to
 connect to a server to subscribe the message. The data format of the
 message
 sent to server or received by client is showed as belowing:

 [ length_string | 0 | UTF-8 XML(GZ format) ]

 Since the data format is byte stream, so I write an ProtocolEncoder and a
 ProtocolDecoder to perform the encode and decode job.

 The server will send a large message(about 6MB in size) at the first time
 when a client connect to, it will take about 8 minutes for server to push
 such message. And now the error occurs, at the client site, I think, Mina
 will try to split a large size package into small size packages, which
 will
 causes messageReceived being called many times. So the the decoder can't
 work as I expected.

 Will anyboy know how to solve such problem?

 Thanks.

 -
 驱鱼爬树，赶鸭上吊
 --
 View this message in context:
 http://www.nabble.com/How-to-receive-the-large-size-package--tp15891083s16868p15891083.html
 Sent from the Apache MINA Commits mailing list archive at Nabble.com.

Re: Is it the right time to use Mina 2.0.0-M1?

[Maarten Bosteels]

Hello Steven,

When you're starting a new project, I would highly recommend to use
the latest milestone of 2.0 (currently  MINA-2.0.0-M1)

see also this thread:  http://markmail.org/message/oh32gvosd4mwsng5

We hope you will enjoy using MINA.

regards
Maarten

On Fri, Mar 7, 2008 at 7:08 AM, Steven [EMAIL PROTECTED] wrote:


 Or should  I wait for the official version?

 I am new to Mina.

 Thank you!



 Steven

Re: MINA-2.0.0-M1 -- SslFilter handshake failed?

[Maarten Bosteels]

You're using the VmPipeConnector and Acceptor ?

Am not sure it makes sense to use an SSLFilter for the VmPipe transport ?

SSL is meant to be used on sockets.

Maarten


On Fri, Mar 7, 2008 at 4:22 PM, Mark Renouf [EMAIL PROTECTED] wrote:

 Hmm. I saw this from some googling I did on that particular message.
 We generally control both ends of the communication within our product
 so I had assumed the handshake would negotiate this automatically.
 From a wireshark trace of the same test over the wire, I saw a huge
 list of cipher-suites proposed to the other end (in fact, if you
 decode those 100 bytes, I beleive that's what you see in the
 messageSent log from my test).


/**
 * Sets the list of cipher suites to be enabled when [EMAIL PROTECTED] 
 SSLEngine}
 * is initialized.
 *
 * @param cipherSuites ttnull/tt means 'use [EMAIL PROTECTED]
 SSLEngine}'s default.'
 */
public void setEnabledCipherSuites(String[] cipherSuites) {
this.enabledCipherSuites = cipherSuites;
}

 Just for kicks, I tried setEnabledCipherSuites(null); but with no
 change in behavior


 On Fri, Mar 7, 2008 at 10:12 AM, Niklas Therning [EMAIL PROTECTED]
 wrote:
  I think it is the no cipher suites in common error which causes the
   handshake problem. You can use SslFilter.setEnabledCipherSuites() to
   specify which suites should be enabled.
 
   HTH
 
   /Niklas
 
   Mark Renouf skrev:
 
 
   I've been struggling with an SSL issue. I had it all working but I've
lost track of some changes and basically I'm stuck again. I've
dissolved it down to a unit test where I have a pair of VmPipe
(acceptor/connector) talking, each with an SslFilter. Each have a
seperate keystore, and a common truststore. Each's certificates are
signed by a CA cert in the trust store. These are known-good as they
were take from a production server.
   
The server has a simple handler set which waits for PING and sends
back PONG. The test passes without the SSL Filter in place. In the
tests I also placed a logging filter last on the filter chain of the
connector so I can see the raw data after processing.
   
When I enable SSL on both ends, I get a failed handshake. I'm using
SSLContextFactory and KeyStoreFactory to load keystores. I've
independently verified the keystores are valid and being loaded
correctly (right passwords etc).
   
The com.X.X lines below are just  package names from an
unreleased product of my employer which I've anonymized for now :-)
   
The handlers look like this:
IoHandler clientHandler = new IoHandlerAdapter() {
@Override
public void exceptionCaught(IoSession session, Throwable
cause) throws Exception {
LOGGER.fatal(CLIENT IoHandler: exceptionCaught,
 cause);
}
};
   
IoHandler serverHandler = new IoHandlerAdapter() {
@Override
public void exceptionCaught(IoSession session, Throwable
cause) throws Exception {
LOGGER.fatal(SERVER IoHandler: exceptionCaught,
 cause);
session.close(true);
}
   
@Override
public void messageReceived(IoSession session, Object
message) throws Exception {
if (message instanceof IoBuffer) {
String msg =
((IoBuffer)message).getString(CHARSET.newDecoder());
if (msg.equals(PING)) {
IoBuffer buffer = IoBuffer.allocate(4);
buffer.putString(PONG, CHARSET.newEncoder
 ());
buffer.flip();
session.write(buffer);
}
}
}
};
   
There's also a LoggingFilter attached with the messageSent and
messageReceived levels visible (attached to the client's filter
 chain)
   
Here is the relevant test code:
   
Set up SSLContext ctx1 using SSLContextFactory
   
   171  IoAcceptor acceptor = new VmPipeAcceptor();
   172  acceptor.setHandler(serverHandler);
   173  SslFilter serverFilter = new SslFilter(ctx1);
   174  serverFilter.setNeedClientAuth(true);
   175  acceptor.getFilterChain().addLast(SSL,
 serverFilter);
   176  acceptor.bind(new VmPipeAddress(1));
   
Set up SSLContext ctx2 using SSLContextFactory
   
   189  IoConnector connector = new VmPipeConnector();
   190  connector.setHandler(clientHandler);
   191  SslFilter clientFilter = new SslFilter(ctx2);
   192  clientFilter.setUseClientMode(true);
  (Set up LoggingFilter)
   203  connector.getFilterChain().addLast(LOG,
 loggingFilter);
   204  connector.getFilterChain().addLast(SSL,
 

Re: Re : MINA-2.0.0-M1 -- SslFilter handshake failed?

[Maarten Bosteels]

Hi Marc,

Have you tried setting  serverFilter.setNeedClientAuth(false) ?
Just to see if that helps.

Maarten

On Fri, Mar 7, 2008 at 5:03 PM, Mark Renouf [EMAIL PROTECTED] wrote:

 Hmm. I really hoped this was it. I just tried this (downloaded
 jce_policy-1_5_0.zip from sun and installed jars into my
 jre/lib/security folder). No change... :-(

 If it helps, I added a little more code to display the ciphersuites,
 protocols and the details of the keys and certificates in use:
 (They are exactly the same for client and server, except for the
 actualy key and cert, so I'm only listing the client side)

 SSLParameters clientSSLParams = clientSSLContext.getDefaultSSLParameters
 ();
LOGGER.info(Client Protocols:  +
 Arrays.asList(clientSSLParams.getProtocols()));
LOGGER.info(Client Cipher Suites:  +
 Arrays.asList(clientSSLParams.getCipherSuites()));

 2008-03-07 11:01:10,206 INFO  main SSLTest - Client Protocols:
 [SSLv2Hello, SSLv3, TLSv1]
 2008-03-07 11:01:10,206 INFO  main SSLTest - Client Cipher Suites:
 [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA,
 TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA,
 TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
 TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
 SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,
 SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA,
 SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA,
 SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA,
 SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA,
 SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA]

 2008-03-07 10:55:14,558 INFO  main SSLTest - Client Certificate: [
 [
  Version: V1
  Subject: CN=X
  Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4

  Key:  Sun RSA public key, 512 bits
  modulus: X
  public exponent: 65537
  Validity: [From: Thu Jul 27 18:11:39 EDT 2006,
   To: Tue Jul 26 18:11:39 EDT 2016]
  Issuer: CN=XX
  SerialNumber: [ ]
 ]

 2008-03-07 10:55:14,567 INFO  main SSLTest - Client Key:
 Sun RSA private CRT key, 512 bits
(actual key material follows)


 On Fri, Mar 7, 2008 at 10:19 AM, Edouard De Oliveira
 [EMAIL PROTECTED] wrote:
  Did you modify your JCE permissions ?
   Due to crypto restrictions your Keystores may be in good shape but
 unusable.
   Download the unrestricted JCE policy files from java web site and try
 again.
 
   My 0.02 $
 
   Cordialement, Regards,
   -Edouard De Oliveira-
   http://tedorg.free.fr/en/main.php

Re: Re : MINA-2.0.0-M1 -- SslFilter handshake failed?

[Maarten Bosteels]

Hello Mark,

On Fri, Mar 7, 2008 at 8:45 PM, Mark Renouf [EMAIL PROTECTED] wrote:

 Sorry for the spam... (I hope this is relevant?)

 I found the difference, in my use of SSLContextFactory, I was not calling:

sslContextFactory.setTrustManagerFactoryAlgorithmUseDefault(true);
sslContextFactory.setKeyManagerFactoryAlgorithmUseDefault(true);

 I seriously think these should be the default behavior. If these are
 not set, and no protocol is set, the factory simply fails to create
 either a KeyManagerFactory or TrustManagerFactory internally with no
 warnings or errors. (lines 83  98 of SslContextFactory.java in
 release 2.0.0-M1)


Your suggestion sounds reasonable.



 I believe this is from the mina-integration subproject... is there a
 more appropriate list or bug database I should submit this to?



http://issues.apache.org/jira/browse/DIRMINA

regards,
Maarten



 On Fri, Mar 7, 2008 at 2:14 PM, Mark Renouf [EMAIL PROTECTED] wrote:
  Another update.
   Ok. That hunch payed off... I replaced the SSLContextFactory with the
   manual equivalent and it's working now
 
   My eyes are a bit weary at this point so I can't spot an obvious
   difference. Hopefully I'll have a chance to go look at
   SSLContextFactory and compare it with this code, there's got to be a
   critical difference somewhere.
 
   Anyway, here is the working init code to create the each SSLContext.
   This is the only part I changed:
 
  KeyStore serverKeyStore = KeyStore.getInstance(PKCS12);
  serverKeyStore.load(loader.getResourceAsStream
 (ssl/server.p12),
   DEFAULT_KEY_PASS.toCharArray());
 
  KeyStore clientKeyStore = KeyStore.getInstance(PKCS12);
  clientKeyStore.load(loader.getResourceAsStream
 (ssl/client.p12),
   DEFAULT_KEY_PASS.toCharArray());
 
  KeyStore trustStore = KeyStore.getInstance(JKS);
  trustStore.load(loader.getResourceAsStream(ssl/trusted.jks),
   DEFAULT_KEY_PASS.toCharArray());
 
  KeyManagerFactory serverKeyManagerFactory =
   KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
  serverKeyManagerFactory.init(serverKeyStore,
   DEFAULT_KEY_PASS.toCharArray());
  KeyManager[] serverKeyManagers =
   serverKeyManagerFactory.getKeyManagers();
 
  KeyManagerFactory clientKeyManagerFactory =
   KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
  clientKeyManagerFactory.init(clientKeyStore,
   DEFAULT_KEY_PASS.toCharArray());
  KeyManager clientKeyManagers[] =
   clientKeyManagerFactory.getKeyManagers();
 
  TrustManagerFactory serverTrustManagerFactory =
   TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm
 ());
  serverTrustManagerFactory.init(trustStore);
  TrustManager[] serverTrustManagers =
   serverTrustManagerFactory.getTrustManagers();
 
  TrustManagerFactory clientTrustManagerFactory =
   TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm
 ());
  clientTrustManagerFactory.init(trustStore);
  TrustManager[] clientTrustManagers =
   clientTrustManagerFactory.getTrustManagers();
 
  SSLContext serverSSLContext = SSLContext.getInstance(TLS);
  serverSSLContext.init(serverKeyManagers, serverTrustManagers,
 null);
 
  SSLContext clientSSLContext = SSLContext.getInstance(TLS);
  clientSSLContext.init(clientKeyManagers, clientTrustManagers,
 null);

Re: [FTPServer] Plans for Logging

[Maarten Bosteels]

ok, I will adapt the javadocs, I thought they were clear...

Can you have a look at the test-case for the MdcInjectingFilter, and see if
anything is missing ?

Thanks,
Maarten

On Fri, Feb 29, 2008 at 10:58 PM, Niklas Gustavsson [EMAIL PROTECTED]
wrote:

 On Fri, Feb 29, 2008 at 10:52 PM, Mike Heath [EMAIL PROTECTED] wrote:
   The MDC properties are stored in a ThreadLocal so if you have the
   logging filter before an executor filter, the MDC properties will get
   lost.  If you put the MDC logging filter after the executor filter then
   it should work just fine.

 Seconds after sending my email I realized that it was the same
 MdcInjectionFilter instance needed in both places, previously we
 created separate instances. This fixes the issue Dave discovered. Fix
 commited in rev 632454.

 The JavaDoc doesn't make this very clear and I'm not sure if it is the
 intended behavior?

 /niklas

Re: Basic Development Question

[Maarten Bosteels]

Hello,

On Thu, Feb 28, 2008 at 2:54 AM, Aviator [EMAIL PROTECTED] wrote:


 Hello  I'm somewhat new to MINA. Currently using V2.0 on Win XP. I was
 wondering what the correct approach would be for trying to do the following:

 I have a simple server which accepts client connections (very much like
 the one in the MINA v2.0 Quick Start Guide). Suppose some event is
 triggered within the server in a separate event thread (from the threads
 managing the client sessions). Suppose this event is time based (happens
 everyday at 12:00pm) and is a simple message which is to be sent to a
 specific client saying 'Lunch Time'. What is the correct approach needed for
 this event thread to contact the appropriate client session to send the
 message 'Lunch Time'? Is it as simple as the event thread performing a
 session.write(aObject) for the appropriate client


yes, that should work.



 or is there some more amazing way to achieve this? For example, can the
 event thread inform the client session that there is a message which needs
 to be sent and let the client session's thread actually do the write?


I don't think there is a mechanism like that. And I think the first approach
is easier, no ?

regards,
Maarten



 Thanks

 _

Re: MdcInjectionFilter with nested calls

[Maarten Bosteels]

Hello Daniel,

On Feb 18, 2008 4:54 PM, Daniel Cheng [EMAIL PROTECTED] wrote:

 Hi list,

 MdcInjectionFilter fails on nested call. It assume only one IoSession on
 a thread at any time.


yes, that might be an issue, not sure, I will investigate it.
Which session info would you expect to be in the MDC, both ?




 See attached source for a test case.  You need both port 21 and 22 open
 on localhost to run the test case. If you can't open the attachment, try
  http://www.sdiz.net/temp/MainTest.java

 (btw, checkDeadlock() in await() think I have a deadlock when I remove
 the Thread.sleep() call on line 39 ... is this bug?)


I don't think so.
Instead of using cf.await() you should use an IoFutureListener:

Your code:

public void sessionOpened(final IoSession session) throws Exception {
  logger.info([conn2] before connect to conn1);
  final ConnectFuture cf = conn1.connect(new InetSocketAddress(localhost,
TEST_PORT2));
  logger.info([conn2] after connect to conn1);
  Thread.sleep(3000); // WAIT FOR CONNECT
  cf.await(); // (or await will think this as deadlock)
  cf.getSession().write(IoBuffer.wrap(HELP\n.getBytes(LATIN1)));
  // BUG HERE!!! we have no MDC here!!
  logger.info([conn2] after write to conn1);
}


Better:

public void sessionOpened(final IoSession session) throws Exception {
  logger.info([conn2] before connect to conn1);
  final ConnectFuture cf = conn1.connect(new InetSocketAddress(localhost,
TEST_PORT2));
  logger.info([conn2] after connect to conn1);
  final byte[] bytes = HELP\n.getBytes(LATIN1);
  cf.addListener(new IoFutureListenerConnectFuture() {
public void operationComplete(ConnectFuture future) {
  future.getSession().write(IoBuffer.wrap(bytes));
  logger.info([conn2] after write to conn1);
}
   });
  }

This also solves the MDC problem.

Maarten


 --
 This space was intended to be left blank.

Re: ByteBuffer

[Maarten Bosteels]

On Feb 19, 2008 3:39 PM, Christian Migowski [EMAIL PROTECTED] wrote:

 I am curious, how would that ByteArrayCodecFactory help?


It would just be convenient for people that need to send/receive
a byte[] with a length prefix.



 I had to deal with a protocol that hasn't neither a fixed length nor a
 fixed
 delimiter (it is XML fragments sent directly on the wire, without any
 header, so the Msg was complete when i found a matching end tag to a list
 of
 start tags).


Is it a custom protocol ? I think the protocol smells a bit.
Is the character encoding used in the XML fragments always the same ?

You're gonna have a hard time decoding when clients are allowed to send XML
using the encoding of their choice (eg. both UTF-8 and UTF-16)

Maarten


 The reason may be that i am still inexperienced with the Java
 way of doing things, but the solution i found was to read up to a certain
 amount of bytes (using the method below), check if the message was
 complete,
 if not rewind the buffer to the start position and wait for the next
 invocation.

 christian!


 On 2/19/08, Maarten Bosteels [EMAIL PROTECTED] wrote:
 
  Have a look at
 
 
 http://www.nabble.com/Re%3A-sending-receiving-a-byte---p14220485s16868.html
 
  Is your array of bytes prefixed with a length indicator ?
  If not, how do you know the end of the message ?
 
  Maybe we should add a ByteArrayCodecFactory to MINA.
 
  Maarten
 
  On Feb 19, 2008 3:19 PM, Christian Migowski [EMAIL PROTECTED]
 wrote:
 
   Hi,
  
   i stumbled over this as well some time ago. The Javadoc says this
   exception
   happens when the ByteBuffer isn't backed by an accessible array, my
   finding
   was it isn't guaranteed in any way it is - better do not rely on that
   method.
   Fortunately you can easily rewrite your code to
  
   int len = in.remaining();
   //(i do think your usage of limit() is not what you intend to do)
   byte[] stream = new byte[len];
   in.get(stream , 0, in.remaining());
  
  
   hope that helps.
   regards,
   christian!
  
  
   On 2/19/08, Brenno Hayden [EMAIL PROTECTED] wrote:
   
Hi,
   
I am having a difficulty in mke this cast? Can I do something? Some
  tip
   ?
   
*code*
   
ByteArrayDecoder extends CumulativeProtocolDecoder {
   
protected boolean doDecode(IoSession session, ByteBuffer in,
ProtocolDecoderOutput out) throws Exception {
if (in instanceof ByteBuffer) {
 int len = in.limit();
 byte[] stream = new byte[len];
 //TODO
 stream = in.array(); // Why ?
 out.write(stream);
 return true;
}else {
  return false.
}
}
   
*console*:
   
org.apache.mina.filter.codec.ProtocolDecoderException:
java.lang.UnsupportedOperationException
   
   
   
Thanks
   
   
--

Brenno Hayden F. Dantas
   
  
 

Re: ByteBuffer

[Maarten Bosteels]

Have a look at
http://www.nabble.com/Re%3A-sending-receiving-a-byte---p14220485s16868.html

Is your array of bytes prefixed with a length indicator ?
If not, how do you know the end of the message ?

Maybe we should add a ByteArrayCodecFactory to MINA.

Maarten

On Feb 19, 2008 3:19 PM, Christian Migowski [EMAIL PROTECTED] wrote:

 Hi,

 i stumbled over this as well some time ago. The Javadoc says this
 exception
 happens when the ByteBuffer isn't backed by an accessible array, my
 finding
 was it isn't guaranteed in any way it is - better do not rely on that
 method.
 Fortunately you can easily rewrite your code to

 int len = in.remaining();
 //(i do think your usage of limit() is not what you intend to do)
 byte[] stream = new byte[len];
 in.get(stream , 0, in.remaining());


 hope that helps.
 regards,
 christian!


 On 2/19/08, Brenno Hayden [EMAIL PROTECTED] wrote:
 
  Hi,
 
  I am having a difficulty in mke this cast? Can I do something? Some tip
 ?
 
  *code*
 
  ByteArrayDecoder extends CumulativeProtocolDecoder {
 
  protected boolean doDecode(IoSession session, ByteBuffer in,
  ProtocolDecoderOutput out) throws Exception {
  if (in instanceof ByteBuffer) {
   int len = in.limit();
   byte[] stream = new byte[len];
   //TODO
   stream = in.array(); // Why ?
   out.write(stream);
   return true;
  }else {
return false.
  }
  }
 
  *console*:
 
  org.apache.mina.filter.codec.ProtocolDecoderException:
  java.lang.UnsupportedOperationException
 
 
 
  Thanks
 
 
  --
  
  Brenno Hayden F. Dantas
 

Re: ByteBuffer

[Maarten Bosteels]

On Feb 19, 2008 4:27 PM, Luis Neves [EMAIL PROTECTED] wrote:

 Maarten Bosteels wrote:
  On Feb 19, 2008 3:39 PM, Christian Migowski [EMAIL PROTECTED]
 wrote:


  I had to deal with a protocol that hasn't neither a fixed length nor a
  fixed
  delimiter (it is XML fragments sent directly on the wire, without any
  header, so the Msg was complete when i found a matching end tag to a
 list
  of
  start tags).
 
 
  Is it a custom protocol ? I think the protocol smells a bit.
  Is the character encoding used in the XML fragments always the same ?
 
  You're gonna have a hard time decoding when clients are allowed to send
 XML
  using the encoding of their choice (eg. both UTF-8 and UTF-16)


 See XMMP, it is basically an endless stream of XML stanzas.


Hello Luis,

I guess you mean XMPP ?  According to [1] it uses UTF-8 character encoding
exclusively,
which makes decoding a lot easier. That's why I asked Brenno if the encoding
is fixed.

[1] http://www.xmpp.org/rfcs/rfc3920.html

regards,
Maarten


 --
 Luis Neves

Re: ByteBuffer

[Maarten Bosteels]

;
}
 }
 //--
 *ByteArrayProtocolEnconder.java*

 package codec;

 import org.apache.mina.common.ByteBuffer;
 import org.apache.mina.common.IoSession;
 import org.apache.mina.filter.codec.ProtocolEncoderAdapter;
 import org.apache.mina.filter.codec.ProtocolEncoderOutput;

 public class ByteArrayProtocolEnconder extends ProtocolEncoderAdapter {

public ByteArrayProtocolEnconder() {

}

public void encode(IoSession session, Object message,
 ProtocolEncoderOutput output)
throws Exception {
byte[] bytes = (byte[]) message;
int totalLength = bytes.length;
ByteBuffer buf = ByteBuffer.allocate(totalLength);
buf.put(bytes);
buf.flip();
output.write(buf);
}
 }

 On Feb 19, 2008 10:39 AM, Christian Migowski [EMAIL PROTECTED] wrote:

  I am curious, how would that ByteArrayCodecFactory help?
 
  I had to deal with a protocol that hasn't neither a fixed length nor a
  fixed
  delimiter (it is XML fragments sent directly on the wire, without any
  header, so the Msg was complete when i found a matching end tag to a
 list
  of
  start tags). The reason may be that i am still inexperienced with the
 Java
  way of doing things, but the solution i found was to read up to a
 certain
  amount of bytes (using the method below), check if the message was
  complete,
  if not rewind the buffer to the start position and wait for the next
  invocation.
 
  christian!
 
 
  On 2/19/08, Maarten Bosteels [EMAIL PROTECTED] wrote:
  
   Have a look at
  
  
 
 http://www.nabble.com/Re%3A-sending-receiving-a-byte---p14220485s16868.html
  
   Is your array of bytes prefixed with a length indicator ?
   If not, how do you know the end of the message ?
  
   Maybe we should add a ByteArrayCodecFactory to MINA.
  
   Maarten
  
   On Feb 19, 2008 3:19 PM, Christian Migowski [EMAIL PROTECTED]
  wrote:
  
Hi,
   
i stumbled over this as well some time ago. The Javadoc says this
exception
happens when the ByteBuffer isn't backed by an accessible array, my
finding
was it isn't guaranteed in any way it is - better do not rely on
 that
method.
Fortunately you can easily rewrite your code to
   
int len = in.remaining();
//(i do think your usage of limit() is not what you intend to do)
byte[] stream = new byte[len];
in.get(stream , 0, in.remaining());
   
   
hope that helps.
regards,
christian!
   
   
On 2/19/08, Brenno Hayden [EMAIL PROTECTED] wrote:

 Hi,

 I am having a difficulty in mke this cast? Can I do something?
 Some
   tip
?

 *code*

 ByteArrayDecoder extends CumulativeProtocolDecoder {

 protected boolean doDecode(IoSession session, ByteBuffer in,
 ProtocolDecoderOutput out) throws Exception {
 if (in instanceof ByteBuffer) {
  int len = in.limit();
  byte[] stream = new byte[len];
  //TODO
  stream = in.array(); // Why ?
  out.write(stream);
  return true;
 }else {
   return false.
 }
 }

 *console*:

 org.apache.mina.filter.codec.ProtocolDecoderException:
 java.lang.UnsupportedOperationException



 Thanks


 --
 
 Brenno Hayden F. Dantas

   
  
 



 --
 
 Brenno Hayden F. Dantas

Re: Blocking DNS queries (Was: Re: [AsyncWeb] Ideas for client)

[Maarten Bosteels]

On Feb 13, 2008 10:07 AM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote:

 2008-02-12 (화), 23:57 -0700, Mike Heath 쓰시길:
  이희승 (Trustin Lee) wrote:
   2008-02-12 (화), 11:16 -0700, Mike Heath 쓰시길:
   Eero Nevalainen wrote:
   Btw, what was the status of DNS resolution in MINA? I remember that
 at
   some point DNS resolving used the blocking java API calls. I could
   imagine that an asynchronous HTTP-client would have to perform a lot
 of
   DNS queries(or not, depending on use). Could this become a pithole?
   That's a very good point, Eero.  I think blocking DNS lookups could
   definitely be a very big pit hole.  Did anything ever come from all
 the
   asynchronous DNS lookup discussions?
  
   And that's not the only DNS issue.  If a DNS returns multiple A
 records
   for a given host name, most browsers will try to connect to the IP
   address from the first A record.  If that fails, they'll try the next
 IP
   address and so on until the connection succeeds or all of the A
 records
   have been exhausted.  We should support this same behavior in
 AsyncWeb.
  
   I thought it's the operating system who decides which A record to use
   and it's often random round-robin style.  Is there any related
   documentation or is it from your experiment?  Just curious.
 
  The way Mozilla browsers handle DNS Round Robin is explained here
  http://www.mozilla.org/docs/netlib/dns.html under the Round Robin
  Support section.
 
   It would be nice to have a built in DNS lookup mechanism in MINA as we
   discussed in our previous discussion, but once the domain name is
   resolved, it will be cached by the operation system, so it shouldn't
 be
   a big problem in most cases.  It will of course be a problem if
 someone
   is writing a web robot or something similar.
 
  I do agree that in most cases it won't be a problem.

 Thanks for the link to the documentation.

 So, I guess we need some pluggability in domain name resolution.  For
 now, we are using InetSocketAddress and as long as we depend on it, we
 don't have any control over how domain name is resolved in MINA.  This
 mean that we need to provide our own endpoint representation classes.
 It will probably cause the major API change, but I think it worth to do
 this.  How does that sound?  Will we need to implement this in 2.0 or...
 in 3.0? :)


I would say 2.0-M2

Maarten


 --
 what we call human nature is actually human habit
 --
 http://gleamynode.net/

Re: [VOTE] Release Apache MINA 2.0-M1

[Maarten Bosteels]

+1 Release MINA 2.0-M1

Maarten

On Feb 12, 2008 8:38 AM, Cameron Taggart [EMAIL PROTECTED] wrote:

 +1

  [ ]: +1, Release MINA 2.0-M1
  [ ]: 0, Abstain
  [ ]: -1, Don't release MINA 2.0-M1

Re: [AsyncWeb] Need an async client now

[Maarten Bosteels]

On Feb 11, 2008 8:20 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote:


 On Feb 11, 2008, at 12:20 AM, Maarten Bosteels wrote:

  On Feb 11, 2008 7:37 AM, Mike Heath [EMAIL PROTECTED] wrote:
 
  The new logging features in SLF4J and removing IoSessionLogger were
  what
  was holding up an M1 release.  Where do we stand on the logging front
  right now?
 
 
  see my comments on http://issues.apache.org/jira/browse/DIRMINA-513
 
  IoSessionLogger has been removed, but I could not yet add MDC-aware
  Formatter implementations because the new SLF4J hasn't been
  released. 
 
  Meanwhile Ceki has published an SLF4J-API-1.5.0-M0 in maven.
  I will commit the formatter asap (hopefully tonight CET) and close
  this
  issue.

 Just curious.  What are these logging features that are so important?


Hello Alan,

see
http://www.nabble.com/Re%3A--MINA--2.0-Milestone-1---p15092056s16868.html

DIRMINA-513 wasn't that important IMO.
But about two weeks ago it was the only unresolved issue for 2.0.0-M1, so we
decided to fix it before cutting the first milestone.
And it's fixed now.

regards,
Maarten

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

[Maarten Bosteels (JIRA)]

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

Maarten Bosteels resolved DIRMINA-513.
--

Resolution: Fixed

Added  org.apache.mina.util.Log4jXmlFormatter

 get rid of IoSessionLogger 
 ---

 Key: DIRMINA-513
 URL: https://issues.apache.org/jira/browse/DIRMINA-513
 Project: MINA
  Issue Type: Improvement
  Components: Core
Affects Versions: 2.0.0-M1
Reporter: Maarten Bosteels
Assignee: Maarten Bosteels
Priority: Minor
 Fix For: 2.0.0-M1


 It seems like the next version of SLF4J is going to support MDC for  
 java.util.logging 
 The users who use java.util.logging as their logging framework will have 
 access to MDC
 so that they can implement a formatter which prints out the MDC content. 
 This means we can get rid of IoSessionLogger completely and rely on 
 MdcInjectionFilter
 However, probably SLF4J won't provide a MDC-aware Formatter implementation 
 for java.util.logging, so we might need to include it
 in org.apache.mina.util package as an alternative solution.

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

Re: [AsyncWeb] Need an async client now

[Maarten Bosteels]

On Feb 11, 2008 7:37 AM, Mike Heath [EMAIL PROTECTED] wrote:

 The new logging features in SLF4J and removing IoSessionLogger were what
 was holding up an M1 release.  Where do we stand on the logging front
 right now?


see my comments on http://issues.apache.org/jira/browse/DIRMINA-513

IoSessionLogger has been removed, but I could not yet add MDC-aware
Formatter implementations because the new SLF4J hasn't been released. 

Meanwhile Ceki has published an SLF4J-API-1.5.0-M0 in maven.
I will commit the formatter asap (hopefully tonight CET) and close this
issue.

Maarten




 -Mike

 Maarten Bosteels wrote:
  On Feb 10, 2008 9:05 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote:
 
  On Feb 10, 2008, at 11:35 AM, Maarten Bosteels wrote:
 
  Hello,
 
  On Feb 10, 2008 5:28 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote:
 
  Is it ready?  You're only at M1.  What are the next milestones
  planned
  before you hit beta?
 
  The version numbering scheme is described at the bottom of
  http://mina.apache.org/downloads.html [1]
 
  IMO we should have created 2.0-M0 a few months ago. But for some
  reason we
  have been postponing it as long as there were open JIRA issues that
  could
  require an API change.
 
  According to [1] we are allowed to make API changes between M1 and M2
  but of course it's nicer for the user if we can avoid it.
 
  I just had a look at JIRA at there were more open issues than I
  thought (6)
  but no show-stoppers AFAICS.
 
  Maybe we should have a vote about cutting 2.0-M0 ?
  Maybe I'm being dense.  You mean 2.0-RC1?  When do you guys cut a
  branch to stabilize your beta?  Does it depend on the situation?
 
 
  Good question.
 
  In my very humble opinion cutting 2-0-M1 means :
  (a) creating a 2.0 branch
  and
  (b) creating a 2.0-M1 tag
 
  All further development for 2.0 would then happen on the 2.0 branch
 instead
  of on the trunk.
  Isn't that the usual way to proceed ?
 
  Maarten
 
 
 
  Regards,
  Alan
 
 
 

Re: [AsyncWeb] Need an async client now

[Maarten Bosteels]

Hello,

On Feb 10, 2008 5:28 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote:

 Is it ready?  You're only at M1.  What are the next milestones planned
 before you hit beta?


The version numbering scheme is described at the bottom of
http://mina.apache.org/downloads.html [1]

IMO we should have created 2.0-M0 a few months ago. But for some reason we
have been postponing it as long as there were open JIRA issues that could
require an API change.

According to [1] we are allowed to make API changes between M1 and M2
but of course it's nicer for the user if we can avoid it.

I just had a look at JIRA at there were more open issues than I thought (6)
but no show-stoppers AFAICS.

Maybe we should have a vote about cutting 2.0-M0 ?

Maarten




 Regards,
 Alan

 On Feb 9, 2008, at 3:56 PM, Maarten Bosteels wrote:

  Sticking to MINA 2.0 overall will be in the best interest of the
  community
 
  I couldn't agree more. I really see no reason to stick with 1.x
  In fact, I think we should 'release' MINA-2.0-M1 asap.
 
  Maarten
 
  On Feb 9, 2008 7:49 PM, Alex Karasulu [EMAIL PROTECTED] wrote:
 
  On Feb 9, 2008 12:39 PM, Alan D. Cabrera [EMAIL PROTECTED]
  wrote:
 
 
  On Feb 9, 2008, at 6:09 AM, Alex Karasulu wrote:
 
  On Feb 9, 2008 3:56 AM, Alan D. Cabrera [EMAIL PROTECTED]
  wrote:
 
  What should I use?  I prefer the API from Geronimo but I see
  that it
  doesn't get built in in Mina.  I would also prefer to use Mina 1.x
  and
  wait until Mina 2.x shakes itself out.
 
  So, I'm going to toss out the idea of releasing the new API as 1.0
  and
  we can release the new Mina 2.x based API as 2.0.  Thoughts?
 
 
  IMO I think looking ahead towards the use of MINA 2.0 is the best
  route here
  and it seems that people have already taken care of the merge.
  Perhaps
  there's some emails that you may have missed on the commits@ list
  and here.
  Mike already merged the two I think unless I'm mistaken which may
  be
  the
  case since I have been catching up as well.
 
  Well, it is in SVN.  At the moment there are two clients in there.
  The newer one does not get added to the Jar artifact per its POM
  configuration.  I really prefer the newer one from Geronimo.
 
  Oh and 1.0 whichever MINA it's based on makes sense to me but
  jumping
  to 2.0 to denote the use of MINA
  2.0 sounds good too.  I just think we should stick to MINA 2.0
  through and
  through because of the gains made therein.
 
  Only the Pope and my mother-in-law are infallible.   I think that
  MINA
  2.x rocks and will be a resounding success but I think it will
  take a
  little bit for things to shake out.  IIUC, there's still
  discussion to
  fiddle with bits of 2.0.
 
  I just want to start w/ MINA 1.x for now.  Its characteristics are
  known and it's been around the block a few times.  I am happy to do
  the scut work for a 1.0 release.
 
 
  Loved the comment about the Pope and your MIL :).  You can always
  work on
  a
  1.0 based version but we're still far from a release as well since
  the PMC
  is just mobilizing around these new projects. Also note that a MINA
  2.0release is imminent.  Furthermore there's been considerable effort
  put into
  keeping all the people interested in Asyncweb working together
  towards a
  common goal.  Sticking to MINA 2.0 overall will be in the best
  interest of
  the community.  We're seeing great synergy where core MINA folks are
  working
  closely with the AHC developers.  It's really great to see ramping
  up and
  took a bit of effort.
 
  If there are any hick-ups along the way with MINA 2.0 you have my
  word and
  I'm sure the word of others' here to resolve them immediately.
  Fragmenting
  this community into those that work on 1.0 and 2.0 based version of
  AHC
  just
  when the collaboration is ramping up would not be good.  Please don't
  presume the time frame is going to be longer when based on MINA 2.0.
  Whatever the issue may be for you we'll try our best to accommodate
  whatever
  it may be.  Is there some other problem that you have not mentioned
  which
  requires a 1.0 release besides just doing it rapidly?
 
  Thanks,
  Alex
 

Re: [AsyncWeb] Need an async client now

[Maarten Bosteels]

 Sticking to MINA 2.0 overall will be in the best interest of the community

I couldn't agree more. I really see no reason to stick with 1.x
In fact, I think we should 'release' MINA-2.0-M1 asap.

Maarten

On Feb 9, 2008 7:49 PM, Alex Karasulu [EMAIL PROTECTED] wrote:

 On Feb 9, 2008 12:39 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote:

 
  On Feb 9, 2008, at 6:09 AM, Alex Karasulu wrote:
 
   On Feb 9, 2008 3:56 AM, Alan D. Cabrera [EMAIL PROTECTED] wrote:
  
   What should I use?  I prefer the API from Geronimo but I see that it
   doesn't get built in in Mina.  I would also prefer to use Mina 1.x
   and
   wait until Mina 2.x shakes itself out.
  
   So, I'm going to toss out the idea of releasing the new API as 1.0
   and
   we can release the new Mina 2.x based API as 2.0.  Thoughts?
  
  
   IMO I think looking ahead towards the use of MINA 2.0 is the best
   route here
   and it seems that people have already taken care of the merge.
   Perhaps
   there's some emails that you may have missed on the commits@ list
   and here.
   Mike already merged the two I think unless I'm mistaken which may be
   the
   case since I have been catching up as well.
 
  Well, it is in SVN.  At the moment there are two clients in there.
  The newer one does not get added to the Jar artifact per its POM
  configuration.  I really prefer the newer one from Geronimo.
 
   Oh and 1.0 whichever MINA it's based on makes sense to me but jumping
   to 2.0 to denote the use of MINA
   2.0 sounds good too.  I just think we should stick to MINA 2.0
   through and
   through because of the gains made therein.
 
  Only the Pope and my mother-in-law are infallible.   I think that MINA
  2.x rocks and will be a resounding success but I think it will take a
  little bit for things to shake out.  IIUC, there's still discussion to
  fiddle with bits of 2.0.
 
  I just want to start w/ MINA 1.x for now.  Its characteristics are
  known and it's been around the block a few times.  I am happy to do
  the scut work for a 1.0 release.
 

 Loved the comment about the Pope and your MIL :).  You can always work on
 a
 1.0 based version but we're still far from a release as well since the PMC
 is just mobilizing around these new projects. Also note that a MINA
 2.0release is imminent.  Furthermore there's been considerable effort
 put into
 keeping all the people interested in Asyncweb working together towards a
 common goal.  Sticking to MINA 2.0 overall will be in the best interest of
 the community.  We're seeing great synergy where core MINA folks are
 working
 closely with the AHC developers.  It's really great to see ramping up and
 took a bit of effort.

 If there are any hick-ups along the way with MINA 2.0 you have my word and
 I'm sure the word of others' here to resolve them immediately.
  Fragmenting
 this community into those that work on 1.0 and 2.0 based version of AHC
 just
 when the collaboration is ramping up would not be good.  Please don't
 presume the time frame is going to be longer when based on MINA 2.0.
 Whatever the issue may be for you we'll try our best to accommodate
 whatever
 it may be.  Is there some other problem that you have not mentioned which
 requires a 1.0 release besides just doing it rapidly?

 Thanks,
 Alex

Re: use isPrimitive() instead of comparing the string to a list of primitives

[Maarten Bosteels]

Hi Stivo,

Thanks for the patch !
I will have a look at it.

Maarten

On Feb 7, 2008 9:56 AM, Stivo [EMAIL PROTECTED] wrote:


 I figured out how to make a patch so here goes.
 I ran the maven test with it, and it ran fine.

 Index: C:/Users/Stivo/workspacenew/mina
 trunk/core/src/main/java/org/apache/mina/common/IoBuffer.java
 ===
 --- C:/Users/Stivo/workspacenew/mina
 trunk/core/src/main/java/org/apache/mina/common/IoBuffer.java   (revision
 619305)
 +++ C:/Users/Stivo/workspacenew/mina
 trunk/core/src/main/java/org/apache/mina/common/IoBuffer.java   (working
 copy)
 @@ -306,20 +306,6 @@
 return newCapacity;
 }

 -protected static final SetString primitiveTypeNames = new
 HashSetString();
 -
 -static {
 -primitiveTypeNames.add(void);
 -primitiveTypeNames.add(boolean);
 -primitiveTypeNames.add(byte);
 -primitiveTypeNames.add(char);
 -primitiveTypeNames.add(short);
 -primitiveTypeNames.add(int);
 -primitiveTypeNames.add(long);
 -primitiveTypeNames.add(float);
 -primitiveTypeNames.add(double);
 -}
 -
 /**
  * Creates a new instance.  This is an empty constructor.
  */
 Index: C:/Users/Stivo/workspacenew/mina
 trunk/core/src/main/java/org/apache/mina/common/AbstractIoBuffer.java
 ===
 --- C:/Users/Stivo/workspacenew/mina
 trunk/core/src/main/java/org/apache/mina/common/AbstractIoBuffer.java
 (revision 619305)
 +++ C:/Users/Stivo/workspacenew/mina
 trunk/core/src/main/java/org/apache/mina/common/AbstractIoBuffer.java
 (working copy)
 @@ -1608,8 +1608,7 @@
 @Override
 protected void writeClassDescriptor(ObjectStreamClass
 desc)
 throws IOException {
 -String className = desc.getName();
 -if (primitiveTypeNames.contains(className)) {
 +   if (desc.forClass().isPrimitive()) {
 write(0);
 super.writeClassDescriptor(desc);
 } else {

 --
 View this message in context:
 http://www.nabble.com/use-isPrimitive%28%29-instead-of-comparing-the-string-to-a-list-of-primitives-tp15267788s16868p15329675.html
 Sent from the Apache MINA Support Forum mailing list archive at Nabble.com
 .

Re: use isPrimitive() instead of comparing the string to a list of primitives

[Maarten Bosteels]

Could you create a JIRA ticket and attach your patch to it ?
And don't forget to click the radio button that says
'Grant license to ASF for inclusion in ASF works (as per the Apache Software
License §5)'

Thanks
Maarten

On Feb 7, 2008 10:25 AM, Maarten Bosteels [EMAIL PROTECTED] wrote:

 Hi Stivo,

 Thanks for the patch !
 I will have a look at it.

 Maarten


 On Feb 7, 2008 9:56 AM, Stivo [EMAIL PROTECTED] wrote:

 
  I figured out how to make a patch so here goes.
  I ran the maven test with it, and it ran fine.
 
  Index: C:/Users/Stivo/workspacenew/mina
  trunk/core/src/main/java/org/apache/mina/common/IoBuffer.java
  ===
  --- C:/Users/Stivo/workspacenew/mina
  trunk/core/src/main/java/org/apache/mina/common/IoBuffer.java
  (revision
  619305)
  +++ C:/Users/Stivo/workspacenew/mina
  trunk/core/src/main/java/org/apache/mina/common/IoBuffer.java   (working
  copy)
  @@ -306,20 +306,6 @@
  return newCapacity;
  }
 
  -protected static final SetString primitiveTypeNames = new
  HashSetString();
  -
  -static {
  -primitiveTypeNames.add(void);
  -primitiveTypeNames.add(boolean);
  -primitiveTypeNames.add(byte);
  -primitiveTypeNames.add(char);
  -primitiveTypeNames.add(short);
  -primitiveTypeNames.add(int);
  -primitiveTypeNames.add(long);
  -primitiveTypeNames.add(float);
  -primitiveTypeNames.add(double);
  -}
  -
  /**
   * Creates a new instance.  This is an empty constructor.
   */
  Index: C:/Users/Stivo/workspacenew/mina
  trunk/core/src/main/java/org/apache/mina/common/AbstractIoBuffer.java
  ===
  --- C:/Users/Stivo/workspacenew/mina
  trunk/core/src/main/java/org/apache/mina/common/AbstractIoBuffer.java
  (revision 619305)
  +++ C:/Users/Stivo/workspacenew/mina
  trunk/core/src/main/java/org/apache/mina/common/AbstractIoBuffer.java
  (working copy)
  @@ -1608,8 +1608,7 @@
  @Override
  protected void writeClassDescriptor(ObjectStreamClass
  desc)
  throws IOException {
  -String className = desc.getName();
  -if (primitiveTypeNames.contains(className)) {
  +   if (desc.forClass().isPrimitive()) {
  write(0);
  super.writeClassDescriptor(desc);
  } else {
 
  --
  View this message in context:
  http://www.nabble.com/use-isPrimitive%28%29-instead-of-comparing-the-string-to-a-list-of-primitives-tp15267788s16868p15329675.html
  Sent from the Apache MINA Support Forum mailing list archive at
  Nabble.com.
 
 

Re: connect timeout

[Maarten Bosteels]

On Feb 5, 2008 9:17 AM, Julien Vermillard [EMAIL PROTECTED] wrote:

 On Mon, 04 Feb 2008 18:52:37 -0700
 Jeff Genender [EMAIL PROTECTED] wrote:

  great question..Im interested in this as well.
 
  Jeff
 
  Sangjin Lee wrote:
   I had a quick question on the connect timeout...
   The connect timeout supplied to connectors is in the unit of
   seconds, and it appears the minimum value you can use is 1 second (
   AbstractIoConnector.setConnectTimeout() in the case of the trunk).
   Is this by design?  I can see cases where one needs to have a
   shorter connect timeout, but it seems it is not possible today.
   One solution might be to use ConnectFuture.join() with a timeout,
   but that works only if you want to block until it times out...
  
   It also seems that this minimum timeout value is somewhat tied to
   the timeout value used in the select() loop in the connector, which
   is hard coded to be 1 second.  Would it be a good idea to support
   connect timeout values in milliseconds, and make it shorter than 1
   second?
  
   Thanks,
   Sangjin
  

 Hi,

 Apparently it's doable, the timeout value is multiplicated by 1000
 before being placed in the ConnectionRequest deadline.
 As far I understand it, it's not a big deal but an API change.


+1 for sub-second timeout values
And I think it's best to change the API now, before cutting 2.0-M1
How about adding a java.util.concurrent.TimeUnit parameter to
setConnectTimeout() ?

Maarten



 Julien