Re: [VOTE] Release Apache Mina SSHD 2.4.0

[Jeff Genender]

Did I miss this?

+1 from me.

Jeff


> On Jan 26, 2020, at 4:07 PM, Guillaume Nodet  wrote:
> 
> I think we're still missing a binding vote..., we need at least 3.
> 
> Le sam. 18 janv. 2020 à 09:02, Guillaume Nodet  a écrit :
> 
>> I've staged a release candidate:
>>  * Repo:
>> https://repository.apache.org/content/repositories/orgapachemina-1047
>>  * Distributions:
>> https://repository.apache.org/content/repositories/orgapachemina-1047/org/apache/sshd/apache-sshd/2.4.0/
>>  * Git Tag: https://github.com/apache/mina-sshd/releases/tag/sshd-2.4.0
>> 
>> Please review and vote !
>> 
>> Cheers,
>> Guillaume Nodet
>> 
>> 
> 
> -- 
> 
> Guillaume Nodet


-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

Re: [RESULT][VOTE] Move mina.a.o from CMS/svn to Hugo/git

[Jeff Genender]

Hey Emanuell,

I missed the vote… but I am +1 too…

Jeff


> On Feb 24, 2020, at 8:41 AM, Roy Lenferink  wrote:
> 
> Thanks Emmanuel! Requesting repositories is selfservice, so indeed they will 
> be available pretty 
> quick :)
> 
> I have everything available in my copy of the mina-site repository here [1] 
> 
> The repository contains the 4 needed branches:
> - asf-site => contains the generated content which will be served on mina.a.o
> - master => contains the source to generate the site
> - sshd-apidocs => as the name suggests, apidocs for sshd which will be served 
> on mina.a.o
> - mina-gen-docs => as the name suggests, the generated mina documentation 
> which will be served 
> on mina.a.o
> 
> I was not able to create a pull request since a pull request needs to be 
> targeted against an already
> existing base branch.
> 
> The simplest way (for MINA committers) to move forward is to just create an 
> initial empty commit on
> the 4 different branches against which I can create the pull request _OR_ a 
> committer can clone 
> rlenferink/mina-site [1], change its remote to the apache one [2] and push 
> the 4 branches to the 
> remote (keeping in mind this takes some time for the mina-gen-docs branch as 
> it contains the
> documentation of all previous releases).
> 
> Let me know if any help from my side is needed ;)
> 
> [1] https://github.com/rlenferink/mina-site
> [2] g...@github.com:apache/mina-site.git
> 
> On 2020/02/24 08:41:37, Emmanuel Lécharny  wrote: 
>> 
>> woot, it's fast ! (I remember a time where it took around one week to 
>> have such a repo created ...)
>> 
>> https://gitbox.apache.org/repos/asf/mina-site.git
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

Re: [VOTE] Release Apache Mina SSHD 2.5.0

[Jeff Genender]

+1

Jeff


> On Jun 18, 2020, at 1:35 AM, Emmanuel Lécharny  wrote:
> 
> My +1
> 
> - built from git and from packages
> 
> - signature checked
> 
> 
> I insist that the packages should be pushed into 
> https://dist.apache.org/repos/dist/dev/mina/sshd/ with SHA256 and SHA512 
> signatures, as Maven only creates MD5 and SHA1 signatures that are not 
> anymore valid for The ASF.
> 
> 
> Thanks !
> 
> On 16/06/2020 17:27, Guillaume Nodet wrote:
>> I've staged a release candidate:
>>   * Repo:
>> https://repository.apache.org/content/repositories/orgapachemina-1049
>>   * Distributions:
>> https://repository.apache.org/content/repositories/orgapachemina-1049/org/apache/sshd/apache-sshd/2.5.0/
>>   * Git Tag: https://github.com/apache/mina-sshd/releases/tag/sshd-2.5.0
>> 
>> Please review and vote !
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

Re: [VOTE] Release Apache Mina SSHD 2.5.1

[Jeff Genender]

+1

Jeff

> On Jun 26, 2020, at 3:16 AM, Guillaume Nodet  wrote:
> 
> I've staged a release candidate:
>  * Maven Repo:
> https://repository.apache.org/content/repositories/orgapachemina-1050
>  * Distributions: https://dist.apache.org/repos/dist/dev/mina/sshd/2.5.1/
>  * Git Tag: https://github.com/apache/mina-sshd/releases/tag/sshd-2.5.1
> 
> This release is a bug fix release for SSHD-1022
> .
> 
> Please review and vote !
> 
> -- 
> 
> Guillaume Nodet


-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

Re: [VOTE] Release Apache MINA 2.1.4

[Jeff Genender]

+1

Jeff

> On Aug 17, 2020, at 10:35 AM, Emmanuel Lécharny  wrote:
> 
> Hi !
> 
> I'm calling for a vote of Apache MINA 2.1.4 release.
> 
> It fixes the following issues :
> 
> 
> Bugs
> 
> [DIRMINA-966] - NIO Datagram messages can get duplicated when unable to 
> be sent by the underlying DatagramChannel
> [DIRMINA-1014] - SocketAcceptor doesn't unbind correctly
> [DIRMINA-1115] - Filter ProfilerTimerFilter ArithmeticException
> [DIRMINA-1123] - Receive buffer size is never set for NIO acceptor
> [DIRMINA-1126] - filterWrite in ProtocolCodecFilter can send corrupted 
> writeRequest message to the next filter
> 
> Improvements
> 
> [DIRMINA-1064] - Implement cipher suites preference flag introduced in 
> JDK 8
> [DIRMINA-1105] - SSLHandler buffer handling
> 
> A temporary tag has been created (it can be removed if the vote is not 
> approved) :
> 
> https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=8d1b14809f9277782756641fc85b6cc39b018734
>  
> 
> 
> 
> The newly approved Nexus has been used for the preparation of this
> release and all final artifacts are stored in a staging repository:
> https://repository.apache.org/content/repositories/orgapachemina-1051
> 
> 
> The distributions are available for download on :
> https://dist.apache.org/repos/dist/dev/mina/mina/2.1.4/
> 
> Let us vote :
> [ ] +1 | Release MINA 2.1.4
> [ ] ± | Abstain
> [ ] -1 | Do *NOT*   release MINA 2.1.4
> 
> Thanks !
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

Re: [VOTE] Release Apache Mina SSHD 2.7.0 (2nd try)

[Jeff Genender]

+1

Jeff


> On May 11, 2021, at 8:21 AM, Guillaume Nodet  wrote:
> 
> I've staged another release candidate built on JDK 1.8:
>  * maven repo:
> https://repository.apache.org/content/repositories/orgapachemina-1057
>  * Distributions: https://dist.apache.org/repos/dist/dev/mina/sshd/2.7.0/
>  * Git tag: https://github.com/apache/mina-sshd/releases/tag/sshd-2.7.0
> 
> This release contains a number of changes:
>  https://github.com/apache/mina-sshd/blob/master/docs/changes/2.7.0.md
> 
> Please review and vote !
> 
> -- 
> 
> Guillaume Nodet


-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

Re: [VOTE] Release Apache Mina SSHD 2.7.0 (2nd try)

[Jeff Genender]

+1

Jeff


> On May 28, 2021, at 12:27 AM, Emmanuel Lécharny  wrote:
> 
> My +1 with your key :-)
> 
> On 28/05/2021 08:17, Guillaume Nodet wrote:
>> I think we're still missing some votes...
>> Le mar. 11 mai 2021 à 16:21, Guillaume Nodet  a écrit :
>>> I've staged another release candidate built on JDK 1.8:
>>>   * maven repo:
>>> https://repository.apache.org/content/repositories/orgapachemina-1057
>>>   * Distributions: https://dist.apache.org/repos/dist/dev/mina/sshd/2.7.0/
>>>   * Git tag: https://github.com/apache/mina-sshd/releases/tag/sshd-2.7.0
>>> 
>>> This release contains a number of changes:
>>>   https://github.com/apache/mina-sshd/blob/master/docs/changes/2.7.0.md
>>> 
>>> Please review and vote !
>>> 
>>> --
>>> 
>>> Guillaume Nodet
>>> 
>>> 
> 
> -- 
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

Re: [VOTE] Mina SSHD 2.8.0

[Jeff Genender]

+1

Jeff

> On Nov 30, 2021, at 12:12 AM, Guillaume Nodet  wrote:
> 
> I've staged a release candidate at
>   https://repository.apache.org/content/repositories/orgapachemina-1061
> GIt Tag:
>  https://github.com/apache/mina-sshd/releases/tag/sshd-2.8.0
> Issues solved:
> 
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SSHD%20AND%20fixVersion%20%3D%202.8.0
> 
> Please review and vote !
> 
> Cheers
> Guillaume Nodet


-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

Re: [VOTE] Release Apache MINA 2.1.6

[Jeff Genender]

+1

Jeff


> On Feb 6, 2022, at 1:18 AM, Emmanuel Lecharny  wrote:
> 
> Hi,
> 
> This is a bug fix release for MINA.
> 
> Here is the list of fixed issues :
> 
> 
>   * [DIRMINA-1152] IoServiceStatistics introduces huge latencies
>   * [DIRMINA-1156]Inconsistent worker / idleWorker in 
> OrderedThreadPoolExecutor
> 
> It also contain some minor fixes (ignored tests being fixed, a minor
> infinite loop fixed in the Buffer toString() method if used in some
> corner case, etc)
> 
> 
> Here's the Jira link for this version if you'd like to review issues
> in more details:
> 
> https://issues.apache.org/jira/projects/DIRMINA/versions/12351317
> 
> A temporary tag has been created (it can be removed if the vote is not
> approved):
> 
> https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=a58e68216d492f78d0341aef997ad3c78275cb65
> 
> The newly approved Nexus has been used for the preparation of this
> release and all final artifacts are stored
> in a staging repository:
> https://repository.apache.org/content/repositories/orgapachemina-1065/
> 
> 
> The distributions are available for download on :
> https://dist.apache.org/repos/dist/dev/mina/mina/2.1.6/
> 
> Let us vote :
> [ ] +1 | Release MINA 2.1.6
> [ ] +/- | Abstain
> [ ] -1 | Do *NOT*  release MINA 2.1.6
> 
> Thanks !
> 
> 
> 
> -- 
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

Re: [VOTE] Release Apache MINA 2.0.23

[Jeff Genender]

+1

Jeff


> On Feb 10, 2022, at 5:03 PM, Emmanuel Lecharny  wrote:
> 
> Hi,
> 
> This is a maintenance release for MINA 2.0.
> 
> It contains many backported issues from the 2.1 and 2.2 branches.
> 
> A temporary tag has been created (it can be removed if the vote is not
> approved):
> 
> https://gitbox.apache.org/repos/asf?p=mina.git;a=commit;h=ccb577ed622490a84780f039840ddc640c6a0874
> 
> The newly approved Nexus has been used for the preparation of this
> release and all final artifacts are stored
> in a staging repository:
> https://repository.apache.org/content/repositories/orgapachemina-1066/
> 
> 
> The distributions are available for download on :
> https://dist.apache.org/repos/dist/dev/mina/mina/2.0.23/
> 
> Let us vote :
> [ ] +1 | Release MINA 2.0.23
> [ ] +/- | Abstain
> [ ] -1 | Do *NOT*  release MINA 2.0.23
> 
> Thanks !
> 
> 
> -- 
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

Re: [VOTE] Apache FtpServer 1.1.3 release

[Jeff Genender]

+1

Jeff


> On Feb 20, 2022, at 3:03 AM, Emmanuel Lécharny  wrote:
> 
> Hi,
> 
> some links were wrog (damn copy/paste...)
> 
> The distributions are available (with signatures) for download on
> 
> https://dist.apache.org/repos/dist/dev/mina/ftpserver/1.1.3/
> 
> and all final artifacts are stored in a staging repository:
> https://repository.apache.org/content/repositories/orgapachemina-1067/org/apache/ftpserver/ftpserver/1.1.3/
> 
> Thanks !
> 
> On 20/02/2022 09:48, Emmanuel Lecharny wrote:
>> Hi,
>> This is a bug fix release. This version uses the latest MINA release
>> (2.1.6), the latest Log4j version (2.17.1) and an issue with TLS 1.3
>> that wasn't enabled properly.
>> A temporary tag has been created (it can be removed if the vote is not 
>> approved)
>> The newly approved Nexus has been used for the preparation of this
>> release and all final artifacts are stored in a staging repository:
>> https://repository.apache.org/content/repositories/orgapachemina-1067/
>> The distributions are available for download on :
>> https://repository.apache.org/content/repositories/orgapachemina-004/org/apache/mina/ftpserver/1.1.3/
>> Let us vote :
>> [ ] +1 | Release Apache FtpServer 1.1.3
>> [ ] +/- | Abstain
>> [ ] -1 | Do *NOT* release Apache FtpServer 1.1.3
>> Thanks !
> 
> -- 
> *Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
> T. +33 (0)4 89 97 36 50
> P. +33 (0)6 08 33 32 61
> emmanuel.lecha...@busit.com https://www.busit.com/
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
> For additional commands, e-mail: dev-h...@mina.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

Asynchronous Http Client donation

[Jeff Genender]

Hi,

First, I want to say that I am a big fan of Mina.  For those who don't
know me (which is everyone), I am a committer on Geronimo and have had
several people ask about an async http client API to use with our NIO
clients with comet for the 2.0 Geronimo server.  We have had folks who
want to be able to do HTTP calls to 3rd party servers from servlets/web
apps to get content, and not tie up a thread while its doing its thing.
 So I decided to try to whip together an API that was similar to Commons
HttpClient, fully asynchronous, but based on Mina...and I think I have
80-90% of it completed.  It is here:

http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient

For what it's worth...it doesn't seem appropriate for Geronimo. So I
would like to donate it to Mina.  Please have a look at it and give me
feed back for if I have gone down the right path.  It can be enhanced
greatly as this is just a start, but I think it can be very useful and
become a powerful API with everyone moving to NIO.

Don't hold back any comments ;-)  I would really like to see an API like
this and I believe Mina is just perfect for this.

Please let me know what you think..and if you don't think its right for
Mina..thats ok too ;-)  But getting your feedback would be best for
me...and making this a community project is even better ;-)

Jeff

Re: Asynchronous Http Client donation

[Jeff Genender]

Simon Aquilina wrote:
> Hi,
> 
> I am sorry if this reply is not exactly what you may be expecting back.
> I am sure around here there are many experts that will have many more
> interesting replies then this one. However could you please explain to
> me (and possible others) what Asynch[ronous] Http Client is, and what
> are its advantages? If I know exactly what it is then I can imagine ways
> on how to use it :)

Sure...I would be happy to explain it.

With the movement of web containers to NIO (Ex. Jetty, Tomcat, and
AsyncWeb), they are able to handle a lot more throughput and
simultaneous connections.

For some web applications, the servlets may need to retrieve data from a
third party web service or scrape 3rd party HTML to embed in a page, or
need to grab content as a proxy, like images or ads or pdf from another
server.  In these sorts of scenarios, the NIO/Comet in the web server
would normally have a thread that is blocking when using a blocking
client API (like Commons HttpClient or Sun's HttpURLConnect) to retrieve
this data.  This could significantly throttle the throughput of the NIO
containers.  By having an Async Http Client API, the thread could be
parked and put into use for something else while the original call is
waiting for a connection or a response from the third party server.

Jeff

> 
> Thanks and Regards,
> Sim085
> 
>> From: Jeff Genender <[EMAIL PROTECTED]>
>> Reply-To: [EMAIL PROTECTED]
>> To: dev@mina.apache.org
>> Subject: Asynchronous Http Client donation
>> Date: Fri, 17 Aug 2007 20:19:07 -0600
>>
>> Hi,
>>
>> First, I want to say that I am a big fan of Mina.  For those who don't
>> know me (which is everyone), I am a committer on Geronimo and have had
>> several people ask about an async http client API to use with our NIO
>> clients with comet for the 2.0 Geronimo server.  We have had folks who
>> want to be able to do HTTP calls to 3rd party servers from servlets/web
>> apps to get content, and not tie up a thread while its doing its thing.
>>  So I decided to try to whip together an API that was similar to Commons
>> HttpClient, fully asynchronous, but based on Mina...and I think I have
>> 80-90% of it completed.  It is here:
>>
>> http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient
>>
>> For what it's worth...it doesn't seem appropriate for Geronimo. So I
>> would like to donate it to Mina.  Please have a look at it and give me
>> feed back for if I have gone down the right path.  It can be enhanced
>> greatly as this is just a start, but I think it can be very useful and
>> become a powerful API with everyone moving to NIO.
>>
>> Don't hold back any comments ;-)  I would really like to see an API like
>> this and I believe Mina is just perfect for this.
>>
>> Please let me know what you think..and if you don't think its right for
>> Mina..thats ok too ;-)  But getting your feedback would be best for
>> me...and making this a community project is even better ;-)
>>
>> Jeff
> 
> _
> Don't just search. Find. Check out the new MSN Search!
> http://search.msn.com/

Re: Asynchronous Http Client donation

[Jeff Genender]

Mark wrote:
> I will have some free time in the next week or so.  I can take the lead on
> incorporating this into the baseline, if someone wants to give me a good
> recommendation as to where to place the code.  My initial thought is to
> create a new top level project inside of the trunk.  Maybe
> "mina-asynch-httpclient" ?

+1 from a non-binding person ;-)

Jeff


> 
> 
> 
> On 8/17/07, Jeff Genender <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> First, I want to say that I am a big fan of Mina.  For those who don't
>> know me (which is everyone), I am a committer on Geronimo and have had
>> several people ask about an async http client API to use with our NIO
>> clients with comet for the 2.0 Geronimo server.  We have had folks who
>> want to be able to do HTTP calls to 3rd party servers from servlets/web
>> apps to get content, and not tie up a thread while its doing its thing.
>> So I decided to try to whip together an API that was similar to Commons
>> HttpClient, fully asynchronous, but based on Mina...and I think I have
>> 80-90% of it completed.  It is here:
>>
>> http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient
>>
>> For what it's worth...it doesn't seem appropriate for Geronimo. So I
>> would like to donate it to Mina.  Please have a look at it and give me
>> feed back for if I have gone down the right path.  It can be enhanced
>> greatly as this is just a start, but I think it can be very useful and
>> become a powerful API with everyone moving to NIO.
>>
>> Don't hold back any comments ;-)  I would really like to see an API like
>> this and I believe Mina is just perfect for this.
>>
>> Please let me know what you think..and if you don't think its right for
>> Mina..thats ok too ;-)  But getting your feedback would be best for
>> me...and making this a community project is even better ;-)
>>
>> Jeff
>>
> 
> 
> 

Re: Asynchronous Http Client donation

[Jeff Genender]

Let me know when you have moved the code over so I can start submitting
patches to it since I am developing against the Geronimo sandbox now.

Thanks,

Jeff

Mark wrote:
> I created a mina-httpclient component on the trunk.  Just working things
> out, along with an example and I will check things in.
> 
> 
> On 8/21/07, Mike Heath <[EMAIL PROTECTED]> wrote:
>> This sounds awesome!
>>
>> I would like to see this as the client part of AsyncWeb for two reasons.
>>   First it seams to be a natural fit.  Second it might give us a little
>> more incentive to finally get AsycWeb moved over to MINA.
>>
>> -Mike
>>
>> Jeff Genender wrote:
>>> Hi,
>>>
>>> First, I want to say that I am a big fan of Mina.  For those who don't
>>> know me (which is everyone), I am a committer on Geronimo and have had
>>> several people ask about an async http client API to use with our NIO
>>> clients with comet for the 2.0 Geronimo server.  We have had folks who
>>> want to be able to do HTTP calls to 3rd party servers from servlets/web
>>> apps to get content, and not tie up a thread while its doing its thing.
>>>  So I decided to try to whip together an API that was similar to Commons
>>> HttpClient, fully asynchronous, but based on Mina...and I think I have
>>> 80-90% of it completed.  It is here:
>>>
>>> http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient
>>>
>>> For what it's worth...it doesn't seem appropriate for Geronimo. So I
>>> would like to donate it to Mina.  Please have a look at it and give me
>>> feed back for if I have gone down the right path.  It can be enhanced
>>> greatly as this is just a start, but I think it can be very useful and
>>> become a powerful API with everyone moving to NIO.
>>>
>>> Don't hold back any comments ;-)  I would really like to see an API like
>>> this and I believe Mina is just perfect for this.
>>>
>>> Please let me know what you think..and if you don't think its right for
>>> Mina..thats ok too ;-)  But getting your feedback would be best for
>>> me...and making this a community project is even better ;-)
>>>
>>> Jeff
>>>
>>
> 
> 

Re: Asynchronous Http Client donation

[Jeff Genender]

Mark,

Have a look look at:

src/test/java/org/apache/ahc/AsyncHttpClientTest.java

The doConnection() is pretty much an example.  Basically, you set up an
implementation of the AHCCallback to notify you of a response, set up a
HttpRequestMessage for your URI, and then make the call to ahc.connect()
 and ahc.sendRequest(request).

However, I am probably going to get rid of the direct access to the
HttpRequestMessage and have folks just set/get on the AsyncHttpClient
object, which will act as a proxy to the HttpRequestMessage.  This will
simplify things.  I will also probably get rid of the sendRequest() and
have everything happen in the connect() method as a single async call -
again to simplify its use.

There are a few TODOs I am currently working on.

1) I am working on the HTTP/1.1 chunking (hopefully be done today).
2) Need to handle the HTTP/1.1 100 Continue (should be easy to do).
3) Auto-handle 301 Redirect.
4) Handle proxies.
5) A good timeout implementation.  Not sure whether to use the
sessionIdle() or use a concurrent timer.  Since its a single
request/response, sessionIdle() may work fine.
6) Possibly allow handling of streams for very large packets (right now
it pulls the entire response into memory - which works for 99% of the
use cases).  But it would be nice to allow people to get their data
moved in chunks.  I probably need some input on implementing this
efficiently...but I think this is the lowest priority item.
7) Finer grained control over the threading model.  Basically allow
people to tweak the thread pool or pass in their own to use.

What currently works:

A) HTTPS/SSL/HTTP submission and response
B) Cookie handling
C) Header handling
D) Parameter handling (web parameters)
E) All HTTP request types (GET, POST, etc)
D) Text and Binary responses

As for the donation's being up to Apache spec...I am already an Apache
guy (CLA already on file) and it's coming from Apache into Apache ;-)
AFICT I have all of the necessary headers are in the source - hopefully
I haven't missed anything.  We probably just need to rename the
packages, etc, to something more meaningful/appropriate to Mina.

Thanks,

Jeff

Mark wrote:
> will do.  BTW, do you have any code that I could use in the "mina-examples"
> component?  I have the code you wrote up to MINA 2.0 compliance, but I want
> to provide a sample program as well.
> 
> Thanks,
> Mark
> 
> On 8/21/07, Jeff Genender <[EMAIL PROTECTED]> wrote:
>> Let me know when you have moved the code over so I can start submitting
>> patches to it since I am developing against the Geronimo sandbox now.
>>
>> Thanks,
>>
>> Jeff
>>
>> Mark wrote:
>>> I created a mina-httpclient component on the trunk.  Just working things
>>> out, along with an example and I will check things in.
>>>
>>>
>>> On 8/21/07, Mike Heath <[EMAIL PROTECTED]> wrote:
>>>> This sounds awesome!
>>>>
>>>> I would like to see this as the client part of AsyncWeb for two
>> reasons.
>>>>   First it seams to be a natural fit.  Second it might give us a little
>>>> more incentive to finally get AsycWeb moved over to MINA.
>>>>
>>>> -Mike
>>>>
>>>> Jeff Genender wrote:
>>>>> Hi,
>>>>>
>>>>> First, I want to say that I am a big fan of Mina.  For those who don't
>>>>> know me (which is everyone), I am a committer on Geronimo and have had
>>>>> several people ask about an async http client API to use with our NIO
>>>>> clients with comet for the 2.0 Geronimo server.  We have had folks who
>>>>> want to be able to do HTTP calls to 3rd party servers from
>> servlets/web
>>>>> apps to get content, and not tie up a thread while its doing its
>> thing.
>>>>>  So I decided to try to whip together an API that was similar to
>> Commons
>>>>> HttpClient, fully asynchronous, but based on Mina...and I think I have
>>>>> 80-90% of it completed.  It is here:
>>>>>
>>>>> http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient
>>>>>
>>>>> For what it's worth...it doesn't seem appropriate for Geronimo. So I
>>>>> would like to donate it to Mina.  Please have a look at it and give me
>>>>> feed back for if I have gone down the right path.  It can be enhanced
>>>>> greatly as this is just a start, but I think it can be very useful and
>>>>> become a powerful API with everyone moving to NIO.
>>>>>
>>>>> Don't hold back any comments ;-)  I would really like to see an API
>> like
>>>>> this and I believe Mina is just perfect for this.
>>>>>
>>>>> Please let me know what you think..and if you don't think its right
>> for
>>>>> Mina..thats ok too ;-)  But getting your feedback would be best for
>>>>> me...and making this a community project is even better ;-)
>>>>>
>>>>> Jeff
>>>>>
>>>
> 
> 
> 

Re: Asynchronous Http Client donation

[Jeff Genender]

Mike,

I would concur with you on this.  I think a sub-project of its own is
good since it can be used as a standalone API (with a dependency on Mina
of course).  I would recommend that this API be a separate artifact from
asyncweb as I think we want the client to be capable of being slit off
from the server (for obvious reasons).

Jeff

Mike Heath wrote:
> I'm wondering where this project should really go.  Do we want to make
> it part of MINA (ie. put it in mina/trunk) or do we want to create a
> separate subproject that depends on MINA (ie. put it in something like
> mina/async-httpclient/trunk).
> 
> I'm concerned about the agility of MINA if we start adding protocol
> handlers to MINA itself.  What if we make a change to MINA that breaks
> one of our protocol handlers?  What if there's a bug in a protocol
> handler that doesn't affect 99.9% of MINA's user base?  Will these
> problems keep us from making releases?  If we fix a major bug in MINA
> that doesn't affect async-httpclient, do we still release a new version
> of async-httpclient with MINA because async-httpclient is part of the
> baseline MINA build?
> 
> I would rather see async-httpclient be a subproject of MINA and have it
> reside it's own directory in subversion with its own build and with its
> own examples separate from the MINA examples.
> 
> That being said, I would MUCH rather see AsyncWeb finally moved over to
> MINA as a sub-project and then make async-httpclient part of AsyncWeb.
> There's certainly going to be a lot of overlap between the two.  We
> should leverage that.
> 
> -Mike
> 
> Mark wrote:
>> I created a mina-httpclient component on the trunk.  Just working things
>> out, along with an example and I will check things in.
>>
>>
>> On 8/21/07, Mike Heath <[EMAIL PROTECTED]> wrote:
>>> This sounds awesome!
>>>
>>> I would like to see this as the client part of AsyncWeb for two reasons.
>>>   First it seams to be a natural fit.  Second it might give us a little
>>> more incentive to finally get AsycWeb moved over to MINA.
>>>
>>> -Mike
>>>
>>> Jeff Genender wrote:
>>>> Hi,
>>>>
>>>> First, I want to say that I am a big fan of Mina.  For those who don't
>>>> know me (which is everyone), I am a committer on Geronimo and have had
>>>> several people ask about an async http client API to use with our NIO
>>>> clients with comet for the 2.0 Geronimo server.  We have had folks who
>>>> want to be able to do HTTP calls to 3rd party servers from servlets/web
>>>> apps to get content, and not tie up a thread while its doing its thing.
>>>>  So I decided to try to whip together an API that was similar to
>>>> Commons
>>>> HttpClient, fully asynchronous, but based on Mina...and I think I have
>>>> 80-90% of it completed.  It is here:
>>>>
>>>> http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient
>>>>
>>>> For what it's worth...it doesn't seem appropriate for Geronimo. So I
>>>> would like to donate it to Mina.  Please have a look at it and give me
>>>> feed back for if I have gone down the right path.  It can be enhanced
>>>> greatly as this is just a start, but I think it can be very useful and
>>>> become a powerful API with everyone moving to NIO.
>>>>
>>>> Don't hold back any comments ;-)  I would really like to see an API
>>>> like
>>>> this and I believe Mina is just perfect for this.
>>>>
>>>> Please let me know what you think..and if you don't think its right for
>>>> Mina..thats ok too ;-)  But getting your feedback would be best for
>>>> me...and making this a community project is even better ;-)
>>>>
>>>> Jeff
>>>>
>>>
>>
>>

Re: Asynchronous Http Client donation

[Jeff Genender]

Agreed...if we can split the artifacts, then that is fine with me.

Jeff

Mike Heath wrote:
> Jeff Genender wrote:
>> I would concur with you on this.  I think a sub-project of its own is
>> good since it can be used as a standalone API (with a dependency on Mina
>> of course).  I would recommend that this API be a separate artifact from
>> asyncweb as I think we want the client to be capable of being slit off
>> from the server (for obvious reasons).
> 
> Certainly if you want an HTTP client, it's unlikely that you would want
> an HTTP server.  This, of course, makes sense.  I would imagine,
> however, that there are going to be a lot of similarities between the
> client and server code (header parsing, cookies support, the many
> caching options of HTTP/1.1, etc.).  That's why I was thinking making it
> part of AsyncWeb would be a good idea.  I don't think the client and
> server should be distributed in the same artifact either.  However, I
> believe there's a lot to be gained by keeping the the HTTP client and
> server close together.
> 
> WDYT?
> 
> -Mike

Re: Asynchronous Http Client donation

[Jeff Genender]

Give me just a teeny-weeny bit more time to get the chunking code
checked in and its all yours...I'll ping the list.

Jeff

Mark wrote:
> sounds good to me.  I will work this once Mike lets me know that he has
> everything checked in.
> 
> On 8/22/07, Trustin Lee <[EMAIL PROTECTED]> wrote:
>> On 8/22/07, Mike Heath <[EMAIL PROTECTED]> wrote:
>>> Mark wrote:
 Just so we are straight on terminology, what I referred to as a MINA
 component is what I think you all are calling sub-projects.  I will be
>> sure
 to get this right from now on.  These include:

 mina-example
 mina-filter-codec-netty
 mina-filter-compression
 mina-integration-jmx
 mina-integration-spring
>>>
>>> I would say that these are optional components of MINA since they are
>>> part of the MINA build and all share the same version.  When we do a
>>> MINA release we vote on, build, and distribute all of these modules and
>>> not just mina-core.  I don't think async-httpclient should be tied to
>>> this process.
>>>
>>> I think a better home for async-httpclient would be to create something
>>> like https://svn.apache.org/repos/asf/mina/async-httpclient and put
>>> 'trunk', 'tags', and 'branches' in there.  Then in trunk put a parent
>>> pom.xml that builds the 'client' and 'examples' modules.  This would
>>> make async-httpclient totally independent of the MINA release cycle.
>>>
>>> Do others see things differently?
>> We might be able to extract common codec from both server and client
>> side into a separate module and let two depend on it, resulting three
>> submodules in total:
>>
>> * mina-filter-codec-http
>> * mina-protocol-server-http
>> * mina-protocol-client-http
>>
>> wdty?
>>
>> Trustin
>> --
>> what we call human nature is actually human habit
>> --
>> http://gleamynode.net/
>> --
>> PGP Key ID: 0x0255ECA6
>>
> 
> 
> 

Re: Asynchronous Http Client donation

[Jeff Genender]

Mike and Mark,

I did my final commits.  Feel free to grab the code.  I will hold on
further development until it hits the Mina repo.  You can find it all here:

http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient/

Thanks,

Jeff

Mike Heath wrote:
> Trustin Lee wrote:
>> We might be able to extract common codec from both server and client
>> side into a separate module and let two depend on it, resulting three
>> submodules in total:
>>
>> * mina-filter-codec-http
>> * mina-protocol-server-http
>> * mina-protocol-client-http
>>
>> wdty?
>>
>> Trustin
> 
> Are you suggesting making the above sub-modules part of MINA itself?  I
> don't like this idea as stated in my previous messages.  I don't like
> tying the release of MINA to the release of HTTP protocol handlers and
> vice versa.
> 
> I very much like the idea of extracting common functionality between an
> HTTP server and HTTP client and having both the client and server depend
> on the common module.
> 
> After giving it a lot of thought, I'm of the opinion more now than ever
> that we should make async-httpclient part of AsyncWeb.  They have too
> much in common to keep them separate IMO.  There's no reason that
> AsyncWeb should be a server only project and IIRC, there were plans made
> a while ago to create a client for AsyncWeb.  Such a move would also
> give us a good incentive to finally get AsyncWeb migrated over to MINA.
> 
> WDYT?
> 
> -Mike

Re: Asynchronous Http Client donation

[Jeff Genender]

Kevin Smeltzer wrote:
> Is this a project for doing transfer through HTTP using Mina? If so it
> could be very valuable (to me anyways) :-D

Yep ;-)



> 
> On 8/27/07, Mark <[EMAIL PROTECTED]> wrote:
>> I have been moving things around, creating the 3 separate subprojects.
>> Everything is compiling and seems to be in good shape.  I posted a question
>> to the list a couple days ago about javadocs at the class level and have not
>> heard back.  Maybe your email and mine will bump this thread and someone can
>> answer my question.
>>
>> Either way, I will check in what I have tonight.  I'm on EST
>>
>> --
>> ..Cheers
>> Mark
>>
>> On 8/27/07, Jeff Genender <[EMAIL PROTECTED]> wrote:
>>> Any status on where we are at with this?  I have patches I want to start
>>> delivering ;-)
>>>
>>> Jeff
>>>
>>> Mike Heath wrote:
>>>> I don't want to hold up moving this code over.  If/when we decide to put
>>>> it on a different release schedule, moving the module over to a
>>>> 'commons' repo or something similar will be trivial.  So, for the time
>>>> being, I would be fine if we moved asynchronous http client into MINA as
>>>> a module.
>>>>
>>>> I'm eager to play with this client and I'm very eager to look into using
>>>> it to create asynchronous web service calls.
>>>>
>>>> -Mike
>>>>
>>>> Mark wrote:
>>>>> I like Trustin's three module ideas as well.  I also think Mike has a
>>>>> valid
>>>>> concern on the release schedule.  I would rather get a consensus on
>>> this
>>>>> before we move forward.
>>>>>
>>>>>
>>>>> On 8/23/07, Cameron Taggart <[EMAIL PROTECTED]> wrote:
>>>>>> I liked Trustin's three module idea:
>>>>>>
>>>>>> * mina-filter-codec-http <-- common code
>>>>>> * mina-protocol-server-http <-- asyncweb imported here
>>>>>> * mina-protocol-client-http <-- AsyncHttpClient imported here
>>>>>>
>>>>>> Can it be  decided later, after the import, whether it should be on
>>>>>> the same release cycle as MINA!?  Apache Felix has components such as
>>>>>> their "commons" on a different release schedule.  I think MINA could
>>>>>> do the same if needed.  The most important thing I think is to get the
>>>>>> code imported right now.
>>>>>>
>>>>>> Cameron
>>>>>>
>>>>>> On 8/23/07, Mark <[EMAIL PROTECTED]> wrote:
>>>>>>> based on Mike's comments, I am not sure where we want to go with all
>>>>>> this.
>>>>>>> On 8/22/07, Jeff Genender <[EMAIL PROTECTED]> wrote:
>>>>>>>> Mike and Mark,
>>>>>>>>
>>>>>>>> I did my final commits.  Feel free to grab the code.  I will hold on
>>>>>>>> further development until it hits the Mina repo.  You can find it
>>> all
>>>>>>>> here:
>>>>>>>>
>>>>>>>> http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient/
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Jeff
>>>>>>>>
>>>>>>>> Mike Heath wrote:
>>>>>>>>> Trustin Lee wrote:
>>>>>>>>>> We might be able to extract common codec from both server and
>>>>>> client
>>>>>>>>>> side into a separate module and let two depend on it, resulting
>>>>>> three
>>>>>>>>>> submodules in total:
>>>>>>>>>>
>>>>>>>>>> * mina-filter-codec-http
>>>>>>>>>> * mina-protocol-server-http
>>>>>>>>>> * mina-protocol-client-http
>>>>>>>>>>
>>>>>>>>>> wdty?
>>>>>>>>>>
>>>>>>>>>> Trustin
>>>>>>>>> Are you suggesting making the above sub-modules part of MINA
>>>>>> itself?  I
>>>>>>>>> don't like this idea as stated in my previous messages.  I don't
>>>>>> like
>>>>>>>>> tying the release of MINA to the release of HTTP protocol handlers
>>>>>> and
>>>>>>>>> vice versa.
>>>>>>>>>
>>>>>>>>> I very much like the idea of extracting common functionality
>>> between
>>>>>> an
>>>>>>>>> HTTP server and HTTP client and having both the client and server
>>>>>> depend
>>>>>>>>> on the common module.
>>>>>>>>>
>>>>>>>>> After giving it a lot of thought, I'm of the opinion more now than
>>>>>> ever
>>>>>>>>> that we should make async-httpclient part of AsyncWeb.  They have
>>>>>> too
>>>>>>>>> much in common to keep them separate IMO.  There's no reason that
>>>>>>>>> AsyncWeb should be a server only project and IIRC, there were plans
>>>>>> made
>>>>>>>>> a while ago to create a client for AsyncWeb.  Such a move would
>>> also
>>>>>>>>> give us a good incentive to finally get AsyncWeb migrated over to
>>>>>> MINA.
>>>>>>>>> WDYT?
>>>>>>>>>
>>>>>>>>> -Mike
>>>>>>>
>>>>>>> --
>>>>>>> ..Cheers
>>>>>>> Mark
>>>>>>>
>>>>>
>>>>>

Re: Asynchronous Http Client donation

[Jeff Genender]

Any status on where we are at with this?  I have patches I want to start
delivering ;-)

Jeff

Mike Heath wrote:
> I don't want to hold up moving this code over.  If/when we decide to put
> it on a different release schedule, moving the module over to a
> 'commons' repo or something similar will be trivial.  So, for the time
> being, I would be fine if we moved asynchronous http client into MINA as
> a module.
> 
> I'm eager to play with this client and I'm very eager to look into using
> it to create asynchronous web service calls.
> 
> -Mike
> 
> Mark wrote:
>> I like Trustin's three module ideas as well.  I also think Mike has a
>> valid
>> concern on the release schedule.  I would rather get a consensus on this
>> before we move forward.
>>
>>
>> On 8/23/07, Cameron Taggart <[EMAIL PROTECTED]> wrote:
>>> I liked Trustin's three module idea:
>>>
>>> * mina-filter-codec-http <-- common code
>>> * mina-protocol-server-http <-- asyncweb imported here
>>> * mina-protocol-client-http <-- AsyncHttpClient imported here
>>>
>>> Can it be  decided later, after the import, whether it should be on
>>> the same release cycle as MINA!?  Apache Felix has components such as
>>> their "commons" on a different release schedule.  I think MINA could
>>> do the same if needed.  The most important thing I think is to get the
>>> code imported right now.
>>>
>>> Cameron
>>>
>>> On 8/23/07, Mark <[EMAIL PROTECTED]> wrote:
>>>> based on Mike's comments, I am not sure where we want to go with all
>>> this.
>>>> On 8/22/07, Jeff Genender <[EMAIL PROTECTED]> wrote:
>>>>> Mike and Mark,
>>>>>
>>>>> I did my final commits.  Feel free to grab the code.  I will hold on
>>>>> further development until it hits the Mina repo.  You can find it all
>>>>> here:
>>>>>
>>>>> http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient/
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jeff
>>>>>
>>>>> Mike Heath wrote:
>>>>>> Trustin Lee wrote:
>>>>>>> We might be able to extract common codec from both server and
>>> client
>>>>>>> side into a separate module and let two depend on it, resulting
>>> three
>>>>>>> submodules in total:
>>>>>>>
>>>>>>> * mina-filter-codec-http
>>>>>>> * mina-protocol-server-http
>>>>>>> * mina-protocol-client-http
>>>>>>>
>>>>>>> wdty?
>>>>>>>
>>>>>>> Trustin
>>>>>> Are you suggesting making the above sub-modules part of MINA
>>> itself?  I
>>>>>> don't like this idea as stated in my previous messages.  I don't
>>> like
>>>>>> tying the release of MINA to the release of HTTP protocol handlers
>>> and
>>>>>> vice versa.
>>>>>>
>>>>>> I very much like the idea of extracting common functionality between
>>> an
>>>>>> HTTP server and HTTP client and having both the client and server
>>> depend
>>>>>> on the common module.
>>>>>>
>>>>>> After giving it a lot of thought, I'm of the opinion more now than
>>> ever
>>>>>> that we should make async-httpclient part of AsyncWeb.  They have
>>> too
>>>>>> much in common to keep them separate IMO.  There's no reason that
>>>>>> AsyncWeb should be a server only project and IIRC, there were plans
>>> made
>>>>>> a while ago to create a client for AsyncWeb.  Such a move would also
>>>>>> give us a good incentive to finally get AsyncWeb migrated over to
>>> MINA.
>>>>>> WDYT?
>>>>>>
>>>>>> -Mike
>>>>
>>>>
>>>> -- 
>>>> ..Cheers
>>>> Mark
>>>>
>>
>>
>>

Re: Asynchronous Http Client donation

[Jeff Genender]

Excellent!  Thanks.

Should I just open Jiras and attach my patches?

Thanks,

Jeff

Mark wrote:
> OK.  I have checked in mina-filter-codec-http, mina-protocol-client-http and
> mina-protocol-server-http into the trunk.  There is still a lot of
> commenting that needs to be done, but at least the code in in the baseline
> and people can start working it.  Please let me know what more we need from
> a code perspective.  I will work on the javadoc stuff more tonight.
> 
> One piece I am not sure about is what needs to be done in order to get the
> new sub-projects integrated into the developer directions for working on
> multiple branches in the same Eclipse workspace:
> http://mina.apache.org/developer-guide.html#DeveloperGuide-WorkingwithMultipleBranchesinOneEclipseWorkspace
> 
> 
> On 8/27/07, Mark <[EMAIL PROTECTED]> wrote:
>> I am currently working on the HTTP client piece.  Check back later in the
>> day for an update.  I will respond to this thread with further information.
>>
>>
>> --
>> ..Cheers
>> Mark
>>
>> On 8/27/07, Kevin Smeltzer <[EMAIL PROTECTED]> wrote:
>>> Nice!
>>>
>>> I'm in the latter stages ( or so I say ) of development of a massive
>>> multiplayer game that is distributed via an Applet.
>>>
>>> I have been wondering about using TCP/IP for all data transmission
>>> from client to server and vice versa, but there may be problems with
>>> people who are playing the game in an applet.
>>>
>>> Also, applets can only connect to the domain that served the page using
>>> TCP/IP.
>>>
>>> But using HTTP as a transport would hopefully bypass those two problems.
>>>
>>> And that would be awesome! :-D
>>>
>>> Kevin
>>>
>>> On 8/27/07, Jeff Genender <[EMAIL PROTECTED]> wrote:
>>>>
>>>> Kevin Smeltzer wrote:
>>>>> Is this a project for doing transfer through HTTP using Mina? If so
>>> it
>>>>> could be very valuable (to me anyways) :-D
>>>> Yep ;-)
>>>>
>>>>
>>>>
>>>>> On 8/27/07, Mark <[EMAIL PROTECTED]> wrote:
>>>>>> I have been moving things around, creating the 3 separate
>>> subprojects.
>>>>>> Everything is compiling and seems to be in good shape.  I posted a
>>> question
>>>>>> to the list a couple days ago about javadocs at the class level and
>>> have not
>>>>>> heard back.  Maybe your email and mine will bump this thread and
>>> someone can
>>>>>> answer my question.
>>>>>>
>>>>>> Either way, I will check in what I have tonight.  I'm on EST
>>>>>>
>>>>>> --
>>>>>> ..Cheers
>>>>>> Mark
>>>>>>
>>>>>> On 8/27/07, Jeff Genender <[EMAIL PROTECTED]> wrote:
>>>>>>> Any status on where we are at with this?  I have patches I want to
>>> start
>>>>>>> delivering ;-)
>>>>>>>
>>>>>>> Jeff
>>>>>>>
>>>>>>> Mike Heath wrote:
>>>>>>>> I don't want to hold up moving this code over.  If/when we decide
>>> to put
>>>>>>>> it on a different release schedule, moving the module over to a
>>>>>>>> 'commons' repo or something similar will be trivial.  So, for the
>>> time
>>>>>>>> being, I would be fine if we moved asynchronous http client into
>>> MINA as
>>>>>>>> a module.
>>>>>>>>
>>>>>>>> I'm eager to play with this client and I'm very eager to look
>>> into using
>>>>>>>> it to create asynchronous web service calls.
>>>>>>>>
>>>>>>>> -Mike
>>>>>>>>
>>>>>>>> Mark wrote:
>>>>>>>>> I like Trustin's three module ideas as well.  I also think Mike
>>> has a
>>>>>>>>> valid
>>>>>>>>> concern on the release schedule.  I would rather get a consensus
>>> on
>>>>>>> this
>>>>>>>>> before we move forward.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 8/23/07, Cameron Taggart <[EMAIL PROTECTED]> wrote:
>>>>>>

Re: Can someone provide http client example

[Jeff Genender]

Hi Ted,

A good example of how to use it is in AsyncHttpClientTest.java.

The code still needs a bit of work and will undergo a few changes as it
still has some functionality needed, but here is the gist of how to use it.

You need to create an implementation of the AsyncHttpClientCallback.

This is where you get notified of your response.  In particular, you
will be most interested in the onResponse() call.

You then create a connection, let say you are going to yahoo...

MyCallBack callback = new MyCallBack(); // This is your Callback impl
AsyncHttpClient ahc =
   new AsyncHttpClient( "http://www.yahoo.com";, callback );
ahc.connect();

Once you have made the connection, you need to set up your request for
the URI.  You can set request parameters, cookies, declare the method
type, etc (look at the HttpRequestMessage.java for all the cool stuff
you can do with it).  But keeping it simple..:

HttpRequestMessage request = new HttpRequestMessage("/index.html");

Then you send the request:

ahc.sendRequest( request );

When you receive a response, your callback should contain a
HttpResponseMessage in the OnResponse().

Let me know if that helped.

Jeff

tedc wrote:
> Dear all :
> I had seen someone have http client program of mina, but have some can give
> a example like http server. I will try to see jgenender program, and don't
> know how to use it.
> anyone can give me some advice 
> Thanks 
> Ted Chen

Re: Can someone provide http client example

[Jeff Genender]

Hi Ted,

Yep...the error is a bug on how he handle the Host header.  I opened a
JIRA and attached a patch to fix it.

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

Thanks,

Jeff

tedc wrote:
> Hi Jeff:
> Thanks for your help. Now I can send the http request to server, but I
> recevie the request error from yahoo. And how can I send the query string to
> Google.
> Thanks for your help.
> Ted 
> 
> 
> jgenender wrote:
>> Hi Ted,
>>
>> A good example of how to use it is in AsyncHttpClientTest.java.
>>
>> The code still needs a bit of work and will undergo a few changes as it
>> still has some functionality needed, but here is the gist of how to use
>> it.
>>
>> You need to create an implementation of the AsyncHttpClientCallback.
>>
>> This is where you get notified of your response.  In particular, you
>> will be most interested in the onResponse() call.
>>
>> You then create a connection, let say you are going to yahoo...
>>
>> MyCallBack callback = new MyCallBack(); // This is your Callback impl
>> AsyncHttpClient ahc =
>>new AsyncHttpClient( "http://www.yahoo.com";, callback );
>> ahc.connect();
>>
>> Once you have made the connection, you need to set up your request for
>> the URI.  You can set request parameters, cookies, declare the method
>> type, etc (look at the HttpRequestMessage.java for all the cool stuff
>> you can do with it).  But keeping it simple..:
>>
>> HttpRequestMessage request = new HttpRequestMessage("/index.html");
>>
>> Then you send the request:
>>
>> ahc.sendRequest( request );
>>
>> When you receive a response, your callback should contain a
>> HttpResponseMessage in the OnResponse().
>>
>> Let me know if that helped.
>>
>> Jeff
>>
>> tedc wrote:
>>> Dear all :
>>> I had seen someone have http client program of mina, but have some can
>>> give
>>> a example like http server. I will try to see jgenender program, and
>>> don't
>>> know how to use it.
>>> anyone can give me some advice 
>>> Thanks 
>>> Ted Chen
>>
> 

Can someone apply the patches in 2 JIRAs for http filter?

[Jeff Genender]

DIRMINA-433

DIRMINA-434

Thanks,

Jeff

Re: New name for ByteBuffer?

[Jeff Genender]

+1...renaming it would be good.  When I explain it...I have to be very
careful in saying "I mean Mina's ByteBuffer..not a regular ByteBuffer"

Jeff

Trustin Lee wrote:
> Hi folks,
> 
> It is often confusing to discriminate MINA ByteBuffer and NIO
> ByteBuffer.  Do we need renaming?  I didn't have much difficulties
> actually because most Java code doesn't use both types at the same
> time.
> 
> There was an opinion about renaming it to MinaByteBuffer, but I don't
> think it's the best name available for us.  I think DataBuffer,
> ExtendedByteBuffer, ExtendedBuffer or just Buffer might also be a
> candidate.  There's Buffer in NIO, too, but nobody uses that class
> directly.
> 
> I'd like to find the best name; short and not confusing one.  Please
> don't hesitate to respond to this message with your idea so we can
> find out the best alternative.
> 
> Trustin

Test failures on trunk?

[Jeff Genender]

I noticed the following today:

Failed tests:

testSuspendResumeReadWrite(org.apache.mina.transport.socket.nio.DatagramTrafficControlTest)

Does anyone know when that may get fixed?

Thanks,

Jeff

Re: How can I close the Client SocketConnector?

[Jeff Genender]

I have 2 patches awaiting to get applied to the 1.1 branch and 2,x that
allows you to close the SocketConnector.

Could someone please apply them?

DIRMINA-441
DIRMINA-443

Thanks,

Jeff

kanful wrote:
> I can't close  the Client SocketConnector? so I use  normal socket to devlop
> client 
> 
> 

Re: [jira] Commented: (DIRMINA-443) SocketConnection cannot be manually closed (for v2.X)

[Jeff Genender]

Can you apply DIRMINA-441 to the 1.1 branch?

Thanks,

Jeff



Maarten Bosteels (JIRA) wrote:
> [ 
> https://issues.apache.org/jira/browse/DIRMINA-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529425
>  ] 
> 
> Maarten Bosteels commented on DIRMINA-443:
> --
> 
> Thanks for the patch.
> I applied it to the trunk.
> 
> Should we also apply this to SerialConnector, DatagramConnector and 
> VmPipeConnector ?
> 
>> SocketConnection cannot be manually closed (for v2.X)
>> -
>>
>> Key: DIRMINA-443
>> URL: https://issues.apache.org/jira/browse/DIRMINA-443
>> Project: MINA
>>  Issue Type: Bug
>>  Components: Core
>>Affects Versions: 2.0.0-M1
>>Reporter: Jeff Genender
>>Assignee: Maarten Bosteels
>> Fix For: 2.0.0-M1
>>
>> Attachments: DIRMINA-443-jgenender.patch
>>
>>
>> The SocketConnection cannot be closed. Currently it will wait a certain 
>> amount of timeout as specified by the worker timeout to shut down the 
>> connection. This can result in OOM and hanging clients until the timeouts 
>> occur. Mina should allow the SocketConnection to be closed manually if the 
>> connection is known to be completed. 
> 

Re: [jira] Commented: (DIRMINA-443) SocketConnection cannot be manually closed (for v2.X)

[Jeff Genender]

Maarten Bosteels wrote:
> Jeff,
> 
> The 1.1 API is frozen.
> IMHO this is a new feature not a bug, so I think we shouldn't apply
> it to the 1.1 branch.

I think I would certainly call it a bug since the client seems to hang
under certain conditions in 1.1.2.  There are several recent emails
complaining about this, so it does seem to be an important issue.

Since 2.X is in a state of flux and won't be released for a while yet,
is there any chance a 1.1.3 can be made available and this patch as a
part of it?

Also if 1.1 is frozen, can we get a comment on the main web page stating
that?  It would be great to know the status.  If its somewhere else,
then I may have missed it ;-)

Jeff

> 
> regards,
> Maarten
> 
> 
> On 9/21/07, Jeff Genender <[EMAIL PROTECTED]> wrote:
>> Can you apply DIRMINA-441 to the 1.1 branch?
>>
>> Thanks,
>>
>> Jeff
>>
>>
>>
>> Maarten Bosteels (JIRA) wrote:
>>> [ 
>>> https://issues.apache.org/jira/browse/DIRMINA-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529425
>>>  ]
>>>
>>> Maarten Bosteels commented on DIRMINA-443:
>>> --
>>>
>>> Thanks for the patch.
>>> I applied it to the trunk.
>>>
>>> Should we also apply this to SerialConnector, DatagramConnector and 
>>> VmPipeConnector ?
>>>
>>>> SocketConnection cannot be manually closed (for v2.X)
>>>> -
>>>>
>>>> Key: DIRMINA-443
>>>> URL: https://issues.apache.org/jira/browse/DIRMINA-443
>>>> Project: MINA
>>>>  Issue Type: Bug
>>>>  Components: Core
>>>>Affects Versions: 2.0.0-M1
>>>>Reporter: Jeff Genender
>>>>Assignee: Maarten Bosteels
>>>> Fix For: 2.0.0-M1
>>>>
>>>> Attachments: DIRMINA-443-jgenender.patch
>>>>
>>>>
>>>> The SocketConnection cannot be closed. Currently it will wait a certain 
>>>> amount of timeout as specified by the worker timeout to shut down the 
>>>> connection. This can result in OOM and hanging clients until the timeouts 
>>>> occur. Mina should allow the SocketConnection to be closed manually if the 
>>>> connection is known to be completed.

Re: How can I close the Client SocketConnector?

[Jeff Genender]

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

DIRMINA-443 was already applied.

A work around to closing the client connection is to shutdown your
Executor if you used that, and then do a connector.setWorkerTimeout(0).

Jeff

kanful wrote:
> where I can get it? give me the url please! thanks
> 
> jgenender wrote:
>> I have 2 patches awaiting to get applied to the 1.1 branch and 2,x that
>> allows you to close the SocketConnector.
>>
>> Could someone please apply them?
>>
>> DIRMINA-441
>> DIRMINA-443
>>
>> Thanks,
>>
>> Jeff
>>
>> kanful wrote:
>>> I can't close  the Client SocketConnector? so I use  normal socket to
>>> devlop
>>> client 
>>>
>>>
>>
> 

Re: ASyncWeb v/s Tomcat 5.5.20 Performance issues

[Jeff Genender]

A few considerations for you...

Be sure to tweak your TCP IP parameters or you will hit a wall very
quickly with AsyncWeb.  You need to significantly up your socket queue
lengths and significantly decrease your TCP time wait.  Otherwise you
will fill your IP queue and your server will probably appear to hang for
a while waiting for the TIME_WAIT and SYN_RECV to clear.  There are
probably several changes you need to tweak your IP stack.  Google on
tuning IP parameters for your OS and you should find lots of articles on
how to.

Also be sure you have a large enough acceptCount size to be sure it will
handle the load, or you will get rejected connections.  I would tweak
the acceptCount to equal your maximum concurrent connections.

Also...something else to keep in mind...AsyncWeb is really going to
shine in concurrent connections, not necessarily transactions per
second.  This means it could handle a lot more load than a single
threaded connector on Tomcat could.  Thus speed is not necessarily a
good way to measure scalability.

Jeff

Deepak J wrote:
> Perhaps not the right forum to post these results. But just wanted your
> opinion on the tests.
> 
> S/W versions:
> Tomcat 5.5.20
> ASyncWeb 0.8.2
> JRE 1.5.0._06
> 
> Test Methodology:
> A multi thread client constructs HTTP/POST messages (headers + content). The
> size of each message is ~160KB. The client can be pointed either at Tomcat
> or at ASyncWeb server. The number of client threads and iterations per
> thread is configurable. Thus a config of thread=10 & iterations=1000 will
> result in 1 HTTP/POST.  Keep-Alive functionality is not being tested
> hence after each HTTP connection there is a call to disconnect(). A static
> counter is incremented after a 200 OK. After all client threads complete
> execution a result is printed indicating total time taken for the test,
> number of 200 OK received & total connections/sec
> The server code, which resides in the Tomcat Servlet and ASyncWeb
> stand-alone app is identical in functionality in both places. When a request
> is received the Content-Length header is fetched. Data from the InputStream
> is read in a while loop and writtern in byte chunks of size 1024 to a byte
> array output stream. Once the stream has been read, the size of the byte
> array is compared with the content-length and a log is printed if they don't
> match. On successful completion a 200 OK is returned.
> 
> Test Results:
> 
> NoThreads Iterations Tomcat 5.5.20
>
> ASyncWeb 0.8.2
> -
> 1  10 1000 Test duration = 138626 millis  
>  
> Test duration = 901996 millis
> Total Connections = 9995  
>
> Total Connections = 1
> Connections/Sec = 72  
>   
> Connections/Sec = 11
> 
> 
> 2  1002 Test duration = 2878 millis   
> 
> Test duration = 20892 millis
> Total Connections = 200   
> 
> Total Connections = 200
> Connections/Sec = 69  
>   
> Connections/Sec = 9 
> 
> 3  500   10Test duration = 41796 millis   
>   
> OutOfMemory in Server 
> Total Connections = 5000
> Connections/Sec = 119 
> -
> 
> Now I am wondering if there are tweeks needed to get better number. Should
> AsyncWeb not perform better that Tomcat's One-Thread-Per-Connection model?
> 
> 
> 

Re: HTTP Client using MINA

[Jeff Genender]

It appears HTTPClient is not NIO based, so the Mina alternative should
perform better.  However, there is the Apache httpcomponents-core that
is a part of the http components project that does appear to be NIO
based, although I don't know much about it's performance.

Jeff

Michael Grundvig wrote:
> I second that HTTPClient from Apache Commons is superb. It would be even
> better if it was written with MINA though and didn't use the Commons
> Logging absurdity.
> 
> Mike
> 
> - Original Message - From: "hezjing" <[EMAIL PROTECTED]>
> To: 
> Sent: Friday, September 21, 2007 6:45 AM
> Subject: Re: HTTP Client using MINA
> 
> 
>> Hi Siddarth
>>
>> Another alternative you may want look at, is HttpClient (see
>> http://jakarta.apache.org/httpcomponents/httpclient-3.x/).
>>
>>
>> On 9/21/07, Siddarth <[EMAIL PROTECTED]> wrote:
>>>
>>> I want to simulate an HTTP GET request , i want to write a Client
>>> programs
>>> which talks to few websites and does an http Get
>>>
>>> help appriciated
>>> -- 
>>> View this message in context:
>>> http://www.nabble.com/HTTP-Client-using-MINA-tf4493177s16868.html#a12814517
>>>
>>> Sent from the Apache MINA Support Forum mailing list archive at
>>> Nabble.com.
>>>
>>>
>>
>>
>> -- 
>>
>> Hez 
> 

Re: Asynchronous timeout/sleep/delay/etc.

[Jeff Genender]

How is the ScheduledExecutorService a blocking mechanism?

Jeff

yz wrote:
> I just started playing around with Mina, and I tried searching the archives
> for a discussion about this, but I noticed a glaring lack of any
> asynchronous scheduling of callbacks. I.e., we can't schedule a
> timeout/sleep/delay within this framework. Is this accurate? Is there some
> reason why this relatively straightforward and standard feature is not
> available in this framework?
> 
> As a workaround, it seems that we must resort to synchronous, blocking
> timeout mechanisms (e.g. ScheduledExecutorService). Is the general approach
> here to simply save the IoSession (while inside one of the IoHandler
> callbacks) and use it (a) from other threads (b) at any time in the future?
> If this is the case, meaning the IoSession never changes across the
> IoHandler callbacks, then why is IoSession continually passed back into
> those callbacks?
> 
> IoSession says it's thread-safe (I assume this implies the thread-safety of
> the reactor core as well) but the Filters may not be. How do I tell if a
> particular filter is thread-safe? In particular, I'm interested in
> LoggingFilter and ProtocolCodecFilter with ObjectSerializationCodec, but for
> these there's no mention in the docs regarding their thread-safety.
> 
> Thanks in advance for your answers.

Re: Asynchronous timeout/sleep/delay/etc.

[Jeff Genender]

yz wrote:
> It requires another thread.

It requires a thread that is dedicated to managing scheduling as a
daemon, but it certainly is not blocking anything else.  I believe this
is probably one of the components that is best suited for scheduling a
timeout as it scales incredibly well.  I have written some that handle
1000s of concurrent connections and have no issues at all.

When you send a message, you would create a Future task via the
SchedulerExecutorService in your messageSent(), with an ioSession as a
member of the Future task.  This requires nearly no overhead and has
absolutely no blocking associated with it.  If you receive a response
w/in the allotted time, you cancel the timeout.  If not, your task
fires, and you can close the connection or do other actions.  If you
expect many many connections, you can use a thread pool to handle the
firing of the tasks.

If using a scheduler is not working for you, then you could make use of
the session idler, but then you still are using an internal thread that
is monitoring the idling time (which happens anyways), as a daemon.  You
are not going to get around something that polls something else, its the
nature of the IO beast in just about any programming language.

In any case, I do not see any reason why a ScheduledExecutorService is a
bad thing.

Jeff

> 
> 
> jgenender wrote:
>> How is the ScheduledExecutorService a blocking mechanism?
>>
>> Jeff
>>
>> yz wrote:
>>> I just started playing around with Mina, and I tried searching the
>>> archives
>>> for a discussion about this, but I noticed a glaring lack of any
>>> asynchronous scheduling of callbacks. I.e., we can't schedule a
>>> timeout/sleep/delay within this framework. Is this accurate? Is there
>>> some
>>> reason why this relatively straightforward and standard feature is not
>>> available in this framework?
>>>
>>> As a workaround, it seems that we must resort to synchronous, blocking
>>> timeout mechanisms (e.g. ScheduledExecutorService). Is the general
>>> approach
>>> here to simply save the IoSession (while inside one of the IoHandler
>>> callbacks) and use it (a) from other threads (b) at any time in the
>>> future?
>>> If this is the case, meaning the IoSession never changes across the
>>> IoHandler callbacks, then why is IoSession continually passed back into
>>> those callbacks?
>>>
>>> IoSession says it's thread-safe (I assume this implies the thread-safety
>>> of
>>> the reactor core as well) but the Filters may not be. How do I tell if a
>>> particular filter is thread-safe? In particular, I'm interested in
>>> LoggingFilter and ProtocolCodecFilter with ObjectSerializationCodec, but
>>> for
>>> these there's no mention in the docs regarding their thread-safety.
>>>
>>> Thanks in advance for your answers.
>>
> 

Re: [VOTE] Import AsyncWeb from Safehaus to MINA

[Jeff Genender]

non-binding +1

Jeff

Trustin Lee wrote:
> Hi,
> 
> There has been enormous amount of requests about importing AsyncWeb
> under MINA PMC.  I must admit that I was too lazy to deal with legal
> issues even after the proper software grant for AsyncWeb has been
> received.
> 
> Now, I'd like to fire the vote for importing AsyncWeb under Apache MINA PMC.
> 
> AsyncWeb is currently located at:
> * https://svn.safehaus.org/repos/asyncweb/trunk/
> 
> If the vote passes, I will fill out the incubation paperwork at:
> * http://incubator.apache.org/ip-clearance/index.html
> 
> And we would then import AsyncWeb under our sandbox at:
> * https://svn.apache.org/repos/asf/mina/sandbox/asyncweb
> 
> [ ]: +1, import
> [ ]: 0, abstain
> [ ]: -1, don't import
> 
> Cheers,
> Trustin Lee

[Fwd: Call for Papers Opens for ApacheCon Europe 2008]

[Jeff Genender]

Would anyone mind if I submitted a preso on Mina for this event?

Jeff
--- Begin Message ---
Call for Papers Opens for ApacheCon Europe 2008

The Apache Software Foundation (ASF) invites submissions to its official
conference, ApacheCon Europe 2008. To be held 7 April through 11 April,
2008 at the new Mövenpick Hotel Amsterdam City Centre. ApacheCon serves
as a forum for showcasing the ASF's latest developments, including its
projects, membership, and community. Offering unparalleled educational
opportunities, with dedicated presentations, hands-on trainings, and
sessions that address core technology, development, business/marketing,
and licensing issues in Open Source.

The conference program includes competitively selected presentations,
trainings/workshops, and a small number of invited speakers. All sessions
undergo a peer review process by the ApacheCon Conference Planning team.

With the great success of ApacheCon Europe 2007, we are excited to
return to Amsterdam in 2008. And we are proud to announce that we are
going to intensify and deepen the pre-conference trainings by offering
several 2-day trainings and each training session will have certifications
of completion for those to fulfill all the requirements of the training.

The ASF comprises some of the most active and recognized developers in
the Open Source community. By bringing together the pioneers, developers,
and users of flagship Open Source technologies, ApacheCon provides an
influential platform for dialogue, between the speaker and the audience,
between project contributors and the community at large, traversing a
wide range of ideas, expertise, and personalities.

ApacheCon welcomes submissions from like-minded delegates across many
fields, geographic locations, and areas of development. Please note you
do not have to be a member or committer with ASF to submit a proposal.
The unique nature of the Apache community lends itself to creating a
conference content that is not only the best of Open Source but cutting
edge as well.

Conference Themes and Topics

 * Apache HTTP server topics such as installation, configuration, and
   migration
 * ASF-wide projects such as, Jakarta, Tomcat, Maven, Geronimo, Harmony,
   Lucene, SpamAssassin, Portals, and Web Services
 * Scripting languages and dynamic content such as Java, Perl, Python,
   Ruby, XSL, and PHP
 * Security and e-commerce
 * Performance tuning, load balancing and high availability
 * New technologies and broader initiatives such as Web Services and
   Web 2.0
 * ASF-Incubated projects such as Abdera, CXF, and Qpid
 * Case studies and industry profiles demonstrating the use of Apache
   software
 * Open source community and business models, legal and marketing issues

NOTE: Marketing-oriented submissions aimed at promoting specific 
organizations or products will not be accepted.


Submission Guidelines

Submissions must include title; speaker(s) name(s) with affiliation and
email address; format (Training vs. General Session) and duration
1-hour general session, or half-, full-day, or two-day training);
intended audience and maximum number of participants (Trainings only);
expertise level (beginner to advanced); background knowledge expected of
the participants (Trainings only); a brief summary (50 words or less);
full description including abstract and objectives (200 words or less);
and speaker bio(s) (100 words or less).

Types of Presentations: Trainings and Workshops, General Sessions, Case
Studies and Industry Profiles.

Speakers whose proposals are accepted have registration fees waived,
reasonable travel and part of their lodging expenses paid.


Important Dates

Proposal submission deadline:   Friday, 26 October, 2007
Notification of acceptance: Friday, 23 November, 2007
Materials for Web site: Friday, 7 March, 2008
Materials for Trainings:Friday, 22 March, 2008
Conference Date:Monday to Friday, 7-11 April 2008
Trainings:  Monday and Tuesday, 7+8 April, 2008
General Sessions:   Wednesday to Friday, 9-11 April, 2008


To submit your completed proposal, please log on to the
ApacheCon CFP system: http://www.apachecon.com/html/login.html

If you are not yet subscribed to the ApacheCon announcement mailing
list, send an email message to [EMAIL PROTECTED]


About ApacheCon Europe 2008

ApacheCon is co-produced by the Apache Software Foundation and Stone
Circle Productions. The ApacheCon Planning team comprises ASF Members
from all over the world working on a wholly-volunteer basis.
For more information, visit http://www.apachecon.com/ or the
ApacheCon Europe Web site at http://www.eu.apachecon.com/.

-- 
ApacheCon Planning Team
info at apachecon.com
--- End Message ---

Re: [VOTE] New name for org.apache.mina.common.ByteBuffer

[Jeff Genender]

[X]: MinaByteBuffer

Trustin Lee wrote:
> Hi community,
> 
> We discussed about renaming org.apache.mina.common.ByteBuffer to
> something else because it makes many people confuse from NIO
> ByteBuffer.  Many names were suggested, and it seems like we didn't
> reach to the consensus, so here goes the vote.
> 
> Please refer to the following archive page to get some help for
> reconsidering your decision before you vote:
> 
> http://www.nabble.com/New-name-for-ByteBuffer--tf4471037s16868.html
> 
> [ ]: Buffer
> [ ]: ByteBuffer
> [ ]: DataBuffer
> [ ]: ExtendedBuffer
> [ ]: ExtendedByteBuffer
> [ ]: IoBuffer
> [ ]: IoDataBuffer
> [ ]: MinaBuffer
> [ ]: MinaByteBuffer
> [ ]: OctetBuffer
> 
> Cheers,
> Trustin

Re: [VOTE] Release Apache MINA 1.0.6 and 1.1.3

[Jeff Genender]

non-binding +1

Trustin Lee wrote:
> Hi everyone,
> 
> I feel like it's time to roll out a new MINA release - 1.0.6 and
> 1.1.3, again with all the same fixes:
> 
> https://issues.apache.org/jira/browse/DIRMINA?report=com.atlassian.jira.plugin.system.project:roadmap-panel
> 
> The snapshot of the distribution can be found here:
> 
> http://people.apache.org/~trustin/snapshot/
> 
> Please feel free to test them and don't hesitate to cast -1 if
> something is wrong with the distribution.
> 
> [ ]: +1, Release.
> [ ]: 0, Abstain.
> [ ]: -1, Don't release.
> 
> Cheers,
> Trustin

Re: poll: which logging framework are you using

[Jeff Genender]

[X] slf4j-simple

Maarten Bosteels wrote:
> It would be interesting to know which logging framework your MINA
> applications are using.
> 
> [ ] log4j
> [ ] logback
> [ ] java.util.logging
> [ ] slf4j-simple
> [ ] slf4j-nop
> [ ] x4juli
> [ ] other (please specify)
> 
> Please, check all that apply.
> 
> Thanks,
> Maarten

Re: poll: which logging framework are you using

[Jeff Genender]

Yeah actually, thats probably more what I use too ;-)

Alex Karasulu wrote:
> On 9/28/07, Jeff Genender <[EMAIL PROTECTED]> wrote:
>> [X] slf4j-simple
>>> [X] other (please specify)
> 
> log4j via SLF4J binding.
> 
> Alex
> 

Re: MINA TCP/IP server clustering

[Jeff Genender]

I wrote an implementation of GCache (Geronimo Cache) that is in the
Geronimo sandbox.  Its a clustering implementation based on Mina.  Its
nto complete yet, but it gives you an idea.

It is not JVM level, since it API based.  If you are looking for an open
source impl for a JVM based clustering container, have a look at Terracotta.

Jeff

Kumaran Arul wrote:
> Hi 
> 
> 
> Has anyone got any experience with clustering MINA servers at a JVM
> level? 
> 
> How can we replicate IoSessions? Would Terracotta be a good choice?
> 
> Any lead or tips will be greatly appreciated?
> 
> 
> 
> Regards
> Arul
> 
> 
> 
> 
> ***
> CAUTION: This email and files included in its transmission 
> are solely intended for the use of the addressee(s) and may 
> contain information that is confidential and privileged. 
> If you receive this email in error, please advise us 
> immediately and delete it without copying the contents 
> contained within. Woolworths Limited (including its group 
> of companies) do not accept liability for the views 
> expressed within or the consequences of any computer 
> viruses that may be transmitted with this email. The 
> contents are also subject to copyright. No part of it 
> should be reproduced, adapted or transmitted without the 
> written consent of the copyright owner.
> ***

Re: mina-protocol-http-client, AsyncWeb and Jakarta HttpComponents

[Jeff Genender]

Trustin Lee wrote:
> 2) I also think mina-protocol-http-client module needs more work to
> provide enough features to compare with existing HTTP client libraries
> such as Jakarta HttpComponents, so moving it into sandbox might be a
> better solution considering that we are going to release MINA 2.0.0-M1
> soon and we don't want to release unfinished module.  It also might be
> the best idea to cooperate with HttpComponents team to make our
> current HTTP codec (i.e. mina-filter-codec-http) and mina-core plug
> into HttpComponents NIO extension very easily.  I'd like to know what
> the HttpComponents team think about this issue.

Trustin, I have a lot more code to contribute in this area as it is
currently here:

http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient

This version contains authentication for Basic, Digest, and NTLM and is
much more robust.

I am currently working on connection reuse and caching and pooling for
those HTTP/1.1 connections that support keep-alives.  I am also working
on allowing the NIO socket level attributes to be set as well as client
SSL certificate authentication and Proxy Auth capabilities.

Jeff


> 
> Trustin

Re: mina-protocol-http-client, AsyncWeb and Jakarta HttpComponents

[Jeff Genender]

Whoops and forgot to mention...this version also has response timeouts
working as well.

Jeff

Jeff Genender wrote:
> 
> Trustin Lee wrote:
>> 2) I also think mina-protocol-http-client module needs more work to
>> provide enough features to compare with existing HTTP client libraries
>> such as Jakarta HttpComponents, so moving it into sandbox might be a
>> better solution considering that we are going to release MINA 2.0.0-M1
>> soon and we don't want to release unfinished module.  It also might be
>> the best idea to cooperate with HttpComponents team to make our
>> current HTTP codec (i.e. mina-filter-codec-http) and mina-core plug
>> into HttpComponents NIO extension very easily.  I'd like to know what
>> the HttpComponents team think about this issue.
> 
> Trustin, I have a lot more code to contribute in this area as it is
> currently here:
> 
> http://svn.apache.org/repos/asf/geronimo/sandbox/AsyncHttpClient
> 
> This version contains authentication for Basic, Digest, and NTLM and is
> much more robust.
> 
> I am currently working on connection reuse and caching and pooling for
> those HTTP/1.1 connections that support keep-alives.  I am also working
> on allowing the NIO socket level attributes to be set as well as client
> SSL certificate authentication and Proxy Auth capabilities.
> 
> Jeff
> 
> 
>> Trustin

Re: AsyncHttpClient with no content-length header

[Jeff Genender]

Yes, please open a JIRA on this.  According to the HTTP spec, anything
with content should have a content line.  However, there does appear to
be a site that is not compliant (http://www.toptable.co.uk/) and
probably more... thus we could fall back to reading until there is no
more data.  However, this concerns me as a possible buffer/memory
problem (it would then be easy to crash a Mina client).  Anyone have an
opinion on this?

Jeff

Vishal_Jain wrote:
> Is there a JIRA id for this issue ? 
> or any workarounds ?
> 
> vishal
> 
> 
> berdim99 wrote:
>> Hi.
>> It seems that AsyncHttpClient fails to decode a web page in which the
>> web-server doesn't send a content-length header.
>> What happens is that the callback is called with a null content, after
>> which the decoder throws an exception because it thinks that the rest of
>> the incoming data are of a new HTTP response (but they are actually the
>> previous response content).
>> (Such web site is http://www.toptable.co.uk/).
>>
>> Any help is appreciated.
>> Micha.
>>
> 

Re: [New Committer] Everyone let's give a warm welcome to Jeff Genender

[Jeff Genender]

Thank you and I am honored. ;-)

I am a big fan of Mina and have been for quite a while and am excited to
step up and help out.

About me...I am a Apache junkie of sorts as I am a committer on
Geronimo, OpenEJB, ServiceMix, and CXF.  more or less a Java dude (Ill
bet ya couldn't tell).

Thanks again!

Jeff

Alex Karasulu wrote:
> Hi all,
> 
> We have a new committer, Jeff Genender,  who's a committer other projects
> here at the ASF and a member of the foundation as well.  He's great guy and
> has been working on some of the http client code and is pretty excited about
> MINA ... let me stop putting words in his mouth though.  Jeff go ahead and
> tell us about yourself if you have a minute.
> 
> Welcome!
> Alex
> 

AbstractIoSession and final qualifiers

[Jeff Genender]

Hey guys,

I was hoping to see if we could discuss some of the "final" qualifiers
on some of the methods in the AbstractIOSession.  The reason I ask is it
would be cool to be able to override some of the methods such as:

public WriteFuture write(Object message)
public final int getScheduledWriteMessages()

To be able to write MockObjects for unit tests of code.  Any thoughts on
making these protected instead of final?

Thanks,

Jeff

Re: AbstractIoSession and final qualifiers

[Jeff Genender]

I like it (the assert) ;-)

But I am not sure about having a completely different
AbstractIOMockSession since we would then be copying code to a certain
degree. I think it would just be cleaner to have the methods protected
so there is no need for code duplication ;-)

What do *you* think? ;-)

Jeff


Emmanuel Lecharny wrote:
> Jeff Genender wrote:
>> Hey guys,
>>
>> I was hoping to see if we could discuss some of the "final" qualifiers
>> on some of the methods in the AbstractIOSession.  The reason I ask is it
>> would be cool to be able to override some of the methods such as:
>>
>> public WriteFuture write(Object message)
>> public final int getScheduledWriteMessages()
>>
>> To be able to write MockObjects for unit tests of code.  Any thoughts on
>> making these protected instead of final?
>>
>> Thanks,
>>
>> Jeff
>>
>>   
> Hi,
> 
> makes sense to me... Or we may have a AbstractMockIoSession implementing
> the IoSession interface, for unit tests ?
> 
> While looking at the abstract class, I found some methods with this kind
> of code :
> 
>public final WriteFuture write(Object message, SocketAddress
> remoteAddress) {
>if (message == null) {
>throw new NullPointerException("message");
>}
>...
> 
> Wouldn't be a perfect case for an assert ? Like :
> 
>public final WriteFuture write(Object message, SocketAddress
> remoteAddress) {
>assert message != null : "Null messages are not allowed";
>...
> 
> wdyt ?
> 
> 
> 

Re: AbstractIoSession and final qualifiers

[Jeff Genender]

I agree...this makes sense...Filter is the way to go.

Jeff

Trustin Lee wrote:
> Alternatively, we could add a protected method in AbstractIoSession
> and make write() method to call it before returning.  However, it is
> essentially the same with adding an IoFilter IMHO.
> 
> The implementation of IoSession and IoFilterChain is not so trivial so
> creating another mock object is a kind of huge task so we will finally
> have a lot of duplicated code there, so I think it is somewhat
> difficult to create a separate mock object; I already tried to do that
> and gave up. :)
> 
> Trustin
> 
> On Dec 27, 2007 10:48 AM, Trustin Lee <[EMAIL PROTECTED]> wrote:
>> Hi Jeff and Emmanuel,
>>
>> You can add some hook for IoSession.write() by inserting an IoFilter,
>> so I am not sure about removing the final modifier from write().
>>
>> Overriding getScheduledMessages and getScheduledBytes makes sense
>> though because they will always be 0 because messageSent event will be
>> always fired immediately.
>>
>> WDYT?
>>
>> Trustin
>>
>>
>> On Dec 27, 2007 10:21 AM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
>>> Jeff Genender wrote:
>>>> What do *you* think? ;-)
>>>>
>>> Beside the assert, which was a side effect of my quick glance at the
>>> method you want to override, I think that dooming the final is sane.
>>>
>>> If someone needs to protect this method, then the best solution would be
>>> to define a super class with final methods calling the AbstractIoSession
>>> non final methods.
>>>
>>> Another solution (puke) would be to remove the
>>> public/protected/private qualifier, and to add a MockIoSession in the
>>> same package. Not very elegant, but does the job too...
>>>
>>> There are always tradeoff when you want to thoroughly unit-test some
>>> code. When it comes to an API, it seems impossible to avoid those
>>> tradeoff, IMHO.
>>>
>>> Any other opinion ? Trustin ? Julien ?
>>>
>>>> Jeff
>>>>
>>>>
>>>> Emmanuel Lecharny wrote:
>>>>
>>>>> Jeff Genender wrote:
>>>>>
>>>>>> Hey guys,
>>>>>>
>>>>>> I was hoping to see if we could discuss some of the "final" qualifiers
>>>>>> on some of the methods in the AbstractIOSession.  The reason I ask is it
>>>>>> would be cool to be able to override some of the methods such as:
>>>>>>
>>>>>> public WriteFuture write(Object message)
>>>>>> public final int getScheduledWriteMessages()
>>>>>>
>>>>>> To be able to write MockObjects for unit tests of code.  Any thoughts on
>>>>>> making these protected instead of final?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Jeff
>>>>>>
>>>>>>
>>>>>>
>>>>> Hi,
>>>>>
>>>>> makes sense to me... Or we may have a AbstractMockIoSession implementing
>>>>> the IoSession interface, for unit tests ?
>>>>>
>>>>> While looking at the abstract class, I found some methods with this kind
>>>>> of code :
>>>>>
>>>>>public final WriteFuture write(Object message, SocketAddress
>>>>> remoteAddress) {
>>>>>if (message == null) {
>>>>>throw new NullPointerException("message");
>>>>>}
>>>>>...
>>>>>
>>>>> Wouldn't be a perfect case for an assert ? Like :
>>>>>
>>>>>public final WriteFuture write(Object message, SocketAddress
>>>>> remoteAddress) {
>>>>>assert message != null : "Null messages are not allowed";
>>>>>...
>>>>>
>>>>> wdyt ?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> --
>>> cordialement, regards,
>>> Emmanuel Lécharny
>>> www.iktek.com
>>> directory.apache.org
>>>
>>>
>>>
>>
>>
>> --
>> what we call human nature is actually human habit
>> --
>> http://gleamynode.net/
>> --
>> PGP Key ID: 0x0255ECA6
>>
> 
> 
> 

Re: AbstractIoSession and final qualifiers

[Jeff Genender]

Trustin (and others)...so how about these changes and additions to the
AbstractIoSession?  This will allow the scheduledBytes/messages to be
overriden, and also allow someone to set them.

Index: core/src/main/java/org/apache/mina/common/AbstractIoSession.java
===
--- core/src/main/java/org/apache/mina/common/AbstractIoSession.java
(revision 607135)
+++ core/src/main/java/org/apache/mina/common/AbstractIoSession.java
(working copy)
@@ -488,14 +488,22 @@
 lastThroughputCalculationTime = currentTime;
 }

-public final long getScheduledWriteBytes() {
+public long getScheduledWriteBytes() {
 return scheduledWriteBytes.get();
 }

-public final int getScheduledWriteMessages() {
+public int getScheduledWriteMessages() {
 return scheduledWriteMessages.get();
 }

+public void setScheduledWriteBytes(long byteCount){
+scheduledWriteBytes.set(byteCount);
+}
+
+public void setScheduledWriteMessages(int messages) {
+scheduledWriteMessages.set(messages);
+}
+
 protected final void increaseReadBytes(long increment, long
currentTime) {
 if (increment <= 0) {
 return;


Thanks,

Jeff

Trustin Lee wrote:
> Hi Jeff and Emmanuel,
> 
> You can add some hook for IoSession.write() by inserting an IoFilter,
> so I am not sure about removing the final modifier from write().
> 
> Overriding getScheduledMessages and getScheduledBytes makes sense
> though because they will always be 0 because messageSent event will be
> always fired immediately.
> 
> WDYT?
> 
> Trustin
> 
> On Dec 27, 2007 10:21 AM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
>> Jeff Genender wrote:
>>> What do *you* think? ;-)
>>>
>> Beside the assert, which was a side effect of my quick glance at the
>> method you want to override, I think that dooming the final is sane.
>>
>> If someone needs to protect this method, then the best solution would be
>> to define a super class with final methods calling the AbstractIoSession
>> non final methods.
>>
>> Another solution (puke) would be to remove the
>> public/protected/private qualifier, and to add a MockIoSession in the
>> same package. Not very elegant, but does the job too...
>>
>> There are always tradeoff when you want to thoroughly unit-test some
>> code. When it comes to an API, it seems impossible to avoid those
>> tradeoff, IMHO.
>>
>> Any other opinion ? Trustin ? Julien ?
>>
>>> Jeff
>>>
>>>
>>> Emmanuel Lecharny wrote:
>>>
>>>> Jeff Genender wrote:
>>>>
>>>>> Hey guys,
>>>>>
>>>>> I was hoping to see if we could discuss some of the "final" qualifiers
>>>>> on some of the methods in the AbstractIOSession.  The reason I ask is it
>>>>> would be cool to be able to override some of the methods such as:
>>>>>
>>>>> public WriteFuture write(Object message)
>>>>> public final int getScheduledWriteMessages()
>>>>>
>>>>> To be able to write MockObjects for unit tests of code.  Any thoughts on
>>>>> making these protected instead of final?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jeff
>>>>>
>>>>>
>>>>>
>>>> Hi,
>>>>
>>>> makes sense to me... Or we may have a AbstractMockIoSession implementing
>>>> the IoSession interface, for unit tests ?
>>>>
>>>> While looking at the abstract class, I found some methods with this kind
>>>> of code :
>>>>
>>>>public final WriteFuture write(Object message, SocketAddress
>>>> remoteAddress) {
>>>>if (message == null) {
>>>>throw new NullPointerException("message");
>>>>}
>>>>...
>>>>
>>>> Wouldn't be a perfect case for an assert ? Like :
>>>>
>>>>public final WriteFuture write(Object message, SocketAddress
>>>> remoteAddress) {
>>>>assert message != null : "Null messages are not allowed";
>>>>...
>>>>
>>>> wdyt ?
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> --
>> cordialement, regards,
>> Emmanuel Lécharny
>> www.iktek.com
>> directory.apache.org
>>
>>
>>
> 
> 
> 

Re: AbstractIoSession and final qualifiers

[Jeff Genender]

Yep...agreed...how is this?

Index: core/src/main/java/org/apache/mina/common/AbstractIoSession.java
===
--- core/src/main/java/org/apache/mina/common/AbstractIoSession.java
(revision 607135)
+++ core/src/main/java/org/apache/mina/common/AbstractIoSession.java
(working copy)
@@ -496,6 +496,14 @@
 return scheduledWriteMessages.get();
 }

+protected void setScheduledWriteBytes(long byteCount){
+scheduledWriteBytes.set(byteCount);
+}
+
+protected void setScheduledWriteMessages(int messages) {
+scheduledWriteMessages.set(messages);
+}
+
 protected final void increaseReadBytes(long increment, long
currentTime) {
 if (increment <= 0) {
 return;



Trustin Lee wrote:
> Hi Jeff,
> 
> Do we need to remove the final modifier if we are going to provide
> setters?  And assuming you are using DummySession as a mock object,
> I'd suggest making AbstractIoSession.setScheduled...(...) protected
> and make them public in DummySession.  WDYT?
> 
> Cheers,
> Trustin
> 
> On Dec 28, 2007 8:19 AM, Jeff Genender <[EMAIL PROTECTED]> wrote:
>> Trustin (and others)...so how about these changes and additions to the
>> AbstractIoSession?  This will allow the scheduledBytes/messages to be
>> overriden, and also allow someone to set them.
>>
>> Index: core/src/main/java/org/apache/mina/common/AbstractIoSession.java
>> ===
>> --- core/src/main/java/org/apache/mina/common/AbstractIoSession.java
>> (revision 607135)
>> +++ core/src/main/java/org/apache/mina/common/AbstractIoSession.java
>> (working copy)
>> @@ -488,14 +488,22 @@
>>  lastThroughputCalculationTime = currentTime;
>>  }
>>
>> -public final long getScheduledWriteBytes() {
>> +public long getScheduledWriteBytes() {
>>  return scheduledWriteBytes.get();
>>  }
>>
>> -public final int getScheduledWriteMessages() {
>> +public int getScheduledWriteMessages() {
>>  return scheduledWriteMessages.get();
>>  }
>>
>> +public void setScheduledWriteBytes(long byteCount){
>> +scheduledWriteBytes.set(byteCount);
>> +}
>> +
>> +public void setScheduledWriteMessages(int messages) {
>> +scheduledWriteMessages.set(messages);
>> +}
>> +
>>  protected final void increaseReadBytes(long increment, long
>> currentTime) {
>>  if (increment <= 0) {
>>  return;
>>
>>
>> Thanks,
>>
>> Jeff
>>
>>
>> Trustin Lee wrote:
>>> Hi Jeff and Emmanuel,
>>>
>>> You can add some hook for IoSession.write() by inserting an IoFilter,
>>> so I am not sure about removing the final modifier from write().
>>>
>>> Overriding getScheduledMessages and getScheduledBytes makes sense
>>> though because they will always be 0 because messageSent event will be
>>> always fired immediately.
>>>
>>> WDYT?
>>>
>>> Trustin
>>>
>>> On Dec 27, 2007 10:21 AM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
>>>> Jeff Genender wrote:
>>>>> What do *you* think? ;-)
>>>>>
>>>> Beside the assert, which was a side effect of my quick glance at the
>>>> method you want to override, I think that dooming the final is sane.
>>>>
>>>> If someone needs to protect this method, then the best solution would be
>>>> to define a super class with final methods calling the AbstractIoSession
>>>> non final methods.
>>>>
>>>> Another solution (puke) would be to remove the
>>>> public/protected/private qualifier, and to add a MockIoSession in the
>>>> same package. Not very elegant, but does the job too...
>>>>
>>>> There are always tradeoff when you want to thoroughly unit-test some
>>>> code. When it comes to an API, it seems impossible to avoid those
>>>> tradeoff, IMHO.
>>>>
>>>> Any other opinion ? Trustin ? Julien ?
>>>>
>>>>> Jeff
>>>>>
>>>>>
>>>>> Emmanuel Lecharny wrote:
>>>>>
>>>>>> Jeff Genender wrote:
>>>>>>
>>>>>>> Hey guys,
>>>>>>>
>>>>>>> I was hoping to see if we could discuss some of the "final" qualifiers
>>>>>>> on some of the

Re: Question regards AsyncWeb

[Jeff Genender]

James,

I believe it is here:

https://svn.apache.org/repos/asf/mina/sandbox/asyncweb/

Jeff




James Apfel wrote:
> Hi all,
> 
> where's the current AsyncWeb code being hosted that compiles with MINA trunk?
> 
> It be also awesome if somebody could give me some hints regards
> AsyncWeb and MINA 1.1.x. The latest release that's offered on
> safehaus.org seems to be built for older versions of MINA?
> 
> Thanks
> James

Re: Happy new year !

[Jeff Genender]

Emmanuel Lecharny wrote:
> Hi Ladies and Gentlemen,
> 
> I wish you an Happy New Year ! I hope that 2008 will be way better than
> 2007, with less wars, less bugs and less cholesterol :)

Hmmm...with you being from France...that cholesterol thing may be a
tough one ;-)

Happy new year to you guys too and am glad to be helping out.

Jeff

Re: [DISCUSS] Time to move AsyncHttpClient out of Sandbox

[Jeff Genender]

Trustin Lee wrote:
> AsyncWeb and Jeff's AsyncHttpClient are different projects.  Anyways,
> Jeff is free to modify the trunk, which already contains
> AsyncHttpClient, whenever he wants.  He made some big changes in
> Geronimo sandbox before I made some big changes in his original
> contribution, and that's why it's taking some time.  So.. Jeff will
> migrate the code to the trunk eventually I guess.

Yes I will ;-) I am swamped at the moment...but I will ;-)

Jeff

> 
> IMHO, AsyncWeb itself, being David (Irving) the original contributor
> of the project, needs more work and more contributor(s) to become a
> part of the trunk because David seems to be too busy to follow up the
> subproject for now unfortunately.  Where are you David?  We miss you
> so much! :)
> 
> Trustin
> 
> On Jan 10, 2008 6:16 AM, Alex Karasulu <[EMAIL PROTECTED]> wrote:
>> I think Jeff started working on some of it over at MINA btw.  Excuse the
>> cross post.
>>
>> Alex
>>
>> On Jan 9, 2008 4:10 PM, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
>>
>>> If it is better and easier than http-client are they interested in
>>> it?  Seems like a logical fit.  That said, I think Genender boy wanted
>>> to melt some metal when he started this work.  If it remains without a
>>> home I'd put it in components and let folks pick it up if they are
>>> interested.
>>>
>>> On Jan 9, 2008, at 9:55 AM, Kevan Miller wrote:
>>>
 On Jan 8, 2008, at 9:59 AM, Donald Woods wrote:

> #3 is okay with me.  Was just thinking that #2 (plugin) would allow
> us to expose it on our plugin website and allow other users to just
> place a dependency on it in their plugins
 Oops. Got distracted and forgot to reply...

 I was thinking that AHC functionality could be released under
 components (and thus easier to consume by other projects). We can
 then create a plugin which includes this component. So, really a
 combination of 2 and 3.

 --kevan


>
> -Donald
>
> Kevan Miller wrote:
>> On Jan 5, 2008, at 2:45 PM, Donald Woods wrote:
>>> There has been a lot of ongoing work by Jeff, Prasad, Rick,
>>> Sangjin and others on the AsyncHttpClient (aka. AHC) code in the
>>> sandbox and I'd like to start the discussion on moving it from
>>> sandbox into trunk.
>>>
>>> There are a couple options as to where it could reside -
>>> 1) under server/trunk/applications
>>> 2) under server/trunk/plugins
>>> 3) under geronimo/components/
>>>
>>> What are everyone's thoughts?  I'd like to get this into our 2.1
>>> release and possibly into the 2.0.x branch if time allows.
>> Personally, I don't think it should go into server/trunk.
>> There's a 4'th option -- create a subproject (e.g. geronimo/ahc).
>> The only real difference,  between this and 3) is web site, jira,
>> etc.
>> At the moment, I'm leaning towards 3) -- geronimo/components/ahc
>> (or some more descriptive name), but could probably be swayed...
>> --kevan

>>>
> 
> 
> 

Re: [DISCUSS] Time to move AsyncHttpClient out of Sandbox

[Jeff Genender]

Ugg...yeah...we need to get that team looking at our stuff.  The problem
is that the large delta is where the problem is going to be.  I would
like to see the delta be made and brought over here and have them work
over here.

Jeff

Emmanuel Lecharny wrote:
> Hey,
> 
> Alex just posted some X-post information to MINA and Geronimo, just to
> inform MINA that Geronimo want to get Jeff's work out from Sandbox.
> 
> What are all the next mails about ? I see mentions of a kind of roadmap
> for geronimo, and some other informations about asynchweb which is
> totally a different beast... I think some context has been added, and
> not through mails...
> 
> Any heads up ?
> 
> 
> Trustin Lee wrote:
>> What's important is actually not where to host it or whether to fork
>> or not - Jeff, the main contributor of the project, and the MINA team
>> already decided to host it under the MINA trunk and Jeff wants to keep
>> working on here with AHC.  So I think Jeff will take care of the
>> Geronimo discussion properly.  I also think it's OK even if they do
>> whatever they want to do with G sandbox as long as Jeff will keep
>> working here, which is much more reasonable than hosting it under
>> HttpComponent project or Geronimo trunk.  Jeff should explain this to
>> the Geronimo team and I believe he already did very enough as a person
>> who wants to host it here.
>>
>> Trustin
>>
>> On Jan 10, 2008 8:27 AM, Alex Karasulu <[EMAIL PROTECTED]> wrote:
>>  
>>> I think you missed it again.  See here:
>>>
>>>
>>>>>> On Jan 9, 2008 4:10 PM, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
>>>>>>
>>>>>>  
>>>>>>> If it is better and easier than http-client are they interested in
>>>>>>> it?  Seems like a logical fit.  That said, I think Genender boy
>>>>>>> 
>>> wanted
>>>
>>>>>>> to melt some metal when he started this work.  If it remains without
>>>>>>> 
>>> a
>>>
>>>>>>> home I'd put it in components and let folks pick it up if they are
>>>>>>> interested.
>>>>>>> 
>>> They don't want to fork it at Geronimo but would prefer it to find a
>>> home
>>> that is more fitting. http-client was mentioned.
>>>
>>> Alex
>>>
>>>
>>> On Jan 9, 2008 6:16 PM, Trustin Lee <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>>> Well, I think it's OK for the Geronimo team to fork AHC, and I'd like
>>>> to respect them if Jeff already gave the information that his AHC work
>>>> will be placed under MINA trunk.  They have their release schedule and
>>>> I don't want to let them wait for us.  They will need to migrate to
>>>> the official MINA AHC eventually though.  Jeff could show us better
>>>> road map for this.
>>>>
>>>> Trustin
>>>>
>>>> On Jan 10, 2008 7:55 AM, Alex Karasulu <[EMAIL PROTECTED]> wrote:
>>>>  
>>>>> On Jan 9, 2008 4:57 PM, Trustin Lee <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>>    
>>>>>> AsyncWeb and Jeff's AsyncHttpClient are different projects.  Anyways,
>>>>>> Jeff is free to modify the trunk, which already contains
>>>>>> AsyncHttpClient, whenever he wants.
>>>>>>   
>>>>> I know that.
>>>>>
>>>>> You obviously missed why I posted this information.  The
>>>>> AsyncHttpClient
>>>>> code Jeff worked on in his Geronimo sandbox is about to get forked
>>>>> over
>>>>> 
>>>> to
>>>>  
>>>>> some other project.  The Geronimo folks are looking for a home for
>>>>> it. I
>>>>> wanted people in general to know that Jeff is here working on that
>>>>> 
>>>> stuff.
>>>>  
>>>>> Makes sense?
>>>>> 
>>>> Yep, thanks for the information.
>>>>
>>>>
>>>> On Jan 10, 2008 7:02 AM, Jeff Genender <[EMAIL PROTECTED]> wrote:
>>>>  
>>>>> Trustin Lee wrote:
>>>>>
>>>>>> He made some big changes in
>>>>>> Geronimo sandbox before I made some big changes in his original
&g

Re: [DISCUSS] Time to move AsyncHttpClient out of Sandbox

[Jeff Genender]

Not wrong at all.  Its a little more complicated than that though :/

Let me get some of those guys to chime in.

Jeff

Emmanuel Lecharny wrote:
> Jeff Genender wrote:
>> Ugg...yeah...we need to get that team looking at our stuff.  The problem
>> is that the large delta is where the problem is going to be.  I would
>> like to see the delta be made and brought over here and have them work
>> over here.
>>
>> Jeff
>>   
> As there is nothing like what you have written in MINA currently, your
> options are :
> - move it from geronimo sandbox to some Mina sandbox
> - create a sub-project in Mina
> 
> Obvioulsy, #1 is not a valid option ;)
> 
> Am I wrong ?
> 
> 
> 

Re: [DISCUSS] Time to move AsyncHttpClient out of Sandbox

[Jeff Genender]

Trustin Lee wrote:

Sure we are! Please feel free to start to make contribution.  :)

BTW is there any express procedure for accepting the existing AHC
committers (i.e. Sangjin and Rick) in the MINA PMC? 


You mean committer, not PMC? ;-)


As you know, they
are not ASF members and didn't contribute directly to the MINA project
so far.  I wonder what I am supposed to do.  Should I wait for some
patches from them just like we do for most people?


Yes...absolutely (wait and have patches subitted or some contribution). 
 Follow the Apache way ;-)





Yet another list to subscribe to... ;-)


Welcome! ;)

Trustin

Re: [DISCUSS] Time to move AsyncHttpClient out of Sandbox

[Jeff Genender]

Keep in mind, I made a Mina 2 branch of AHC in the Geronimo sandbox a 
few weeks back...Its basically the same as the AHC Mina 1, but the APIs 
ere changed to work with Mina 2.


But the Mina version is significantly different from the one in G right now.

Jeff

Sangjin Lee wrote:

On 1/15/08, Kevan Miller <[EMAIL PROTECTED]> wrote:


On Jan 15, 2008, at 1:26 AM, Trustin Lee wrote:


Hi Kevan,

On Jan 12, 2008 2:59 AM, Kevan Miller <[EMAIL PROTECTED]> wrote:

Note that this is cross-posted to geronimo dev and mina dev lists...
Hopefully the last one...

Alex and Trustin,
Thanks for the info... More below...

On Jan 9, 2008, at 6:16 PM, Trustin Lee wrote:


Well, I think it's OK for the Geronimo team to fork AHC, and I'd
like
to respect them if Jeff already gave the information that his AHC
work
will be placed under MINA trunk.  They have their release schedule
and
I don't want to let them wait for us.  They will need to migrate to
the official MINA AHC eventually though.  Jeff could show us better
road map for this.

Sounds like a good plan. We wouldn't necessarily *have* to migrate,
but I, for one, would expect that we'll *want* to migrate to Mina
(once Mina was able to release the functionality and assuming Mina is
as good as AHC... ;-)

AHC already depends on MINA.  For now, MINA has older version of AHC
as a submodule, and Jeff is trying to move the stuff in the G sandbox
here.

Right. Sorry, I wasn't very clear. I should have said something like
"we'll *want* to migrate from Geronimo AHC to a Mina AHC..."




Sangjin, Rick, *and* Jeff have been making a number of changes and
enhancements to AHC in our sandbox. Looks like some nice stuff... I
would assume you'd be interested in their work (and would guess
they'd
like to share it with you)? Best to work out those details on mina
dev, I would think... Rick has been a G committer for a while...
Sangjin is new to our community, but has been making a number of good
contributions to AHC.

Sure we are! Please feel free to start to make contribution.  :)

BTW is there any express procedure for accepting the existing AHC
committers (i.e. Sangjin and Rick) in the MINA PMC?  As you know, they
are not ASF members and didn't contribute directly to the MINA project
so far.  I wonder what I am supposed to do.  Should I wait for some
patches from them just like we do for most people?

Sangjin is not a Geronimo committer, but has been making some nice
contributions...

There's no express procedure for moving code from Geronimo to Mina.
You can always just copy the code. However, best, if Sangjin and Rick
engaged with your community -- explaining their changes, and
submitting patches. I'm suggesting that they do that, but it's their
decision to make...

--kevan




As Kevan said, I'm not yet a Geronimo committer, but I've been actively
providing patches around AHC, and I hope I'd be a committer soon.  It'd be
nice to become a Mina committer as well. :)

I agree the right thing to do is for us to resubmit patches to Mina.  Since
the version of Mina the Geronimo AHC is based on is 1.1.x, I suspect simple
copy just won't work.  We could essentially "replay" our patches (presumably
in the same order), making sure things work correctly at each step.  How
does that sound?

Thanks,
Sangjin

Re: [DISCUSS] Time to move AsyncHttpClient out of Sandbox

[Jeff Genender]

Hi sangjin,

http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2/

Jeff

Sangjin Lee wrote:

Jeff,
Can you point me to the Mina 2 branch of AHC in G sandbox?

Thanks,
Sangjin

On 1/15/08, Jeff Genender <[EMAIL PROTECTED]> wrote:

Keep in mind, I made a Mina 2 branch of AHC in the Geronimo sandbox a
few weeks back...Its basically the same as the AHC Mina 1, but the APIs
ere changed to work with Mina 2.

But the Mina version is significantly different from the one in G right
now.

Jeff

Sangjin Lee wrote:

On 1/15/08, Kevan Miller <[EMAIL PROTECTED]> wrote:

On Jan 15, 2008, at 1:26 AM, Trustin Lee wrote:


Hi Kevan,

On Jan 12, 2008 2:59 AM, Kevan Miller <[EMAIL PROTECTED]> wrote:

Note that this is cross-posted to geronimo dev and mina dev lists...
Hopefully the last one...

Alex and Trustin,
Thanks for the info... More below...

On Jan 9, 2008, at 6:16 PM, Trustin Lee wrote:


Well, I think it's OK for the Geronimo team to fork AHC, and I'd
like
to respect them if Jeff already gave the information that his AHC
work
will be placed under MINA trunk.  They have their release schedule
and
I don't want to let them wait for us.  They will need to migrate to
the official MINA AHC eventually though.  Jeff could show us better
road map for this.

Sounds like a good plan. We wouldn't necessarily *have* to migrate,
but I, for one, would expect that we'll *want* to migrate to Mina
(once Mina was able to release the functionality and assuming Mina is
as good as AHC... ;-)

AHC already depends on MINA.  For now, MINA has older version of AHC
as a submodule, and Jeff is trying to move the stuff in the G sandbox
here.

Right. Sorry, I wasn't very clear. I should have said something like
"we'll *want* to migrate from Geronimo AHC to a Mina AHC..."


Sangjin, Rick, *and* Jeff have been making a number of changes and
enhancements to AHC in our sandbox. Looks like some nice stuff... I
would assume you'd be interested in their work (and would guess
they'd
like to share it with you)? Best to work out those details on mina
dev, I would think... Rick has been a G committer for a while...
Sangjin is new to our community, but has been making a number of good
contributions to AHC.

Sure we are! Please feel free to start to make contribution.  :)

BTW is there any express procedure for accepting the existing AHC
committers (i.e. Sangjin and Rick) in the MINA PMC?  As you know, they
are not ASF members and didn't contribute directly to the MINA project
so far.  I wonder what I am supposed to do.  Should I wait for some
patches from them just like we do for most people?

Sangjin is not a Geronimo committer, but has been making some nice
contributions...

There's no express procedure for moving code from Geronimo to Mina.
You can always just copy the code. However, best, if Sangjin and Rick
engaged with your community -- explaining their changes, and
submitting patches. I'm suggesting that they do that, but it's their
decision to make...

--kevan



As Kevan said, I'm not yet a Geronimo committer, but I've been actively
providing patches around AHC, and I hope I'd be a committer soon.  It'd

be

nice to become a Mina committer as well. :)

I agree the right thing to do is for us to resubmit patches to

Mina.  Since

the version of Mina the Geronimo AHC is based on is 1.1.x, I suspect

simple

copy just won't work.  We could essentially "replay" our patches

(presumably

in the same order), making sure things work correctly at each step.  How
does that sound?

Thanks,
Sangjin

Re: [ASYNCWEB] What's the plan regarding it's leaving the sandbox?

[Jeff Genender]

I personally don't know what is going on but I really like AsyncWeb and 
would love to see it come out of the sandbox.  I would be happy to also 
help refactoring it.


Jeff

Alex Karasulu wrote:

Do you have any idea on when we can release MINA proper 2.0 M1.  I ask
this because I would like to see at least some beta release of asyncweb
which depends on it?  Furthermore we probably need to move it out of the
sandbox now that the IP has been cleared but it needs some work.  I will
start cleaning it up to get it ready for some kind of beta release.

Also are we bound to maintain the MINA API between milestone releases?



Any comment? Anyone besides Trustin know what's going on?

If releases without freezing the API are not possible then we might have an
issue with this model.

Alex

Re: [Asyncweb] Motives behind filter-codec-http and asyncweb

[Jeff Genender]

Trustin Lee wrote:


BTW providing AHC as a subproject might be a good idea - for now it's
included as a MINA submodule, but we can provide it as a separate
subproject.  I'd like to know what Jeff thinks about it.


+1...I like the idea of it being a sub project ;-)



Trustin

On Jan 21, 2008 3:05 AM, Alex Karasulu <[EMAIL PROTECTED]> wrote:

Hi,

MINA 2.0 is pushing the inclusion of specific protocol codecs into the core:
I am specifically referring to the filter-codec-http module.

Who decided on this policy and why? Trustin, according to SVN logs you
commit this and it seems as though some of it was extracted from or overlaps
the asycweb functionality.

What is the intention for asyncweb as a subproject if it's functionality is
being moved over to MINA core?

Thanks,
Alex

Re: groupIds and artifactIds

[Jeff Genender]

I agree totally.  +1 from me too.

Jeff

Timothy Bennett wrote:
> On Jan 24, 2008 10:18 AM, Alex Karasulu <[EMAIL PROTECTED]> wrote:
> 
>> I think asyncweb has the potential to grow into it's own TLP one day.
>> Should any subproject with these intentions, like MINA did, be allowed to
>> carve out it's own groupId and it's own package base?
>>
> 
> +1
> 
> org.apache.asyncweb
> 

Re: [Asyncweb] Updates on recent changes

[Jeff Genender]

Nice!

Alex Karasulu wrote:

Hi all,

I started cleaning up and organizing the Asyncweb subproject today which
entailed:

   o moving Asyncweb out of the sandbox into the new structure discussed
here [0] with slight differences
   o moving filter-codec-http into Asyncweb as a module
   o changing package names
   o moving 3 classes of protocol-http-client into Asyncweb as a module
   o cleaning up NOTICE.txt and LICENSE.txt files
   o cleaning up problems resulting from back and forth movement of the HTTP
codec

Here's what the present directory structure of asyncweb looks like as seen
here [1]:

   ... mina/asyncweb
  .
  |-- branches
  |-- tags
  `-- trunk
  |-- LICENSE.txt
  |-- NOTICE.txt
  |-- assembly
  |-- client
  |-- common
  |-- examples
  |-- pom.xml
  |-- server
  `-- spring

There are 6 modules here.  Some points about the module migrations and name
changes: [NOTE: Below the module name based on the maven POM's  tag is
used.]


Module: Apache Asyncweb Common
-

Most of a common package containing the HttpX interfaces was, as shown
earlier, re-factored and moved into the MINA subproject along with the HTTP
codec into the MINA filter-codec-http module.  Asyncweb is not concerned
with advertising that this module and it's artifact is a MINA codec which a
small part of it contains.  Furthermore this module is shared between the
http client AHC (3 classes) and the Asyncweb server. Because of these
reasons it was best called the asyncweb-common module.  Again the fact that
this module contains a codec is irrelevant.


Module: Apache Asyncweb Client
-

The Asyncweb Client module is comprised of 3 Java source files and
represents the previous protocol-http-client which was referred to as Async
HTTP Client (AHC).  This module depends on and uses the Asyncweb Common API
and the HTTP codec within it to function.  Hence as discussed and out of
common sense this protocol-http-client module in the MINA subproject was
moved under Asyncweb as the Apache Asyncweb Client module.


Module: Apache Asyncweb Server
--

This represents the old Asyncweb 'core' module from the sandbox with the
mentioned cleanups.


Module: Apache Asyncweb Spring
--

This represents the old Asyncweb 'springframework' integration module from
the sandbox with the mentioned cleanups.


Module: Apache Asyncweb Examples
---

This represents the old Asyncweb 'example' module from the sandbox with the
mentioned cleanups.


Module: Apache Asyncweb Assembly
---

This represents the old Asyncweb 'assembly' module from the sandbox with
minor cleanups.

I hope everyone has a chance to take a look, build etc and give feedback.
If curious and you don't have the time here's what the build run output
looks like with these names and this structure.

[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO]   Apache Asyncweb Parent
[INFO]   Apache Asyncweb Common
[INFO]   Apache Asyncweb Server
[INFO]   Apache Asyncweb Client
[INFO]   Apache Asyncweb Spring
[INFO]   Apache Asyncweb Examples
...
[INFO]

[INFO] Reactor Summary:
[INFO]

[INFO] Apache Asyncweb Parent  SUCCESS [
1.856s]
[INFO] Apache Asyncweb Common  SUCCESS [
4.871s]
[INFO] Apache Asyncweb Server  SUCCESS [
3.959s]
[INFO] Apache Asyncweb Client  SUCCESS [
11.553s]
[INFO] Apache Asyncweb Spring  SUCCESS [
0.668s]
[INFO] Apache Asyncweb Examples .. SUCCESS [
0.795s]
[INFO]

[INFO]

[INFO] BUILD SUCCESSFUL
[INFO]



I hope this report clarifies the changes and helps people get back up to
speed with Asyncweb.

Thanks,
Alex



[0] Directory Restructuring Thread - http://tinyurl.com/23dclx
[1] Asynchweb in Subversion - http://svn.apache.org/repos/asf/mina/asyncweb

Re: AsyncHttpClient, Connector, disposing and parked threads

[Jeff Genender]

Yes...that problem was fixed as well as a host of others.

Jeff

Alex Karasulu wrote:

Someone from Geronimo mentioned that this problem was actually fixed in the
Geronimo version a while back.  Perhaps something we should look into or
inquire about.

Jeff can you give us an update on that?

Alex

On Jan 28, 2008 12:25 PM, Julien Vermillard <[EMAIL PROTECTED]> wrote:


Hi,
Following an IRC convo, between alex, tazle and me :

We had a few complaint recently about remaining unclosed socket and
thread after multiple connection using the NioSocketConnector or simply
the AsyncHttpClient not releasing correctly file descriptor on linux.

The problem for AsyncHttpClient is was because each connection create a
NioSocketConnector and forget to .dispose() it.

When you connect and close a session a thread will remain in the
threadpool for 1 minute (it's the default behaviour), you can still
overide it specifying another Executorfilter behaviour.

BTW AHC is using 1 SocketConnector per AHC instance, I think it should
be changed to share it.

Julien

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Jeff Genender]

Actually I already made a Mina 2.x version that is in the G sandbox ;-)

Jeff

Kevan Miller wrote:


On Jan 29, 2008, at 7:28 PM, Mike Heath wrote:


Alex Karasulu wrote:

Hi,

Please excuse the cross post but it's quite necessary. Furthermore 
people
should not feel like they cannot cross post responses so please feel 
free.


It looks like the two versions of the http client based on MINA are 
starting

to diverge.  I've noticed the other day that some of the fixes for bugs
already solved by one group are being re-implement all over again 
over again
by another.  It's a shame to have that happen so perhaps we can take 
some

concrete steps to prevent this divergence from progressing.

As a first step I've cleaned up and restructured the Asyncweb code 
base and

posted this email here on the new directory structure in Subversion:

 *http://tinyurl.com/ypmbd3

*So I'm sending out this cross post in the hopes of bringing the two 
groups

together as one unified community which apparently has the same goal in
mind: a fast low-resource consuming asynchronous http client.  What 
ever it
takes, I'm sure the MINA PMC is more than willing to accommodate.  If 
you
have trusted committers already working on this in the Geronimo 
community
there is no reason why we cannot trust them to continue working on it 
here

at MINA's Asyncweb project.  Let's open up discussions on this.


I totally agree with Alex on this.  It looks there are fixes in the G
branch that haven't made it to the MINA branch.  How can bridge the gap
in communication as well as the gap in bug fixing?

My opinion is that we need to stop all work on the G sandbox branch and
move all work over to MINA.  Is there anything impeding that? ...besides
a lot of work merging the changes...


Thanks Alex and Mike.

So, as we discussed the last time, the community members that have been 
active in this area are Jeff Genender, Sangjin Lee, and Rick McGuire. 
You already know Jeff. Have you reached out to Sangjin and Rick? I'd 
urge them both to become involved in the Mina community, as their time 
and interest permit.


Personally, I'm certainly in favor of seeing a united effort in creating 
an async http client. Mina would seem to be a natural home for this 
support (since Mina 2.x is moving up the stack and implementing 
protocols). I think our community would be quite happy to receive this 
capability by consumng Mina technology. Given the current state of our 
two projects, I think it's somewhat doubtful that the Geronimo project 
will end up releasing the AsyncHTTPClient code in our sandbox.


I can understand, however, if Rick and Sangjin see value in the current 
codebase -- being based on a released version of Mina (1.1.2)  and 
perhaps at a different point in terms of stability and function. I 
suspect that this might be part of the reason why they haven't become 
involved in the 2.x development work occurring at Mina.


So, one possible solution that occurs to me is to transfer the current 
1.1.x code in Geronimo sandbox to the Mina project. This might allow 
Rick and Sangjin to complete their work on the current codebase and also 
ease their transition towards merging code and fixes into the Mina 2.x 
codebase. Alternatively, we can leave the code in Geronimo sandbox while 
Sangjin and Rick transition their focus to the Mina 2.x support.


Will leave it to the Mina project, Rick, and Sangjin to say what makes 
the most sense.


--kevan

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Jeff Genender]

Rick,

This was the port I did to Mina 2:

http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2/

Jeff

Rick McGuire wrote:

Alex Karasulu wrote:

Kevan,

Thanks for taking the time to respond.  More inline ...

On Jan 30, 2008 1:08 AM, Kevan Miller <[EMAIL PROTECTED]> wrote:
...

 

So, as we discussed the last time, the community members that have been
active in this area are Jeff Genender, Sangjin Lee, and Rick McGuire. 
You

already know Jeff. Have you reached out to Sangjin and Rick?
I'd urge them both to become involved in the Mina community, as their 
time

and interest permit.




Right very good point.

So Sangjin and Rick are you interested in working on this with the 
rest of

the asyncweb crew at MINA?
  
Yes, I'm definitely interested in helping out.  Right now, I'm having a 
hard time figuring which is the correct Mina 2.0 version.  There appear 
to be at least 3 different versions of an AsyncHttpClient floating 
around (one in the Mina trunk, one in the AsyncWeb tree, one in the 
Geronimo sandbox).  Which is the appropriate one to start porting the 
recent changes to the 1.1.5 version to?


Rick




 

I can understand, however, if Rick and Sangjin see value in the current
codebase




NP that's something to consider and evaluate.  And regardless of the 
code in
general we can share knowledge and expertise.  I'm sure experiences 
will rub

off and this is the most important part of it.  The code here is small
compared to the collaborative potential.


 

So, one possible solution that occurs to me is to transfer the current
1.1.x code in Geronimo sandbox to the Mina project. This might allow 
Rick

and Sangjin to complete their work on the current codebase and also ease
their transition towards merging code and fixes into the Mina 
2.xcodebase. Alternatively, we can leave the code in Geronimo sandbox 
while

Sangjin and Rick transition their focus to the Mina 2.x support.

Will leave it to the Mina project, Rick, and Sangjin to say what 
makes the

most sense.




I think all options are open for us.

Thanks for your help towards fostering greater community.

Alex

  

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Jeff Genender]

Being that its in the sandbox...anything goes. ;-)

However...with that said...lets see what pans out here at Mina.  I would 
certainly consider the delta now before we get 3 diverse versions ;-)


Yes the preferred version is Mina 2.x.

Jeff

Rick McGuire wrote:

Jeff Genender wrote:

Rick,

This was the port I did to Mina 2:

http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2/

Jeff,

Is that the preferred version?  Since that branch is in the geronimo SVN 
tree, do you have any objections to me directly porting and applying 
some of the recent 1.1.5 changes to that version?  Or should I submit 
patches via Jira (and where should the patches be submitted)?  If that's 
not the preferred version, then which one is?


Rick


Jeff

Rick McGuire wrote:

Alex Karasulu wrote:

Kevan,

Thanks for taking the time to respond.  More inline ...

On Jan 30, 2008 1:08 AM, Kevan Miller <[EMAIL PROTECTED]> wrote:
...

 
So, as we discussed the last time, the community members that have 
been
active in this area are Jeff Genender, Sangjin Lee, and Rick 
McGuire. You

already know Jeff. Have you reached out to Sangjin and Rick?
I'd urge them both to become involved in the Mina community, as 
their time

and interest permit.




Right very good point.

So Sangjin and Rick are you interested in working on this with the 
rest of

the asyncweb crew at MINA?
  
Yes, I'm definitely interested in helping out.  Right now, I'm having 
a hard time figuring which is the correct Mina 2.0 version.  There 
appear to be at least 3 different versions of an AsyncHttpClient 
floating around (one in the Mina trunk, one in the AsyncWeb tree, one 
in the Geronimo sandbox).  Which is the appropriate one to start 
porting the recent changes to the 1.1.5 version to?


Rick




 
I can understand, however, if Rick and Sangjin see value in the 
current

codebase




NP that's something to consider and evaluate.  And regardless of the 
code in
general we can share knowledge and expertise.  I'm sure experiences 
will rub

off and this is the most important part of it.  The code here is small
compared to the collaborative potential.


 

So, one possible solution that occurs to me is to transfer the current
1.1.x code in Geronimo sandbox to the Mina project. This might 
allow Rick
and Sangjin to complete their work on the current codebase and also 
ease
their transition towards merging code and fixes into the Mina 
2.xcodebase. Alternatively, we can leave the code in Geronimo 
sandbox while

Sangjin and Rick transition their focus to the Mina 2.x support.

Will leave it to the Mina project, Rick, and Sangjin to say what 
makes the

most sense.




I think all options are open for us.

Thanks for your help towards fostering greater community.

Alex

  

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Jeff Genender]

Yes.. I think that is the best course of action.  I think they are  
pretty similar since I created the mina 2 version in late December.  I  
think the delta is rather small.


Jeff

On Jan 31, 2008, at 1:34 PM, "Sangjin Lee" <[EMAIL PROTECTED]> wrote:


Just so I understand...
What is the direction we're taking?  Just for the terminology sake,  
I'll

call these versions

- g-ahc-v1: Geronimo AHC based on Mina 1.1 (the one that Rick and I  
were

working on)
- g-ahc-v2: Geronimo AHC based on Mina trunk
- mina-ahc: Mina AHC that was refactored into asyncweb

Are we migrating changes from g-ahc-v1 to g-ahc-v2 first and will  
try to

migrate them again from g-ahc-v2 to mina-ahc?

Thanks,
Sangjin


On Jan 30, 2008 6:36 PM, Alex Karasulu <[EMAIL PROTECTED]> wrote:


On Jan 30, 2008 1:49 PM, Jeff Genender <[EMAIL PROTECTED]> wrote:


Being that its in the sandbox...anything goes. ;-)

However...with that said...lets see what pans out here at Mina.  I  
would
certainly consider the delta now before we get 3 diverse  
versions ;-)


Yes the preferred version is Mina 2.x.


Indeed! We might want to first make sure the two Geronimo forks are  
merged
and using MINA 2.0.  Meaning all the features and fixes in the one  
based

on
MINA 1.1.x are put into the one based on MINA 2.0-M1.

That might bring the consolidated Geronimo fork closer to the MINA  
version
in Asyncweb trunk.  Then we can focus on how to merge these two  
together?


Alex

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Jeff Genender]

Or you can use Linux or Mac ;-)

j/k!

Thanks for looking into that Rick.

Jeff

Rick McGuire wrote:
> I had some time this morning, and decided to take a look at this.  It
> was fairly straightforward merging the changes back in to the 2.0
> sandbox branch.
> There's a bit of a problem going on here with the jsps used for the
> tests.  In the 1.1.5-based version, there was no eol-style property set
> for the jsps.  This caused the strings that were returned by the tests
> to use \n for line terminators, which the unit tests expected to find in
> the message responses.  In the 2.0 version, the eol-style is set to
> native, which causes the unit tests to fail when run on a Windows
> system.  I was able to hack these up so they're now running cleanly, but
> I'm not terribly confident these won't end up breaking again in the
> future.  I suspect a less encoding-specific approach is going to be
> needed for validating the responses should be used.
> 
> Rick
> 
> 
> Jeff Genender wrote:
>> Yes.. I think that is the best course of action.  I think they are
>> pretty similar since I created the mina 2 version in late December.  I
>> think the delta is rather small.
>>
>> Jeff
>>
>> On Jan 31, 2008, at 1:34 PM, "Sangjin Lee" <[EMAIL PROTECTED]> wrote:
>>
>>> Just so I understand...
>>> What is the direction we're taking?  Just for the terminology sake, I'll
>>> call these versions
>>>
>>> - g-ahc-v1: Geronimo AHC based on Mina 1.1 (the one that Rick and I were
>>> working on)
>>> - g-ahc-v2: Geronimo AHC based on Mina trunk
>>> - mina-ahc: Mina AHC that was refactored into asyncweb
>>>
>>> Are we migrating changes from g-ahc-v1 to g-ahc-v2 first and will try to
>>> migrate them again from g-ahc-v2 to mina-ahc?
>>>
>>> Thanks,
>>> Sangjin
>>>
>>>
>>> On Jan 30, 2008 6:36 PM, Alex Karasulu <[EMAIL PROTECTED]> wrote:
>>>
>>>> On Jan 30, 2008 1:49 PM, Jeff Genender <[EMAIL PROTECTED]> wrote:
>>>>
>>>>> Being that its in the sandbox...anything goes. ;-)
>>>>>
>>>>> However...with that said...lets see what pans out here at Mina.  I
>>>>> would
>>>>> certainly consider the delta now before we get 3 diverse versions ;-)
>>>>>
>>>>> Yes the preferred version is Mina 2.x.
>>>>>
>>>>>
>>>> Indeed! We might want to first make sure the two Geronimo forks are
>>>> merged
>>>> and using MINA 2.0.  Meaning all the features and fixes in the one
>>>> based
>>>> on
>>>> MINA 1.1.x are put into the one based on MINA 2.0-M1.
>>>>
>>>> That might bring the consolidated Geronimo fork closer to the MINA
>>>> version
>>>> in Asyncweb trunk.  Then we can focus on how to merge these two
>>>> together?
>>>>
>>>> Alex
>>>>
>>

Re: I wish to say a few words...

[Jeff Genender]

Thanks guys!

Jeff


Emmanuel Lecharny wrote:
> Alex Karasulu wrote:
>> On Feb 3, 2008 4:53 PM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
>>
>>  
>>> Jeff Genender wrote:
>>>
>>>> Is someone not doing a good job as a monitor?  This stuff shouldn't get
>>>> onto these lists.
>>>>
>>>>   
>>> Id do monitor every single mail on MINA and Directory. I can assure you
>>> that this mail hasn't been considered as spam at all. It went directly
>>> through the mailing list, for some reason.
>>>
>>> Should we report this to infra ?
>>>
>>> 
>>
>> Yeah good point otherwise it will happen over and over again.
>>
>>   
> Reported...
> 

Re: connect timeout

[Jeff Genender]

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
> 

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Jeff Genender]

Mike Heath wrote:
> I've been looking into merging
> http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2/
> into http://svn.apache.org/repos/asf/mina/asyncweb/trunk/client/ and I'm
> trying to figure out the best way to proceed.  Here are some of the pain
> points I see:
>  - The only redeeming quality about the AsyncWeb client is that it uses
> the AsyncWeb codec.
>  - There are a few things in AHC that duplicate functionality already
> available in MINA (timeouts for example)

I think this timeout is a different timeout in implementation...that is
unless this was added to 2.0, then duplication may be correct.  Its a
response timeout, not socket timeout...I think thats different.

>  - The AHC codec and the AsycnWeb codec have diverged quite a bit.
> 
> To resolve these pain points, here is how I would like to proceed.  I
> would like to copy the AHC async-http-client-mina2 code as is into the
> AsyncWeb client repository.  Because  AHC and AsyncWeb client use
> different package names, there shouldn't be any conflicts doing this.
> Once that is done, we can look at removing the AHC code that
> reimplements functionality available in MINA.  As long as all the tests
> are passing, we should be fine and if there are gaps in testing, we
> should fill those.
> 
> Once that is done, we can look at refactoring the AHC code base to use
> the AsyncWeb codec while at the same time, make sure that the AsyncWeb
> codec isn't missing any functionality that is implemented in AHC.
> 
> I think at this point, we can rename the AHC packages and move it over
> top the current AsyncWeb client.  Am I missing anything in AsyncWeb
> client that needs to merged into AHC?  It's only four classes and I
> didn't see anything in there that isn't available in AHC.
> 
> Before going ahead and doing this, I wanted to know what everyone else
> thinks of this plan.  Does anyone else have a different idea as to how
> best to undertake this merge?  Am I missing anything?
> 

I like the plan...seems like a good way to go.


> -Mike
> 
> 
> 
> Sangjin Lee wrote:
>> Yeah I believe so (as far as I can tell).  It was more or less a
>> straightforward porting, so there might be interesting and subtle behavior
>> changes we may need to look at.  But it should be a good solid baseline.
>> Thanks,
>> Sangjin
>>
>>
>> On Feb 4, 2008 2:50 PM, Mike Heath <[EMAIL PROTECTED]> wrote:
>>
>>> Rick McGuire wrote:
 I had some time this morning, and decided to take a look at this.  It
 was fairly straightforward merging the changes back in to the 2.0
 sandbox branch.
 There's a bit of a problem going on here with the jsps used for the
 tests.  In the 1.1.5-based version, there was no eol-style property set
 for the jsps.  This caused the strings that were returned by the tests
 to use \n for line terminators, which the unit tests expected to find in
 the message responses.  In the 2.0 version, the eol-style is set to
 native, which causes the unit tests to fail when run on a Windows
 system.  I was able to hack these up so they're now running cleanly, but
 I'm not terribly confident these won't end up breaking again in the
 future.  I suspect a less encoding-specific approach is going to be
 needed for validating the responses should be used.

 Rick
>>> Rick,
>>>
>>> Does
>>> http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2/
>>> contain all the bug fixes and latest features of AsyncHttpClient?  Can
>>> we use this to merge the changes over to the client under MINA?
>>>
>>> -Mike
>>>
>>> 
>>>

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Jeff Genender]

Mike Heath wrote:

Jeff Genender wrote:



I think this timeout is a different timeout in implementation...that is
unless this was added to 2.0, then duplication may be correct.  Its a
response timeout, not socket timeout...I think thats different.


MINA has support for triggering events for read idle, write idle, or
both.  See IoSession.setIdleTime(IdleStatus, int) in MINA 1.x and
IoSession.getConfig().setIdleTime(IdleStatus,int) in MINA 2.  The idle
events get handled by IoHandler.sessionIdle(IoSession, IdleStatus) in
both versions.


Will idle work here?  The Mina FAQ states that sessionIdle cannot be 
used in a request-response timeout:


http://tinyurl.com/25gnja

Also, with pipelining, can idle time even be used?

Jeff

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Jeff Genender]

Mike Heath wrote:

What the FAQ is saying is that the idle event wont tell you which
request message was issued when the timeout occured.  So using an idle
read to detect an unresponsive connection is perfectly legitimate.

I don't see why using idle wouldn't work for pipelining.  If the session
times out, it gets closed which would cause any pending requests to fail
anyway.

I may just be presumptuous.  Am I missing something?



This is pipelining...using a single connection for reuse for multiple 
requests, which tells me that a sessionIdle would probably not work.


But if you are saying its possible, then great!

Jeff


-Mike

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Jeff Genender]

Mike Heath wrote:
> To clarify, my understanding of pipelining is that it is sending
> multiple requests and then waiting for the corresponding responses.
> This is more than HTTP keep alive which would also allow using a single
> connection for multiple requests but doesn't necessarily involve the
> batching of pipelining.

I understand it slightly different..that you can send multiple requests
through the same socket.  The difference between what you said and what
I said is I think pipelining does not have stacked waiting.

> 
>> But if you are saying its possible, then great!
> 
> What I'm saying is that in the AHC code at
> http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2,
> the HttpIoHandler.TimeoutTask is unaware of which request has been sent.
>  It only knows which IoSession is being used (that's the only field in
> the TimeoutTask).  So essentially the timeout logic as it is implemented
> in AHC is no different than using the MINA idle logic.
> 
> Does the AHC client currently support pipelining?  If I issue two
> pipelined requests, and the first one times out causing the session to
> close.  How does the future of the second request get notified of the
> timeout?  I only see code for working with CURRENT_REQUEST (from the
> IoSession attributes).  I don't see any code for dealing with pending
> requests.
> 

You are rightno AHC does not support pipelining but we were coding
it to go in that direction so we could.  We knew that it would be a lot
more complex to implement, but wanted to sow the seeds of the code to
handle it when we did.

OTOH, I must admit I implemented the ScheduledExecutor based on the FAQ
and a few IRC discussions ;-)  but if sessionIdle will work, then that
would be the way to go.

> -Mike
> 
> BTW - Thanks for the discussion, Jeff.  It's really helped me to go back
> and look deeper in the AHC code.

Thank you...and thanks for taking an interest...this is great ;-)

> 
> -Mike

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Jeff Genender]

Wow...this is awesome...I could have used this because this is
essentially the same mechanism I wrote in AHC ;-)

Yeah...this should be documented in the FAQ somewhere as this would come
in handy.

Jeff

Julien Vermillard wrote:
> Hi,
> 
> Just by the way, if you want to monitor a request/response behaviour you
> got the reqres filter :
> http://svn.apache.org/viewvc/mina/trunk/core/src/main/java/org/apache/mina/filter/reqres/
> 
> Julien

Re: [AsyncWeb] SSL server and client certs

[Jeff Genender]

Look in the Trust Factory..that is exactly where you need to look.

Currently the SSL impl is based on communication and anonymous only (I
was working on the SSL client cert but got side tracked with my new job).

You probably should allow for a setter that allow you to set a
certificate object and, to make things easy on the user, a way to pull
one from a file and keystore (Im just thing about how to make this API
as simple as possible).

The Trust Factory is exactly the area I would recommend adding the
enhancement.

Alan...this is awesome stuff...thanks for taking such an interest!

Jeff

Alan D. Cabrera wrote:
> I need this.  What will it take for me to add it?  It looks like it I
> need to flesh out that trust factory.
> 
> 
> Regards,
> Alan

Re: [AsyncWeb] Need an async client now

[Jeff Genender]

I agree...I think 2.0 is the way to go...the enhancements really make it
nicer.

Jeff

Alex Karasulu 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] AHC Wiki Space Created

[Jeff Genender]

Awesome...thanks Alan.

Alan D. Cabrera wrote:
> I've made this space for us:
> 
> http://cwiki.apache.org/confluence/display/AHC/Index
> 
> 
> Regards,
> Alan

Re: [AsyncWeb] Client redesign

[Jeff Genender]

David M. Lloyd wrote:
>> Yes, this is my thinking as well - the casual user wants a simplified API,
> while the advanced user wants a more detailed interface.
>

Certainly no reason not to offer both capabilities ;-)

Jeff


> - DML

Re: [VOTE] Release Apache MINA 2.0-M1

[Jeff Genender]

+1

Mike Heath wrote:

Hello Community,

It looks like Maarten has resolved DIRMINA-513.  I don't see any reason
to hold up a 2.0-M1 release.

There are a multitude of changes in MINA 2.0-M1, too many to enumerate
in a single email.  A laundry list of changes going into this release
can be found here
https://issues.apache.org/jira/browse/DIRMINA?report=com.atlassian.jira.plugin.system.project:roadmap-panel

This release should not be considered final nor entirely stable.  It is
a release so that developers using MINA know what to expect in 2.0 as
well as help us to find bugs and deficiencies in the API.

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

-Mike

Re: MINA at JavaOne 2008 - idea wanted

[Jeff Genender]

Yeah I am in agreement with Mike.  An architectural overview...and an 
example (heck use AHC vs HttpClient) and show how it scales.  That will 
get ooohs and ahhhs.


Jeff

Mike Heath wrote:

One of the problems I've had when promoting MINA is that most Java
developers don't understand the scalability implications of the
thread-per-connection architecture.  If I jump right in with how cool
MINA is with its separation of concerns, futures, filters, event
mechanism, simplifies packet fragmentation problems, etc., the audience
either gets lost or replies with something like, "Using InputStreamsis
just as flexible as filters but doesn't come with all the difficulties
of having to build a state machine.  MINA just makes things complicated!"

However, if I start out showing how quickly I get an OOM exception when
using a thread-per-connection architecture and then show how I can
handle thousands of connections in MINA without consuming loads of
memory, the audience is able to better understand the main problem that
MINA solves.  Showing how painful it is to use NIO directly is fairly
simple at this point.  The important part is making sure the audience
understands the need for the functionality that NIO has to offer.

Once the audience understands the problems MINA solves, I've found
they're usually much more receptive to the coolness that MINA has to offer.

Just my $0.02.

-Mike

이희승 (Trustin Lee) wrote:

Hi,

I was invited as a speaker of JavaOne 2008 and will speak about Apache
MINA there.  Please feel free to contact me to give me some idea about
what you want to hear about MINA if you have any plan to attend this
year's JavaOne.

Cheers,
Trustin

Re: doubt Mina

[Jeff Genender]

FYI...if you are going to do this...you are gonna have to tweak your IP
stack to be able to handle that many open sockets.

Jeff

[EMAIL PROTECTED] wrote:
> to example echoserver, how to make this test:
> open 2 conection and send message simultaneous? someone did this? 
> I want to check the performance of the example echoserver.
> 
> some tips?
> 
> thanks
> 
> On 2/13/08, 이희승 (Trustin Lee) <[EMAIL PROTECTED]> wrote:
>> I am not sure if it's a more flexible solution considering we are going
>> to have more transports.  For example, we have serial port communication
>> transport, and we will have to add a visit method per each transport.
>>
>> Trustin
>>
>> 2008-02-13 (수), 09:58 -0500, Adam Fisk 쓰시길:
>>> This would be a nice place for the good old visitor pattern, so
>>> something like, in SocketSession,
>>>
>>> SocketSession implements VisitableSession
>>>
>>> ...
>>> public void accept(final SessionVisitor visitor)
>>> {
>>> visitor.visitSocketSession(this);
>>> }
>>>
>>> Then you have a lot of flexibility with the visitor itself to handle
>>> types nicely. The SessionVisitor would be an interface like:
>>>
>>> public interface SessionVisitor
>>> {
>>>  void visitSocketSocket(final SocketSession session);
>>>  void visitDatagramSession(final DatagramSession session);
>>> }
>>>
>>> I'd be happy to make a patch along those lines if people were
>>> interested.  It would use generics for return types rather than the
>>> above for slightly more flexibility.
>>>
>>> -Adam
>>>
>>>
>>> On Feb 13, 2008 12:06 AM, 이희승 (Trustin Lee) <[EMAIL PROTECTED]> wrote:
 2008-01-28 (월), 10:47 -0400, Brenno Hayden 쓰시길:
> Hello ,
> i have same doubt..
>  -  How can I tell if the connection is udp or tcp?
 In 1.x, you can use IoSession.getTransportType().  In 2.x, you can
 simply use 'instanceof SocketSession' or 'instanceof DatagramSession'.

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

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

Re: [AsyncWeb] build broken w/ last checkin

[Jeff Genender]

Sangjin Lee wrote:
> I noticed this too...  Incidentally I also noticed that the SSL unit tests
> were broken due to the way that the SSL filter is added but that seems to be
> an old issue.  The SSL filter should be added before the protocol codec
> filter...
> Shall I file a bug and submit a patch for both?

File a bug and *commit* a patch...you are a committer now ;-)

Jeff

Re: [AsyncWeb] build broken w/ last checkin

[Jeff Genender]

Hmmm...that is something that should not take long...

We need to get this handled ASAP.  Alex...any thoughts?

Jeff

Sangjin Lee wrote:
> Not yet...  I haven't got an account setup confirmation from ASF...
> Regards,
> Sangjin
> 
> On Mon, Mar 3, 2008 at 12:09 PM, Jeff Genender <[EMAIL PROTECTED]> wrote:
> 
>>
>> Sangjin Lee wrote:
>>> I noticed this too...  Incidentally I also noticed that the SSL unit
>> tests
>>> were broken due to the way that the SSL filter is added but that seems
>> to be
>>> an old issue.  The SSL filter should be added before the protocol codec
>>> filter...
>>> Shall I file a bug and submit a patch for both?
>> File a bug and *commit* a patch...you are a committer now ;-)
>>
>> Jeff
>>
>>
> 

Re: [AsyncWeb] build broken w/ last checkin

[Jeff Genender]

I agree with Alan...I understood that the G version was going away now
that we built community over here on this.  Comments?

Jeff

Alan Cabrera wrote:
> 
> On Mar 1, 2008, at 8:12 PM, Alan D. Cabrera wrote:
> 
>> AsyncHttpClient was changed w/ the last checkin on 2/26 and now the
>> build is broken.
> 
> I looked at the actual changes.  I'm just trying to grok the changes
> because I realize that I am new here.  It seems that the "old"
> AsyncHttpClient is still evolving?  How does this fit in with the plans
> for the "old" AsyncHttpClient, the "new" Geronimo AsyncHttpClient, and
> the new API that's currently in discussion?
> 
> I had thought, maybe naively, that we were going to roll the "old" two
> into the new one.
> 
> 
> Regards,
> Alan

Re: Moving the AHC 1.1.5 client from the Geronimo sandbox.

[Jeff Genender]

+1! ;-)

Sangjin Lee wrote:
> I began looking into this...  Just to summarize what's going to happen
> - The svn path under which the code will be moved is
> https://svn.apache.org/repos/asf/mina/asyncweb/branches/1.0/client(currently
> the branches directory is empty).
> - The code will be moved as is from the G sandbox, but the package will be
> renamed and refactored from org.apache.ahc.* to
> org.apache.asyncweb.client.*.
> - groupId: org.apache.asyncweb
> - artifactId: asyncweb-client
> - version: 1.0-SNAPSHOT
> - name: AsyncHttpClient
> 
> Please let me know if this is different than what you guys think...
> 
> Thanks,
> Sangjin
> 
> 
> On Sat, Apr 5, 2008 at 1:34 AM, "이희승 (Trustin Lee) <[EMAIL PROTECTED]>
> wrote:
> 
>> Please go ahead and move it here.  :)
>>
>> Cheers,
>>
>> Sangjin Lee wrote:
>>> +1
>>> Regards,
>>> Sangjin
>>>
>>> On Fri, Apr 4, 2008 at 9:45 AM, Alan D. Cabrera <[EMAIL PROTECTED]>
>>> wrote:
>>>
 I hold no strong opinions about the artifactId.  Since there is no 1.0
 release then I don't see a real need to have a separate artifactId.

 Moving GAHC to a 1.0 branch instead of a sandbox would be great and is
>> the
 reason I chimed in.  I really want to kill GAHC and give it a nice home
 here.


 Regards,
 Alan


 On Apr 3, 2008, at 9:43 PM, "이희승 (Trustin Lee) <[EMAIL PROTECTED]>
>> wrote:
  Sounds like a good idea.  I'd prefer GAHC to use the same artifactId
> with our current trunk stuff as Alex suggested for smooth transition
> (and less pollution in our Maven repository :).  What do you think
>> about
> moving GAHC to /asyncweb/branches/1.0 instead of sandbox?  I'm fine
>> with
> releasing GAHC with AsyncWeb Client 1.0 and release AsyncWeb suite
>> (i.e.
> client + server) with the version number 2 after then.
>
>
> Alan D. Cabrera wrote:
>
>> Exactly, a clear demarcation.  It's really G AHC in it's new home.
>> Also, we're committed that it's a deprecated line and that, when the
>> new
>> stuff is ready, everyone should be using the new 2.0 stuff that's
>> built
>> on MINA 2.0 goodness.
>>
>> Regards,
>> Alan
>>
>> On Apr 3, 2008, at 12:53 PM, Alex Karasulu wrote:
>>
>>  Why not have the same artifactId and just have different version?
>>  Or
>>> you
>>> want a clear demarcation so there can be no confusion?
>>>
>>> Alex
>>>
>>> 2008/4/3 Alan D. Cabrera <[EMAIL PROTECTED]>:
>>>
>>>  Yep, that's it.
 The idea was for it to get its own branch and we release it under
 1.0 of
 it's own artifactId, which would be different than the artifactId
 of
 the new
 client that Mike et al are working on.  This would be 2.0 and
 written
 from
 "scratch" off of MINA 2.0.


 Regards,
 Alan



 On Apr 3, 2008, at 11:45 AM, Sangjin Lee wrote:

 I think it's this:

>
>> http://www.nabble.com/-AsyncWeb--build-broken-w--last-checkin-td15784297.html
>
> Look towards the bottom (the most recent) of the thread...  We
> discussed
> making it a branch of asyncweb.
>
> Thanks,
> Sangjin
>
>
> On Thu, Apr 3, 2008 at 11:21 AM, Alan D. Cabrera <
> [EMAIL PROTECTED]>
> wrote:
>
> Where do I look in the headers?
>
>> Regards,
>> Alan
>>
>>
>> On Apr 3, 2008, at 9:51 AM, "이희승 (Trustin Lee) <
>> [EMAIL PROTECTED]>
>> wrote:
>>
>> Uh.. did we?  Could you tell me the message ID so I can
>> re-read the
>>
>>  related thread?
>>> Thanks,
>>>
>>> Alan D. Cabrera wrote:
>>>
>>> The discussion that took place earlier was that this would
>>> be our
>>>
 v1.0
 release of Async client in the Mina project, IIRC.  I
 think it
 still
 needs to be put to a vote.


 Regards,
 Alan

 On Apr 3, 2008, at 6:48 AM, "이희승 (Trustin Lee)
 <[EMAIL PROTECTED]>
 wrote:

 Let's move it to the sandbox first and then find out the
 best way
 to

  merge it to upstream (AsyncWeb).  WDYT?
> Rick McGuire wrote:
>
> Changes to the 1.1.5 AHC client in the Geronimo sandbox
> appear
>
>> to
>> have
>> settled down, so I think now would be a good time to
>> move it
>> to
>> the Mina
>> project if everybody agrees.  Where would be the
>> appropriate
>> place

Re: Tying up loose ends

[Jeff Genender]

+1

Alan D. Cabrera wrote:
> I think we should release the AHC client that's current in the 1.0 branch.
> 
> Thoughts?
> 
> 
> Regards,
> Alan

Re: Do we need all those @Override ?

[Jeff Genender]

I would keep them because they really help when there are changes in
super classes during a compile.

Jeff

Emmanuel Lecharny wrote:
> i guys,
> 
> while browsing MINA's code, I see @Override used everywhere. I know it
> can be helpful when overriding an existing method, but do you think we
> need to keep them ?
> 
> wdyt ?
> 

Re: Do we need all those @Override ?

[Jeff Genender]

Yep...thats basically correct.

Its a protection for if you change a base method.  Normally w/o the
annotation, you would orphan any subclasses by changing a super class
signature.  With the @Override, the compiler throws an error and says
you are overriding a function that doesn't exist.  Its really good for
orphan control.  Its great because debugging these things can be awful
which is why I typically like them.  They have saved me many times ;-)

Jeff

Emmanuel Lecharny wrote:
> Alex Karasulu wrote:
>> Hey Mike, Jeff,
>>
>> Not denying these claims but just curious.  Can you guys educate me as to
>> how it works, or helps in these cases.  I never bothered to
>> investigate this
>> @Override tag.
>>   
> 
> Basically (and I'm not a user of this tag), it's helpfull when you want
> to override a method from an upper class and want to be sure that the
> API user won't call the wrong method by mistake.
> 
> For instance, suppose you override the compareTo method because the
> super.compareTo is not ok, and now suppose you misnamed the method
> (compareto with a lower 't'). The API user will use compareTo, and will
> call the super method instead of the one you want him to use.
> 
> With the @Override tag, this can't happen, because the compiler won't
> fine a compareto method, and will issue an error.
> 
> So, yes, it may be useful.
>> Thanks,
>> Alex
>>
>> On Thu, Jun 5, 2008 at 6:28 PM, Jeff Genender <[EMAIL PROTECTED]>
>> wrote:
>>
>>  
>>> I would keep them because they really help when there are changes in
>>> super classes during a compile.
>>>
>>> Jeff
>>>
>>> Emmanuel Lecharny wrote:
>>>
>>>> i guys,
>>>>
>>>> while browsing MINA's code, I see @Override used everywhere. I know it
>>>> can be helpful when overriding an existing method, but do you think we
>>>> need to keep them ?
>>>>
>>>> wdyt ?
>>>>
>>>>   
>>
>>   
> 
> 

Re: [VOTE] Releasing FtpServer 1.0.0-M3

[Jeff Genender]

+1

On Sep 4, 2008, at 12:44 PM, Alex Karasulu wrote:


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

Alex

Re:

[Jeff Genender]

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

On Nov 18, 2008, at 4:04 AM,  wrote:


Hi guys,

I think it's time to stop discussing for ever and to start a vote.

MINA 2.0.0-Mx is around for months now, and we have more and more  
users developing applications around it. We have tons of proposal to  
improve MINA, but many of them are pretty drastic, and may  
jeopardize our users' investment. OTOS, if we close MINA 2.0 now, we  
also close the door to some very important features and improvement  
we want to have in MINA, which will be differed for months if we  
start a 3.0.


So the best would be to determinate which strategy should be the  
best. Here is a proposal.


[] Continue to add new features to MINA 2.0 milestones until we  
reach a stable point

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

If we select (1), we will have to determinate the clear roadmap,  
otherwise we won't be able to release 2.0 before 2017...
If we pick (2), we have to check the open JIRAs, fix them, and  
define a timeframe for 2.0-RC1 release (and it should be a matter of  
weeks, not months)


Guys, it's up to you !

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

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

[Jeff Genender]

Great idea...great code!

On Nov 19, 2008, at 4:27 AM, Guillaume Nodet wrote:


I guess the next step is to start a formal vote about that, right ?
As I've been the only committer on the project, I don't think a
software grant would be needed for that.

On Thu, Nov 13, 2008 at 3:07 PM, Guillaume Nodet <[EMAIL PROTECTED]>  
wrote:

A few weeks ago, I've started a small project at googlecode to
implement an SSH server in Java based on Mina.
You'll find some background at http://gnodet.blogspot.com/

The project is still in its early stage and require a lot more work  
to

be fully usable, but I've been doing some tests and the basic SSH
protocol itself is implemented.
The project is available at http://code.google.com/p/sshd/

My thinking is that it would be a good candidate to become a
subproject of Mina (along with ftpserver and asyncweb), so i'm
starting this discussion to gauge the interest of the MINA TLP to  
host

such a subproject.

--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Open Source SOA
http://fusesource.com





--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Open Source SOA
http://fusesource.com

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

[Jeff Genender]

+1

Jeff


On Nov 20, 2008, at 2:52 AM, Guillaume Nodet wrote:


+1

On Thu, Nov 20, 2008 at 12:21 AM, Emmanuel Lecharny <[EMAIL PROTECTED] 
> wrote:

Hi guys,

Guillaume Nodet has written a SSH server based on MINA, and as we  
discussed
it last week, it would be interesting to have it as a subproject.  
It's time

for a formal vote then :

[] +1 Yes, accept the SSH server as a sub-project
[] +/-0 I don't really care
[] -1 Nope, it does not belong to MINA


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







--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Open Source SOA
http://fusesource.com

Re: [Vote] Release MINA 2.0.0-M4

[Jeff Genender]

+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: IntelliJ IDEA for development

[Jeff Genender]

They already offer open source licenses to Apache (and many other open  
source projects) as opposed to per-project.  Committers with  
apache.org addresses just need to apply.


Here is the info:

http://www.jetbrains.com/idea/buy/buy.jsp#openSource

Thanks,

Jeff


On Jan 21, 2009, at 3:58 AM, Ashish wrote:


JetBrains supports open source community, including ASF, by providing
individual licenses.
I was thinking for applying for Open Source License for MINA project

Should I go ahead and apply for it? Do we have any guidelines for  
the same?


I have used IntelliJ for a quite sometime and abandoned it couple of
months ago, as the new version was creating more trouble
than helping me. Lately I have been using MyEclipse for all my  
development.


The reason why I want to try it again is, IDEA is little lighter than
Eclipse (while running).

Any suggestions?

Re: [VOTE] Releasing FtpServer 1.0.0

[Jeff Genender]

+1

On Feb 22, 2009, at 6:06 PM, Erix Yao wrote:


+1

2009/2/23 Guillaume Nodet 


I've just downloaded the sources tar.gz and tried to build those.
The org.apache.ftpserver.clienttests.SuspendResumeTest is hanging
forever.  Is that a know thing ?

Also, the README.txt in the binary distribution seems quite outdated
(talking about 1.0-M2 and the incubator).

On Sat, Feb 21, 2009 at 21:29, Niklas Gustavsson >

wrote:

Hey,

this is the vote for the big one dot oh. After our two release
candidates, we have fixed two minor bugs and I think we're now ready
to go. After 1.0.0, we will start working on patch releases on the  
1.0

branch as well as new features for 1.1.

You can find the binaries and Maven artifacts here:
http://people.apache.org/~ngn/ftpserver/1.0.0/

These files was built from the following code:
https://svn.apache.org/repos/asf/mina/ftpserver/branches/1.0.0

Should be release the big guy?
[ ]: +1, Release FtpServer 1.0.0
[ ]: 0, Abstain
[ ]: -1, Don't release FtpServer 1.0.0

/niklas





--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Open Source SOA
http://fusesource.com

Re: AsyncWeb jars incomplete

[Jeff Genender]

Ditto for me... glad to see folks making use of this.  I could help a  
bit too, but my bandwidth is also tight.


Glad to see this come up again.

Jeff


On Mar 3, 2009, at 10:13 AM, Sangjin Lee wrote:

I was one of the people who were involved in bringing AHC over from  
the

Geronimo sandbox (where it was first developed) to under asyncweb.
Originally it was based on mina 1.1.x as at that time mina 2.0 was  
still in
its active development.  We did the bare minimum to make it compile  
against
mina 2.0 (but not necessarily all the runtime correctness), and  
merged them.

It landed at the org.apache.ahc package to avoid confusion with the
pre-existing client code that was under org.apache.asyncweb.client.
The intention has been that not only would we make it work correctly  
with
2.0, move to a common codec, subsume the existing client, etc. but  
also
would redesign the client.  Unfortunately, the momentum stalled  
because key
people who were most interested in making this happen (myself  
included)
didn't get to make the big push.  For me, my involvement was cut  
down for

reasons that are unrelated to the project.

Some discussion threads that may be of help:

http://tinyurl.com/djr4pa
http://tinyurl.com/azbpzg
http://tinyurl.com/dkrlzv
http://tinyurl.com/csonsf

Having said that, I'd love to see this get going again (although my
bandwidth on this is still quite limited).  I'd certainly be happy to
contribute what I can...

As a side note, there is a "working" version of the asyncweb client  
in the
1.0 branch.  This is almost the original version that is based on  
1.0, and I
think it is of production quality (we're using it in production).   
It hasn't
seen an official release however.  But please note that I don't  
think we
will (or should) support this in a serious manner.  Instead, we need  
to

focus our effort on the trunk version based on mina 2.0.  My 2 cents.

Thanks,
Sangjin


On Mon, Mar 2, 2009 at 8:34 AM, Jacob Tomaw   
wrote:



Emmanuel,

Your caution is understandable.  The only code change for the  
server is
setting up the MINA LoggingFilter, but clearly there might be  
changes in

MINA from M3 to M4 that affect the server in an unknown way.

I am very interested in improving AsyncWeb (at least the client  
portion).
My company is in the process of upgrading out 85+ application (no  
idea how

many JVMs) to use AHC to communicate with each other.

Is there someone already attached to the project who has a deep  
knowledge

of
AsyncWeb and has a direction they would like to see the project  
go?  Right
now there are to clients in the client dir and it is not clear what  
should
happen with the two of them and if any more transitioning need to  
take

place.

Thanks,
Jacob

On Fri, Feb 27, 2009 at 11:25 AM, Emmanuel Lecharny 
wrote:



Jacob Tomaw wrote:

I see that this is happening because the client is not completely  
moved

from
the ahc structure to the asyncweb.client structure.  It is also not

using

the common codec.

I am prepared to open jiras and create patches to clean this up.

However,

I
want to gauge the likelihood of these patches being integrated  
into the

trunk.  I see several jiras with ptches attached and not further

comment.

Neither acceptance or rejection.



Hi Jacob,

it's just a matter to find people interested in improving  
AsyncWeb ! I

will
have a look at the patches, and try to get them applied.  However,  
I have

a
very shallow knowledge about AsyncWeb code base, so I'm afraid it  
can

break

the server...


Thanks !

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






--
Jacob Tomaw
tfl:The Flatiron Life (http://tomaw.com)
Follow me on Twitter! (http://twitter.com/JacobTomaw)

Re: unable to send multiple messages simontanously

[Jeff Genender]

This is usually caused by an un-tuned IP stack in your OS.  These  
symptoms usually occur when you have hit the max sockets.  You  
generally hit this limit because your socket timeouts are set too high  
(it can be 30-60 seconds by default before the socket is released back  
to the OS).


I would Google tuning IP stacks for your particular OS and concentrate  
on upping your allowed sockets and setting your socket timeout/wait to  
1 second.  If you are sending all these calls from a single client,  
you may need to do this on the client too.


Jeff

On Mar 14, 2009, at 7:53 AM, Nagesh wrote:


Hi All,

I am testing the server load by trying to send multiple  messages
simontanously.

I am trying to create the 100 sessions and trying to
write  messages to those 100 session with a second gap.
but it starts sending up to some time after that it does not give
any exception and stops sending messages.

can any one suggest me what might be the problem and possible  
solution to

it.

any help is highly appreciated.

Thanks,
Ajay.