Hello MINA developers & users,
I'm sure your inboxes have been flooded with emails from JIRA regarding
issues being closed. Emmanuel and I have decided to and are beginning the
process of deprecating the 3.0 branch. This means that support for the 3.0
branch has officially ended. All
[
https://issues.apache.org/jira/browse/DIRMINA-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Valliere resolved DIRMINA-951.
---
Resolution: Abandoned
> Add Getting started Page for MINA
[
https://issues.apache.org/jira/browse/DIRMINA-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny updated DIRMINA-951:
--
Fix Version/s: 3.0.0-trunk
Add Getting started Page for MINA 3.0
Is https://issues.apache.org/jira/browse/DIRMINA-934 dead or just
forgotten? I'm still using a patched version in Red5 and would love to see
it committed. Lastly, whats the current status of a 3.0 release? I'd like
to get started porting the our I/O code to work with it.
Regards,
Paul
--
+1 for JMX
On Thu, Jul 25, 2013 at 6:03 PM, Julien Vermillard jvermill...@gmail.comwrote:
On Thu, Jul 25, 2013 at 5:59 PM, Ashish paliwalash...@gmail.com wrote:
On Thu, Jul 25, 2013 at 9:24 PM, Emmanuel Lécharny elecha...@gmail.com
wrote:
Le 7/25/13 5:24 PM, Ashish a écrit :
Folks,
Folks,
Since we have M1 release, we can think about adding Monitoring support to
MINA.
Yammer's Metrics package is quite widely used for this.
http://metrics.codahale.com/
I do not have a concrete idea on how to go about putting monitoring in
place. It would be worth discussing about it.
We
nice idea, would like to see a metrics module providing IoFilter using
metrics.codahale.
--
Julien Vermillard http://people.apache.org/~jvermillard/
On Thu, Jul 25, 2013 at 5:24 PM, Ashish paliwalash...@gmail.com wrote:
Folks,
Since we have M1 release, we can think about adding
25 juillet 2013 17h24
Objet : Adding Monitoring to MINA 3.0
Folks,
Since we have M1 release, we can think about adding Monitoring support to
MINA.
Yammer's Metrics package is quite widely used for this.
http://metrics.codahale.com/
I do not have a concrete idea on how to go about putting
tests
So big +1 for your idea Ashish
Cordialement, Regards,
-Edouard De Oliveira-
De : Ashish paliwalash...@gmail.com
À : dev@mina.apache.org
Envoyé le : Jeudi 25 juillet 2013 17h24
Objet : Adding Monitoring to MINA 3.0
Folks,
Since we have M1
Le 7/25/13 5:24 PM, Ashish a écrit :
Folks,
Since we have M1 release, we can think about adding Monitoring support to
MINA.
Yammer's Metrics package is quite widely used for this.
http://metrics.codahale.com/
I do not have a concrete idea on how to go about putting monitoring in
place.
On Thu, Jul 25, 2013 at 9:24 PM, Emmanuel Lécharny elecha...@gmail.comwrote:
Le 7/25/13 5:24 PM, Ashish a écrit :
Folks,
Since we have M1 release, we can think about adding Monitoring support to
MINA.
Yammer's Metrics package is quite widely used for this.
On Thu, Jul 25, 2013 at 5:59 PM, Ashish paliwalash...@gmail.com wrote:
On Thu, Jul 25, 2013 at 9:24 PM, Emmanuel Lécharny elecha...@gmail.comwrote:
Le 7/25/13 5:24 PM, Ashish a écrit :
Folks,
Since we have M1 release, we can think about adding Monitoring support to
MINA.
Yammer's
[
https://issues.apache.org/jira/browse/DIRMINA-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ashish Paliwal updated DIRMINA-951:
---
Summary: Add Getting started Page for MINA 3.0 (was: Add Getting started
for MINA 3.0
Ashish Paliwal created DIRMINA-951:
--
Summary: Add Getting started for MINA 3.0
Key: DIRMINA-951
URL: https://issues.apache.org/jira/browse/DIRMINA-951
Project: MINA
Issue Type: Task
Le 7/16/13 2:34 AM, sebb a écrit :
On 29 June 2013 21:41, Emmanuel Lécharny elecha...@gmail.com wrote:
Le 6/29/13 7:35 PM, Julien Vermillard a écrit :
I think having the codec module java 6 compatible would help to use it
with MINA2 or other framework.
WDYT ?
I don't mind if it's JAVA 6
Le 7/16/13 2:41 AM, sebb a écrit :
On 21 May 2013 10:02, Steve Ulrich steve.ulr...@proemion.com wrote:
2 Reasons for 7.0:
1) When MINA 3 is released, Java 8 is near or already released
2) Developers who don't want to upgrade to Java 7 because of the (testing,
developing, whatever) effort
sebb [mailto:seb...@gmail.com] wrote:
On 21 May 2013 10:02, Steve Ulrich steve.ulr...@proemion.com wrote:
2 Reasons for 7.0:
1) When MINA 3 is released, Java 8 is near or already released
2) Developers who don't want to upgrade to Java 7 because of the
(testing, developing, whatever)
Le 7/16/13 10:34 AM, Steve Ulrich a écrit :
sebb [mailto:seb...@gmail.com] wrote:
On 21 May 2013 10:02, Steve Ulrich steve.ulr...@proemion.com wrote:
2 Reasons for 7.0:
1) When MINA 3 is released, Java 8 is near or already released
2) Developers who don't want to upgrade to Java 7 because of
On 16 July 2013 09:12, Emmanuel Lécharny elecha...@gmail.com wrote:
Le 7/16/13 2:41 AM, sebb a écrit :
On 21 May 2013 10:02, Steve Ulrich steve.ulr...@proemion.com wrote:
2 Reasons for 7.0:
1) When MINA 3 is released, Java 8 is near or already released
2) Developers who don't want to upgrade
Le 7/16/13 12:10 PM, sebb a écrit :
I don't think that's generally true.
If MINA is part of a larger system, then updating Java as well as MINA
is a lot more work and testing than just updating MINA.
Especially if the system is installed on multiple nodes which may have
different hardware
On 16 July 2013 14:07, Emmanuel Lécharny elecha...@gmail.com wrote:
Le 7/16/13 12:10 PM, sebb a écrit :
I don't think that's generally true.
If MINA is part of a larger system, then updating Java as well as MINA
is a lot more work and testing than just updating MINA.
Especially if the
Le 7/16/13 6:57 PM, sebb a écrit :
In other words, Time is of the essence
Well yes, but that has little to do with whether to move to Java 6 or Java 7.
In our case, it does. We aren't enough and we have not a lot of work
time to dedicate to support for older versions of java for all the MINA
On 29 June 2013 21:41, Emmanuel Lécharny elecha...@gmail.com wrote:
Le 6/29/13 7:35 PM, Julien Vermillard a écrit :
I think having the codec module java 6 compatible would help to use it
with MINA2 or other framework.
WDYT ?
I don't mind if it's JAVA 6 compatble, as soon as we still can
[mailto:raphael.barazzu...@gmail.com] wrote:
IMHO, developers who will do the jump to MINA 3.0, might also want to
benefit of the cutting-edge features of JDK7.
+1 for MINA 3.0 on JDK7
--
PROEMION GmbH
Steve Ulrich
the jump to MINA 3.0, might also want to
benefit of the cutting-edge features of JDK7.
+1 for MINA 3.0 on JDK7
--
PROEMION GmbH
Steve Ulrich
IT Development (IT/DEV)
Donaustrasse 14
D-36043 Fulda, Germany
Phone +49 (0
Le 6/29/13 7:35 PM, Julien Vermillard a écrit :
I think having the codec module java 6 compatible would help to use it
with MINA2 or other framework.
WDYT ?
I don't mind if it's JAVA 6 compatble, as soon as we still can benefit
from Java 7 features in the core.
Also be sure to add a warning in
A couple of examples for those modules would be a nice addition.
Raphael you think you can provide that ?
julien
--
Julien Vermillard http://people.apache.org/~jvermillard/
On Thu, May 9, 2013 at 7:58 PM, Jeff MAURY jeffma...@gmail.com wrote:
My +1
Jeff
—
Sent from Mailbox for iPhone
Hi Julien,
You're right it'd a nice addition. I've some fixes to commit and then I can
focus on providing examples.
Regards,
Raphaël
On Tue, Jun 11, 2013 at 3:33 PM, Julien Vermillard jvermill...@gmail.comwrote:
A couple of examples for those modules would be a nice addition.
Raphael
+1 for MINA 3.0 on JDK7
2013/5/20 Raphaël Barazzutti raphael.barazzu...@gmail.com
IMHO, developers who will do the jump to MINA 3.0, might also want to
benefit of the cutting-edge features of JDK7.
+1 for MINA 3.0 on JDK7
On Mon, May 20, 2013 at 9:39 AM, Julien Vermillard jvermill
] wrote:
IMHO, developers who will do the jump to MINA 3.0, might also want to
benefit of the cutting-edge features of JDK7.
+1 for MINA 3.0 on JDK7
--
PROEMION GmbH
Steve Ulrich
IT Development (IT/DEV)
Donaustrasse 14
D
Hi !
Would it cause problems for having MINA 3 jdk7 only ?
The rational is quite simple : multicast udp support is only in jdk7.
I know a lot of people are still running jdk6 or event 5 :) that's why I ask.
Julien
Le 5/20/13 8:36 AM, Julien Vermillard a écrit :
Hi !
Would it cause problems for having MINA 3 jdk7 only ?
The rational is quite simple : multicast udp support is only in jdk7.
I know a lot of people are still running jdk6 or event 5 :) that's why I ask.
Java 6 is EOL since last year.
The idea of being 7 only is to avoid that ;)
On Mon, May 20, 2013 at 9:15 AM, Emmanuel Lécharny elecha...@gmail.com wrote:
Le 5/20/13 8:36 AM, Julien Vermillard a écrit :
Hi !
Would it cause problems for having MINA 3 jdk7 only ?
The rational is quite simple : multicast udp support is only
IMHO, developers who will do the jump to MINA 3.0, might also want to
benefit of the cutting-edge features of JDK7.
+1 for MINA 3.0 on JDK7
On Mon, May 20, 2013 at 9:39 AM, Julien Vermillard jvermill...@gmail.comwrote:
The idea of being 7 only is to avoid that ;)
On Mon, May 20, 2013 at 9
raphael.barazzu...@gmail.com wrote:
Hi MINA-developers!
Using extensively MINA 2.0 at my work, I’d like to contribute to the next
MINA version.
IMHO, MINA 3.0 could provide serialization facilities like Apache Thrift
and Google Protobuf transport.
According to that I decide to propose
Le 5/9/13 5:17 PM, Julien Vermillard a écrit :
What do you think of having the two modules (thrift and protobuff)
dicrectly at the root of the project and not in a serialization
intermediate module ?
That would reduce pom hierarchy/maintenance.
My +1
--
Regards,
Cordialement,
Emmanuel
My +1
Jeff
—
Sent from Mailbox for iPhone
On Thu, May 9, 2013 at 7:48 PM, Emmanuel Lécharny elecha...@gmail.com
wrote:
Le 5/9/13 5:17 PM, Julien Vermillard a écrit :
What do you think of having the two modules (thrift and protobuff)
dicrectly at the root of the project and not in a
raphael.barazzu...@gmail.com wrote:
Hi MINA-developers!
Using extensively MINA 2.0 at my work, I’d like to contribute to the next
MINA version.
IMHO, MINA 3.0 could provide serialization facilities like Apache Thrift
and Google Protobuf transport.
According to that I decide
serialization
codec bothering everybody on android !
Julien
On Sun, May 5, 2013 at 1:31 AM, Raphaël Barazzutti
raphael.barazzu...@gmail.com wrote:
Hi MINA-developers!
Using extensively MINA 2.0 at my work, I’d like to contribute to the next
MINA version.
IMHO, MINA 3.0 could provide
Le 5/5/13 10:44 AM, Julien Vermillard a écrit :
Hi Raphäel
Looks neat, I have definitively a use case for that : RPC.
Perhaps we should have two maven module : one for thrift, one for
protobuf ? This would avoid people to have thrift dependency when they
use protobuff (and vice versa).
Hi Ashish,
You're right, to decode fragmented packet I need to keep track of the data
before the message is complete.
With MINA 2.0, I'm using a CumulativeProtocolDecoder to handle these
issues.
I'll fix this using a context in my decoders,
I agree with you that MINA 3.0 might need something
bothering everybody on android !
Julien
On Sun, May 5, 2013 at 1:31 AM, Raphaël Barazzutti
raphael.barazzu...@gmail.com wrote:
Hi MINA-developers!
Using extensively MINA 2.0 at my work, I’d like to contribute to the next
MINA version.
IMHO, MINA 3.0 could provide serialization facilities
Hi MINA-developers!
Using extensively MINA 2.0 at my work, I’d like to contribute to the next
MINA version.
IMHO, MINA 3.0 could provide serialization facilities like Apache Thrift
and Google Protobuf transport.
According to that I decide to propose the following code to be merged with
the main
Le 5/5/13 1:31 AM, Raphaël Barazzutti a écrit :
Hi MINA-developers!
Hi Raphaël !
Using extensively MINA 2.0 at my work, I’d like to contribute to the next
MINA version.
IMHO, MINA 3.0 could provide serialization facilities like Apache Thrift
and Google Protobuf transport.
This is most
decoder to decode the messages. My implementation is
still in initial stage.
On Sun, May 5, 2013 at 5:01 AM, Raphaël Barazzutti
raphael.barazzu...@gmail.com wrote:
Hi MINA-developers!
Using extensively MINA 2.0 at my work, I’d like to contribute to the next
MINA version.
IMHO, MINA 3.0 could
Le 11/17/12 7:42 AM, Julien Vermillard a écrit :
well I strongly disagreeing here :)
The selector listener and the selector loop should be seen as a wrapper on
top of nio to make things easier.
I don't disagree here.
The event can happen at the same moment so we need to provide them as is
Hi guys,
I looked at the SelectorListner interface and its implementation.
Here is the hierarchy of classes implementing this interface :
(SelectorListener)
o
|
+-- [NioTcpServer]
|
+-- [NioUdpServer]
|
+-- [NioTcpSesession]
The interface
well I strongly disagreeing here :)
The selector listener and the selector loop should be seen as a wrapper on
top of nio to make things easier.
The event can happen at the same moment so we need to provide them as is
and not to choose the order to propagate them.
It's up to the listener to
Hi,
I'm reintroducing IoHandler in mina 3.
The idea is to have one Iohandler per IoService :
{snip}
final NioTcpServer server = new NioTcpServer();
// create the fitler chain for this service
server.setFilters(securityFilter,codec,logging);
server.setIoHanlder( new DefaultIoHandler() {
//
+1 for IoHandler
Just thinking about the Use Cases for IoServiceListeners. If we have it,
what could we achieve by having it. One thing is could have Event listeners
which can do custom functionality on these events. Like if serviceInactive
event, might want to close some resources, and acquire
Sorry for the delayed +...
Your commit just reminded me that I had to say I agreed on your suggestion.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
We did. Julien did committed some code.
Lets see if we those changes.
On Thu, Nov 8, 2012 at 2:41 PM, Emmanuel Lécharny elecha...@gmail.comwrote:
Le 11/8/12 10:01 AM, Ashish a écrit :
Does anyone know why our Sonar profile hasn't been updated since Sept 30th
2012?
I think we changed the SVN url and added a /mina/ before the /trunk.
jenkins build suffered that syndrome and automatically unactivated
On Thu, Nov 8, 2012 at 10:39 AM, Ashish paliwalash...@gmail.com wrote:
We did. Julien did committed some code.
Lets see if we those changes.
On Thu, Nov
Le 11/8/12 12:20 PM, Julien Vermillard a écrit :
I think we changed the SVN url and added a /mina/ before the /trunk.
I have created a JIRA in order to have MINA being updated, and the other
subprojects to be added :
https://issues.apache.org/jira/browse/INFRA-5495
--
Regards,
Cordialement,
It's back !
https://analysis.apache.org/drilldown/violations/24437
Le 11/8/12 12:20 PM, Julien Vermillard a écrit :
I think we changed the SVN url and added a /mina/ before the /trunk.
jenkins build suffered that syndrome and automatically unactivated
On Thu, Nov 8, 2012 at 10:39 AM,
It's 2.0.8 version..
The link I sent was different (it was for trunk). I think it might have got
broken when we changed our directory structure.
Anyways not priority, it's definitely helpful, but not a blocker :)
On Thu, Nov 8, 2012 at 7:02 PM, Emmanuel Lécharny elecha...@gmail.comwrote:
It's
MINA 2.0 and MINA 3.0. It will be done later this
afternon. Right now, the 2.0 sonar instance has been fixed and reflects
the current state. -- Regards, Cordialement, Emmanuel Lécharny
www.iktek.com
Hi guys, some thoughts about the TCP server. feel free to comment.
TCP server MINA 3
-
As we are reworking the server part of MINA, we can review the current
architecture. There are a few problems we can address.
1) One vs Many selectors
In MINA 2, we do have at least 2
Hi Emmanuel,
1) One Reactor is preferable. Easier to manage, easier to code, meets all the
requirements.
2) Event Processing: Use non-blocking sockets. Accept, connect, read and write
won't hang each other up.
I have some code that does this. I'll get it and attach to a subsequent email.
It
On Fri, Jun 1, 2012 at 2:28 PM, Emmanuel Lécharny elecha...@gmail.com wrote:
Le 5/31/12 8:55 PM, Julien Vermillard a écrit :
Hi,
In mina 2 the event loops are composed of Acceptor/Connector (for
accepting/connecting TCP sessions) and IoProcessor for handling
session read and write events.
Le 6/2/12 4:38 PM, Julien Vermillard a écrit :
On Fri, Jun 1, 2012 at 2:28 PM, Emmanuel Lécharnyelecha...@gmail.com wrote:
Le 5/31/12 8:55 PM, Julien Vermillard a écrit :
Hi,
In mina 2 the event loops are composed of Acceptor/Connector (for
accepting/connecting TCP sessions) and IoProcessor
Le 5/31/12 8:55 PM, Julien Vermillard a écrit :
Hi,
In mina 2 the event loops are composed of Acceptor/Connector (for
accepting/connecting TCP sessions) and IoProcessor for handling
session read and write events. For each service you need at least one
Acceptor/connector and one IoProcessor, so
Hi,
In mina 2 the event loops are composed of Acceptor/Connector (for
accepting/connecting TCP sessions) and IoProcessor for handling
session read and write events. For each service you need at least one
Acceptor/connector and one IoProcessor, so at least two threads. For a
simple TCP base
Julien,
I agree. A single thread with one Selector can be optimized for non-blocking
I/O to handle a large number of streams simultaneously.
-Chad
On May 31, 2012, at 2:55 PM, Julien Vermillard wrote:
Hi,
In mina 2 the event loops are composed of Acceptor/Connector (for
On Tue, Jan 24, 2012 at 1:44 PM, Emmanuel Lecharny elecha...@gmail.com wrote:
On 1/24/12 1:32 PM, Christian Schwarz wrote:
Hello,
will it be possible to disable the Idle detection when i don't need it?
We should make it optional, absolutely. This should be a parameter of the
IoProcessor
Hi,
Actually in MINA1/2 the idle is computed each second by scanning *all*
session of a service. If you have a large number of session, it could
create some student latency in the selector loop.
For trying to keep the scanning a bit more lightweight, I was thinking
about another solution :
For
On 1/24/12 12:53 PM, Julien Vermillard wrote:
Hi,
Hi,
Actually in MINA1/2 the idle is computed each second by scanning *all*
session of a service. If you have a large number of session, it could
create some student latency in the selector loop.
yes, not good...
For trying to keep the
Hello,
will it be possible to disable the Idle detection when i don't need it? In
MINA 2 we have 10 Idle-Checker-Threads if we implement 10 different
Protocols ( one IOService per Protocol). If we dont need them, they are a
wasted resource. So it would be nice to disable the Idle detection.
On 1/24/12 1:32 PM, Christian Schwarz wrote:
Hello,
will it be possible to disable the Idle detection when i don't need it?
We should make it optional, absolutely. This should be a parameter of
the IoProcessor (as an IoProcessor will handle more than one service).
--
Regards,
On Mon, Jan 16, 2012 at 1:10 PM, Emmanuel Lecharny elecha...@gmail.comwrote:
On 1/16/12 2:56 PM, Chad Beaulac wrote:
Emmanuel, (all)
I'm working on this Camel ticket:
https://issues.apache.org/**jira/browse/CAMEL-2624https://issues.apache.org/jira/browse/CAMEL-2624
I finished the initial
On 1/17/12 3:02 PM, Chad Beaulac wrote:
On Mon, Jan 16, 2012 at 1:10 PM, Emmanuel Lecharnyelecha...@gmail.comwrote:
On 1/16/12 2:56 PM, Chad Beaulac wrote:
Emmanuel, (all)
I'm working on this Camel ticket:
On Jan 17, 2012, at 9:32 AM, Emmanuel Lécharny elecha...@apache.org wrote:
On 1/17/12 3:02 PM, Chad Beaulac wrote:
On Mon, Jan 16, 2012 at 1:10 PM, Emmanuel Lecharnyelecha...@gmail.comwrote:
On 1/16/12 2:56 PM, Chad Beaulac wrote:
Emmanuel, (all)
I'm working on this Camel ticket:
IFAICT, on MINA 2, you should not have any issue.
The loop where we write buffers into the channel is :
...
final int maxWrittenBytes =
session.getConfig().getMaxReadBufferSize()
+ (session.getConfig().getMaxReadBufferSize() 1);
int writtenBytes = 0;
Ok. I'll test the throughput on it with the tests I have.
Thanks
Chad
Sent from my iPad
On Jan 17, 2012, at 11:33 AM, Emmanuel Lecharny elecha...@gmail.com wrote:
IFAICT, on MINA 2, you should not have any issue.
The loop where we write buffers into the channel is :
...
On 1/18/12 2:57 AM, Chad Beaulac wrote:
Ok. I'll test the throughput on it with the tests I have.
Let me know if you have any isues with the throughput you obtain.
Be sure to set the default read buffer size to the maximum size, AFAIR,
it's set to 2048 bytes in MINA 2 (and can't be higher
Emmanuel, (all)
I'm working on this Camel ticket:
https://issues.apache.org/jira/browse/CAMEL-2624
I finished the initial cut of
https://issues.apache.org/jira/browse/CAMEL-3471 to create a mina2
component in Camel.
CAMEL-2624 adds the full async behavior for Mina2 endpoints in Camel.
Would it
On 1/16/12 2:56 PM, Chad Beaulac wrote:
Emmanuel, (all)
I'm working on this Camel ticket:
https://issues.apache.org/jira/browse/CAMEL-2624
I finished the initial cut of
https://issues.apache.org/jira/browse/CAMEL-3471 to create a mina2
component in Camel.
CAMEL-2624 adds the full async
Hi,
snipped a lot of the message :)
So, do you mean that the underlying layer will not allow us to push say,
20M, without informing the session that it's full ? In other word, there
is a limited size that can be pushed and we don't have to take care of
this limit ourselves ?
Sort of. If
On 12/4/11 2:34 PM, Chad Beaulac wrote:
Hi Chad,
Agreed :-)
Do you have a Git repo setup for Mina3? I'll help you write some of it if
you like. With unit tests, of course. ;-)
http://git.apache.org/
This is a read only Git repos. Internally, we are -still- using SVN (but
we are
Looks perfect except one thing. Don't allow clients to put WriteRequest's
into the queue while you're draining it. If you allow other threads to
enqueue more WriteRequest's, the algorithm is unbounded and you risk
getting stuck writing for only one channel. I added a synchronized block
below.
On
On 12/5/11 2:39 PM, Chad Beaulac wrote:
Looks perfect except one thing. Don't allow clients to put WriteRequest's
into the queue while you're draining it. If you allow other threads to
enqueue more WriteRequest's, the algorithm is unbounded and you risk
getting stuck writing for only one
Excellent. I like the counter in the write algorithm.
Sent from my iPhone
On Dec 5, 2011, at 8:50 AM, Emmanuel Lecharny elecha...@gmail.com wrote:
On 12/5/11 2:39 PM, Chad Beaulac wrote:
Looks perfect except one thing. Don't allow clients to put WriteRequest's
into the queue while you're
since it's a ConcurrentLinkedQueue it could be a perf killer to do a .size()
from the oracle javadoc :
Beware that, unlike in most collections, the size method is NOT a
constant-time operation. Because of the asynchronous nature of these
queues, determining the current number of elements requires
On 12/5/11 3:50 PM, Julien Vermillard wrote:
since it's a ConcurrentLinkedQueue it could be a perf killer to do a
.size() from the oracle javadoc : Beware that, unlike in most
collections, the size method is NOT a constant-time operation. Because
of the asynchronous nature of these queues,
Posted on the wrong mailing list... Forwarding there.
Hi Chad,
On 12/4/11 1:25 AM, Chad Beaulac wrote:
A single algorithm
can handle large data pipes and provide extremely low latency for
variable,
small and large message sizes at the same time.
AFAIU, it' snot because you use a big
On Sun, Dec 4, 2011 at 8:04 AM, Emmanuel Lecharny elecha...@gmail.comwrote:
Posted on the wrong mailing list... Forwarding there.
Hi Chad,
On 12/4/11 1:25 AM, Chad Beaulac wrote:
A single algorithm
can handle large data pipes and provide extremely low latency for
variable,
small
I think I'm not communicating my thoughts well enough. A single algorithm
can handle large data pipes and provide extremely low latency for variable,
small and large message sizes at the same time.
On the Producer side:
Application code should determine the block sizes that are pushed onto the
On 12/2/11 2:02 PM, Chad Beaulac wrote:
I think I'm not communicating my thoughts well enough.
Well, I hope I have undesrtood what you said, at least :)
A single algorithm
can handle large data pipes and provide extremely low latency for variable,
small and large message sizes at the same
Hi guys,
yesterday, I committed some changes that make the NioSelectorProcessor
to use the IoBuffer class instead of a singe buffer to store the
incoming data. Here is the snippet of changed code :
int readCount = 0;
IoBuffer
Hi Emmanuel,
A 1k ByteBuffer will be too small for large data pipes. Consider using 64k
like you mentioned yesterday.
Draining the channel before returning control to the program can be
problematic. This thread can monopolize the CPU and other necessary
processing could get neglected. The
Forwarded to the ML
Quick note below.
Sent from my iPhone
On Dec 1, 2011, at 7:51 AM, Emmanuel Lécharnyelecha...@apache.org wrote:
On 12/1/11 1:32 PM, Chad Beaulac wrote:
Hi Emmanuel,
A 1k ByteBuffer will be too small for large data pipes. Consider using 64k
like you mentioned
On 12/1/11 2:49 PM, Emmanuel Lécharny wrote:
Forwarded to the ML
Quick note below.
Sent from my iPhone
On Dec 1, 2011, at 7:51 AM, Emmanuel Lécharnyelecha...@apache.org
wrote:
On 12/1/11 1:32 PM, Chad Beaulac wrote:
Hi Emmanuel,
A 1k ByteBuffer will be too small for large data
On 12/1/11 5:28 PM, Steve Ulrich wrote:
Hi (quickly reading ,
reading everything-you-can-get might starve the application logic.
We currently have some realtime stuff which must be transferred as quickly as
possible, but it's just some bytes (Biggest messages are 1K, smallest about 10 bytes).
The reverse is true for the producer. Let's assume the writer/producer has a
list of ByteBuffer. When the selector fires that you can write for the channel
then:
- write until there's nothing left to write, unregister for the write event,
return to event processing
- write until the the channel
Hi guys,
right now, Julien and I have experimented the MINA 3.0 branch writing a
Http codec and a Ldap codec. So far, so good, for basic scenario it
works well.
Now, I'd like to know if it would be a good idea to move the
ProtocolCodecFilter we have in MINA 2 to MINA 3? The rational would
On Tue, Oct 4, 2011 at 9:29 AM, Emmanuel Lecharny elecha...@gmail.com wrote:
Hi guys,
right now, Julien and I have experimented the MINA 3.0 branch writing a Http
codec and a Ldap codec. So far, so good, for basic scenario it works well.
good to hear :)
Now, I'd like to know if it would
Hi !
actually in MINA 1.0 2..0 there is something implemented with an
ugly hack : the future returned by session.write(..) and
IoHandler#messageSent(..);
The main problem is you usually write a pojo at the session level, and
it's transformed into one or multiple bytebuffer by the chain of
On 9/6/11 3:55 PM, Julien Vermillard wrote:
Hi !
actually in MINA 1.0 2..0 there is something implemented with an
ugly hack : the future returned by session.write(..) and
IoHandler#messageSent(..);
The main problem is you usually write a pojo at the session level, and
it's transformed into
Hi guys,
today, while checking for some old code, I discovered that we already
have an implementation (done by Mark Webb 3 years ago) for a ByteBuffer
array. It mimics the ByteArray interface, but behind the curtain, we
have many ByteBuffers.
This is what we should use in the chain, IMHO.
Hi guys,
we are having a lot of discussion about the way to process chains, FSM
and other high level concerns.
This is *really* interesting.
Although, this is just part of the problem.
Julien has already coded a rough semi-working soltuion using a very
basic chain, with some HTTP protocol
1 - 100 of 393 matches
Mail list logo
