Re: [jira] Commented: (FTPSERVER-287) NLST: Implementation only supports listing files in working directory [patch provided]
On Tue, Jun 2, 2009 at 3:31 AM, Sai Pullabhotla sai.pullabho...@jmethods.com wrote: I would like to say that the results you have indicated only come from FTP servers that actually run the UNIX's ls command when a NLST command is received. Other servers probably adhere to the RFC by just returning names. One addition to this list, FileZilla works as described by Dennis. /niklas
[jira] Issue Comment Edited: (DIRMINA-714) Packet sequence is unordered in multi thread.
[
https://issues.apache.org/jira/browse/DIRMINA-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12715410#action_12715410
]
ncanis2 edited comment on DIRMINA-714 at 6/2/09 1:12 AM:
-
Thank you for your reply. But I have still something bug.
===
After I read your reply, received the newest source from svn(mina).
But, I still had problem in heavy load server. ( about 500 clients )
This is server log
[16:51]-S[DemuxRomiDecoder(decodeBody:162)]:Trace Log =MSG Recv seq=140,
protocol=14
[16:51]-S[DemuxRomiDecoder(decodeBody:162)]:Trace Log =MSG Recv seq=141,
protocol=13
[16:51]-S[DemuxRomiDecoder(decodeBody:162)]:Trace Log =MSG Recv seq=142,
protocol=14
[16:51]-S[DemuxRomiDecoder(decodeBody:162)]:Trace Log =MSG Recv seq=144,
protocol=19
This is client log
[2009-06-02 16:51] ERROR [GameEventFilter(close:108)] :Trace Log =Really MSG
Sent= protocol=13, seq=141
[2009-06-02 16:51] ERROR [GameEventFilter(close:108)] :Trace Log =Really MSG
Sent= protocol=14, seq=142
[2009-06-02 16:51] ERROR [GameEventFilter(close:108)] :Trace Log =Really MSG
Sent= protocol=19, seq=144
[2009-06-02 16:51] ERROR [GameEventFilter(close:108)] :Trace Log =Really MSG
Sent= protocol=14, seq=143
in Server.
If I send 141,142,143,144,I receive 141,142,144,143 in messageSent method.
So client can't receive right packet from server.
=
This is my encoder source..
- MessageEncoder
@Override
public void encode(IoSession session, Object message,
ProtocolEncoderOutput out)
throws Exception {
RomiMessage msg = (RomiMessage) message;
IoBuffer buf_in = msg.getBuf();
IoBuffer buf_out = IoBuffer.allocate(buf_in.limit()+4).sweep();
buf_out.setAutoExpand(true); // Enable auto-expand for easier
encoding
encodeBody(session,msg, buf_out);
buf_out.flip();
out.write(buf_out);
msg = null;
}
=
This is my decoder source..
- MessageDecoder
@Override
public MessageDecoderResult decodable(IoSession session, IoBuffer in) {
if (in.prefixedDataAvailable(HEADER_SIZE, MAX_LENGTH)) {
return MessageDecoderResult.OK;
} else {
return MessageDecoderResult.NEED_DATA;
}
// Return NOT_OK if not matches.
// return MessageDecoderResult.NOT_OK;
}
@Override
public MessageDecoderResult decode(IoSession session, IoBuffer in,
ProtocolDecoderOutput out) throws Exception {
MessageDecoderResult result = decodable(session,in);
if(result!=MessageDecoderResult.OK) return result;
IoBuffer buf = decodeBody(session, in);
if (buf == null) {
return MessageDecoderResult.NOT_OK;
} else {
out.write(buf);
}
return MessageDecoderResult.OK;
}
was (Author: ncanis2):
Thank you for your reply. But I have still something bug.
===
After I read this, received newest source from svn(mina).
But, I had problem in heavy load server.
This is server log
[16:51]-S[DemuxRomiDecoder(decodeBody:162)]:Trace Log =MSG Recv seq=140,
protocol=14
[16:51]-S[DemuxRomiDecoder(decodeBody:162)]:Trace Log =MSG Recv seq=141,
protocol=13
[16:51]-S[DemuxRomiDecoder(decodeBody:162)]:Trace Log =MSG Recv seq=142,
protocol=14
[16:51]-S[DemuxRomiDecoder(decodeBody:162)]:Trace Log =MSG Recv seq=144,
protocol=19
This is client log
[2009-06-02 16:51] ERROR [GameEventFilter(close:108)] :Trace Log =Really MSG
Sent= protocol=13, seq=141
[2009-06-02 16:51] ERROR [GameEventFilter(close:108)] :Trace Log =Really MSG
Sent= protocol=14, seq=142
[2009-06-02 16:51] ERROR [GameEventFilter(close:108)] :Trace Log =Really MSG
Sent= protocol=19, seq=144
[2009-06-02 16:51] ERROR [GameEventFilter(close:108)] :Trace Log =Really MSG
Sent= protocol=14, seq=143
in Server.
If I send 141,142,143,144,I receive 141,142,144,143 in messageSent method.
So client can't receive right packet from server.
=
This is my encoder source..
- MessageEncoder
@Override
public void encode(IoSession session, Object message,
ProtocolEncoderOutput out)
throws Exception {
RomiMessage msg = (RomiMessage) message;
IoBuffer buf_in = msg.getBuf();
IoBuffer buf_out =
[jira] Commented: (DIRMINA-714) Packet sequence is unordered in multi thread.
[ https://issues.apache.org/jira/browse/DIRMINA-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12715417#action_12715417 ] Emmanuel Lecharny commented on DIRMINA-714: --- what about moving the executor before the codec ? Packet sequence is unordered in multi thread. - Key: DIRMINA-714 URL: https://issues.apache.org/jira/browse/DIRMINA-714 Project: MINA Issue Type: Bug Components: Filter Affects Versions: 2.0.0-M5 Environment: xp Reporter: ncanis2 Fix For: 2.0.0-M6 Hi. Packet sequence is unordered. = Server Client = chain.addLast(codec, new ProtocolCodecFilter(rcf)); chain.addLast(executor, getExecuteFilter());= OrderedThreadPoolExecutor c = new OrderedThreadPoolExecutor(20,100); If server send 1,2,3,4,5,6 , client receive 1,2,3,4,6 from server. Clients : 100. where I am wrong? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-716) Get rid of finalize method in AbstractIoFilterChain.java
[ https://issues.apache.org/jira/browse/DIRMINA-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12715419#action_12715419 ] Emmanuel Lecharny commented on DIRMINA-716: --- The key is that this finalizer is used to remove the chain's element from the chain, when the session is closed. However, the session closure generates an event which is propagated though the chain. We have to clear the chain when the sessionClosed event has been processed, and not in the finlize() method. Alos this is something I question : why should we copy the chain for every new session, as if the chain could change ? I mean, if we can change the chain dynamically (which is good) for a specific session, I guess that the best would be to copy the chain when this modification occurs, not when the session is created, no ? Get rid of finalize method in AbstractIoFilterChain.java -- Key: DIRMINA-716 URL: https://issues.apache.org/jira/browse/DIRMINA-716 Project: MINA Issue Type: Bug Components: Core Affects Versions: 2.0.0-M5 Reporter: Yongxing Wang Assignee: Emmanuel Lecharny The finalize method in AbstractIoFilterChain.java can possibly cause OOM error when the system is under very heavy load. The negative impact of finalize method can be found at: http://www.fasterj.com/articles/finalizer1.shtml AbstractIoFilterChain holds a reference to Session object which can hold a list of unwritten data. The deterministic run of Finalizer can very well cause memory not fred up on time under heavy load. And it can certainly cause very bad memory usage pattern and contribute to the overall heavy system load. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-714) Packet sequence is unordered in multi thread.
[ https://issues.apache.org/jira/browse/DIRMINA-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12715420#action_12715420 ] ncanis2 commented on DIRMINA-714: - I tested it, but I have still problem .. What should I do? Server sent still strange sequence. example 1,3,2 Packet sequence is unordered in multi thread. - Key: DIRMINA-714 URL: https://issues.apache.org/jira/browse/DIRMINA-714 Project: MINA Issue Type: Bug Components: Filter Affects Versions: 2.0.0-M5 Environment: xp Reporter: ncanis2 Fix For: 2.0.0-M6 Hi. Packet sequence is unordered. = Server Client = chain.addLast(codec, new ProtocolCodecFilter(rcf)); chain.addLast(executor, getExecuteFilter());= OrderedThreadPoolExecutor c = new OrderedThreadPoolExecutor(20,100); If server send 1,2,3,4,5,6 , client receive 1,2,3,4,6 from server. Clients : 100. where I am wrong? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-714) Packet sequence is unordered in multi thread.
[ https://issues.apache.org/jira/browse/DIRMINA-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12715423#action_12715423 ] ncanis2 commented on DIRMINA-714: - Can I solve this bug using another version? (ex 2.0rc1 ~ rc5) Packet sequence is unordered in multi thread. - Key: DIRMINA-714 URL: https://issues.apache.org/jira/browse/DIRMINA-714 Project: MINA Issue Type: Bug Components: Filter Affects Versions: 2.0.0-M5 Environment: xp Reporter: ncanis2 Fix For: 2.0.0-M6 Hi. Packet sequence is unordered. = Server Client = chain.addLast(codec, new ProtocolCodecFilter(rcf)); chain.addLast(executor, getExecuteFilter());= OrderedThreadPoolExecutor c = new OrderedThreadPoolExecutor(20,100); If server send 1,2,3,4,5,6 , client receive 1,2,3,4,6 from server. Clients : 100. where I am wrong? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (DIRMINA-714) Packet sequence is unordered in multi thread.
[ https://issues.apache.org/jira/browse/DIRMINA-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12715423#action_12715423 ] ncanis2 edited comment on DIRMINA-714 at 6/2/09 1:45 AM: - Can I solve this bug using another version? (ex 2.0m1 ~ rm5) was (Author: ncanis2): Can I solve this bug using another version? (ex 2.0rc1 ~ rc5) Packet sequence is unordered in multi thread. - Key: DIRMINA-714 URL: https://issues.apache.org/jira/browse/DIRMINA-714 Project: MINA Issue Type: Bug Components: Filter Affects Versions: 2.0.0-M5 Environment: xp Reporter: ncanis2 Fix For: 2.0.0-M6 Hi. Packet sequence is unordered. = Server Client = chain.addLast(codec, new ProtocolCodecFilter(rcf)); chain.addLast(executor, getExecuteFilter());= OrderedThreadPoolExecutor c = new OrderedThreadPoolExecutor(20,100); If server send 1,2,3,4,5,6 , client receive 1,2,3,4,6 from server. Clients : 100. where I am wrong? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (DIRMINA-714) Packet sequence is unordered in multi thread.
[ https://issues.apache.org/jira/browse/DIRMINA-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12715423#action_12715423 ] ncanis2 edited comment on DIRMINA-714 at 6/2/09 1:45 AM: - Can I solve this bug using another version? (ex 2.0m1 ~ m5) was (Author: ncanis2): Can I solve this bug using another version? (ex 2.0m1 ~ rm5) Packet sequence is unordered in multi thread. - Key: DIRMINA-714 URL: https://issues.apache.org/jira/browse/DIRMINA-714 Project: MINA Issue Type: Bug Components: Filter Affects Versions: 2.0.0-M5 Environment: xp Reporter: ncanis2 Fix For: 2.0.0-M6 Hi. Packet sequence is unordered. = Server Client = chain.addLast(codec, new ProtocolCodecFilter(rcf)); chain.addLast(executor, getExecuteFilter());= OrderedThreadPoolExecutor c = new OrderedThreadPoolExecutor(20,100); If server send 1,2,3,4,5,6 , client receive 1,2,3,4,6 from server. Clients : 100. where I am wrong? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-716) Get rid of finalize method in AbstractIoFilterChain.java
[ https://issues.apache.org/jira/browse/DIRMINA-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12715432#action_12715432 ] Edouard De Oliveira commented on DIRMINA-716: - The finalize() catch is a good one i tried to see it for myself and i confirm the poor memory management it causes (you can look at http://tedorgwp.free.fr/?p=450 which contains graphs of the generated heap load). I do also fully agree with the copy on change method as i think it only happens in specific implementations. Other implementations will gain some additionnal free memory from this tweak. Get rid of finalize method in AbstractIoFilterChain.java -- Key: DIRMINA-716 URL: https://issues.apache.org/jira/browse/DIRMINA-716 Project: MINA Issue Type: Bug Components: Core Affects Versions: 2.0.0-M5 Reporter: Yongxing Wang Assignee: Emmanuel Lecharny The finalize method in AbstractIoFilterChain.java can possibly cause OOM error when the system is under very heavy load. The negative impact of finalize method can be found at: http://www.fasterj.com/articles/finalizer1.shtml AbstractIoFilterChain holds a reference to Session object which can hold a list of unwritten data. The deterministic run of Finalizer can very well cause memory not fred up on time under heavy load. And it can certainly cause very bad memory usage pattern and contribute to the overall heavy system load. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-714) Packet sequence is unordered in multi thread.
[ https://issues.apache.org/jira/browse/DIRMINA-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12715472#action_12715472 ] ncanis2 commented on DIRMINA-714: - Yes. I have tested the lastest version. I've still this bug.. Packet sequence is unordered in multi thread. - Key: DIRMINA-714 URL: https://issues.apache.org/jira/browse/DIRMINA-714 Project: MINA Issue Type: Bug Components: Filter Affects Versions: 2.0.0-M5 Environment: xp Reporter: ncanis2 Fix For: 2.0.0-M6 Hi. Packet sequence is unordered. = Server Client = chain.addLast(codec, new ProtocolCodecFilter(rcf)); chain.addLast(executor, getExecuteFilter());= OrderedThreadPoolExecutor c = new OrderedThreadPoolExecutor(20,100); If server send 1,2,3,4,5,6 , client receive 1,2,3,4,6 from server. Clients : 100. where I am wrong? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-714) Packet sequence is unordered in multi thread.
[ https://issues.apache.org/jira/browse/DIRMINA-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien Vermillard updated DIRMINA-714: -- Fix Version/s: (was: 2.0.0-M6) 2.0.0-M7 Packet sequence is unordered in multi thread. - Key: DIRMINA-714 URL: https://issues.apache.org/jira/browse/DIRMINA-714 Project: MINA Issue Type: Bug Components: Filter Affects Versions: 2.0.0-M5 Environment: xp Reporter: ncanis2 Fix For: 2.0.0-M7 Hi. Packet sequence is unordered. = Server Client = chain.addLast(codec, new ProtocolCodecFilter(rcf)); chain.addLast(executor, getExecuteFilter());= OrderedThreadPoolExecutor c = new OrderedThreadPoolExecutor(20,100); If server send 1,2,3,4,5,6 , client receive 1,2,3,4,6 from server. Clients : 100. where I am wrong? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-714) Packet sequence is unordered in multi thread.
[ https://issues.apache.org/jira/browse/DIRMINA-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12715507#action_12715507 ] Emmanuel Lecharny commented on DIRMINA-714: --- I would be very interested in debugging a scenario which exhibit this kind of behavior. So far, the only code I have is taken from https://issues.apache.org/jira/browse/DIRMINA-687 and https://issues.apache.org/jira/browse/DIRMINA-675, both fixed. Could you define a minimal sample, with a client and a server, to demonstrate the problem ? Packet sequence is unordered in multi thread. - Key: DIRMINA-714 URL: https://issues.apache.org/jira/browse/DIRMINA-714 Project: MINA Issue Type: Bug Components: Filter Affects Versions: 2.0.0-M5 Environment: xp Reporter: ncanis2 Fix For: 2.0.0-M7 Hi. Packet sequence is unordered. = Server Client = chain.addLast(codec, new ProtocolCodecFilter(rcf)); chain.addLast(executor, getExecuteFilter());= OrderedThreadPoolExecutor c = new OrderedThreadPoolExecutor(20,100); If server send 1,2,3,4,5,6 , client receive 1,2,3,4,6 from server. Clients : 100. where I am wrong? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[Vysper] Porting to MINA 2.0.X (Some errors)
Back again with the topic. Did most of the porting on local copy, to
see how much time does it take :-)
One Observation
When using this code snippet in class XMLStreamTokenizerTestCase.java
private IoBuffer createByteBuffer() {
return IoBuffer.allocate(0, false).setAutoExpand(true);
}
was getting this error Derived buffers and their parent can't be expanded.
When I changed the code to
private IoBuffer createByteBuffer() {
return IoBuffer.allocate(1, false).setAutoExpand(true);
}
it worked fine. I guess I am missing something here
Errors
Most of the code has been ported, stuck with 2 Test Cases
Now stuck with testing the Decoder part
The test case code is below (XMLStreamTokenizerTestCase.java). Used
ProtocolCodeSession, as used in CumulativeProtocolDecoderTest
It fails at first assert, expected is 4, but it gets 1.
public void testDecoderSimple() throws Exception {
XMLStreamTokenizer decoder = new XMLStreamTokenizer();
IoSession session = new ProtocolCodecSession();
IoBuffer firstByteBuffer = createByteBuffer();
IoBuffer secondByteBuffer = createByteBuffer();
String stanza = StanzaWriter.XML_PROLOG + \n\r +
stream:stream to='example.com' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams' version='1.0' +
trailing-stanza/;
firstByteBuffer.putString(stanza, CHARSET_ENCODER_UTF8).flip();
MockProtocolDecoderOutput protocolDecoderOutput = new
MockProtocolDecoderOutput();
decoder.decode(session, firstByteBuffer, protocolDecoderOutput);
assertEquals(4, protocolDecoderOutput.size());
secondByteBuffer.putString(next/next,
CHARSET_ENCODER_UTF8).flip();
decoder.decode(session, secondByteBuffer, protocolDecoderOutput);
assertEquals(5, protocolDecoderOutput.size());
IoBuffer emptyBuffer = createByteBuffer().putString(eee,
CHARSET_ENCODER_UTF8).flip();
decoder.decode(session, emptyBuffer, protocolDecoderOutput);
assertEquals(plain must be terminated by , 5,
protocolDecoderOutput.size());
IoBuffer termBuffer = createByteBuffer().putString(r,
CHARSET_ENCODER_UTF8).flip();
decoder.decode(session, termBuffer, protocolDecoderOutput);
// eee is now terminated, but r is not balanced yet
assertEquals(plain termination, 6, protocolDecoderOutput.size());
}
Will continue to debug this, meanwhile any pointers are appreciated.
--
thanks
ashish
Blog: http://www.ashishpaliwal.com/blog
My Photo Galleries: http://www.pbase.com/ashishpaliwal
Re: [jira] Commented: (FTPSERVER-287) NLST: Implementation only supports listing files in working directory [patch provided]
On Tue, Jun 2, 2009 at 8:51 AM, Niklas Gustavsson nik...@protocol7.com wrote: On Tue, Jun 2, 2009 at 3:31 AM, Sai Pullabhotla sai.pullabho...@jmethods.com wrote: I would like to say that the results you have indicated only come from FTP servers that actually run the UNIX's ls command when a NLST command is received. Other servers probably adhere to the RFC by just returning names. One addition to this list, FileZilla works as described by Dennis. Another one, proftpd prints full path, but does not support parent directories (.. seems to be ignored). Does support home directory paths, but translated them to absolute paths (from the root of the file system). All of this seems to be a mess, not sure that we conclude that we do the wrong, nor the right thing at the moment. At least clients can not assume anything and thus probably have to find the file names (without the path) in whatever gets returned. Of course, the client knows the path already, since it sent it. Dennis, could you maybe describe some further on why you need to full path and how your client interoperates with servers that do not full support this (like proftpd which is a major player in this area). /niklas
[jira] Commented: (DIRMINA-714) Packet sequence is unordered in multi thread.
[ https://issues.apache.org/jira/browse/DIRMINA-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12715776#action_12715776 ] ncanis2 commented on DIRMINA-714: - Ok. I'll try to make it. Packet sequence is unordered in multi thread. - Key: DIRMINA-714 URL: https://issues.apache.org/jira/browse/DIRMINA-714 Project: MINA Issue Type: Bug Components: Filter Affects Versions: 2.0.0-M5 Environment: xp Reporter: ncanis2 Fix For: 2.0.0-M7 Hi. Packet sequence is unordered. = Server Client = chain.addLast(codec, new ProtocolCodecFilter(rcf)); chain.addLast(executor, getExecuteFilter());= OrderedThreadPoolExecutor c = new OrderedThreadPoolExecutor(20,100); If server send 1,2,3,4,5,6 , client receive 1,2,3,4,6 from server. Clients : 100. where I am wrong? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DIRMINA-714) Packet sequence is unordered in multi thread.
[ https://issues.apache.org/jira/browse/DIRMINA-714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ncanis2 updated DIRMINA-714: Attachment: mina_m6_seq_test_src.zip - All Logger level set ERROR - When packet sequence is wrong, server would close the client session. then saved sequence info logs wil be shown on console. = I made sample program you want. I think this sample has some bugs. sorry about that. but, it has same the bug that I talked you. When I run this program.. [11:1]-S[SeqServerHandler(sessionClosed:35)]:Sent Trace log=[4] Really MSG Sent= seq=0 [11:1]-S[SeqServerHandler(sessionClosed:35)]:Sent Trace log=[4] Really MSG Sent= seq=1 [11:1]-S[SeqServerHandler(sessionClosed:35)]:Sent Trace log=[4] Really MSG Sent= seq=2 [11:1]-S[SeqServerHandler(sessionClosed:35)]:Sent Trace log=[4] Really MSG Sent= seq=3 [11:1]-S[SeqServerHandler(sessionClosed:35)]:Sent Trace log=[4] Really MSG Sent= seq=4 [11:1]-S[SeqServerHandler(sessionClosed:35)]:Sent Trace log=[4] Really MSG Sent= seq=5 [11:1]-S[SeqServerHandler(sessionClosed:35)]:Sent Trace log=[4] Really MSG Sent= seq=6 [11:1]-S[SeqServerHandler(sessionClosed:35)]:Sent Trace log=[4] Really MSG Sent= seq=8 [11:1]-S[SeqServerHandler(sessionClosed:35)]:Sent Trace log=[4] Really MSG Sent= seq=7 Packet sequence is unordered in multi thread. - Key: DIRMINA-714 URL: https://issues.apache.org/jira/browse/DIRMINA-714 Project: MINA Issue Type: Bug Components: Filter Affects Versions: 2.0.0-M5 Environment: xp Reporter: ncanis2 Fix For: 2.0.0-M7 Attachments: mina_m6_seq_test_src.zip Hi. Packet sequence is unordered. = Server Client = chain.addLast(codec, new ProtocolCodecFilter(rcf)); chain.addLast(executor, getExecuteFilter());= OrderedThreadPoolExecutor c = new OrderedThreadPoolExecutor(20,100); If server send 1,2,3,4,5,6 , client receive 1,2,3,4,6 from server. Clients : 100. where I am wrong? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-714) Packet sequence is unordered in multi thread.
[
https://issues.apache.org/jira/browse/DIRMINA-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12715790#action_12715790
]
ncanis2 commented on DIRMINA-714:
-
please check follow issue number.
https://cwiki.apache.org/jira/browse/DIRMINA-653
in my case..
Synchronizing on the session.write makes the problem go away for 1 hour.;
synchronized (session)
{
future = session.write(message);
}
I thing you should check that.
I'll test more for long time with synchronized write.
Thank you.
Packet sequence is unordered in multi thread.
-
Key: DIRMINA-714
URL: https://issues.apache.org/jira/browse/DIRMINA-714
Project: MINA
Issue Type: Bug
Components: Filter
Affects Versions: 2.0.0-M5
Environment: xp
Reporter: ncanis2
Fix For: 2.0.0-M7
Attachments: mina_m6_seq_test_src.zip
Hi.
Packet sequence is unordered.
= Server Client =
chain.addLast(codec, new ProtocolCodecFilter(rcf));
chain.addLast(executor, getExecuteFilter());=
OrderedThreadPoolExecutor c = new OrderedThreadPoolExecutor(20,100);
If server send 1,2,3,4,5,6 , client receive 1,2,3,4,6 from server.
Clients : 100.
where I am wrong?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (DIRMINA-714) Packet sequence is unordered in multi thread.
[
https://issues.apache.org/jira/browse/DIRMINA-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12715790#action_12715790
]
ncanis2 edited comment on DIRMINA-714 at 6/2/09 8:58 PM:
-
please check follow issue number.
https://cwiki.apache.org/jira/browse/DIRMINA-653
in my case..
Synchronizing on the session.write makes the problem go away for 1 hour.;
synchronized (session)
{
future = session.write(message);
}
I think you should check DIRMINA-653 also.
I'll test more for long time with synchronized write.
Thank you.
was (Author: ncanis2):
please check follow issue number.
https://cwiki.apache.org/jira/browse/DIRMINA-653
in my case..
Synchronizing on the session.write makes the problem go away for 1 hour.;
synchronized (session)
{
future = session.write(message);
}
I thing you should check that.
I'll test more for long time with synchronized write.
Thank you.
Packet sequence is unordered in multi thread.
-
Key: DIRMINA-714
URL: https://issues.apache.org/jira/browse/DIRMINA-714
Project: MINA
Issue Type: Bug
Components: Filter
Affects Versions: 2.0.0-M5
Environment: xp
Reporter: ncanis2
Fix For: 2.0.0-M7
Attachments: mina_m6_seq_test_src.zip
Hi.
Packet sequence is unordered.
= Server Client =
chain.addLast(codec, new ProtocolCodecFilter(rcf));
chain.addLast(executor, getExecuteFilter());=
OrderedThreadPoolExecutor c = new OrderedThreadPoolExecutor(20,100);
If server send 1,2,3,4,5,6 , client receive 1,2,3,4,6 from server.
Clients : 100.
where I am wrong?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (DIRMINA-714) Packet sequence is unordered in multi thread.
[
https://issues.apache.org/jira/browse/DIRMINA-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12715790#action_12715790
]
ncanis2 edited comment on DIRMINA-714 at 6/2/09 9:00 PM:
-
please check follow issue number.
https://cwiki.apache.org/jira/browse/DIRMINA-653
in my case..
Synchronizing on the session.write makes the problem go away for 1 hour.;
synchronized (session)
{
future = session.write(message);
}
I think you should check DIRMINA-653 also.
I'll test more for long time with (synchronized session.write)
Thank you.
was (Author: ncanis2):
please check follow issue number.
https://cwiki.apache.org/jira/browse/DIRMINA-653
in my case..
Synchronizing on the session.write makes the problem go away for 1 hour.;
synchronized (session)
{
future = session.write(message);
}
I think you should check DIRMINA-653 also.
I'll test more for long time with synchronized write.
Thank you.
Packet sequence is unordered in multi thread.
-
Key: DIRMINA-714
URL: https://issues.apache.org/jira/browse/DIRMINA-714
Project: MINA
Issue Type: Bug
Components: Filter
Affects Versions: 2.0.0-M5
Environment: xp
Reporter: ncanis2
Fix For: 2.0.0-M7
Attachments: mina_m6_seq_test_src.zip
Hi.
Packet sequence is unordered.
= Server Client =
chain.addLast(codec, new ProtocolCodecFilter(rcf));
chain.addLast(executor, getExecuteFilter());=
OrderedThreadPoolExecutor c = new OrderedThreadPoolExecutor(20,100);
If server send 1,2,3,4,5,6 , client receive 1,2,3,4,6 from server.
Clients : 100.
where I am wrong?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-709) PENDING session is removed and added endlessly -- garbage allocation and high CPU usage problem
[
https://issues.apache.org/jira/browse/DIRMINA-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12715810#action_12715810
]
Victor N commented on DIRMINA-709:
--
Our production servers are working with this fix during ~1 month, everything
seems to work.
The only side-effect is mentioned in my comment above - sometimes, rarely, I
can see this warning in log files, but everything is working.
Forgot to say that I disabled MdcInjectionFilterTest when building mina with
the patch because this test failed.
Are there any plans to review this fix and include it into the next build -
maybe M7 ?
PENDING session is removed and added endlessly -- garbage allocation and
high CPU usage problem
Key: DIRMINA-709
URL: https://issues.apache.org/jira/browse/DIRMINA-709
Project: MINA
Issue Type: Bug
Components: Core
Affects Versions: 2.0.0-M4
Environment: Debian Linux, kernel 2.6.24
Reporter: Victor N
(This problem was discussed in mail lists, I will copy it here).
Seems I have found a bug with IoSession - I can see that a PREPARING
session is not removed correctly from queue.
When some session is in PREPARING state, it is removed from
removingSessions queue but right after that it is added to this queue
again! So this session is added to the queue and removed from it until
forever.
As a result, this give us significant garbage allocation, so CPU spends most
of time in garbage collector (I can see this is JConsole).
I see comments there in AbstractPollingIoProcessor class:
private int remove() {
...
case PREPARING:
// Retry later if session is not yet fully initialized.
// (In case that Session.close() is called before
addSession() is processed)
scheduleRemove(session);
return removedSessions;
...
}
I have added logging to this code, and I can see that the SAME session is
removed and added again and again.
Can somebody explain this logic please? Why don't we remove the PENDING
session? Or maybe is there a workaround for this.
Sorry, I can not provide a test for this issue, but it is reproduced almost
every day at out production servers under some load. Maybe, you can reproduce
it by adding a delay in addSession() and then closing the session during this
delay.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
