Using a bunch of connections in a client?
Hi, I'm trying to write a client that can utilize a set number of connections
using MINA trunk (mina-core-2.0.0-M1-20071221.061156-110.jar).
I'm using the netcat
(http://svn.apache.org/viewvc/mina/trunk/example/src/main/java/org/apache/mina/example/netcat/Main.java?view=markup)
as an example but I think I'm doing it wrong. I've never used NIO before so
this is all a bit confusing to me.
What's the preferred way of managing a lot of nio client connections using
MINA? At the moment I'm just creating a lot of NioSocketConnector objects,
and connecting them. I have added an IoFutureListener to the ConnectFuture
obtained by calling nioSocketConnector.connect(InetSocketAddress):
public void operationComplete(IoFuture arg0) {
if(arg0 instanceof ConnectFuture) {
ConnectFuture cf = (ConnectFuture)arg0;
debug(connected=+cf.isConnected()+,exc=+cf.getException());
if(cf.isConnected()) {
/**
* Add the connected client to the clients
queue for processing
*/
boolean offered =
clients.offer((TyrClient)cf.getSession().getAttribute(CLIENT));
if(!offered)
throw new RuntimeException(Couldn't
offer connected client.);
} else {
/**
* Add a new connection attempt to the
connection queue.
*/
boolean offered =
pending.offer(createNewConnection(TIMEOUT));
if(!offered)
throw new RuntimeException(Couldn't
offer connection.);
}
}
}
And I'm getting a lot of this:
[T:NioSocketConnector-75] connected=false,exc=java.net.ConnectException:
Connection refused
[T:NioSocketConnector-76] connected=false,exc=java.net.ConnectException:
Connection refused
[T:NioSocketConnector-77] connected=false,exc=java.net.ConnectException:
Connection refused
(Which is being expected since I'm just connecting to a closed port)
and then,
7693 [NioSocketConnector-77] WARN
org.apache.mina.common.DefaultExceptionMonitor - Unexpected exception.
org.apache.mina.common.RuntimeIoException: Failed to initialize.
at
org.apache.mina.common.AbstractPollingIoConnector.init(AbstractPollingIoConnector.java:103)
at
org.apache.mina.common.AbstractPollingIoConnector.init(AbstractPollingIoConnector.java:61)
at
org.apache.mina.transport.socket.nio.NioSocketConnector.init(NioSocketConnector.java:52)
at tyr.Client.createNewConnection(RickRoller.java:46)
at tyr.Client.operationComplete(RickRoller.java:154)
at
org.apache.mina.common.DefaultIoFuture.notifyListener(DefaultIoFuture.java:302)
at
org.apache.mina.common.DefaultIoFuture.notifyListeners(DefaultIoFuture.java:287)
at
org.apache.mina.common.DefaultIoFuture.setValue(DefaultIoFuture.java:221)
at
org.apache.mina.common.DefaultConnectFuture.setException(DefaultConnectFuture.java:95)
at
org.apache.mina.common.AbstractPollingIoConnector.processSessions(AbstractPollingIoConnector.java:262)
at
org.apache.mina.common.AbstractPollingIoConnector.access$500(AbstractPollingIoConnector.java:41)
at
org.apache.mina.common.AbstractPollingIoConnector$Worker.run(AbstractPollingIoConnector.java:298)
at
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.io.IOException: Too many open files
at sun.nio.ch.IOUtil.initPipe(Native Method)
at sun.nio.ch.EPollSelectorImpl.init(EPollSelectorImpl.java:49)
at
sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.java:18)
at java.nio.channels.Selector.open(Selector.java:209)
at
org.apache.mina.transport.socket.nio.NioSocketConnector.init(NioSocketConnector.java:69)
at
org.apache.mina.common.AbstractPollingIoConnector.init(AbstractPollingIoConnector.java:98)
... 15 more
So what am I doing wrong?
Thanks,
Alex.
--
View this message in context:
http://www.nabble.com/Using-a-bunch-of-connections-in-a-client--tp14514544s16868p14514544.html
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.
Question regarding mina server with high load client
Hi Recently I have been experimenting with mina core 2 and I have a few questions regarding the behaviour of mina in some sample programs I made. here is the client code. its simple, it simply rams as many messages as possible into the server. http://pastebin.com/m14ac361e Now I made two servers. One mina based, which is simply the date/time echo server as described in the documentation. The second one is a simple one thread per client server. Here is the code http://pastebin.com/m3a5a14a7 Now the result from both the servers differ a lot. The second server works in lock step with client and responds to messages without any delay. But with mina server the response is very slow and after about 10 messages the response is almost nill and after a few seconds I start getting out of memory exceptions while creating more date objects. Now I have the following questions (I very good spirit) 1. What is the reason behind this behaviour ? 2. I understand that second server will not be able to scale very much but mina probably will, but does this mean that mina server will not be able to handle high load from few clients but low load from many clients? 3. Is there a solution to this ? IMHO, first server example demonstrates that such high load can be handled at server. Thank you
[jira] Reopened: (DIRMINA-495) IoConnector needs a way to store information into the IoSession before the IoHandler gets ahold of it
[
https://issues.apache.org/jira/browse/DIRMINA-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Heath reopened DIRMINA-495:
I've been trying to retrofit some of my existing code to use the
IoSessionInitializer. This code is a client that has its own API and uses MINA
under the hood. I need to be able to cancel a pending connect future from my
API. To facilitate this, I discovered that it would greatly simplify my code
if the ConnectFuture instance is passed into the IoSessionInitializer.
Modifying the IoSessionInitializer interface to look like:
public interface IoSessionInitializer {
void initializeSession(IoSession session, IoFuture future);
}
would fix my problem. The future object passed into the initializeSession
method would be the ConnectFuture that is returned by IoConnector.connect(...);
IoConnector needs a way to store information into the IoSession before the
IoHandler gets ahold of it
-
Key: DIRMINA-495
URL: https://issues.apache.org/jira/browse/DIRMINA-495
Project: MINA
Issue Type: New Feature
Components: Core
Reporter: David M. Lloyd
Assignee: Mike Heath
Fix For: 2.0.0-M1
Attachments: DIRMINA-495-3.patch, DIRMINA-495-mikeheath.patch,
IoConnector.patch
It is often necessary to pass information into the IoHandler associated with
an IoConnector. Sometimes this information is needed even as early as
IoSession creation time. A mechanism is needed to pass information in to the
IoSession at the time you call IoConnector.connect(). Discussing this with
Mike Heath, we determined that a logical approach could be to have variants
of the connect() methods that accept information that can be attached to the
IoSession when it is created.
One option is to simply pass a Map in to the connect method. The contents of
the Map would be copied into the IoSession's attribute map after it is
constructed but before the IoHandler.sessionCreated method is created. In
addition, it seems likely that in many cases only one entry would need to be
added - in this case the user could simply do this:
ioConnector.connect(addr, Collections.singletonMap(MY_KEY, theValue));
Another option would be to use variable argument lists to accept any number
of key-value pairs. The pairs could be represented by a class -
AttributePair for example. It could look like this:
public final class AttributePairK, V {
private final K key;
private final V value;
private AttributePair(K key, V value) { this.key = key; this.value =
value; }
public static K, V AttributePairK,V pair(K key, V value) { return
new AttributePairK, V(key, value); }
}
Then the user can use static imports to pull in the pair method. The
connect() method on IoConnector could accept a variable list of AttributePair
objects, so the user could write code like this:
ioConnector.connect(addr, pair(MY_KEY1, myValue), pair(MY_KEY2,
myValue2));
Though this approach is somewhat more complicated than just using a Map.
Other approaches may also be discussed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Question regarding mina server with high load client
Ashish Sharma wrote: Hi Hi ! 2. I understand that second server will not be able to scale very much but mina probably will, but does this mean that mina server will not be able to handle high load from few clients but low load from many clients? I'm not able to answer your Q 1 and 3 right now, but I can assure you that MINA can handle high load from many clients. We are using it into Apache Directory Server, and were able to simulate this with hundreds of clients and thousands of messages per second, for hours ( we did a test which lasted 72 hours, for hundreds of millions messages). You migth have missed something in your Mina server code, I guess. Thank you -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
[jira] Closed: (DIRMINA-495) IoConnector needs a way to store information into the IoSession before the IoHandler gets ahold of it
[
https://issues.apache.org/jira/browse/DIRMINA-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Heath closed DIRMINA-495.
--
Resolution: Fixed
Added IoFuture to argument list on IoSessionInitializer.initializeSession.
IoConnector needs a way to store information into the IoSession before the
IoHandler gets ahold of it
-
Key: DIRMINA-495
URL: https://issues.apache.org/jira/browse/DIRMINA-495
Project: MINA
Issue Type: New Feature
Components: Core
Reporter: David M. Lloyd
Assignee: Mike Heath
Fix For: 2.0.0-M1
Attachments: DIRMINA-495-3.patch, DIRMINA-495-mikeheath.patch,
IoConnector.patch
It is often necessary to pass information into the IoHandler associated with
an IoConnector. Sometimes this information is needed even as early as
IoSession creation time. A mechanism is needed to pass information in to the
IoSession at the time you call IoConnector.connect(). Discussing this with
Mike Heath, we determined that a logical approach could be to have variants
of the connect() methods that accept information that can be attached to the
IoSession when it is created.
One option is to simply pass a Map in to the connect method. The contents of
the Map would be copied into the IoSession's attribute map after it is
constructed but before the IoHandler.sessionCreated method is created. In
addition, it seems likely that in many cases only one entry would need to be
added - in this case the user could simply do this:
ioConnector.connect(addr, Collections.singletonMap(MY_KEY, theValue));
Another option would be to use variable argument lists to accept any number
of key-value pairs. The pairs could be represented by a class -
AttributePair for example. It could look like this:
public final class AttributePairK, V {
private final K key;
private final V value;
private AttributePair(K key, V value) { this.key = key; this.value =
value; }
public static K, V AttributePairK,V pair(K key, V value) { return
new AttributePairK, V(key, value); }
}
Then the user can use static imports to pull in the pair method. The
connect() method on IoConnector could accept a variable list of AttributePair
objects, so the user could write code like this:
ioConnector.connect(addr, pair(MY_KEY1, myValue), pair(MY_KEY2,
myValue2));
Though this approach is somewhat more complicated than just using a Map.
Other approaches may also be discussed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Using a bunch of connections in a client?
Hello Alex,
1) you can use one SocketConnector to create many connections
2) search the forum for Too many open files
This thread might interest you:
http://www.nabble.com/Too-many-open-files-to7521146s16868.html
HTH
Maarten
On Dec 27, 2007 4:43 PM, stork [EMAIL PROTECTED] wrote:
Hi, I'm trying to write a client that can utilize a set number of connections
using MINA trunk (mina-core-2.0.0-M1-20071221.061156-110.jar).
I'm using the netcat
(http://svn.apache.org/viewvc/mina/trunk/example/src/main/java/org/apache/mina/example/netcat/Main.java?view=markup)
as an example but I think I'm doing it wrong. I've never used NIO before so
this is all a bit confusing to me.
What's the preferred way of managing a lot of nio client connections using
MINA? At the moment I'm just creating a lot of NioSocketConnector objects,
and connecting them. I have added an IoFutureListener to the ConnectFuture
obtained by calling nioSocketConnector.connect(InetSocketAddress):
public void operationComplete(IoFuture arg0) {
if(arg0 instanceof ConnectFuture) {
ConnectFuture cf = (ConnectFuture)arg0;
debug(connected=+cf.isConnected()+,exc=+cf.getException());
if(cf.isConnected()) {
/**
* Add the connected client to the clients
queue for processing
*/
boolean offered =
clients.offer((TyrClient)cf.getSession().getAttribute(CLIENT));
if(!offered)
throw new RuntimeException(Couldn't
offer connected client.);
} else {
/**
* Add a new connection attempt to the
connection queue.
*/
boolean offered =
pending.offer(createNewConnection(TIMEOUT));
if(!offered)
throw new RuntimeException(Couldn't
offer connection.);
}
}
}
And I'm getting a lot of this:
[T:NioSocketConnector-75] connected=false,exc=java.net.ConnectException:
Connection refused
[T:NioSocketConnector-76] connected=false,exc=java.net.ConnectException:
Connection refused
[T:NioSocketConnector-77] connected=false,exc=java.net.ConnectException:
Connection refused
(Which is being expected since I'm just connecting to a closed port)
and then,
7693 [NioSocketConnector-77] WARN
org.apache.mina.common.DefaultExceptionMonitor - Unexpected exception.
org.apache.mina.common.RuntimeIoException: Failed to initialize.
at
org.apache.mina.common.AbstractPollingIoConnector.init(AbstractPollingIoConnector.java:103)
at
org.apache.mina.common.AbstractPollingIoConnector.init(AbstractPollingIoConnector.java:61)
at
org.apache.mina.transport.socket.nio.NioSocketConnector.init(NioSocketConnector.java:52)
at tyr.Client.createNewConnection(RickRoller.java:46)
at tyr.Client.operationComplete(RickRoller.java:154)
at
org.apache.mina.common.DefaultIoFuture.notifyListener(DefaultIoFuture.java:302)
at
org.apache.mina.common.DefaultIoFuture.notifyListeners(DefaultIoFuture.java:287)
at
org.apache.mina.common.DefaultIoFuture.setValue(DefaultIoFuture.java:221)
at
org.apache.mina.common.DefaultConnectFuture.setException(DefaultConnectFuture.java:95)
at
org.apache.mina.common.AbstractPollingIoConnector.processSessions(AbstractPollingIoConnector.java:262)
at
org.apache.mina.common.AbstractPollingIoConnector.access$500(AbstractPollingIoConnector.java:41)
at
org.apache.mina.common.AbstractPollingIoConnector$Worker.run(AbstractPollingIoConnector.java:298)
at
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.io.IOException: Too many open files
at sun.nio.ch.IOUtil.initPipe(Native Method)
at sun.nio.ch.EPollSelectorImpl.init(EPollSelectorImpl.java:49)
at
sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.java:18)
at java.nio.channels.Selector.open(Selector.java:209)
at
org.apache.mina.transport.socket.nio.NioSocketConnector.init(NioSocketConnector.java:69)
at
org.apache.mina.common.AbstractPollingIoConnector.init(AbstractPollingIoConnector.java:98)
... 15 more
So what am I doing wrong?
Thanks,
Alex.
--
View this message in context:
Re: Using a bunch of connections in a client?
I'm not sure I understand - how can a SocketConnector create more than one
connection?
That would explain why the connections aren't getting close properly.
Maarten Bosteels wrote:
Hello Alex,
1) you can use one SocketConnector to create many connections
2) search the forum for Too many open files
This thread might interest you:
http://www.nabble.com/Too-many-open-files-to7521146s16868.html
HTH
Maarten
On Dec 27, 2007 4:43 PM, stork [EMAIL PROTECTED] wrote:
Hi, I'm trying to write a client that can utilize a set number of
connections
using MINA trunk (mina-core-2.0.0-M1-20071221.061156-110.jar).
I'm using the netcat
(http://svn.apache.org/viewvc/mina/trunk/example/src/main/java/org/apache/mina/example/netcat/Main.java?view=markup)
as an example but I think I'm doing it wrong. I've never used NIO before
so
this is all a bit confusing to me.
What's the preferred way of managing a lot of nio client connections
using
MINA? At the moment I'm just creating a lot of NioSocketConnector
objects,
and connecting them. I have added an IoFutureListener to the
ConnectFuture
obtained by calling nioSocketConnector.connect(InetSocketAddress):
public void operationComplete(IoFuture arg0) {
if(arg0 instanceof ConnectFuture) {
ConnectFuture cf = (ConnectFuture)arg0;
debug(connected=+cf.isConnected()+,exc=+cf.getException());
if(cf.isConnected()) {
/**
* Add the connected client to the
clients queue for processing
*/
boolean offered =
clients.offer((TyrClient)cf.getSession().getAttribute(CLIENT));
if(!offered)
throw new
RuntimeException(Couldn't offer connected client.);
} else {
/**
* Add a new connection attempt to the
connection queue.
*/
boolean offered =
pending.offer(createNewConnection(TIMEOUT));
if(!offered)
throw new
RuntimeException(Couldn't offer connection.);
}
}
}
And I'm getting a lot of this:
[T:NioSocketConnector-75] connected=false,exc=java.net.ConnectException:
Connection refused
[T:NioSocketConnector-76] connected=false,exc=java.net.ConnectException:
Connection refused
[T:NioSocketConnector-77] connected=false,exc=java.net.ConnectException:
Connection refused
(Which is being expected since I'm just connecting to a closed port)
and then,
7693 [NioSocketConnector-77] WARN
org.apache.mina.common.DefaultExceptionMonitor - Unexpected exception.
org.apache.mina.common.RuntimeIoException: Failed to initialize.
at
org.apache.mina.common.AbstractPollingIoConnector.init(AbstractPollingIoConnector.java:103)
at
org.apache.mina.common.AbstractPollingIoConnector.init(AbstractPollingIoConnector.java:61)
at
org.apache.mina.transport.socket.nio.NioSocketConnector.init(NioSocketConnector.java:52)
at tyr.Client.createNewConnection(RickRoller.java:46)
at tyr.Client.operationComplete(RickRoller.java:154)
at
org.apache.mina.common.DefaultIoFuture.notifyListener(DefaultIoFuture.java:302)
at
org.apache.mina.common.DefaultIoFuture.notifyListeners(DefaultIoFuture.java:287)
at
org.apache.mina.common.DefaultIoFuture.setValue(DefaultIoFuture.java:221)
at
org.apache.mina.common.DefaultConnectFuture.setException(DefaultConnectFuture.java:95)
at
org.apache.mina.common.AbstractPollingIoConnector.processSessions(AbstractPollingIoConnector.java:262)
at
org.apache.mina.common.AbstractPollingIoConnector.access$500(AbstractPollingIoConnector.java:41)
at
org.apache.mina.common.AbstractPollingIoConnector$Worker.run(AbstractPollingIoConnector.java:298)
at
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.io.IOException: Too many open files
at sun.nio.ch.IOUtil.initPipe(Native Method)
at sun.nio.ch.EPollSelectorImpl.init(EPollSelectorImpl.java:49)
at
sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.java:18)
at java.nio.channels.Selector.open(Selector.java:209)
at
org.apache.mina.transport.socket.nio.NioSocketConnector.init(NioSocketConnector.java:69)
at
Re: Using a bunch of connections in a client?
On Dec 27, 2007 7:43 PM, stork [EMAIL PROTECTED] wrote:
I'm not sure I understand - how can a SocketConnector create more than one
connection?
I meant: when you need to create more than one connection, you
could/should reuse one connector instance.
IoConnector connector = ...;
ConnectFuture future = connector.connect(...);
future.join(); // Wait until the connection attempt is finished.
IoSession session = future.getSession();
session.write(...);
Maarten
That would explain why the connections aren't getting close properly.
Maarten Bosteels wrote:
Hello Alex,
1) you can use one SocketConnector to create many connections
2) search the forum for Too many open files
This thread might interest you:
http://www.nabble.com/Too-many-open-files-to7521146s16868.html
HTH
Maarten
On Dec 27, 2007 4:43 PM, stork [EMAIL PROTECTED] wrote:
Hi, I'm trying to write a client that can utilize a set number of
connections
using MINA trunk (mina-core-2.0.0-M1-20071221.061156-110.jar).
I'm using the netcat
(http://svn.apache.org/viewvc/mina/trunk/example/src/main/java/org/apache/mina/example/netcat/Main.java?view=markup)
as an example but I think I'm doing it wrong. I've never used NIO before
so
this is all a bit confusing to me.
What's the preferred way of managing a lot of nio client connections
using
MINA? At the moment I'm just creating a lot of NioSocketConnector
objects,
and connecting them. I have added an IoFutureListener to the
ConnectFuture
obtained by calling nioSocketConnector.connect(InetSocketAddress):
public void operationComplete(IoFuture arg0) {
if(arg0 instanceof ConnectFuture) {
ConnectFuture cf = (ConnectFuture)arg0;
debug(connected=+cf.isConnected()+,exc=+cf.getException());
if(cf.isConnected()) {
/**
* Add the connected client to the
clients queue for processing
*/
boolean offered =
clients.offer((TyrClient)cf.getSession().getAttribute(CLIENT));
if(!offered)
throw new
RuntimeException(Couldn't offer connected client.);
} else {
/**
* Add a new connection attempt to the
connection queue.
*/
boolean offered =
pending.offer(createNewConnection(TIMEOUT));
if(!offered)
throw new
RuntimeException(Couldn't offer connection.);
}
}
}
And I'm getting a lot of this:
[T:NioSocketConnector-75] connected=false,exc=java.net.ConnectException:
Connection refused
[T:NioSocketConnector-76] connected=false,exc=java.net.ConnectException:
Connection refused
[T:NioSocketConnector-77] connected=false,exc=java.net.ConnectException:
Connection refused
(Which is being expected since I'm just connecting to a closed port)
and then,
7693 [NioSocketConnector-77] WARN
org.apache.mina.common.DefaultExceptionMonitor - Unexpected exception.
org.apache.mina.common.RuntimeIoException: Failed to initialize.
at
org.apache.mina.common.AbstractPollingIoConnector.init(AbstractPollingIoConnector.java:103)
at
org.apache.mina.common.AbstractPollingIoConnector.init(AbstractPollingIoConnector.java:61)
at
org.apache.mina.transport.socket.nio.NioSocketConnector.init(NioSocketConnector.java:52)
at tyr.Client.createNewConnection(RickRoller.java:46)
at tyr.Client.operationComplete(RickRoller.java:154)
at
org.apache.mina.common.DefaultIoFuture.notifyListener(DefaultIoFuture.java:302)
at
org.apache.mina.common.DefaultIoFuture.notifyListeners(DefaultIoFuture.java:287)
at
org.apache.mina.common.DefaultIoFuture.setValue(DefaultIoFuture.java:221)
at
org.apache.mina.common.DefaultConnectFuture.setException(DefaultConnectFuture.java:95)
at
org.apache.mina.common.AbstractPollingIoConnector.processSessions(AbstractPollingIoConnector.java:262)
at
org.apache.mina.common.AbstractPollingIoConnector.access$500(AbstractPollingIoConnector.java:41)
at
org.apache.mina.common.AbstractPollingIoConnector$Worker.run(AbstractPollingIoConnector.java:298)
at
org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.io.IOException: Too many open files
at
Re: memory leak in http codec
Luis Neves wrote:
I'm running the server with logging set to DEBUG and I would
like to know if there is anything more I can do to try to isolate this
problem.
I'm still struggling with this issue, I'm forced to restart the server every 10
minutes... the debug logging doesn't seem to point to anything specific (at
least to my eyes).
There are some requests that look weird, e.g:
DEBUG #org.apache.mina.filter.codec.http.HttpRequestDecodingState$3#
[NioProcessor-12] - Decoded header:
{---=[:-],
Accept=[*/*], Accept-Encoding=[gzip, deflate], Accept-Language=[pt],
Connection=[Keep-Alive], Host=[wa.sl.pt], User-Agent=[Mozilla/4.0 (compatible;
MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Media
Center PC 4.0)]}
DEBUG #org.apache.mina.filter.codec.http.HttpRequestDecodingState$3#
[NioProcessor-12] - Request is HTTP 1/1. Checking for transfer coding
DEBUG #org.apache.mina.filter.codec.http.HttpRequestDecodingState$3#
[NioProcessor-12] - No entity body for this request
and another one:
DEBUG #org.apache.mina.filter.codec.http.HttpRequestDecodingState$3#
[NioProcessor-12] - Decoded header: {Accept=[*/*], Accept-Language=[pt],
Connection=[Keep-Alive], Host=[wa.sl.pt], User-Agent=[Mozilla/4.0 (compatible;
MSIE 6.0; Windows NT 5.1)],
~~~=[:~~~],
~~~=[~ ~~~]}
DEBUG #org.apache.mina.filter.codec.http.HttpRequestDecodingState$3#
[NioProcessor-12] - Request is HTTP 1/1. Checking for transfer coding
DEBUG #org.apache.mina.filter.codec.http.HttpRequestDecodingState$3#
[NioProcessor-12] - No entity body for this request
I find those - and ~ very weird, I doubt that the clients are sending those
headers. If the result of a Mina artifact, from where are those headers coming?
Thanks!
--
Luis Neves
[jira] Updated: (DIRMINA-503) NioProcessor.transferFile needs to catch IOException on Linux
[ https://issues.apache.org/jira/browse/DIRMINA-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Heath updated DIRMINA-503: --- Affects Version/s: 2.0.0-M1 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 Affects Versions: 2.0.0-M1 Environment: Linux 2.6.22 Sun JDK 1.6.0_03 Reporter: Geoff Cadien Assignee: Mike Heath 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.
[jira] Resolved: (DIRMINA-503) NioProcessor.transferFile needs to catch IOException on Linux
[ https://issues.apache.org/jira/browse/DIRMINA-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Heath resolved DIRMINA-503. Resolution: Fixed This has been fixed although I'm unsure if it will affect the APR transport. 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 Assignee: Mike Heath 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: AbstractIoSession and final qualifiers
Trustin (and others)...so how about these changes and additions to the
AbstractIoSession? This will allow the scheduledBytes/messages to be
overriden, and also allow someone to set them.
Index: core/src/main/java/org/apache/mina/common/AbstractIoSession.java
===
--- core/src/main/java/org/apache/mina/common/AbstractIoSession.java
(revision 607135)
+++ core/src/main/java/org/apache/mina/common/AbstractIoSession.java
(working copy)
@@ -488,14 +488,22 @@
lastThroughputCalculationTime = currentTime;
}
-public final long getScheduledWriteBytes() {
+public long getScheduledWriteBytes() {
return scheduledWriteBytes.get();
}
-public final int getScheduledWriteMessages() {
+public int getScheduledWriteMessages() {
return scheduledWriteMessages.get();
}
+public void setScheduledWriteBytes(long byteCount){
+scheduledWriteBytes.set(byteCount);
+}
+
+public void setScheduledWriteMessages(int messages) {
+scheduledWriteMessages.set(messages);
+}
+
protected final void increaseReadBytes(long increment, long
currentTime) {
if (increment = 0) {
return;
Thanks,
Jeff
Trustin Lee wrote:
Hi Jeff and Emmanuel,
You can add some hook for IoSession.write() by inserting an IoFilter,
so I am not sure about removing the final modifier from write().
Overriding getScheduledMessages and getScheduledBytes makes sense
though because they will always be 0 because messageSent event will be
always fired immediately.
WDYT?
Trustin
On Dec 27, 2007 10:21 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote:
Jeff Genender wrote:
What do *you* think? ;-)
Beside the assert, which was a side effect of my quick glance at the
method you want to override, I think that dooming the final is sane.
If someone needs to protect this method, then the best solution would be
to define a super class with final methods calling the AbstractIoSession
non final methods.
Another solution (puke) would be to remove the
public/protected/private qualifier, and to add a MockIoSession in the
same package. Not very elegant, but does the job too...
There are always tradeoff when you want to thoroughly unit-test some
code. When it comes to an API, it seems impossible to avoid those
tradeoff, IMHO.
Any other opinion ? Trustin ? Julien ?
Jeff
Emmanuel Lecharny wrote:
Jeff Genender wrote:
Hey guys,
I was hoping to see if we could discuss some of the final qualifiers
on some of the methods in the AbstractIOSession. The reason I ask is it
would be cool to be able to override some of the methods such as:
public WriteFuture write(Object message)
public final int getScheduledWriteMessages()
To be able to write MockObjects for unit tests of code. Any thoughts on
making these protected instead of final?
Thanks,
Jeff
Hi,
makes sense to me... Or we may have a AbstractMockIoSession implementing
the IoSession interface, for unit tests ?
While looking at the abstract class, I found some methods with this kind
of code :
public final WriteFuture write(Object message, SocketAddress
remoteAddress) {
if (message == null) {
throw new NullPointerException(message);
}
...
Wouldn't be a perfect case for an assert ? Like :
public final WriteFuture write(Object message, SocketAddress
remoteAddress) {
assert message != null : Null messages are not allowed;
...
wdyt ?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Using a bunch of connections in a client?
Hi there,
I used to confused on the same problem as well, so please let me share my
understanding on this.
You would only need on IoConnector if you only need one set of business
logic for handling server's response.
Let's image your IoConnector is your web browser, and IoAcceptor is a remote
website. You can use one browser to connect to many website or open many
pages of one website at the same time. (The more browsers you open, the more
resource gets consumed.)
Every time when you call IoConnector.connect(), an IoSession is created.
Just like your web browser opens a page to a website, your browser and the
remote server need to maintain a HttpSession. All further request to the
same website(IoAcceptor) can all share this session.
Depends on the class of your protocol (stateful- you store things in the
session | stateless - nothing gets stored ), you can choose to create a
different IoSession for each working thread, or just let all the working
threads share a common one. IoSession is thread-safe, simultaneous calls
would effect each other.
It's recommended to have an ExectorFilter before your IoHandler if methods
in the handler need to do I/O operations(database accessing, socket
operation, etc time consuming tasks).
Wish this would help you.
Cheers,
Qi
stork wrote:
I'm not sure I understand - how can a SocketConnector create more than one
connection?
That would explain why the connections aren't getting close properly.
Maarten Bosteels wrote:
Hello Alex,
1) you can use one SocketConnector to create many connections
2) search the forum for Too many open files
This thread might interest you:
http://www.nabble.com/Too-many-open-files-to7521146s16868.html
HTH
Maarten
On Dec 27, 2007 4:43 PM, stork [EMAIL PROTECTED] wrote:
Hi, I'm trying to write a client that can utilize a set number of
connections
using MINA trunk (mina-core-2.0.0-M1-20071221.061156-110.jar).
I'm using the netcat
(http://svn.apache.org/viewvc/mina/trunk/example/src/main/java/org/apache/mina/example/netcat/Main.java?view=markup)
as an example but I think I'm doing it wrong. I've never used NIO before
so
this is all a bit confusing to me.
What's the preferred way of managing a lot of nio client connections
using
MINA? At the moment I'm just creating a lot of NioSocketConnector
objects,
and connecting them. I have added an IoFutureListener to the
ConnectFuture
obtained by calling nioSocketConnector.connect(InetSocketAddress):
public void operationComplete(IoFuture arg0) {
if(arg0 instanceof ConnectFuture) {
ConnectFuture cf = (ConnectFuture)arg0;
debug(connected=+cf.isConnected()+,exc=+cf.getException());
if(cf.isConnected()) {
/**
* Add the connected client to the
clients queue for processing
*/
boolean offered =
clients.offer((TyrClient)cf.getSession().getAttribute(CLIENT));
if(!offered)
throw new
RuntimeException(Couldn't offer connected client.);
} else {
/**
* Add a new connection attempt to the
connection queue.
*/
boolean offered =
pending.offer(createNewConnection(TIMEOUT));
if(!offered)
throw new
RuntimeException(Couldn't offer connection.);
}
}
}
And I'm getting a lot of this:
[T:NioSocketConnector-75] connected=false,exc=java.net.ConnectException:
Connection refused
[T:NioSocketConnector-76] connected=false,exc=java.net.ConnectException:
Connection refused
[T:NioSocketConnector-77] connected=false,exc=java.net.ConnectException:
Connection refused
(Which is being expected since I'm just connecting to a closed port)
and then,
7693 [NioSocketConnector-77] WARN
org.apache.mina.common.DefaultExceptionMonitor - Unexpected exception.
org.apache.mina.common.RuntimeIoException: Failed to initialize.
at
org.apache.mina.common.AbstractPollingIoConnector.init(AbstractPollingIoConnector.java:103)
at
org.apache.mina.common.AbstractPollingIoConnector.init(AbstractPollingIoConnector.java:61)
at
org.apache.mina.transport.socket.nio.NioSocketConnector.init(NioSocketConnector.java:52)
at tyr.Client.createNewConnection(RickRoller.java:46)
at tyr.Client.operationComplete(RickRoller.java:154)
at
org.apache.mina.common.DefaultIoFuture.notifyListener(DefaultIoFuture.java:302)
at
org.apache.mina.common.DefaultIoFuture.notifyListeners(DefaultIoFuture.java:287)
at
Re: AbstractIoSession and final qualifiers
Hi Jeff,
Do we need to remove the final modifier if we are going to provide
setters? And assuming you are using DummySession as a mock object,
I'd suggest making AbstractIoSession.setScheduled...(...) protected
and make them public in DummySession. WDYT?
Cheers,
Trustin
On Dec 28, 2007 8:19 AM, Jeff Genender [EMAIL PROTECTED] wrote:
Trustin (and others)...so how about these changes and additions to the
AbstractIoSession? This will allow the scheduledBytes/messages to be
overriden, and also allow someone to set them.
Index: core/src/main/java/org/apache/mina/common/AbstractIoSession.java
===
--- core/src/main/java/org/apache/mina/common/AbstractIoSession.java
(revision 607135)
+++ core/src/main/java/org/apache/mina/common/AbstractIoSession.java
(working copy)
@@ -488,14 +488,22 @@
lastThroughputCalculationTime = currentTime;
}
-public final long getScheduledWriteBytes() {
+public long getScheduledWriteBytes() {
return scheduledWriteBytes.get();
}
-public final int getScheduledWriteMessages() {
+public int getScheduledWriteMessages() {
return scheduledWriteMessages.get();
}
+public void setScheduledWriteBytes(long byteCount){
+scheduledWriteBytes.set(byteCount);
+}
+
+public void setScheduledWriteMessages(int messages) {
+scheduledWriteMessages.set(messages);
+}
+
protected final void increaseReadBytes(long increment, long
currentTime) {
if (increment = 0) {
return;
Thanks,
Jeff
Trustin Lee wrote:
Hi Jeff and Emmanuel,
You can add some hook for IoSession.write() by inserting an IoFilter,
so I am not sure about removing the final modifier from write().
Overriding getScheduledMessages and getScheduledBytes makes sense
though because they will always be 0 because messageSent event will be
always fired immediately.
WDYT?
Trustin
On Dec 27, 2007 10:21 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote:
Jeff Genender wrote:
What do *you* think? ;-)
Beside the assert, which was a side effect of my quick glance at the
method you want to override, I think that dooming the final is sane.
If someone needs to protect this method, then the best solution would be
to define a super class with final methods calling the AbstractIoSession
non final methods.
Another solution (puke) would be to remove the
public/protected/private qualifier, and to add a MockIoSession in the
same package. Not very elegant, but does the job too...
There are always tradeoff when you want to thoroughly unit-test some
code. When it comes to an API, it seems impossible to avoid those
tradeoff, IMHO.
Any other opinion ? Trustin ? Julien ?
Jeff
Emmanuel Lecharny wrote:
Jeff Genender wrote:
Hey guys,
I was hoping to see if we could discuss some of the final qualifiers
on some of the 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: Using a bunch of connections in a client?
Hi Qi and Maarten,
Thank you so much for sharing your experience in detail.
Cheers,
Trustin
On Dec 28, 2007 9:29 AM, Qi [EMAIL PROTECTED] wrote:
Hi there,
I used to confused on the same problem as well, so please let me share my
understanding on this.
You would only need on IoConnector if you only need one set of business
logic for handling server's response.
Let's image your IoConnector is your web browser, and IoAcceptor is a remote
website. You can use one browser to connect to many website or open many
pages of one website at the same time. (The more browsers you open, the more
resource gets consumed.)
Every time when you call IoConnector.connect(), an IoSession is created.
Just like your web browser opens a page to a website, your browser and the
remote server need to maintain a HttpSession. All further request to the
same website(IoAcceptor) can all share this session.
Depends on the class of your protocol (stateful- you store things in the
session | stateless - nothing gets stored ), you can choose to create a
different IoSession for each working thread, or just let all the working
threads share a common one. IoSession is thread-safe, simultaneous calls
would effect each other.
It's recommended to have an ExectorFilter before your IoHandler if methods
in the handler need to do I/O operations(database accessing, socket
operation, etc time consuming tasks).
Wish this would help you.
Cheers,
Qi
stork wrote:
I'm not sure I understand - how can a SocketConnector create more than one
connection?
That would explain why the connections aren't getting close properly.
Maarten Bosteels wrote:
Hello Alex,
1) you can use one SocketConnector to create many connections
2) search the forum for Too many open files
This thread might interest you:
http://www.nabble.com/Too-many-open-files-to7521146s16868.html
HTH
Maarten
On Dec 27, 2007 4:43 PM, stork [EMAIL PROTECTED] wrote:
Hi, I'm trying to write a client that can utilize a set number of
connections
using MINA trunk (mina-core-2.0.0-M1-20071221.061156-110.jar).
I'm using the netcat
(http://svn.apache.org/viewvc/mina/trunk/example/src/main/java/org/apache/mina/example/netcat/Main.java?view=markup)
as an example but I think I'm doing it wrong. I've never used NIO before
so
this is all a bit confusing to me.
What's the preferred way of managing a lot of nio client connections
using
MINA? At the moment I'm just creating a lot of NioSocketConnector
objects,
and connecting them. I have added an IoFutureListener to the
ConnectFuture
obtained by calling nioSocketConnector.connect(InetSocketAddress):
public void operationComplete(IoFuture arg0) {
if(arg0 instanceof ConnectFuture) {
ConnectFuture cf = (ConnectFuture)arg0;
debug(connected=+cf.isConnected()+,exc=+cf.getException());
if(cf.isConnected()) {
/**
* Add the connected client to the
clients queue for processing
*/
boolean offered =
clients.offer((TyrClient)cf.getSession().getAttribute(CLIENT));
if(!offered)
throw new
RuntimeException(Couldn't offer connected client.);
} else {
/**
* Add a new connection attempt to the
connection queue.
*/
boolean offered =
pending.offer(createNewConnection(TIMEOUT));
if(!offered)
throw new
RuntimeException(Couldn't offer connection.);
}
}
}
And I'm getting a lot of this:
[T:NioSocketConnector-75] connected=false,exc=java.net.ConnectException:
Connection refused
[T:NioSocketConnector-76] connected=false,exc=java.net.ConnectException:
Connection refused
[T:NioSocketConnector-77] connected=false,exc=java.net.ConnectException:
Connection refused
(Which is being expected since I'm just connecting to a closed port)
and then,
7693 [NioSocketConnector-77] WARN
org.apache.mina.common.DefaultExceptionMonitor - Unexpected exception.
org.apache.mina.common.RuntimeIoException: Failed to initialize.
at
org.apache.mina.common.AbstractPollingIoConnector.init(AbstractPollingIoConnector.java:103)
at
org.apache.mina.common.AbstractPollingIoConnector.init(AbstractPollingIoConnector.java:61)
at
org.apache.mina.transport.socket.nio.NioSocketConnector.init(NioSocketConnector.java:52)
at tyr.Client.createNewConnection(RickRoller.java:46)
at tyr.Client.operationComplete(RickRoller.java:154)
at
[jira] Commented: (DIRMINA-503) NioProcessor.transferFile needs to catch IOException on Linux
[ https://issues.apache.org/jira/browse/DIRMINA-503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554644 ] Trustin Lee commented on DIRMINA-503: - The APR transport doesn't support file transfer yet. It should be easy to implement though. :) 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 Affects Versions: 2.0.0-M1 Environment: Linux 2.6.22 Sun JDK 1.6.0_03 Reporter: Geoff Cadien Assignee: Mike Heath 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.
[jira] Commented: (DIRMINA-495) IoConnector needs a way to store information into the IoSession before the IoHandler gets ahold of it
[
https://issues.apache.org/jira/browse/DIRMINA-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554645
]
Trustin Lee commented on DIRMINA-495:
-
I'd prefer IoSessionInitializer? extends ConnectFuture to
IoSessionInitializerConnectFuture. Except that, the change looks very good!
IoConnector needs a way to store information into the IoSession before the
IoHandler gets ahold of it
-
Key: DIRMINA-495
URL: https://issues.apache.org/jira/browse/DIRMINA-495
Project: MINA
Issue Type: New Feature
Components: Core
Reporter: David M. Lloyd
Assignee: Mike Heath
Fix For: 2.0.0-M1
Attachments: DIRMINA-495-3.patch, DIRMINA-495-mikeheath.patch,
IoConnector.patch
It is often necessary to pass information into the IoHandler associated with
an IoConnector. Sometimes this information is needed even as early as
IoSession creation time. A mechanism is needed to pass information in to the
IoSession at the time you call IoConnector.connect(). Discussing this with
Mike Heath, we determined that a logical approach could be to have variants
of the connect() methods that accept information that can be attached to the
IoSession when it is created.
One option is to simply pass a Map in to the connect method. The contents of
the Map would be copied into the IoSession's attribute map after it is
constructed but before the IoHandler.sessionCreated method is created. In
addition, it seems likely that in many cases only one entry would need to be
added - in this case the user could simply do this:
ioConnector.connect(addr, Collections.singletonMap(MY_KEY, theValue));
Another option would be to use variable argument lists to accept any number
of key-value pairs. The pairs could be represented by a class -
AttributePair for example. It could look like this:
public final class AttributePairK, V {
private final K key;
private final V value;
private AttributePair(K key, V value) { this.key = key; this.value =
value; }
public static K, V AttributePairK,V pair(K key, V value) { return
new AttributePairK, V(key, value); }
}
Then the user can use static imports to pull in the pair method. The
connect() method on IoConnector could accept a variable list of AttributePair
objects, so the user could write code like this:
ioConnector.connect(addr, pair(MY_KEY1, myValue), pair(MY_KEY2,
myValue2));
Though this approach is somewhat more complicated than just using a Map.
Other approaches may also be discussed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Question regarding mina server with high load client
Hi Ashish, On Dec 28, 2007 2:21 AM, Ashish Sharma [EMAIL PROTECTED] wrote: Hi Recently I have been experimenting with mina core 2 and I have a few questions regarding the behaviour of mina in some sample programs I made. here is the client code. its simple, it simply rams as many messages as possible into the server. http://pastebin.com/m14ac361e Now I made two servers. One mina based, which is simply the date/time echo server as described in the documentation. The second one is a simple one thread per client server. Here is the code http://pastebin.com/m3a5a14a7 Now the result from both the servers differ a lot. The second server works in lock step with client and responds to messages without any delay. But with mina server the response is very slow and after about 10 messages the response is almost nill and after a few seconds I start getting out of memory exceptions while creating more date objects. Now I have the following questions (I very good spirit) 1. What is the reason behind this behaviour ? Please make sure that you are using heap buffers and configured the thread model correctly. And I hope you are using the latest stable release. 3. Is there a solution to this ? IMHO, first server example demonstrates that such high load can be handled at server. If your client connects and disconnects very frequently, it might slow down your MINA application. Please try to keep the connection alive whenever possible. HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
[jira] Created: (DIRMINA-504) Allow ProtocolEncoder to generate non-IoBuffer objects
Allow ProtocolEncoder to generate non-IoBuffer objects -- Key: DIRMINA-504 URL: https://issues.apache.org/jira/browse/DIRMINA-504 Project: MINA Issue Type: Improvement Components: Filter Reporter: Trustin Lee Assignee: Trustin Lee Fix For: 2.0.0-M1 For now, ProtocolEncoderOutput.write() accepts only IoBuffer as a parameter, and therefore a user cannot generate FileRegion or any other kind of object for multi-layered protocols. ProtocolEncoderOutput.write() should accept any object to remove this limitation. Additionally, ProtocolEncoderOutput.mergeAll() should perform sanity check before merging IoBuffers because the content of the queue might be mixed up with IoBuffers and non-IoBuffers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ProtocolEncoderOutput and FileRegion
Hi Geoff, On Dec 27, 2007 10:52 AM, Trustin Lee [EMAIL PROTECTED] wrote: 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! It has been resolved: https://issues.apache.org/jira/browse/DIRMINA-504 HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
[jira] Resolved: (DIRMINA-504) Allow ProtocolEncoder to generate non-IoBuffer objects
[ https://issues.apache.org/jira/browse/DIRMINA-504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trustin Lee resolved DIRMINA-504. - Resolution: Fixed Resolved as described Allow ProtocolEncoder to generate non-IoBuffer objects -- Key: DIRMINA-504 URL: https://issues.apache.org/jira/browse/DIRMINA-504 Project: MINA Issue Type: Improvement Components: Filter Reporter: Trustin Lee Assignee: Trustin Lee Fix For: 2.0.0-M1 For now, ProtocolEncoderOutput.write() accepts only IoBuffer as a parameter, and therefore a user cannot generate FileRegion or any other kind of object for multi-layered protocols. ProtocolEncoderOutput.write() should accept any object to remove this limitation. Additionally, ProtocolEncoderOutput.mergeAll() should perform sanity check before merging IoBuffers because the content of the queue might be mixed up with IoBuffers and non-IoBuffers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: support for asyncrhonous messaging on a per-connection basis
Hi Scott, On Dec 26, 2007 3:48 AM, [EMAIL PROTECTED] wrote: If a single client session sends multiple requests before a response for the first request is sent by the server, it appears that client requests are processed sequentially/serially. It appears that the processing of the second request does commence until the first response is returned (i.e., until messageReceived() returns). I was wondering if there's a mina-specific way to do the processing of multiple requests from a single session in parallel. If you are using 2.0.0-M1-SNAPSHOT, then you can use UnorderedThreadPoolExecutor to achieve what you want. If you are using 1.x, then you will have to modify ExecutorFilter.java. It shouldn't be that difficult. :) Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: AbstractIoSession and final qualifiers
Yep...agreed...how is this?
Index: core/src/main/java/org/apache/mina/common/AbstractIoSession.java
===
--- core/src/main/java/org/apache/mina/common/AbstractIoSession.java
(revision 607135)
+++ core/src/main/java/org/apache/mina/common/AbstractIoSession.java
(working copy)
@@ -496,6 +496,14 @@
return scheduledWriteMessages.get();
}
+protected void setScheduledWriteBytes(long byteCount){
+scheduledWriteBytes.set(byteCount);
+}
+
+protected void setScheduledWriteMessages(int messages) {
+scheduledWriteMessages.set(messages);
+}
+
protected final void increaseReadBytes(long increment, long
currentTime) {
if (increment = 0) {
return;
Trustin Lee wrote:
Hi Jeff,
Do we need to remove the final modifier if we are going to provide
setters? And assuming you are using DummySession as a mock object,
I'd suggest making AbstractIoSession.setScheduled...(...) protected
and make them public in DummySession. WDYT?
Cheers,
Trustin
On Dec 28, 2007 8:19 AM, Jeff Genender [EMAIL PROTECTED] wrote:
Trustin (and others)...so how about these changes and additions to the
AbstractIoSession? This will allow the scheduledBytes/messages to be
overriden, and also allow someone to set them.
Index: core/src/main/java/org/apache/mina/common/AbstractIoSession.java
===
--- core/src/main/java/org/apache/mina/common/AbstractIoSession.java
(revision 607135)
+++ core/src/main/java/org/apache/mina/common/AbstractIoSession.java
(working copy)
@@ -488,14 +488,22 @@
lastThroughputCalculationTime = currentTime;
}
-public final long getScheduledWriteBytes() {
+public long getScheduledWriteBytes() {
return scheduledWriteBytes.get();
}
-public final int getScheduledWriteMessages() {
+public int getScheduledWriteMessages() {
return scheduledWriteMessages.get();
}
+public void setScheduledWriteBytes(long byteCount){
+scheduledWriteBytes.set(byteCount);
+}
+
+public void setScheduledWriteMessages(int messages) {
+scheduledWriteMessages.set(messages);
+}
+
protected final void increaseReadBytes(long increment, long
currentTime) {
if (increment = 0) {
return;
Thanks,
Jeff
Trustin Lee wrote:
Hi Jeff and Emmanuel,
You can add some hook for IoSession.write() by inserting an IoFilter,
so I am not sure about removing the final modifier from write().
Overriding getScheduledMessages and getScheduledBytes makes sense
though because they will always be 0 because messageSent event will be
always fired immediately.
WDYT?
Trustin
On Dec 27, 2007 10:21 AM, Emmanuel Lecharny [EMAIL PROTECTED] wrote:
Jeff Genender wrote:
What do *you* think? ;-)
Beside the assert, which was a side effect of my quick glance at the
method you want to override, I think that dooming the final is sane.
If someone needs to protect this method, then the best solution would be
to define a super class with final methods calling the AbstractIoSession
non final methods.
Another solution (puke) would be to remove the
public/protected/private qualifier, and to add a MockIoSession in the
same package. Not very elegant, but does the job too...
There are always tradeoff when you want to thoroughly unit-test some
code. When it comes to an API, it seems impossible to avoid those
tradeoff, IMHO.
Any other opinion ? Trustin ? Julien ?
Jeff
Emmanuel Lecharny wrote:
Jeff Genender wrote:
Hey guys,
I was hoping to see if we could discuss some of the final qualifiers
on some of the 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: How to lost message
On Dec 25, 2007 10:47 PM, Steve Johns [EMAIL PROTECTED] wrote: Did everyone test if Mina drops the message under heavy loading? In Mina wesite, I only saw the HTTP server benchmark test. Does everyone have the pure socket server benchmark test result? Thanks in advance. With a simple echo client-server test, I was able to get apx. 160~190MB/s throughput. The server and the client was in the same machine, so loopback device was used. A real world test with some proprietary RPC protocol shows that it doesn't drop a message even under heavy load. However, you will have to test your application by yourself, and let us know if something goes wrong. :) HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
