Spring 2.5 and MXBean support

[Lian Cheng]

Thanks for all your hard work!  I'm currently working with MINA 1.1.x,
Spring, JMX and Maven 2. Recently, I introduced MXBeans into my project
while I found out that Spring doesn't support MXBean well until the 2.5
version.  But Mina 1.1.x is depending on Spring 2.0.6, that really causes
some dependency management problems.

I suggest that Mina can now depend on Spring 2.5 rather than 2.0.6, so that
dependency management will be easier. And mina-integration-jmx users can
also take advantages from JMX MXBeans. What's your opinons?

Best regards
Cheng

-- 
View this message in context: 
http://www.nabble.com/Spring-2.5-and-MXBean-support-tp14500631s16868p14500631.html
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.

Spring 2.5 and MXBean support

[Cheng Lian]

Hi all,

Thanks for all your hard work!  I'm currently working with MINA 1.1.x, 
Spring, JMX and Maven 2. Recently, I introduced MXBeans into my project 
while I found out that Spring doesn't support MXBean well until the 2.5 
version.  But Mina 1.1.x is depending on Spring 2.0.6, that really 
causes some dependency management problems.


I suggest that Mina can now depend on Spring 2.5 rather than 2.0.6, so 
that dependency management will be easier. And mina-integration-jmx 
users can also take advantages from JMX MXBeans. What's your opinons?


Best regards
Cheng

Re: memory leak in http codec

[Emmanuel Lecharny]

Luis Neves wrote:

Hi,

Emmanuel Lecharny wrote:

You have plenty of tools to analyze a OOM. Either a commercial tool,
or free tools. Just googling for 'Memory leak java analyzer' will
bring a lot of those guys, like
http://www.manageability.org/blog/stuff/open-source-profilers-for-java.


I'm aware of those tools, I already used Jhat, the IBM HeapAnalyser 
and Jconsole to locate the memory "back hole".
My initial assumption that there was a memory leak doesn't seem to be 
valid.
Monitoring the heap with JConsole the behaviour is not consistent with 
a memory leak, instead of  steadily increasing memory over time what I 
see is a sudden spike in memory and the subsequent OOM error. The 
"holder" for most of the used memory is the field:

private final List childProducts = new ArrayList();
in org.apache.mina.filter.codec.statemachine.DecodingStateMachine


My problem is that I don't fully understand the state machine that 
Mina uses to process HTTP requests and I can't tell what could cause 
the addition of thousands of elements to the "childProducts" field... 
anyway... 
Can you produce a StackTrace when you get the OOM ? It may help to 
understand where the problem has been originated. There is a good luck 
you get into an infinite loop somewhere in your code, the point is to 
determine when you get into this loop (typically behavior when you get a 
sudden spike in a program).


Hope it helps...

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

Re: no response from my mina server

[Emmanuel Lecharny]

OOps,

incorrectly accepted this message which has been sent to
[EMAIL PROTECTED] Forwarded to the correct ML...

On Dec 26, 2007 3:56 PM, sdivin <[EMAIL PROTECTED]> wrote:
>
>   i develop a socket serer based on  mina , after run a long time  ,when the
> client send the request messsage to the server ,the server display the
> response message to the client ,but the client can not receive the response
> message
> --
> View this message in context: 
> http://www.nabble.com/no-response-from-my-mina--server-tp14502874s16868p14502874.html
> Sent from the Apache MINA Commits mailing list archive at Nabble.com.
>
>



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

the client can not receive the response message from the mina server

[hefm]

can you help me ?

 i develop a socket server  based on the MINA,  all the client
send the request message to the server ,the server will send the
response message to the client ,

 but after run some days , when the client send the message to the
server ,the client can not receive the response message from the
server ,but the server logs display  the server write the response to
the response buffer, why the client can not receive the message ?

ProtocolEncoderOutput and FileRegion

[Geoff Cadien]

Is there any reason to not be able to write a FileRegion to
ProtocolEncoderOutput in addition to an IoBuffer?

-geoff

[jira] Created: (DIRMINA-503) NioProcessor.transferFile needs to catch IOException on Linux

[Geoff Cadien (JIRA)]

NioProcessor.transferFile needs to catch IOException on Linux
-

 Key: DIRMINA-503
 URL: https://issues.apache.org/jira/browse/DIRMINA-503
 Project: MINA
  Issue Type: Bug
  Components: Core
 Environment: Linux 2.6.22 Sun JDK 1.6.0_03
Reporter: Geoff Cadien
Priority: Critical
 Fix For: 2.0.0-M1


Under Linux FileChannel.transferTo throws an IOException when the socket send 
buffer is full.  This causes the sending of a FileRegion to fail.  Here is the 
bug report http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5103988  Even 
though it is marked as fixed it continues to exist.

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

Re: the client can not receive the response message from the mina server

[Steve Johns]

Most likely, either client or server didn't detect the disconnection. Please
use heartbeat.

On Dec 26, 2007 11:05 PM, hefm <[EMAIL PROTECTED]> wrote:

> can you help me ?
>
> i develop a socket server  based on the MINA,  all the client
> send the request message to the server ,the server will send the
> response message to the client ,
>
>  but after run some days , when the client send the message to the
> server ,the client can not receive the response message from the
> server ,but the server logs display  the server write the response to
> the response buffer, why the client can not receive the message ?
>

Re: How can i improve the total numbers of session which server will handle connects from client

[Steve Johns]

Did you get your problem fixed?

On Dec 22, 2007 12:36 AM, Steve Johns <[EMAIL PROTECTED]> wrote:

> Try your own client with Sumup server and see if it works. If NOT,
> something wrong with your client. If YES, try to find out what happens in
> ExceptionCaught().Good luck!
>
>
> On Dec 21, 2007 11:22 AM, chinadeng <[EMAIL PROTECTED]> wrote:
>
> >
> > the  problem is still in ,plz,give some advices?
> >
> > Qi wrote:
> > >
> > > Hi,
> > >
> > > For those clients failed establish a connection, do they report any
> > errors
> > > such as connection timeout, etc?
> > > I've run a simple experiment that tries to establish 300 connections
> > to
> > > the example sumupserver running on another machine in the local
> > network,
> > > and I found no problem. However, my client code is in Java, so it is
> > > different from your situation.
> > >
> > > And could you also remove the threadmodel settings and set it to be
> > > Thread.manual, then increase the receiver buffer size in
> > > SocketAcceptorConfig.getSessionConfig().setReceiveBufferSize(), just
> > for a
> > > experiment?
> > >
> > > Cheers,
> > > Qi
> > >
> > >
> > >
> >
> > --
> > View this message in context:
> > http://www.nabble.com/How-can-i-improve-the-total-numbers-of-session-which-server-will--handle-connects-from-client-tp14429723s16868p14449668.html
> >  Sent from the Apache MINA Support Forum mailing list archive at
> > Nabble.com .
> >
> >
>

Re: WriteFuture.join() hangs when called in IoHandler.sessionOpened() in Datagram transport.

[Steve Johns]

Are you saying Mina API Interface WriteFuture example is NOT a proper one?
Thanks.

On Dec 18, 2007 3:14 PM, Trustin Lee <[EMAIL PROTECTED]> wrote:

> Hi Qi,
>
> It's not a bug but a kind of dead lock caused by misuse of the API.
>
> You are usually not supposed to call IoFuture.join() within an
> IoHandler because the IoHandler methods might be being executed in the
> same thread with the I/O processor thread.  You wrote something and
> you call join() to wait for the I/O processor thread to finish the
> write operation in the I/O processor thread, then join() won't return
> at all.  MINA 2 detects this kind of situation automatically and emits
> advisory exception, but it's not in MINA 1.x unfortunately.
>
> The alternative to join() is adding an IoFutureListener.
>
> HTH,
> Trustin
>
> On Dec 17, 2007 4:48 PM, Qi <[EMAIL PROTECTED]> wrote:
> >
> > Hi there,
> >
> > I've just found a possible bug in MINA Datagram transport.
> >
> > In my handler class, I was trying to write some messages once the
> > sessionOpened event is fired, while the program will hang if I get the
> > writeFuture and call join() on it.
> > If I call join with a timeout parameter, after the operation gets
> timeout,
> > WriteFuture.isWritten returns false.
> > (Same senario would go through if it's via SocketConnector transport, as
> > showing in the sumup example.)
> >
> >
> > However, if I don't place the write operation inside sessionOpened();
> > instead, I placed they after DatagramConnector.connect(), then writes
> will
> > successfully go though.
> >
> > I'm using MINA 1.1.5 and JRE 1.6.
> >
> > Source code that demostrate the problem is attached.
> > http://www.nabble.com/file/p14370126/BroadcastSender.java
> > BroadcastSender.java
> > --
> > View this message in context:
> http://www.nabble.com/WriteFuture.join%28%29-hangs-when-called-in-IoHandler.sessionOpened%28%29-in-Datagram-transport.-tp14370126s16868p14370126.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
>

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

[Emmanuel Lecharny]

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]

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

[Emmanuel Lecharny]

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

[Trustin Lee]

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: WriteFuture.join() hangs when called in IoHandler.sessionOpened() in Datagram transport.

[Trustin Lee]

On Dec 27, 2007 7:57 AM, Steve Johns <[EMAIL PROTECTED]> wrote:
> Are you saying Mina API Interface WriteFuture example is NOT a proper one?

Well, it depends on situation.  It is sometimes more convenient to use
WriteFuture.join() and it will work as long as you have inserted an
ExecutorFilter in the filter chain.  I prefer using IoFutureListener
though.

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

Re: the client can not receive the response message from the mina server

[Trustin Lee]

Hi Hefm,

In such a case, you need to try to use a packet capturing tool such as
wireshark or tcpdump to see if the server has sent the data really and
to see if the client is receiving the data.

HTH,
Trustin

On Dec 27, 2007 12:05 AM, hefm <[EMAIL PROTECTED]> wrote:
> can you help me ?
>
>  i develop a socket server  based on the MINA,  all the client
> send the request message to the server ,the server will send the
> response message to the client ,
>
>  but after run some days , when the client send the message to the
> server ,the client can not receive the response message from the
> server ,but the server logs display  the server write the response to
> the response buffer, why the client can not receive the message ?
>



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

Re: ProtocolEncoderOutput and FileRegion

[Trustin Lee]

On Dec 27, 2007 4:14 AM, Geoff Cadien <[EMAIL PROTECTED]> wrote:
> Is there any reason to not be able to write a FileRegion to
> ProtocolEncoderOutput in addition to an IoBuffer?

It's an API flaw.  It should be fixed.  Thanks for the heads up!

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

Re: Spring 2.5 and MXBean support

[Trustin Lee]

Sounds like a good idea as long as it doesn't have any backward
compatibility problem.

FYI, MINA has much better JMX integration in 2.0.

Thanks,
Trustin

On Dec 26, 2007 6:17 PM, Cheng Lian <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Thanks for all your hard work!  I'm currently working with MINA 1.1.x,
> Spring, JMX and Maven 2. Recently, I introduced MXBeans into my project
> while I found out that Spring doesn't support MXBean well until the 2.5
> version.  But Mina 1.1.x is depending on Spring 2.0.6, that really
> causes some dependency management problems.
>
> I suggest that Mina can now depend on Spring 2.5 rather than 2.0.6, so
> that dependency management will be easier. And mina-integration-jmx
> users can also take advantages from JMX MXBeans. What's your opinons?
>
> Best regards
> Cheng
>
>



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

Re: AbstractIoSession and final qualifiers

[Trustin Lee]

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
>



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

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: the client can not receive the response message from the mina server

[Qi]

Hi Steve,

Would you mind explain a bit more on "heartbeat" ?

Cheers,
Qi


Steve Johns-2 wrote:
> 
> Most likely, either client or server didn't detect the disconnection.
> Please
> use heartbeat.
> 
> On Dec 26, 2007 11:05 PM, hefm <[EMAIL PROTECTED]> wrote:
> 
>> can you help me ?
>>
>> i develop a socket server  based on the MINA,  all the client
>> send the request message to the server ,the server will send the
>> response message to the client ,
>>
>>  but after run some days , when the client send the message to the
>> server ,the client can not receive the response message from the
>> server ,but the server logs display  the server write the response to
>> the response buffer, why the client can not receive the message ?
>>
> 
> 

-- 
View this message in context: 
http://www.nabble.com/the-client-can-not-receive-the-response-message-from-the-mina-server-tp14503254s16868p14509885.html
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.

Re: Spring 2.5 and MXBean support

[Lian Cheng]

That would be greate! :-D


Trustin Lee wrote:
> 
> Sounds like a good idea as long as it doesn't have any backward
> compatibility problem.
> 
> FYI, MINA has much better JMX integration in 2.0.
> 
> Thanks,
> Trustin
> 

-- 
View this message in context: 
http://www.nabble.com/Spring-2.5-and-MXBean-support-tp14500657s16868p14510317.html
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.