You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Chris Allen <mr...@gmail.com> on 2005/12/27 17:12:17 UTC
[MINA] ReconnectFilter
Niklas wrote:
>We have plans to implement a ReconnectFilter for MINA. There is a patch
>in JIRA but it hasn't been applied yet. It may be used to automatically
>reconnect a session which has been closed.
Any idea when this might be completed? Did you guys start this at all, and
if so, is there someplace I can find the source of it?
Thanks,
Chris
Re: [MINA] Socket and Session Buffer Size
Posted by Trustin Lee <tr...@gmail.com>.
Hi Alex,
I'm sorry for this late response. As you know, it was holiday. :)
2005/12/29, Alessandro Torrisi <al...@eurone.it>:
>
> Hi ! In this code snippet I set some parameters for the socket of the
> client and for session, I'm trying some values...but can someone explain
> me first the difference between a "SessionReceiveBufferSize" and a
> "SendBufferSize",
SendBufferSize is the actual size of the Socket read buffer in kernel
level. ReceiveBufferSize is the actual size of the Socket write buffer in
kernel level, too. SessionReceiveBufferSize the size of allocated
ByteBuffer that MINA allocates to read the kernel socket read buffer in.
and then what are the best values according to you for connections based
> on a P2P network based on Ethernet ? Could these parameters affect
> performances ?
I don't know the optimal value for now. You'll have to perform the
benchmark test by yourself.
HTH,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
PGP Key ID: 0x854B996C
[MINA] Socket and Session Buffer Size
Posted by Alessandro Torrisi <al...@eurone.it>.
Hi ! In this code snippet I set some parameters for the socket of the
client and for session, I'm trying some values...but can someone explain
me first the difference between a "SessionReceiveBufferSize" and a
"SendBufferSize",
and then what are the best values according to you for connections based
on a P2P network based on Ethernet ? Could these parameters affect
performances ?
....
@Override
public void sessionCreated(IoSession session) throws Exception {
if (session instanceof SocketSession) {
SocketSession sock = (SocketSession) session;
sock.setSessionReceiveBufferSize(4096);
sock.setReceiveBufferSize(4096);
sock.setSendBufferSize(4096);
}
....
Thanks in advance,
Alex
Re: [MINA] ReconnectFilter
Posted by Chris Allen <mr...@gmail.com>.
Yeah, that is cool. Sometimes you just have to get it done. I hear ya. ;-)
Anyway, it's working well for me. I did have some trouble integrating
it with Spring, as I needed reference to my IoConnection before it was
setup and passing this filter into the Application context at start up
caused a circular reference error. I ended up handling it by making
the ReconnectionFilter implement Spring's ApplicationContectAware
interface and getting the IoConnection bean only when the closed
connection event was triggered. I don't particularly like having this
class know about Spring, and also have\ing to know what I named the
IoConnection bean, but I couldn't think of a better solution at the
time. If anyone has any other suggestions let me know.
I'm also planning on adding a limit to the amount of times that the
filter tries to reconnect, just in case the server it's trying to
establish the connection with really is down.
-Chris
On 12/28/05, Julien Vermillard <jv...@archean.fr> wrote:
> Yes you are right, but I use it that way :
>
> session.getFilterChain().addLast("reconnection",new
> ReconnectionFilter(2000,connector,ATMess.this,session.getRemoteAddress(),session.getLocalAddress()));
>
> It was a lazy solution for postponing implemention all the constructor :)
>
> Julien
>
> Le mardi 27 décembre 2005 à 12:35 -0500, Chris Allen a écrit :
>
>
> Hi Julien,
>
> After writing the last email and doing a little more research, I guess the
> thing to do to make your ReconnectionFilter as flexible as possible, would
> be to allow each of the IoConnector.connect() methods to work with this
> class. As you can see in the MINA JavaDocs:
> http://directory.apache.org/subprojects/network/apidocs/org/apache/mina/common/IoConnector.html
> there are four different versions of connect() and the filter currently only
> supports one of them.
>
> The easiest way that I can see to accomplish this is to provide multiple
> constructors for the ReconnectionFilter class that account for each of these
> connection methods. I've currently added my own with the single
> SocketAddress, but for a truly flexible filter I guess it would have to
> support the others as well.
>
> Anyway, I know this is a work in progress, but I just thought that I should
> mention it, even though it's super obvious.
>
> Thanks again for letting me know where to find this class, and for creating
> it in the first place.
>
> -Chris
Re: [MINA] ReconnectFilter
Posted by Julien Vermillard <jv...@archean.fr>.
Yes you are right, but I use it that way :
session.getFilterChain().addLast("reconnection",new
ReconnectionFilter(2000,connector,ATMess.this,session.getRemoteAddress(),session.getLocalAddress()));
It was a lazy solution for postponing implemention all the
constructor :)
Julien
Le mardi 27 décembre 2005 à 12:35 -0500, Chris Allen a écrit :
> Hi Julien,
>
> After writing the last email and doing a little more research, I guess
> the thing to do to make your ReconnectionFilter as flexible as
> possible, would be to allow each of the IoConnector.connect() methods
> to work with this class. As you can see in the MINA JavaDocs:
> http://directory.apache.org/subprojects/network/apidocs/org/apache/mina/common/IoConnector.html there are four different versions of connect() and the filter currently only supports one of them.
>
> The easiest way that I can see to accomplish this is to provide
> multiple constructors for the ReconnectionFilter class that account
> for each of these connection methods. I've currently added my own
> with the single SocketAddress, but for a truly flexible filter I guess
> it would have to support the others as well.
>
> Anyway, I know this is a work in progress, but I just thought that I
> should mention it, even though it's super obvious.
>
> Thanks again for letting me know where to find this class, and for
> creating it in the first place.
>
> -Chris
>
>
> On 12/27/05, Chris Allen <mr...@gmail.com> wrote:
>
> Hi Julien,
>
> I'm looking at your filter and have one question about how to
> use it. In the constructor you have two SocketAddresses. One
> is local and the other is not. Can you explain what the
> difference is between the two?
>
> public ReconnectionFilter(int delay, IoConnector connector,
> IoHandler handler, SocketAddress address,
> SocketAddress localAddress)
>
> Also, if I'm creating my initial connection with something
> like this, I only have one SocketAddress (in this case an
> instance of InetSocketAddress):
>
> ConnectFuture future = connector.connect(new
> InetSocketAddress(
> bridgeAccountDAO.getJabberServerHostName(),
> bridgeAccountDAO
> .getJabberServerPort()), (IoHandler)
> sessionHandler);
>
> In my case, what would I use for the two SocketAddresses in
> the ReconnectFilter?
>
> I suppose I can modify your code to only use one
> SocketConnection as I'm doing (ConnectFuture future =
> connector.connect(address, handler);), but I really would
> like to understand what you are doing before I go ahead and do
> that.
>
> Thanks for any help you can provide.
>
> -Chris
>
>
>
>
> On 12/27/05, Chris Allen <mr...@gmail.com> wrote:
>
> Thanks Julien,
>
> I'm checking it out now.
>
> -Chris
>
>
>
>
> On 12/27/05, Julien Vermillard
> <jv...@archean.fr> wrote:
>
> It's here
> http://issues.apache.org/jira/browse/DIRMINA-68
>
> Le mardi 27 décembre 2005 à 11:12 -0500, Chris
> Allen a écrit :
> > Niklas wrote:
> > >We have plans to implement a
> ReconnectFilter for MINA. There is a
> > patch
> > >in JIRA but it hasn't been applied yet. It
> may be used to
> > automatically
> > >reconnect a session which has been closed.
> >
> > Any idea when this might be completed? Did
> you guys start this at
> > all, and if so, is there someplace I can
> find the source of it?
> >
> > Thanks,
> > Chris
>
>
>
>
>
>
>
>
>
Re: [MINA] ReconnectFilter
Posted by Chris Allen <mr...@gmail.com>.
Hi Julien,
After writing the last email and doing a little more research, I guess the
thing to do to make your ReconnectionFilter as flexible as possible, would
be to allow each of the IoConnector.connect() methods to work with this
class. As you can see in the MINA JavaDocs:
http://directory.apache.org/subprojects/network/apidocs/org/apache/mina/common/IoConnector.htmlthere
are four different versions of connect() and the filter currently only
supports one of them.
The easiest way that I can see to accomplish this is to provide multiple
constructors for the ReconnectionFilter class that account for each of these
connection methods. I've currently added my own with the single
SocketAddress, but for a truly flexible filter I guess it would have to
support the others as well.
Anyway, I know this is a work in progress, but I just thought that I should
mention it, even though it's super obvious.
Thanks again for letting me know where to find this class, and for creating
it in the first place.
-Chris
On 12/27/05, Chris Allen <mr...@gmail.com> wrote:
>
> Hi Julien,
>
> I'm looking at your filter and have one question about how to use it. In
> the constructor you have two SocketAddresses. One is local and the other is
> not. Can you explain what the difference is between the two?
>
> public ReconnectionFilter(int delay, IoConnector connector, IoHandler
> handler, SocketAddress address,
> SocketAddress localAddress)
>
> Also, if I'm creating my initial connection with something like this, I
> only have one SocketAddress (in this case an instance of InetSocketAddress):
>
> ConnectFuture future = connector.connect(new InetSocketAddress(
> bridgeAccountDAO.getJabberServerHostName(),
> bridgeAccountDAO
> .getJabberServerPort()), (IoHandler)
> sessionHandler);
>
> In my case, what would I use for the two SocketAddresses in the
> ReconnectFilter?
>
> I suppose I can modify your code to only use one SocketConnection as I'm
> doing (ConnectFuture future = connector.connect(address, handler);), but
> I really would like to understand what you are doing before I go ahead and
> do that.
>
> Thanks for any help you can provide.
>
> -Chris
>
> On 12/27/05, Chris Allen <mr...@gmail.com> wrote:
> >
> > Thanks Julien,
> >
> > I'm checking it out now.
> >
> > -Chris
> >
> > On 12/27/05, Julien Vermillard < jvermillard@archean.fr> wrote:
> > >
> > > It's here
> > > http://issues.apache.org/jira/browse/DIRMINA-68
> > >
> > > Le mardi 27 décembre 2005 à 11:12 -0500, Chris Allen a écrit :
> > > > Niklas wrote:
> > > > >We have plans to implement a ReconnectFilter for MINA. There is a
> > > > patch
> > > > >in JIRA but it hasn't been applied yet. It may be used to
> > > > automatically
> > > > >reconnect a session which has been closed.
> > > >
> > > > Any idea when this might be completed? Did you guys start this at
> > > > all, and if so, is there someplace I can find the source of it?
> > > >
> > > > Thanks,
> > > > Chris
> > >
> > >
> >
>
Re: [MINA] ReconnectFilter
Posted by Chris Allen <mr...@gmail.com>.
Hi Julien,
I'm looking at your filter and have one question about how to use it. In
the constructor you have two SocketAddresses. One is local and the other is
not. Can you explain what the difference is between the two?
public ReconnectionFilter(int delay, IoConnector connector, IoHandler
handler, SocketAddress address,
SocketAddress localAddress)
Also, if I'm creating my initial connection with something like this, I only
have one SocketAddress (in this case an instance of InetSocketAddress):
ConnectFuture future = connector.connect(new InetSocketAddress(
bridgeAccountDAO.getJabberServerHostName(), bridgeAccountDAO
.getJabberServerPort()), (IoHandler)
sessionHandler);
In my case, what would I use for the two SocketAddresses in the
ReconnectFilter?
I suppose I can modify your code to only use one SocketConnection as I'm
doing (ConnectFuture future = connector.connect(address, handler);), but I
really would like to understand what you are doing before I go ahead and do
that.
Thanks for any help you can provide.
-Chris
On 12/27/05, Chris Allen <mr...@gmail.com> wrote:
>
> Thanks Julien,
>
> I'm checking it out now.
>
> -Chris
>
> On 12/27/05, Julien Vermillard <jv...@archean.fr> wrote:
> >
> > It's here
> > http://issues.apache.org/jira/browse/DIRMINA-68
> >
> > Le mardi 27 décembre 2005 à 11:12 -0500, Chris Allen a écrit :
> > > Niklas wrote:
> > > >We have plans to implement a ReconnectFilter for MINA. There is a
> > > patch
> > > >in JIRA but it hasn't been applied yet. It may be used to
> > > automatically
> > > >reconnect a session which has been closed.
> > >
> > > Any idea when this might be completed? Did you guys start this at
> > > all, and if so, is there someplace I can find the source of it?
> > >
> > > Thanks,
> > > Chris
> >
> >
>
Re: [MINA] ReconnectFilter
Posted by Chris Allen <mr...@gmail.com>.
Thanks Julien,
I'm checking it out now.
-Chris
On 12/27/05, Julien Vermillard <jv...@archean.fr> wrote:
>
> It's here
> http://issues.apache.org/jira/browse/DIRMINA-68
>
> Le mardi 27 décembre 2005 à 11:12 -0500, Chris Allen a écrit :
> > Niklas wrote:
> > >We have plans to implement a ReconnectFilter for MINA. There is a
> > patch
> > >in JIRA but it hasn't been applied yet. It may be used to
> > automatically
> > >reconnect a session which has been closed.
> >
> > Any idea when this might be completed? Did you guys start this at
> > all, and if so, is there someplace I can find the source of it?
> >
> > Thanks,
> > Chris
>
>
Re: [MINA] ReconnectFilter
Posted by Julien Vermillard <jv...@archean.fr>.
It's here
http://issues.apache.org/jira/browse/DIRMINA-68
Le mardi 27 décembre 2005 à 11:12 -0500, Chris Allen a écrit :
> Niklas wrote:
> >We have plans to implement a ReconnectFilter for MINA. There is a
> patch
> >in JIRA but it hasn't been applied yet. It may be used to
> automatically
> >reconnect a session which has been closed.
>
> Any idea when this might be completed? Did you guys start this at
> all, and if so, is there someplace I can find the source of it?
>
> Thanks,
> Chris