答复: can anyone do me a favour

[张园]

Hi Trustin,
Sorry to bother you ,I got the reason ,it's my misunderstanding.

Best  regards,
Andy (张园)
Mobile Internet Division
---
Address: Building A9,Neusoft Park,No.2 Xinxiu Street,Hunnan 
 Industrial Park ,Shenyang 110179, PRC
Tel: +86 024 83669709 13998390079
  Email:[EMAIL PROTECTED]
Website: http://www.neusoft.com 


-邮件原件-
发件人: Trustin Lee [mailto:[EMAIL PROTECTED] 
发送时间: 2008年1月15日 15:09
收件人: dev@mina.apache.org
主题: Re: can anyone do me a favour

Hi Andy,

2008/1/14 张园 <[EMAIL PROTECTED]>:
> My dear friends,
>
> I got a question when I read the source code,how is the SocketIoProcessor
> class dealing the situation that the buf is smaller than the data expected
> in the SocketChannel?

If the allocated read buffer is smaller than the data to be read,
SocketIoProcessor will read it again in the next read loop, with the
increased read buffer size.  It's exactly what the source code you
pasted is doing.

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6



--
Confidentiality Notice: The information contained in this e-mail and any 
accompanying attachment(s) is intended only for the use of the intended 
recipient and may be confidential and/or privileged of Neusoft Group Ltd., its 
subsidiaries and/or its affiliates. If any reader of this communication is not 
the intended recipient, unauthorized use, forwarding, printing, storing, 
disclosure or copying is strictly prohibited, and may be unlawful. If you have 
received this communication in error, please immediately notify the sender by 
return e-mail, and delete the original message and all copies from your system. 
Thank you. 
---

Re: Strange Problem with IoProcessor

[Geoff Cadien]

On Jan 15, 2008 9:55 PM, Trustin Lee <[EMAIL PROTECTED]> wrote:

> Hi Geoff,
>
> Thank you so much for the detailed report first of all.
>
> On Jan 11, 2008 2:28 PM, Geoff Cadien <[EMAIL PROTECTED]> wrote:
> > Linux
> > Java 1.6.0_03
> > Mina 2.0 trunk
> >
> > I've run into a difficult to reproduce problem when using NioConnector.
>  The
> > setup looks something like this (if I'm doing something wrong let me
> know)
> >
> >
> > NioConnector connector = new NioConnector(4)
> > connector.getFilterChain().addLast("protocolFilter", new
> > ProtocolCodecFilter(encoder, decoder));
> > connector.setHandler(new Handler());
> >
> > Here is sessionOpened fromt he Handler.
> >
> > public void sessionOpened(IoSession session) {
> > session.write(...);
> > }
> >
> > Both sessionCreated() and sessionOpened() are called and I know that the
> > request is written.  But no other handler methods are ever called
> > (messageReceived, sessionIdle, exceptionCaught,  or sessionClosed).  Now
> > this happens only very rarely, probably < 1% of the time, under heavy
> load.
> > I did a thread dump and noticed that  each time this occurred there was
> a
> > NioProcessor still executing, and it never exited.  With some well
> placed
> > debugging I was able to determine that inside the
> > AbstractPollingIoProcecess$Worker.run() the nSession local is 1 and
> never
> > changes, so the Worker never exits.  Also allSessions() returns no
> > sessions.  So it seems as though the session has just disappeared.
>
> What happens you disconnect the connection?  Is nSession decreased to
> 0 and does NioProcessor exit?  Please let us keep updated.
>
> Actually the NioProcessor never exits, that's what was disturbing.
> nSessions stays at >= 1 and never exits even when all tcp connections have
> been terminated (verified with netstat).  I have been unable to reproduce
> the problem with any small test cases, either using the mina examples or one
> of my own.  Even in my application it happens rarely.  I wish I had more
> information to provide, but at this point I don't. :(


Thanks,

-geoff

Re: Strange Problem with IoProcessor

[Trustin Lee]

Could you svn up now and try again?  I might have fixed the problem -
not sure enough though. :)

HTH,
Trustin

On Jan 16, 2008 1:55 PM, Trustin Lee <[EMAIL PROTECTED]> wrote:
> Hi Geoff,
>
> Thank you so much for the detailed report first of all.
>
> On Jan 11, 2008 2:28 PM, Geoff Cadien <[EMAIL PROTECTED]> wrote:
> > Linux
> > Java 1.6.0_03
> > Mina 2.0 trunk
> >
> > I've run into a difficult to reproduce problem when using NioConnector.  The
> > setup looks something like this (if I'm doing something wrong let me know)
> >
> >
> > NioConnector connector = new NioConnector(4)
> > connector.getFilterChain().addLast("protocolFilter", new
> > ProtocolCodecFilter(encoder, decoder));
> > connector.setHandler(new Handler());
> >
> > Here is sessionOpened fromt he Handler.
> >
> > public void sessionOpened(IoSession session) {
> > session.write(...);
> > }
> >
> > Both sessionCreated() and sessionOpened() are called and I know that the
> > request is written.  But no other handler methods are ever called
> > (messageReceived, sessionIdle, exceptionCaught,  or sessionClosed).  Now
> > this happens only very rarely, probably < 1% of the time, under heavy load.
> > I did a thread dump and noticed that  each time this occurred there was a
> > NioProcessor still executing, and it never exited.  With some well placed
> > debugging I was able to determine that inside the
> > AbstractPollingIoProcecess$Worker.run() the nSession local is 1 and never
> > changes, so the Worker never exits.  Also allSessions() returns no
> > sessions.  So it seems as though the session has just disappeared.
>
> What happens you disconnect the connection?  Is nSession decreased to
> 0 and does NioProcessor exit?  Please let us keep updated.
>
> Thanks,
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>



-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: Strange Problem with IoProcessor

[Trustin Lee]

Hi Geoff,

Thank you so much for the detailed report first of all.

On Jan 11, 2008 2:28 PM, Geoff Cadien <[EMAIL PROTECTED]> wrote:
> Linux
> Java 1.6.0_03
> Mina 2.0 trunk
>
> I've run into a difficult to reproduce problem when using NioConnector.  The
> setup looks something like this (if I'm doing something wrong let me know)
>
>
> NioConnector connector = new NioConnector(4)
> connector.getFilterChain().addLast("protocolFilter", new
> ProtocolCodecFilter(encoder, decoder));
> connector.setHandler(new Handler());
>
> Here is sessionOpened fromt he Handler.
>
> public void sessionOpened(IoSession session) {
> session.write(...);
> }
>
> Both sessionCreated() and sessionOpened() are called and I know that the
> request is written.  But no other handler methods are ever called
> (messageReceived, sessionIdle, exceptionCaught,  or sessionClosed).  Now
> this happens only very rarely, probably < 1% of the time, under heavy load.
> I did a thread dump and noticed that  each time this occurred there was a
> NioProcessor still executing, and it never exited.  With some well placed
> debugging I was able to determine that inside the
> AbstractPollingIoProcecess$Worker.run() the nSession local is 1 and never
> changes, so the Worker never exits.  Also allSessions() returns no
> sessions.  So it seems as though the session has just disappeared.

What happens you disconnect the connection?  Is nSession decreased to
0 and does NioProcessor exit?  Please let us keep updated.

Thanks,
Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: [VOTE] Release Apache MINA 1.0.9 and 1.1.6.

[Trustin Lee]

On Jan 15, 2008 4:19 PM, Trustin Lee <[EMAIL PROTECTED]> wrote:
> [X]: +1, Release

Cheers,
Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

reply: can anyone do me a favour

[张园]

Hi Trustin,
I am really grateful for you fast reply.
as you say,I got confused , the next read loop is invoked by
Selector.select().Reading remaining data of the turn which left in the
buffer depends on the next read loop,what if Selector.select() won't return
again until  a long long time?What if the client already finished its
sending of data which never cause the return of Selector.select()?In that
case ,is it the remaining data left in the buffer unreachable or neglected?


Best  regards,
Andy (张园)
Mobile Internet Division
---
Address: Building A9,Neusoft Park,No.2 Xinxiu Street,Hunnan 
 Industrial Park ,Shenyang 110179, PRC
Tel: +86 024 83669709 13998390079
  Email:[EMAIL PROTECTED]
Website: http://www.neusoft.com 


-邮件原件-
发件人: Trustin Lee [mailto:[EMAIL PROTECTED] 
发送时间: 2008年1月15日 15:09
收件人: dev@mina.apache.org
主题: Re: can anyone do me a favour

Hi Andy,

2008/1/14 张园 <[EMAIL PROTECTED]>:
> My dear friends,
>
> I got a question when I read the source code,how is the SocketIoProcessor
> class dealing the situation that the buf is smaller than the data expected
> in the SocketChannel?

If the allocated read buffer is smaller than the data to be read,
SocketIoProcessor will read it again in the next read loop, with the
increased read buffer size.  It's exactly what the source code you
pasted is doing.

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6



--
Confidentiality Notice: The information contained in this e-mail and any 
accompanying attachment(s) is intended only for the use of the intended 
recipient and may be confidential and/or privileged of Neusoft Group Ltd., its 
subsidiaries and/or its affiliates. If any reader of this communication is not 
the intended recipient, unauthorized use, forwarding, printing, storing, 
disclosure or copying is strictly prohibited, and may be unlawful. If you have 
received this communication in error, please immediately notify the sender by 
return e-mail, and delete the original message and all copies from your system. 
Thank you. 
---

Question about mina availability wrt next release

[parki]

Hello!

I have been using mina successfully in a project I'm working on - a key
requirement is to be able to open a long running HTTP connection and then
send packets both ways asynchronously and to not consume threads per
connection. I was able to get mina to work (easy) - running with a somewhat
outdated version taken from the development trunk.

There is one issue - if the client application sends more than one HTTP
requests with no delay, this can cause a problem in the HttpRequestDecoder
and things go awry (as the decoder "sees" a request and a half and gets
confused). My fix for now is to ensure that there is a time delay (like ~ 10
ms) which avoids the issue.

I noted this a here in the forum a while ago, and was instructed to grab a
newer version, as this was being worked on at the time. I instead chose to
keep with what I have, and to wait until the next release.

So, I guess my question is two-fold:

1. Does this problem in the HttpRequestDecoder ring any bells?

2. When would be a good time to plan the work of ditching the old dev
version of mina and upgrading to one with the changes planned for the HTTP
stuff?

I'm not in that much of a hurry, just wondering (and thinking of when to
plan the refactoring exercise on my side).

Any help is appreciated.

Thanks - it's great stuff.

Regards,

parki...

-- 
View this message in context: 
http://www.nabble.com/Question-about-mina-availability-wrt-next-release-tp14851428s16868p14851428.html
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.

Network Newbee Question

[skrasnigor]

I am currently using Mina in a simple client/server application using UDP (a
requirement by the external asset we communicate with). For the next
iteration of our application we need to handle communications with multiple
assets instead of one. I am trying to figure out how best to handle this.
One idea I am toying with, but not sure it is feasable, is having a master
server that is listening on all ports. When an external asset sends data to
our server over a port of their choice, I would create a new client/server
pair that would service the external asset over the port that the message
arrived on. Comms would then proceed with this client/server pair until
comms are no longer needed with the asset and the pair is terminated. If
this sounds doable (or makes sense), how best would this be accomplished
with Mina? Any guidance would be appreciated. Thanks.
-- 
View this message in context: 
http://www.nabble.com/Network-Newbee-Question-tp14848463s16868p14848463.html
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.

Re: [VOTE] Release Apache MINA 1.0.9 and 1.1.6.

[Alex Karasulu]

+1

On Jan 15, 2008 7:26 AM, Maarten Bosteels <[EMAIL PROTECTED]> wrote:

> +1 release
>
> On Jan 15, 2008 12:19 PM, Julien Vermillard <[EMAIL PROTECTED]>
> wrote:
> > On Tue, 15 Jan 2008 16:19:06 +0900
> > "Trustin Lee" <[EMAIL PROTECTED]> wrote:
> >
> > > Hi community,
> > >
> > > We have fixed 6 issues in 1.0.9 and 1.1.6 since 1.0.8 and 1.1.5.  The
> > > following URL shows the list of the fixed issues:
> > >
> > >
> https://issues.apache.org/jira/browse/DIRMINA?report=com.atlassian.jira.plugin.system.project:roadmap-panel
> > >
> > > [ ]: +1, Release
> > > [ ]: 0, Abstain
> > > [ ]: -1, Don't release
> > >
> > > Cheers,
> > > Trustin
> >
> > +1 release.
> >
> > Julien
> >
> >
>

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: [DISCUSS] Time to move AsyncHttpClient out of Sandbox

[Sangjin Lee]

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: [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

[Sangjin Lee]

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

[OT] Introducing Log2Log project

[Trustin Lee]

Hi,

As discussed last year, I've just finished the first implementation of
Log2Log project.  It's a bytecode manipulation tool that modifies a
JAR to use your favorite logging framework instead of the logging
framework which was employed by the original JAR.

For example, you might want to create a new application on top of
existing two JARs that depend on different logging frameworks (e.g.
Log4J and SLF4J).  Now you have three more JARs (log4j.jar,
slf4j-api.jar and slf4j-log4j12.jar) in your classpath just for
logging.  What makes things worse is when your application is using
other logging framework such as JBoss Common Logging Framework.
Log2Log can remove the three unnecessary JARs very easily.

Please feel free to download and try it and let me know if it's useful
or not.  After unpacking, run bin/log2log and it will show you some
examples and usage in your console:

* http://tinyurl.com/yv9wo2

I did my best to cover the popular methods and classes of all known
logging frameworks.  Please let me know if the conversion fails; I
want to cover as much as possible, except for configuration-related
classes and methods.

Plus, I think the modified JAR will preserve all the debugging
information like line numbers, so it won't lead you to difficulties in
debugging.

To-do:
* Ant task
* Maven 2 plugin

Cheers,
Trustin

PS: Log2Log will fail to convert the current MINA snapshot because of
IoSessionLogger which extends SLF4J Logger.  Once IoSessionLogger goes
away, it should work.
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: SSLFilter problem on closing connection

[Kerekes András]

Hi,

after checking JIRA, I found this:

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

Which was closed with the following note:
"It's not actually a bug. An SSLException can be sometimes thrown while 
destroying the session if the connection was closed abnormally. You can 
simply ignore that exception. That's why I logged that message in DEBUG 
level."


So I can ignore this exception. But for me it still occurs on every call 
to session.close(), not only sometimes.


Cheers,
András
[ Show »  ]
Trustin Lee 
 - 
10/Oct/06 06:29 PM It's not actually a bug. An SSLException can be 
sometimes thrown while destroying the session if the connection was 
closed abnormally. You can simply ignore that exception. That's why I 
logged that message in DEBUG level.



Kerekes András wrote:


Hi,

did anybody encounter the problem described below using SSL?

Cheers,
András

Kerekes András wrote:

Hi,

I found an interesting issue when using SSL communication in Mina 
1.1.5 (and 1.1.3) . I use a custom protocol with custom message 
classes, one of them is LogoutMessage. When this is sent, it signals 
the server that the client is finishing the communication. After 
sending the LogoutMessage and receiving the corresponding response 
the client closes the session with: ioSession.close().join()


And this throws an exception:

Unexpected exception from SSLEngine.closeInbound().
javax.net.ssl.SSLException: Inbound closed before receiving peer's 
close_notify: possible truncation attack?
   at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown 
Source)

   at com.sun.net.ssl.internal.ssl.SSLEngineImpl.fatal(Unknown Source)
   at com.sun.net.ssl.internal.ssl.SSLEngineImpl.fatal(Unknown Source)
   at com.sun.net.ssl.internal.ssl.SSLEngineImpl.closeInbound(Unknown 
Source)
   at 
org.apache.mina.filter.support.SSLHandler.destroy(SSLHandler.java:167)

   at org.apache.mina.filter.SSLFilter.sessionClosed(SSLFilter.java:367)
   at 
org.apache.mina.common.support.AbstractIoFilterChain.callNextSessionClosed(AbstractIoFilterChain.java:269) 

   at 
org.apache.mina.common.support.AbstractIoFilterChain.access$800(AbstractIoFilterChain.java:53) 

   at 
org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.sessionClosed(AbstractIoFilterChain.java:633) 

   at 
org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java:230) 

   at 
org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(ExecutorFilter.java:264) 

   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown 
Source)

   at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
   at 
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51) 


   at java.lang.Thread.run(Unknown Source)

The server closes the connection normally. We made extensive 
debugging and it seems the when the client closes the session and the 
SSLFilter calls the initiateClosure method it sends the 
close_notification to the server but does not receive the 
confirmation from the server side. The same happens when the server 
initiates the closing of the session after sending the 
LogoutResponse, but this time the exception is thrown at the server 
side.


The reason for this behavior seems to be that the IoSession is 
removed in the SocketIoProcessor's worker thread at the doRemove() 
call, and the execution hits the 'break;' line so the infinite loop 
terminates and by the time the response (confirming the close 
notification) from the other end of the communication arrives there 
is no IoProcessor to process the message and let the SSLFilter close 
the SSL session properly.


I've attached a small example which produces this issue.

Is it a bug or am I doing something wrong?

Thanks for the help!
Andras

Problems closing connections

[Matteo Merli]

Hi,

I'm having some problems in closing connections in a Mina 2.0 server
(today updated svn, but the issue was already present)

Basically, I'm notiicing that when I do a  connection.close() a FIN
packet is not being sent to the client. Mina will consider the session
as closed, but the client will not notice it.

Trying to dig the problem (suspecting it was in my code) I took the
"Echo server" example and changed it to close connection after the 1st
response is sent:

session.write(((IoBuffer) message).duplicate()).addListener(
IoFutureListener.CLOSE );

This is showing the same problem: no FIN packet is sent by the server.
I've attached a tcpdump capture of the echo example.

Is there some detail that I'm missing?

Thank you,
Matteo

-- 
Matteo Merli
<[EMAIL PROTECTED]>

[jira] Commented: (DIRMINA-507) IoBuffer: Support prepending data

[David M. Lloyd (JIRA)]

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

David M. Lloyd commented on DIRMINA-507:


Only if you copy the data - I'm proposing that a mechanism be added to reserve 
space at the start of the buffer.  This way you could prepend data without 
incurring the overhead of copying.

> IoBuffer: Support prepending data
> -
>
> Key: DIRMINA-507
> URL: https://issues.apache.org/jira/browse/DIRMINA-507
> Project: MINA
>  Issue Type: New Feature
>  Components: Core
>Reporter: David M. Lloyd
>Priority: Minor
>
> I'd like to see IoBuffer enhanced to support prepending data.  It could work 
> as follows:
> * A means to specificy or reserve space should be provided.  An 
> IoBuffer.reserve() method could do the trick, and maybe a 3-parameter version 
> of IoBuffer.  IoBuffer.reserve() would keep the position at zero, but 
> decrease the capacity and limit by the given number of bytes, and move the 
> buffer start up by the given number of bytes.
> * A means to reclaim the space must be provided.  An IoBuffer.reclaim() would 
> work by moving the buffer start back down by the given amount, maybe 
> returning a slice to the recovered area.  Or another alternative would be to 
> have a series of prepend* methods which would prepend bytes/ints/etc. similar 
> to put*(), but rather than adding to the end of the buffer, they would add to 
> the beginning, moving the buffer start back down to the start of the 
> just-written data.  Though I'm not sure how helpful it would be to add 
> another dozen methods to a class that already has probably over a hundred 
> methods.
> * Care should be taken that the mechanism to prepend data does not allow a 
> user to "escape" a buffer slice.

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

Re: ProtocolDecoderException.getHexDump always returns 'empty'

[Hakan Guleryuz]

Trustin,

Yes, it works.

Thanks for the fast fix. 
Hakan.


Trustin Lee wrote:
> 
> Hi Hakan,
> 
> I've just checked in the fix.  Please let me know if it works or not.
> 
> Thanks,
> Trustin
> 
> On Jan 10, 2008 8:45 PM, Hakan Guleryuz <[EMAIL PROTECTED]> wrote:
>>
>> Hi,
>> I have extended DemuxingProtocolCodecFactory with multiple codecs
>> attached,
>> When I send a message that is not parsed by any of the codecs I receive
>> the
>> ProtocolDecoderException exception from my handler:
>> public void exceptionCaught(IoSession session, Throwable cause) throws
>> Exception
>> in my IoHandlerAdapter
>>
>> but here ProtocolDecoderException.getHexDump is always empty.
>>
>> The cause is here at the doDecode method of DemuxingProtocolCodecFactory
>> .CumulativeProtocolDecoder class
>> if (undecodables == decoders.length) {
>> // Throw an exception if all decoders cannot decode
>> data.
>> String dump = in.getHexDump();
>> in.position(in.limit()); // Skip data
>> throw new ProtocolDecoderException(
>> "No appropriate message decoder: " + dump);
>> }
>> It should be changed to something like
>> if (undecodables == decoders.length) {
>> // Throw an exception if all decoders cannot decode
>> data.
>> String dump = in.getHexDump();
>> in.position(in.limit()); // Skip data
>> ProtocolDecoderException e =  new
>> ProtocolDecoderException(
>> "No appropriate message decoder: " + dump);
>> e.setHexDump(dump); <-- I believe, this
>> is
>> missed here
>> throw e;
>> }
>>
>> I have checked the source of 1.1.5 and the issue was still there.
>>
>> Thank you for all the efforts in the Mina framework.
>> Hakan.
>> --
>> View this message in context:
>> http://www.nabble.com/ProtocolDecoderException.getHexDump-always-returns-%27empty%27-tp14731177s16868p14731177.html
>> Sent from the Apache MINA Support Forum mailing list archive at
>> Nabble.com.
>>
>>
> 
> 
> 
> -- 
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
> 
> 

-- 
View this message in context: 
http://www.nabble.com/ProtocolDecoderException.getHexDump-always-returns-%27empty%27-tp14731177s16868p14839838.html
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.

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

[Kevan Miller]

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

Re: [VOTE] Release Apache MINA 1.0.9 and 1.1.6.

[Maarten Bosteels]

+1 release

On Jan 15, 2008 12:19 PM, Julien Vermillard <[EMAIL PROTECTED]> wrote:
> On Tue, 15 Jan 2008 16:19:06 +0900
> "Trustin Lee" <[EMAIL PROTECTED]> wrote:
>
> > Hi community,
> >
> > We have fixed 6 issues in 1.0.9 and 1.1.6 since 1.0.8 and 1.1.5.  The
> > following URL shows the list of the fixed issues:
> >
> > https://issues.apache.org/jira/browse/DIRMINA?report=com.atlassian.jira.plugin.system.project:roadmap-panel
> >
> > [ ]: +1, Release
> > [ ]: 0, Abstain
> > [ ]: -1, Don't release
> >
> > Cheers,
> > Trustin
>
> +1 release.
>
> Julien
>
>

Re: [VOTE] Release Apache MINA 1.0.9 and 1.1.6.

[Julien Vermillard]

On Tue, 15 Jan 2008 16:19:06 +0900
"Trustin Lee" <[EMAIL PROTECTED]> wrote:

> Hi community,
> 
> We have fixed 6 issues in 1.0.9 and 1.1.6 since 1.0.8 and 1.1.5.  The
> following URL shows the list of the fixed issues:
> 
> https://issues.apache.org/jira/browse/DIRMINA?report=com.atlassian.jira.plugin.system.project:roadmap-panel
> 
> [ ]: +1, Release
> [ ]: 0, Abstain
> [ ]: -1, Don't release
> 
> Cheers,
> Trustin

+1 release.

Julien

Re: [VOTE] Release Apache MINA 1.0.9 and 1.1.6.

[Emmanuel Lecharny]

[X]: +1, Release
  



Cheers,
Trustin
  

Good to see you back :) And with good news !


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

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

[Julien Vermillard]

On Mon, 14 Jan 2008 23:30:15 -0700
Jeff Genender <[EMAIL PROTECTED]> wrote:

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

Hi,

If the contributions was large enough, perhaps an we simply base
our vote on the commits realised on the AHC in the Geronimo sandbox ? 

Disclamer : I'm not really fluent with ASF written and non-written
rules :)

Julien

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

[Maarten Bosteels (JIRA)]

get rid of IoSessionLogger 
---

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


It seems like the next version of SLF4J is going to support MDC for  
java.util.logging 
The users who use java.util.logging as their logging framework will have access 
to MDC
so that they can implement a formatter which prints out the MDC content. 
This means we can get rid of IoSessionLogger completely and rely on 
MdcInjectionFilter

However, probably SLF4J won't provide a MDC-aware Formatter implementation for 
java.util.logging, so we might need to include it
in org.apache.mina.util package as an alternative solution.


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