Re: Thanks and a question
That's how I can contribute to the Mina. Oh! Gotta love this mailing list! Keep up the wonderful work, Mian Team. 2007/8/14, Trustin Lee <[EMAIL PROTECTED]>: > > Hi Charles, > > On 8/7/07, Charles Woodson <[EMAIL PROTECTED]> wrote: > > Will do, Trustin. As for making this a part of the > > general distribution and submitting the patch through > > Jira, I assume that I should follow the guidelines in > > the developer guide and then attach the patch's source > > files for classes & unit tests to the jira issue. Am > > I missing anything there? > > Yes. Until your patch is ready, you could just create a JIRA issue so > that people find it's a known issue and work is in progress. :) > > Trustin > -- > what we call human nature is actually human habit > -- > http://gleamynode.net/ > -- > PGP Key ID: 0x0255ECA6 >
Implementation of isConnected()
Hi,
I am caching ConnectFuture in my client code and when during the call to
send bytes to the server,
I will test the connection by calling this isConnected() method:
/**
* @return true if we are connected to the remote peer, else false
*/
private final boolean isConnected()
{
IoSession session;
try
{
session = ( m_connectFuture != null ) ? m_connectFuture.getSession()
: null;
} catch( RuntimeIOException e )
{
return false;
}
return( m_connectFuture != null && m_connectFuture.isConnected() &&
session != null && session.isConnected() );
}
If it returns false, I will attempt a reconnection. It is working fine right
now. But I want to know if
there are other alternative solutions. Thanks all.
chihiro
--
View this message in context:
http://www.nabble.com/Implementation-of-isConnected%28%29-tf4637998s16868.html#a13246352
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.
Re: How to terminate all threads in SocketConnector ?
OK. I didn't do (1) & (3). It's working wonderfully now. Thanks. Trustin Lee wrote: > > 1) Please use SimpleByteBufferAllocator: > 2) Please make sure all socket connections were closed. > 3) Did you diable ThreadModel as described in: > -- View this message in context: http://www.nabble.com/How-to-terminate-all-threads-in-SocketConnector---tf4631786s16868.html#a13246222 Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.
Re: How to terminate all threads in SocketConnector ?
1) Please use SimpleByteBufferAllocator:
ByteBuffer.setAllocator(new SimpleByteBufferAllocator());
ByteBuffer.setUseDirectBuffer(false);
2) Please make sure all socket connections were closed.
3) Did you diable ThreadModel as described in:
http://mina.apache.org/configuring-thread-model.html
HTH,
Trustin
On 10/16/07, chihiro <[EMAIL PROTECTED]> wrote:
>
> I am using MINA 1.1.2 snapshot in an OSGi environment.
> OS: debian
> uname -r: 2.6.15-1-686-smp
> JVM version is 1.5.0_06-b05
>
> In a bundle that contains client code, the class Channel's lifecycle
> is in sync with the bundle lifecycle. That is, if I stop the bundle, then
> Channel's dispose() method is called.
>
> e.g.
>
> class Channel
> {
> ExecutorService m_executor;
> SocketConnector m_connector;
>
> public Channel( Executor executor, ... )
> {
> m_executor = executor;
> m_connector = new SocketConnector(
> Runtime.getRuntime().availableProcessors() + 1, executor );
> ... etc ...
> }
>
> public void dispose()
> {
> m_executor.shutdownNow();
> m_connector.setWorkerTimeout( 0 );
> }
> }
>
> But I have noticed that when I stopped the bundle, some SocketConnector
> related threads
> are still alive. Could someone verify that my dispose() method is sufficient
> ? Perhaps I'm missing something.
>
> Here are a snippet from a thread dump of the OSGi container (with the bundle
> stopped):-
>
> ==> This PooledByteBufferExpirer-0 never seems to die. But I think it's
> benign and would only
> die during container restart.
>
> Thread 8086: (state = BLOCKED)
> - java.lang.Thread.sleep(long) @bci=0 (Interpreted frame)
> - org.apache.mina.common.PooledByteBufferAllocator$Expirer.run() @bci=10,
> line=249 (Compiled frame)
>
> ==> This refers to SocketConnectorIoProcessor-3.0. It only dies if the
> server is shutdowned.
>
> Thread 13366: (state = IN_NATIVE)
> - sun.nio.ch.PollArrayWrapper.poll0(long, int, long) @bci=0 (Compiled
> frame; information may be imprecise)
> - sun.nio.ch.PollArrayWrapper.poll(int, int, long) @bci=13, line=100
> (Compiled frame)
> - sun.nio.ch.SelectorImpl.lockAndDoSelect(long) @bci=37, line=69 (Compiled
> frame)
> - sun.nio.ch.SelectorImpl.select(long) @bci=30, line=80 (Compiled frame)
> - org.apache.mina.util.NamePreservingRunnable.run() @bci=11, line=39
> (Interpreted frame)
> -
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(java.lang.Runnable)
> @bci=44, line=650 (Interpreted frame)
> - java.util.concurrent.ThreadPoolExecutor$Worker.run() @bci=28, line=675
> (Interpreted frame)
> - java.lang.Thread.run() @bci=11, line=595 (Interpreted frame)
>
>
> ==> This refers to AnonymousIoService-?. And I have tons of them hanging
> around.
>
> Thread 8091: (state = BLOCKED)
> - sun.misc.Unsafe.park(boolean, long) @bci=0 (Interpreted frame)
> - java.util.concurrent.locks.LockSupport.park() @bci=5, line=118
> (Interpreted frame)
> -
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await()
> @bci=41, line=1767 (Interpreted frame)
> - java.util.concurrent.LinkedBlockingQueue.take() @bci=29, line=359
> (Interpreted frame)
> - java.util.concurrent.ThreadPoolExecutor.getTask() @bci=47, line=470
> (Interpreted frame)
> - java.util.concurrent.ThreadPoolExecutor$Worker.run() @bci=18, line=674
> (Interpreted frame)
> - java.lang.Thread.run() @bci=11, line=595 (Interpreted frame)
>
> Thanks
>
> chihiro
> --
> View this message in context:
> http://www.nabble.com/How-to-terminate-all-threads-in-SocketConnector---tf4631786s16868.html#a13226239
> 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
Re: Thanks and a question
On 10/16/07, Drac <[EMAIL PROTECTED]> wrote:
>
> You don't need a new protocol class for this, just add a constructor overide
> to the TextLineCodecFactory class (or extend the class) to take custom
> encoder and decoder LineDelmiter strings like so:
>
> public TextLineCodecFactory(Charset charset, String encoderDelimStr, String
> decoderDelimStr) {
> encoder = new TextLineEncoder(charset, new
> LineDelimiter(encoderDelimStr));
> decoder = new TextLineDecoder(charset, new
> LineDelimiter(decoderDelimStr));
> }
>
> Then just construct your codec like so:
>
> TextLineCodecFactory codec = new TextLineCodecFactory(Charset.forName(
> "UTF-8"), "\0", "\0");
>
> I was a little surprised that the line delimiters were hard coded into the
> constructor to begin with, and that there was no way to access the
> decoder/encoder to change them. Wouldn't this be one of the most varied
> values from application to application? I'm not sure, I don't do much
> networking stuff so maybe the defaults are used by most systems and Flash is
> a bit of an oddball in that respect. I also guess it's easy enough to extend
> the class and work this in, but it had me scratching my head for half a day
> before I dug deep enough to find this.
Your concern already has been addressed in our development branch
(trunk); LineDelimiter.NUL and related constructors have been added.
HTH,
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: KeepAliveFilter
On 10/16/07, mat <[EMAIL PROTECTED]> wrote: > I just wonder if Mina 2.0 will adopt any KeepAliveFilter(heartbeat)? Sure we will. We will start to work on it based on Eero's donation. HTH, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
[jira] Commented: (DIRMINA-456) Provide mechanism for flushing writeBuffer from IoHandler.messageReceived
[ https://issues.apache.org/jira/browse/DIRMINA-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535387 ] Heath Borders commented on DIRMINA-456: --- Might that have occurred if he was running his filters in the same thread as his IoProcessor? > Provide mechanism for flushing writeBuffer from IoHandler.messageReceived > - > > Key: DIRMINA-456 > URL: https://issues.apache.org/jira/browse/DIRMINA-456 > Project: MINA > Issue Type: Improvement > Components: Core >Affects Versions: 2.0.0-M1 >Reporter: Mike Heath > Fix For: 2.0.0-M1 > > > As described in this thread http://tinyurl.com/3cwkb3, we need to provide > support for flushing the session's write queue from the > IoHandler.messageRecieved() method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ByteBuffer getString() confused after CharacterCodingException
Hi, Trustin:
Yep - I just installed mina 1.1.2, and ByteBuffer now passes the test.
Thanks again for the swift help.
Yigal
Yigal Rachman wrote:
Hi, Trustin:
I ran your test case on my system and had the following error (which is
actually different from what I am seeing!)
Exception in thread "main" java.lang.AssertionError:
expected:<12> but was:<3>
at org.junit.Assert.fail(Assert.java:71)
at org.junit.Assert.failNotEquals(Assert.java:451)
at org.junit.Assert.assertEquals(Assert.java:99)
at org.junit.Assert.assertEquals(Assert.java:116)
at
ca.uvic.dmas.domain.daf.driver.codec.textline.TextLineCodecHarness.main(TextLineCodecHarness.java:26)
The assertion on buffer.limit() failed.
I am running mina 1.0.1 - maybe it is time to upgrade, eh?
Thank you for your help,
Yigal
Trustin Lee wrote:
On 10/16/07, Yigal Rachman <[EMAIL PROTECTED]> wrote:
Hi, Folks:
When ByteBuffer.getString() breaks midway because of a
CharacterCodingException, it fails to restore the position and limit;
thus getString() is destructive when this happens. One can, of course,
work around this, but it should not be necessary.
Could you please specify some example code that reproduces the
problem? We already have a test case for the same case, and it seems
to work fine:
public void testGetStringWithFailure() throws Exception {
String test = "\u30b3\u30e1\u30f3\u30c8\u7de8\u96c6";
ByteBuffer buffer = ByteBuffer.wrap(test.getBytes("Shift_JIS"));
// Make sure the limit doesn't change when an exception arose.
int oldLimit = buffer.limit();
int oldPos = buffer.position();
try {
buffer.getString(3, Charset.forName("ASCII").newDecoder());
Assert.fail();
} catch (Exception e) {
Assert.assertEquals(oldLimit, buffer.limit());
Assert.assertEquals(oldPos, buffer.position());
}
try {
buffer.getString(Charset.forName("ASCII").newDecoder());
Assert.fail();
} catch (Exception e) {
Assert.assertEquals(oldLimit, buffer.limit());
Assert.assertEquals(oldPos, buffer.position());
}
}
HTH,
Trustin
Re: ByteBuffer getString() confused after CharacterCodingException
Hi, Trustin:
I ran your test case on my system and had the following error (which is
actually different from what I am seeing!)
Exception in thread "main" java.lang.AssertionError:
expected:<12> but was:<3>
at org.junit.Assert.fail(Assert.java:71)
at org.junit.Assert.failNotEquals(Assert.java:451)
at org.junit.Assert.assertEquals(Assert.java:99)
at org.junit.Assert.assertEquals(Assert.java:116)
at
ca.uvic.dmas.domain.daf.driver.codec.textline.TextLineCodecHarness.main(TextLineCodecHarness.java:26)
The assertion on buffer.limit() failed.
I am running mina 1.0.1 - maybe it is time to upgrade, eh?
Thank you for your help,
Yigal
Trustin Lee wrote:
On 10/16/07, Yigal Rachman <[EMAIL PROTECTED]> wrote:
Hi, Folks:
When ByteBuffer.getString() breaks midway because of a
CharacterCodingException, it fails to restore the position and limit;
thus getString() is destructive when this happens. One can, of course,
work around this, but it should not be necessary.
Could you please specify some example code that reproduces the
problem? We already have a test case for the same case, and it seems
to work fine:
public void testGetStringWithFailure() throws Exception {
String test = "\u30b3\u30e1\u30f3\u30c8\u7de8\u96c6";
ByteBuffer buffer = ByteBuffer.wrap(test.getBytes("Shift_JIS"));
// Make sure the limit doesn't change when an exception arose.
int oldLimit = buffer.limit();
int oldPos = buffer.position();
try {
buffer.getString(3, Charset.forName("ASCII").newDecoder());
Assert.fail();
} catch (Exception e) {
Assert.assertEquals(oldLimit, buffer.limit());
Assert.assertEquals(oldPos, buffer.position());
}
try {
buffer.getString(Charset.forName("ASCII").newDecoder());
Assert.fail();
} catch (Exception e) {
Assert.assertEquals(oldLimit, buffer.limit());
Assert.assertEquals(oldPos, buffer.position());
}
}
HTH,
Trustin
Re: How to pronounce mina?
What else can we pronounce besides "mn"? ^^ just kidding. On 10/16/07, Mark <[EMAIL PROTECTED]> wrote: > > phonetically, I pronounce it "meena" > > > On 10/16/07, tiandike <[EMAIL PROTECTED]> wrote: > > > > > > How to pronounce mina? > > -- > > View this message in context: > > > http://www.nabble.com/How-to-pronounce-mina--tf4634201s16868.html#a13233575 > > Sent from the Apache MINA Support Forum mailing list archive at > Nabble.com > > . > > > > > > > -- > > The adjuration to be "normal" seems shockingly repellent to me; I see > neither hope nor comfort in sinking to that low level. I think it is > ignorance that makes people think of abnormality only with horror and > allows > them to remain undismayed at the proximity of "normal" to average and > mediocre. For surely anyone who achieves anything is, essentially, > abnormal. > Dr. Karl Menninger >
Re: ByteBuffer getString() confused after CharacterCodingException
Hi, Trustin:
The call I am using is buf.getString( decoder ). The limit does not
change, but the position does; it remains at the "broken" byte. I
thought it would simply read the buffer between position() and limit()
without changing anything - did I misunderstand this?
Yigal
Trustin Lee wrote:
On 10/16/07, Yigal Rachman <[EMAIL PROTECTED]> wrote:
Hi, Folks:
When ByteBuffer.getString() breaks midway because of a
CharacterCodingException, it fails to restore the position and limit;
thus getString() is destructive when this happens. One can, of course,
work around this, but it should not be necessary.
Could you please specify some example code that reproduces the
problem? We already have a test case for the same case, and it seems
to work fine:
public void testGetStringWithFailure() throws Exception {
String test = "\u30b3\u30e1\u30f3\u30c8\u7de8\u96c6";
ByteBuffer buffer = ByteBuffer.wrap(test.getBytes("Shift_JIS"));
// Make sure the limit doesn't change when an exception arose.
int oldLimit = buffer.limit();
int oldPos = buffer.position();
try {
buffer.getString(3, Charset.forName("ASCII").newDecoder());
Assert.fail();
} catch (Exception e) {
Assert.assertEquals(oldLimit, buffer.limit());
Assert.assertEquals(oldPos, buffer.position());
}
try {
buffer.getString(Charset.forName("ASCII").newDecoder());
Assert.fail();
} catch (Exception e) {
Assert.assertEquals(oldLimit, buffer.limit());
Assert.assertEquals(oldPos, buffer.position());
}
}
HTH,
Trustin
Re: MINA 1.0.3 Compatibility
http://mina.apache.org/faq.html#FAQ-Whatisrequiredtobuild%2FrunMINA%3F On 10/16/07, Nicolas Enjolras <[EMAIL PROTECTED]> wrote: > Hi, > > I've shearched a lot on internet but I don't find any response to my > question. > > Is MINA 1.0.3 compatible with a 1.4.1 JRE ? > > If the 1.0.3 is compatible what is the last version of MINA compatible > with JRE 1.4.1 > > Thanks, > > Nicolas. > > -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
MINA 1.0.3 Compatibility
Hi, I've shearched a lot on internet but I don't find any response to my question. Is MINA 1.0.3 compatible with a 1.4.1 JRE ? If the 1.0.3 is compatible what is the last version of MINA compatible with JRE 1.4.1 Thanks, Nicolas.
Re: How to pronounce mina?
phonetically, I pronounce it "meena" On 10/16/07, tiandike <[EMAIL PROTECTED]> wrote: > > > How to pronounce mina? > -- > View this message in context: > http://www.nabble.com/How-to-pronounce-mina--tf4634201s16868.html#a13233575 > Sent from the Apache MINA Support Forum mailing list archive at Nabble.com > . > > -- The adjuration to be "normal" seems shockingly repellent to me; I see neither hope nor comfort in sinking to that low level. I think it is ignorance that makes people think of abnormality only with horror and allows them to remain undismayed at the proximity of "normal" to average and mediocre. For surely anyone who achieves anything is, essentially, abnormal. Dr. Karl Menninger
How to pronounce mina?
How to pronounce mina? -- View this message in context: http://www.nabble.com/How-to-pronounce-mina--tf4634201s16868.html#a13233575 Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.
[jira] Commented: (DIRMINA-455) Add XBean tag to sources to enable XBean based configuration
[ https://issues.apache.org/jira/browse/DIRMINA-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535207 ] Trustin Lee commented on DIRMINA-455: - I like the main idea, but I'd like to know more detail. It seems like the XBean web site doesn't provide any intuitive information on how exactly it is integrated with other IoC frameworks. I also don't have much idea on what classes should I add the XBean tag. Should I add the tag to all public classes? What about public abstract classes? What about interfaces? I also found that the XBean tags are used to generate XML schema files automatically. Isn't it just for automatic generation? If there's a tool for generating the schema files, it should be able to be done without adding tags, probably some wildcard filters in the generator settings. That is, what should be changed is not MINA but the generator tool. Moreover, adding XBean tag to every new class is pain and error prone, so I want to avoid adding any extra tags to MINA code for a certain framework, unless it is de facto standard. If there's no further explanation of accountability of adding the XBean tags nor objection within this week, I will remove the tags currently checked in. > Add XBean tag to sources to enable XBean based configuration > > > Key: DIRMINA-455 > URL: https://issues.apache.org/jira/browse/DIRMINA-455 > Project: MINA > Issue Type: Improvement > Components: Core, Filter >Reporter: Alex Karasulu >Assignee: Alex Karasulu > Fix For: 1.1.4, 1.0.7 > > > The following tag when added to the javadocs enables XBean based > configuration of the MINA components with absolutely no effect on the > operation of MINA: > * @org.apache.xbean.XBean > Adding this will enable MINA users that use the Spring integration classes to > optionally make their spring application configurations much more succinct. > For more information please see http://geronimo.apache.org/xbean/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Import KeepAlive functionality contribution under MINA PMC
Should your ActiveKeepAliveFilter, assiveKeepAliveFilter both extend IoFilterAdapter like in the tutorial "Writing IoFilter"? And you can return IoFilter in Factory method? On 10/16/07, mat <[EMAIL PROTECTED]> wrote: > > Several questions on your KeepAliveFilter. > > 1) Why createActiveKeepAliveFilter, createPassiveKeepAliveFilter NOT > return IoFilter(A factory method is better to return the interface instead > of concrete class)? And my server or client has to extends ChainedIoHandler, > otherwises, i can't use " config.getFilterChain().addFirst" in my original > code. > 2) A Client must use the createPassiveKeepAliveFilter? > > > On 10/16/07, mat <[EMAIL PROTECTED]> wrote: > > > > +1 very important (Definitely a MUST filter) > > > > On 9/27/07, Mark <[EMAIL PROTECTED]> wrote: > > > > > > [X]: +1, import > > > > > > On 9/26/07, Michael Grundvig < [EMAIL PROTECTED] > wrote: > > > > > > > > +1, import > > > > > > > > - Original Message - > > > > From: "Trustin Lee" < [EMAIL PROTECTED]> > > > > To: < dev@mina.apache.org> > > > > Sent: Wednesday, September 26, 2007 5:24 PM > > > > Subject: [VOTE] Import KeepAlive functionality contribution under > > > MINA PMC > > > > > > > > > > > > > Hi again. > > > > > > > > > > There's an important contribution from Eero Nevalainen that will > > > help > > > > > users to implement sending a protocol-specific keep-alive message > > > > > periodically: > > > > > > > > > > https://issues.apache.org/jira/browse/DIRMINA-354 > > > > > > > > > > It's just a few classes, so I thought we could just import the > > > code, > > > > > but procedure is procedure. :) > > > > > > > > > > Software grant has been received long time ago, and also again, it > > > was > > > > > not processed on time due to my laziness. There's no reason not > > > to > > > > > import these classes IMO; it's just a few classes that makes > > > people's > > > > > life a lot easier. > > > > > > > > > > Once vote passes, I will start the paperwork and all the required > > > > > procedure. > > > > > > > > > > [ ]: +1, import > > > > > [ ] 0, abstain > > > > > [ ]: -1, don't import > > > > > > > > > > Cheers, > > > > > Trustin > > > > > -- > > > > > what we call human nature is actually human habit > > > > > -- > > > > > http://gleamynode.net/ > > > > > -- > > > > > PGP Key ID: 0x0255ECA6 > > > > > > > > > > > > > > > > > -- > > > ..Cheers > > > Mark > > > > > > > >
[jira] Resolved: (DIRMINA-452) IdentittyHashMap Iterator has bug in it.
[
https://issues.apache.org/jira/browse/DIRMINA-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Trustin Lee resolved DIRMINA-452.
-
Resolution: Fixed
Assignee: Trustin Lee
I replaced IdentityHashMap and IdentityHashSet with HashMap and HashSet
respectively where its iterator's remove() method is called. Fortunately, Only
idle status checker classes were affected by this issue. Please confirm the
fix and close this issue.
> IdentittyHashMap Iterator has bug in it.
>
>
> Key: DIRMINA-452
> URL: https://issues.apache.org/jira/browse/DIRMINA-452
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.1.0, 1.0.4, 1.1.1, 1.0.5,
> 1.1.2
> Environment: Java, all 1.5 and 1.6 versions at least.
>Reporter: Rupert Smith
>Assignee: Trustin Lee
> Fix For: 1.1.4, 1.0.7
>
>
> There is a bug in IdentityHashMap Iterator which causes an infinite loop.
> This can manifest itself anywhere that the iterator.remove() method is
> called, in conjunction with the put() method. In particular this has been
> observed in the VmPipeIdleStatus checker.
> Certain sequences of puts/iterator.removes cause the map to allow put() to be
> called with a full table. The code then loops round the table forever looking
> for a free slot to add the new entry to.
> A bug report has been submitted to Sun for this problem.
> Suggested work arounds:
> Use HashMap instead of IdentityHashMap.
> Do not use the remove() method on the iterator, find all elements to remove
> in one step, then remove in another.
> Here is some sample test code that exhibits the bug in isolation. Call it
> repeatedly with n=1000, until it locks up:
> public void testRandomPutRemove(final int n)
> {
> final Map idMap = new
> IdentityHashMap();
> final Random r = new Random();
> final float removeProbability = r.nextFloat();
> final float addProbability = r.nextFloat();
> final Queue opSequence = new LinkedList();
> Runnable tester =
> new Runnable()
> {
> public void run()
> {
> for (int i = 0; i < n; i++)
> {
> if (r.nextFloat() < addProbability)
> {
> synchronized (idMap)
> {
> TestElement e = new TestElement();
> idMap.put(e, e);
> opSequence.offer("put");
> }
> }
> else
> {
> synchronized (idMap)
> {
> Iterator it = idMap.keySet().iterator();
> for (int j = 0; it.hasNext(); j++)
> {
> it.next();
> if (r.nextFloat() < removeProbability)
> {
> it.remove();
> opSequence.offer("remove " + j);
> }
> }
> }
> }
> }
> }
> };
> Thread testThread = new Thread(tester);
> testThread.start();
> try
> {
> testThread.join(5000);
> }
> catch (InterruptedException e)
> {
> fail("Test interrupted.");
> }
> if (testThread.getState() == Thread.State.RUNNABLE)
> {
> System.out.println("opSequence = " + opSequence);
> System.out.println("removeProbability = " + removeProbability);
> System.out.println("addProbability = " + addProbability);
> // Wait forever here, to give an opportunity to take thread/heap
> dumps etc.
> try
> {
> testThread.join();
> }
> catch (InterruptedException e)
> {
> // Ignore.
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DIRMINA-454) Trivial denial of service in TextLineDecoder
[ https://issues.apache.org/jira/browse/DIRMINA-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trustin Lee resolved DIRMINA-454. - Resolution: Fixed Thank you very much for the patch and the inspiration. The bug has been fixed. I made sure OOM is not thrown anymore and decoder continues to decode even after too long text line. Please confirm if the bug has been fixed and close this issue. One difference from no-dos.patch is that OOM is not thrown immediately. It keeps discarding incoming data when client sends too long line, and throws an OOM error when EOL (line delimiter) is encountered. It was necessary behavior to make the decoder continue to work even after encountering broken data. ProtocolCodecFilter also has been improved to continue decoding after an exception is thrown. Please refer to the svn commit log for the detailed information. All these changes shouldn't affect existing applications. > Trivial denial of service in TextLineDecoder > > > Key: DIRMINA-454 > URL: https://issues.apache.org/jira/browse/DIRMINA-454 > Project: MINA > Issue Type: Bug > Components: Filter >Affects Versions: 1.0.6, 1.1.3 >Reporter: Owen Jacobson >Assignee: Trustin Lee > Fix For: 1.1.4, 1.0.7 > > Attachments: no-dos.patch > > > In both of TextLineDecoder's decoding methods, the decoder only checks the > size of input after it's found at least one line ending character. > Infinitely long streams of, say, 'y's will cause the decoder to try to buffer > up data until the JVM falls over. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Import KeepAlive functionality contribution under MINA PMC
Several questions on your KeepAliveFilter. 1) Why createActiveKeepAliveFilter, createPassiveKeepAliveFilter NOT return IoFilter(A factory method is better to return the interface instead of concrete class)? And my server or client has to extends ChainedIoHandler, otherwises, i can't use "config.getFilterChain().addFirst" in my original code. 2) A Client must use the createPassiveKeepAliveFilter? On 10/16/07, mat <[EMAIL PROTECTED]> wrote: > > +1 very important (Definitely a MUST filter) > > On 9/27/07, Mark <[EMAIL PROTECTED]> wrote: > > > > [X]: +1, import > > > > On 9/26/07, Michael Grundvig <[EMAIL PROTECTED] > wrote: > > > > > > +1, import > > > > > > - Original Message - > > > From: "Trustin Lee" <[EMAIL PROTECTED]> > > > To: < dev@mina.apache.org> > > > Sent: Wednesday, September 26, 2007 5:24 PM > > > Subject: [VOTE] Import KeepAlive functionality contribution under MINA > > PMC > > > > > > > > > > Hi again. > > > > > > > > There's an important contribution from Eero Nevalainen that will > > help > > > > users to implement sending a protocol-specific keep-alive message > > > > periodically: > > > > > > > > https://issues.apache.org/jira/browse/DIRMINA-354 > > > > > > > > It's just a few classes, so I thought we could just import the code, > > > > but procedure is procedure. :) > > > > > > > > Software grant has been received long time ago, and also again, it > > was > > > > not processed on time due to my laziness. There's no reason not to > > > > import these classes IMO; it's just a few classes that makes > > people's > > > > life a lot easier. > > > > > > > > Once vote passes, I will start the paperwork and all the required > > > > procedure. > > > > > > > > [ ]: +1, import > > > > [ ] 0, abstain > > > > [ ]: -1, don't import > > > > > > > > Cheers, > > > > Trustin > > > > -- > > > > what we call human nature is actually human habit > > > > -- > > > > http://gleamynode.net/ > > > > -- > > > > PGP Key ID: 0x0255ECA6 > > > > > > > > > > > > -- > > ..Cheers > > Mark > > > >
Re: Getting the MINA Chills
Rodrigo Madera wrote: So, Is mina-sm mature enough for a release? Is it going to make it soon enough? We've been using mina-sm in our spam-filtering IMAP proxy (www.spamdrain.net) for the last 6 months and we haven't had any issues with so far. In fact, I'm going to move it into MINA trunk some time this week. Even if it seems to be stable enough for production use there are certainly room for design improvements. I'd love to hear your and everyone else opinion on the design. /Niklas
Re: [VOTE] Import KeepAlive functionality contribution under MINA PMC
+1 very important (Definitely a MUST filter) On 9/27/07, Mark <[EMAIL PROTECTED]> wrote: > > [X]: +1, import > > On 9/26/07, Michael Grundvig <[EMAIL PROTECTED]> wrote: > > > > +1, import > > > > - Original Message - > > From: "Trustin Lee" <[EMAIL PROTECTED]> > > To: > > Sent: Wednesday, September 26, 2007 5:24 PM > > Subject: [VOTE] Import KeepAlive functionality contribution under MINA > PMC > > > > > > > Hi again. > > > > > > There's an important contribution from Eero Nevalainen that will help > > > users to implement sending a protocol-specific keep-alive message > > > periodically: > > > > > > https://issues.apache.org/jira/browse/DIRMINA-354 > > > > > > It's just a few classes, so I thought we could just import the code, > > > but procedure is procedure. :) > > > > > > Software grant has been received long time ago, and also again, it was > > > not processed on time due to my laziness. There's no reason not to > > > import these classes IMO; it's just a few classes that makes people's > > > life a lot easier. > > > > > > Once vote passes, I will start the paperwork and all the required > > > procedure. > > > > > > [ ]: +1, import > > > [ ] 0, abstain > > > [ ]: -1, don't import > > > > > > Cheers, > > > Trustin > > > -- > > > what we call human nature is actually human habit > > > -- > > > http://gleamynode.net/ > > > -- > > > PGP Key ID: 0x0255ECA6 > > > > > > > -- > ..Cheers > Mark >
KeepAliveFilter
I just wonder if Mina 2.0 will adopt any KeepAliveFilter(heartbeat)?
