You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "Luke Hubbard (luke@codegent.com)" <ki...@gmail.com> on 2006/04/26 14:10:53 UTC

possible bug with reuseAddress + spring

Hi Guys,

We have run into a issue in 0.9.3 that wasnt a problem with 0.9.
reuseAddress property in spring has moved to socketAcceptorConfig.
Thats fine, I just updated our config files, but the problem is it doesnt
seem to work. We set it to true, but inside mina we can see its set to
false. With 0.9 it worked. Is this a know issue, should I add to jira (not
quite sure how but could find out). I quess I should have picked a stable
build but I needed some new methods you added to the Buffer.

Thanks for all the hard work, let me know if you want more info, or me to
post this bug somewhere else?

-- Luke

Re: Timing between MessageDecoder.decode and IoHandlerAdapter.sessionOpened

Posted by Samuel Doyle <sd...@yahoo.com>.
Doesn't look like that is the case. I placed my setup
code in session.created prior to adding the cusom
decoder to the filter chain and it appears to have
resolved the problem. 

I have a test harness for my prototype which basically
blasts requests to my MINA proxy server. It is very
much linked to my code at the moment.

S.D.

--- peter royal <pr...@apache.org> wrote:

> On Apr 27, 2006, at 2:12 PM, Samuel Doyle wrote:
> > Looks like it is possible for my custom decoder to
> get
> > invoked before sessionOpened takes place. Can
> anyone
> > confirm this? Should functionality I'm doing in
> > sessionOpened be moved to sessionCreated?
> 
> With TCP sessions, you should see sessionOpened
> occur prior to your  
> decoder being called.. Can you create a simple
> example of the problem?
> -pete
> 
> -- 
> proyal@apache.org - http://fotap.org/~osi
> 
> 
> 


Re: Timing between MessageDecoder.decode and IoHandlerAdapter.sessionOpened

Posted by peter royal <pr...@apache.org>.
On Apr 27, 2006, at 2:12 PM, Samuel Doyle wrote:
> Looks like it is possible for my custom decoder to get
> invoked before sessionOpened takes place. Can anyone
> confirm this? Should functionality I'm doing in
> sessionOpened be moved to sessionCreated?

With TCP sessions, you should see sessionOpened occur prior to your  
decoder being called.. Can you create a simple example of the problem?
-pete

-- 
proyal@apache.org - http://fotap.org/~osi



Re: Timing between MessageDecoder.decode and IoHandlerAdapter.sessionOpened

Posted by Samuel Doyle <sd...@yahoo.com>.
Looks like this was the case, moving some of setup
code to session.created instead of opened looks like
it resolved the problem. Can anyone confirm this?

Thanks, S.D.

--- Samuel Doyle <sd...@yahoo.com> wrote:

> Looks like it is possible for my custom decoder to
> get
> invoked before sessionOpened takes place. Can anyone
> confirm this? Should functionality I'm doing in
> sessionOpened be moved to sessionCreated?
> 
> Thanks, S.D.
> 

Timing between MessageDecoder.decode and IoHandlerAdapter.sessionOpened

Posted by Samuel Doyle <sd...@yahoo.com>.
Looks like it is possible for my custom decoder to get
invoked before sessionOpened takes place. Can anyone
confirm this? Should functionality I'm doing in
sessionOpened be moved to sessionCreated?

Thanks, S.D.

--- peter royal <pr...@apache.org> wrote:

> On Apr 27, 2006, at 12:09 PM, Luke Hubbard
> (luke@codegent.com) wrote:
> > How exactly does one go about adding the an issue
> to jira?
> > I may be being dumb, but I cant seem to find it.
> > Can someone post the url to the page where you
> submit a bug.
> 
>
https://issues.apache.org:443/jira/secure/CreateIssue!default.jspa
> 
> You probably have to be logged in. In the 'Project'
> select box, pick  
> 'Directory MINA'.
> -pete
> 
> -- 
> proyal@apache.org - http://fotap.org/~osi
> 
> 
> 


Re: possible bug with reuseAddress + spring

Posted by peter royal <pr...@apache.org>.
On Apr 27, 2006, at 12:09 PM, Luke Hubbard (luke@codegent.com) wrote:
> How exactly does one go about adding the an issue to jira?
> I may be being dumb, but I cant seem to find it.
> Can someone post the url to the page where you submit a bug.

https://issues.apache.org:443/jira/secure/CreateIssue!default.jspa

You probably have to be logged in. In the 'Project' select box, pick  
'Directory MINA'.
-pete

-- 
proyal@apache.org - http://fotap.org/~osi



Re: possible bug with reuseAddress + spring

Posted by "Luke Hubbard (luke@codegent.com)" <ki...@gmail.com>.
Hi Guys,

How exactly does one go about adding the an issue to jira?
I may be being dumb, but I cant seem to find it.
Can someone post the url to the page where you submit a bug.

Thanks,
Luke

On 4/27/06, Steven Gong <st...@gmail.com> wrote:
>
> On 4/27/06, Trustin Lee <tr...@gmail.com> wrote:
> >
> > On 4/26/06, Steven Gong <st...@gmail.com> wrote:
> > >
> > > I am not familiar with Mina's codebase, but I found something that
> might
> > > be
> > > the root cause of the problem. (the codebase is according to 0.9.3)
> > >
> > > In class o.a.m.transport.socket.nio.SocketAcceptorConfig line 39,
> > there's
> > > a
> > > declaration for sessionConfig and it's used in
> > > o.a.m.transport.socket.nio.support.SocketAcceptorDelegate line 408.
> The
> > > listening socket's reuseAddress property is set correctly
> > > o.a.m.transport.socket.nio.support.SocketAcceptorDelegate.registerNew
> (),
> > > but
> > > it's reset when a new socket session is created in line 408 with the
> > > 'sessionConfig' which has not been initialized correctly. IMHO the
> > > 'sessionConfig's properties need to be populated according to
> > > SocketAcceptorConfig's properties.
> > >
> > > I may be wrong but hope this will help.
> >
> >
> > Isn't serversocket's reuseAddress property different from the accepted
> > socket's reuseAddress property? They just affect different socket
> objects
> > IIRC.  If you want to set the accepted socket's reuseAddress, you have
> to
> > do
> > the following:
> >
> > SocketAcceptorConfig cfg = ...;
> > cfg.getSessionConfig().setReuseAddress(true);
> >
> > To change the server socket property:
> >
> > cfg.setReuseAddress(true);
> >
> > Please let me know if I am wrong.
>
>
> So how can I set the behaviour via spring?
>
> HTH,
> > Trustin
> > --
> > what we call human nature is actually human habit
> > --
> > http://gleamynode.net/
> > --
> > PGP key fingerprints:
> > * E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
> > * B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6
> >
> >
>
>
> --
> Best Regards
> Steven Gong
>
>

Re: possible bug with reuseAddress + spring

Posted by Steven Gong <st...@gmail.com>.
On 4/27/06, Trustin Lee <tr...@gmail.com> wrote:
>
> On 4/26/06, Steven Gong <st...@gmail.com> wrote:
> >
> > I am not familiar with Mina's codebase, but I found something that might
> > be
> > the root cause of the problem. (the codebase is according to 0.9.3)
> >
> > In class o.a.m.transport.socket.nio.SocketAcceptorConfig line 39,
> there's
> > a
> > declaration for sessionConfig and it's used in
> > o.a.m.transport.socket.nio.support.SocketAcceptorDelegate line 408. The
> > listening socket's reuseAddress property is set correctly
> > o.a.m.transport.socket.nio.support.SocketAcceptorDelegate.registerNew(),
> > but
> > it's reset when a new socket session is created in line 408 with the
> > 'sessionConfig' which has not been initialized correctly. IMHO the
> > 'sessionConfig's properties need to be populated according to
> > SocketAcceptorConfig's properties.
> >
> > I may be wrong but hope this will help.
>
>
> Isn't serversocket's reuseAddress property different from the accepted
> socket's reuseAddress property? They just affect different socket objects
> IIRC.  If you want to set the accepted socket's reuseAddress, you have to
> do
> the following:
>
> SocketAcceptorConfig cfg = ...;
> cfg.getSessionConfig().setReuseAddress(true);
>
> To change the server socket property:
>
> cfg.setReuseAddress(true);
>
> Please let me know if I am wrong.


So how can I set the behaviour via spring?

HTH,
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP key fingerprints:
> * E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
> * B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6
>
>


--
Best Regards
Steven Gong

Re: possible bug with reuseAddress + spring

Posted by Trustin Lee <tr...@gmail.com>.
On 4/26/06, Steven Gong <st...@gmail.com> wrote:
>
> I am not familiar with Mina's codebase, but I found something that might
> be
> the root cause of the problem. (the codebase is according to 0.9.3)
>
> In class o.a.m.transport.socket.nio.SocketAcceptorConfig line 39, there's
> a
> declaration for sessionConfig and it's used in
> o.a.m.transport.socket.nio.support.SocketAcceptorDelegate line 408. The
> listening socket's reuseAddress property is set correctly
> o.a.m.transport.socket.nio.support.SocketAcceptorDelegate.registerNew(),
> but
> it's reset when a new socket session is created in line 408 with the
> 'sessionConfig' which has not been initialized correctly. IMHO the
> 'sessionConfig's properties need to be populated according to
> SocketAcceptorConfig's properties.
>
> I may be wrong but hope this will help.


Isn't serversocket's reuseAddress property different from the accepted
socket's reuseAddress property? They just affect different socket objects
IIRC.  If you want to set the accepted socket's reuseAddress, you have to do
the following:

SocketAcceptorConfig cfg = ...;
cfg.getSessionConfig().setReuseAddress(true);

To change the server socket property:

cfg.setReuseAddress(true);

Please let me know if I am wrong.

HTH,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6

Re: possible bug with reuseAddress + spring

Posted by Steven Gong <st...@gmail.com>.
Hi Niklas,

On 4/26/06, Niklas Therning <ni...@trillian.se> wrote:
>
> Luke Hubbard (luke@codegent.com) wrote:
> > Hi Guys,
> >
> > We have run into a issue in 0.9.3 that wasnt a problem with 0.9.
> > reuseAddress property in spring has moved to socketAcceptorConfig.
> > Thats fine, I just updated our config files, but the problem is it
> doesnt
> > seem to work. We set it to true, but inside mina we can see its set to
> > false. With 0.9 it worked. Is this a know issue, should I add to jira
> (not
> > quite sure how but could find out). I quess I should have picked a
> stable
> > build but I needed some new methods you added to the Buffer.
> >
> > Thanks for all the hard work, let me know if you want more info, or me
> to
> > post this bug somewhere else?
> >
> > -- Luke
> >
>
> It's probably a bug. Please report this to JIRA and I'll look into it.
> If possible, please attach the relevant parts of your Spring config file
> as well.


I am not familiar with Mina's codebase, but I found something that might be
the root cause of the problem. (the codebase is according to 0.9.3)

In class o.a.m.transport.socket.nio.SocketAcceptorConfig line 39, there's a
declaration for sessionConfig and it's used in
o.a.m.transport.socket.nio.support.SocketAcceptorDelegate line 408. The
listening socket's reuseAddress property is set correctly
o.a.m.transport.socket.nio.support.SocketAcceptorDelegate.registerNew(), but
it's reset when a new socket session is created in line 408 with the
'sessionConfig' which has not been initialized correctly. IMHO the
'sessionConfig's properties need to be populated according to
SocketAcceptorConfig's properties.

I may be wrong but hope this will help.

Thanks!
>
> /Niklas
>



--
Best Regards
Steven Gong

Re: possible bug with reuseAddress + spring

Posted by Niklas Therning <ni...@trillian.se>.
Luke Hubbard (luke@codegent.com) wrote:
> Hi Guys,
> 
> We have run into a issue in 0.9.3 that wasnt a problem with 0.9.
> reuseAddress property in spring has moved to socketAcceptorConfig.
> Thats fine, I just updated our config files, but the problem is it doesnt
> seem to work. We set it to true, but inside mina we can see its set to
> false. With 0.9 it worked. Is this a know issue, should I add to jira (not
> quite sure how but could find out). I quess I should have picked a stable
> build but I needed some new methods you added to the Buffer.
> 
> Thanks for all the hard work, let me know if you want more info, or me to
> post this bug somewhere else?
> 
> -- Luke
> 

It's probably a bug. Please report this to JIRA and I'll look into it.
If possible, please attach the relevant parts of your Spring config file
as well.

Thanks!

/Niklas