[jira] Resolved: (DIRMINA-636) The ProtocolDecoderOutput class initialization will fail if some filter is added after the codec
[
https://issues.apache.org/jira/browse/DIRMINA-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny resolved DIRMINA-636.
---
Resolution: Fixed
Fixed with : http://svn.apache.org/viewvc?rev=713125&view=rev
> The ProtocolDecoderOutput class initialization will fail if some filter is
> added after the codec
>
>
> Key: DIRMINA-636
> URL: https://issues.apache.org/jira/browse/DIRMINA-636
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.0.0-M3
>Reporter: Emmanuel Lecharny
>
> The way this class is initialized is wrong : it takes the nextFilter as a
> parameter, which means we can't add a filter after the codec without having a
> broken chain.
> Here is the method which initialize this object :
> private ProtocolDecoderOutput getDecoderOut(IoSession session,
> NextFilter nextFilter) {
> ProtocolDecoderOutput out = (ProtocolDecoderOutput)
> session.getAttribute(DECODER_OUT);
> if (out == null) {
> out = new ProtocolDecoderOutputImpl(session, nextFilter); <=
> This is WRONG
> session.setAttribute(DECODER_OUT, out);
> }
> return out;
> }
> It would be way better not to pass the to the
> constructor, but passing them to the flush() method, avoiding any potential
> problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DIRMINA-636) The ProtocolDecoderOutput class initialization will fail if some filter is added after the codec
[
https://issues.apache.org/jira/browse/DIRMINA-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny reassigned DIRMINA-636:
-
Assignee: Emmanuel Lecharny
> The ProtocolDecoderOutput class initialization will fail if some filter is
> added after the codec
>
>
> Key: DIRMINA-636
> URL: https://issues.apache.org/jira/browse/DIRMINA-636
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.0.0-M3
>Reporter: Emmanuel Lecharny
>Assignee: Emmanuel Lecharny
>
> The way this class is initialized is wrong : it takes the nextFilter as a
> parameter, which means we can't add a filter after the codec without having a
> broken chain.
> Here is the method which initialize this object :
> private ProtocolDecoderOutput getDecoderOut(IoSession session,
> NextFilter nextFilter) {
> ProtocolDecoderOutput out = (ProtocolDecoderOutput)
> session.getAttribute(DECODER_OUT);
> if (out == null) {
> out = new ProtocolDecoderOutputImpl(session, nextFilter); <=
> This is WRONG
> session.setAttribute(DECODER_OUT, out);
> }
> return out;
> }
> It would be way better not to pass the to the
> constructor, but passing them to the flush() method, avoiding any potential
> problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-636) The ProtocolDecoderOutput class initialization will fail if some filter is added after the codec
[
https://issues.apache.org/jira/browse/DIRMINA-636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny closed DIRMINA-636.
-
> The ProtocolDecoderOutput class initialization will fail if some filter is
> added after the codec
>
>
> Key: DIRMINA-636
> URL: https://issues.apache.org/jira/browse/DIRMINA-636
> Project: MINA
> Issue Type: Bug
>Affects Versions: 2.0.0-M3
>Reporter: Emmanuel Lecharny
>
> The way this class is initialized is wrong : it takes the nextFilter as a
> parameter, which means we can't add a filter after the codec without having a
> broken chain.
> Here is the method which initialize this object :
> private ProtocolDecoderOutput getDecoderOut(IoSession session,
> NextFilter nextFilter) {
> ProtocolDecoderOutput out = (ProtocolDecoderOutput)
> session.getAttribute(DECODER_OUT);
> if (out == null) {
> out = new ProtocolDecoderOutputImpl(session, nextFilter); <=
> This is WRONG
> session.setAttribute(DECODER_OUT, out);
> }
> return out;
> }
> It would be way better not to pass the to the
> constructor, but passing them to the flush() method, avoiding any potential
> problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DIRMINA-635) The IoFilter.preAdd method should take an IoSession argument
[ https://issues.apache.org/jira/browse/DIRMINA-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny closed DIRMINA-635. - > The IoFilter.preAdd method should take an IoSession argument > > > Key: DIRMINA-635 > URL: https://issues.apache.org/jira/browse/DIRMINA-635 > Project: MINA > Issue Type: Bug >Affects Versions: 2.0.0-M3 >Reporter: Emmanuel Lecharny >Assignee: Emmanuel Lecharny > > When injected an ProtocolCodecFilter in a chain when a session is already > created, the encoder and decoder are never injected into the session's > attribute, leading to NPE. > This could be fixed if we create those objects during the preAdd() phase, but > we need to pass the session to this preAdd method. Anyway, it makes sense, as > we may want to update some session's attribute during the addition, just in > case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DIRMINA-635) The IoFilter.preAdd method should take an IoSession argument
[ https://issues.apache.org/jira/browse/DIRMINA-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny resolved DIRMINA-635. --- Resolution: Fixed Fixed with : http://svn.apache.org/viewvc?rev=713125&view=rev > The IoFilter.preAdd method should take an IoSession argument > > > Key: DIRMINA-635 > URL: https://issues.apache.org/jira/browse/DIRMINA-635 > Project: MINA > Issue Type: Bug >Affects Versions: 2.0.0-M3 >Reporter: Emmanuel Lecharny >Assignee: Emmanuel Lecharny > > When injected an ProtocolCodecFilter in a chain when a session is already > created, the encoder and decoder are never injected into the session's > attribute, leading to NPE. > This could be fixed if we create those objects during the preAdd() phase, but > we need to pass the session to this preAdd method. Anyway, it makes sense, as > we may want to update some session's attribute during the addition, just in > case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DIRMINA-636) The ProtocolDecoderOutput class initialization will fail if some filter is added after the codec
The ProtocolDecoderOutput class initialization will fail if some filter is
added after the codec
Key: DIRMINA-636
URL: https://issues.apache.org/jira/browse/DIRMINA-636
Project: MINA
Issue Type: Bug
Affects Versions: 2.0.0-M3
Reporter: Emmanuel Lecharny
The way this class is initialized is wrong : it takes the nextFilter as a
parameter, which means we can't add a filter after the codec without having a
broken chain.
Here is the method which initialize this object :
private ProtocolDecoderOutput getDecoderOut(IoSession session,
NextFilter nextFilter) {
ProtocolDecoderOutput out = (ProtocolDecoderOutput)
session.getAttribute(DECODER_OUT);
if (out == null) {
out = new ProtocolDecoderOutputImpl(session, nextFilter); <=
This is WRONG
session.setAttribute(DECODER_OUT, out);
}
return out;
}
It would be way better not to pass the to the
constructor, but passing them to the flush() method, avoiding any potential
problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-218) Suggestion to enable user properties file to be updated without restarting server
[
https://issues.apache.org/jira/browse/FTPSERVER-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Niklas Gustavsson updated FTPSERVER-218:
Fix Version/s: 1.0-M4
Assignee: Niklas Gustavsson
> Suggestion to enable user properties file to be updated without restarting
> server
> -
>
> Key: FTPSERVER-218
> URL: https://issues.apache.org/jira/browse/FTPSERVER-218
> Project: FtpServer
> Issue Type: Improvement
> Components: Core
>Affects Versions: 1.0-M3
> Environment: Windows XP, JRE 1.5.0_11
>Reporter: Gary Bell
>Assignee: Niklas Gustavsson
> Fix For: 1.0-M4
>
> Attachments: FTPSERVER-218-TEST.patch, FTPSERVER-218.patch
>
>
> Currently, there is no method by which manual updates to a "user list"
> properties file that backs the PropertiesUserManager class can be loaded into
> a running server. You have to stop and then restart the server to see any
> changes.
> We are using FTPServer in embedded mode, and we need the site administrator
> to be able to hand-edit the file and then issue a custom function in our
> application to get the running server to reload the properties file. Prior to
> FTPServer-187, we handled this use case by creating a new instance of the
> PropertiesUserManager class using the newly-updated properties file and then
> calling server.getListener("default").setUserManager(...) .
> My suggestion is to add a refresh() method to the PropertiesUserManager class
> that will reload the properties file directly. Only new calls to
> getUserByName() would return the updated information - existing BaseUser
> instances remain unchanged.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DIRMINA-635) The IoFilter.preAdd method should take an IoSession argument
[ https://issues.apache.org/jira/browse/DIRMINA-635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Lecharny reassigned DIRMINA-635: - Assignee: Emmanuel Lecharny > The IoFilter.preAdd method should take an IoSession argument > > > Key: DIRMINA-635 > URL: https://issues.apache.org/jira/browse/DIRMINA-635 > Project: MINA > Issue Type: Bug >Affects Versions: 2.0.0-M3 >Reporter: Emmanuel Lecharny >Assignee: Emmanuel Lecharny > > When injected an ProtocolCodecFilter in a chain when a session is already > created, the encoder and decoder are never injected into the session's > attribute, leading to NPE. > This could be fixed if we create those objects during the preAdd() phase, but > we need to pass the session to this preAdd method. Anyway, it makes sense, as > we may want to update some session's attribute during the addition, just in > case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DIRMINA-635) The IoFilter.preAdd method should take an IoSession argument
[ https://issues.apache.org/jira/browse/DIRMINA-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12646583#action_12646583 ] Emmanuel Lecharny commented on DIRMINA-635: --- The preAdd method takes a IoFilterChain as a first argument, which has a getSession() method, so there is no need to pass a IoSession. It will then be easy to modify the preAdd method to initialize the encoder and decoder there, instead of doing so in the sessionCreated() method. Also we have to do it in both case, as the preAdd method is not called when the filter is added in the chain outside of the session. > The IoFilter.preAdd method should take an IoSession argument > > > Key: DIRMINA-635 > URL: https://issues.apache.org/jira/browse/DIRMINA-635 > Project: MINA > Issue Type: Bug >Affects Versions: 2.0.0-M3 >Reporter: Emmanuel Lecharny > > When injected an ProtocolCodecFilter in a chain when a session is already > created, the encoder and decoder are never injected into the session's > attribute, leading to NPE. > This could be fixed if we create those objects during the preAdd() phase, but > we need to pass the session to this preAdd method. Anyway, it makes sense, as > we may want to update some session's attribute during the addition, just in > case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (DIRMINA-635) The IoFilter.preAdd method should take an IoSession argument
The IoFilter.preAdd method should take an IoSession argument Key: DIRMINA-635 URL: https://issues.apache.org/jira/browse/DIRMINA-635 Project: MINA Issue Type: Bug Affects Versions: 2.0.0-M3 Reporter: Emmanuel Lecharny When injected an ProtocolCodecFilter in a chain when a session is already created, the encoder and decoder are never injected into the session's attribute, leading to NPE. This could be fixed if we create those objects during the preAdd() phase, but we need to pass the session to this preAdd method. Anyway, it makes sense, as we may want to update some session's attribute during the addition, just in case. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-218) Suggestion to enable user properties file to be updated without restarting server
[
https://issues.apache.org/jira/browse/FTPSERVER-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Bell updated FTPSERVER-218:
Attachment: FTPSERVER-218.patch
Patch against the PropertiesUserManager class
> Suggestion to enable user properties file to be updated without restarting
> server
> -
>
> Key: FTPSERVER-218
> URL: https://issues.apache.org/jira/browse/FTPSERVER-218
> Project: FtpServer
> Issue Type: Improvement
> Components: Core
>Affects Versions: 1.0-M3
> Environment: Windows XP, JRE 1.5.0_11
>Reporter: Gary Bell
> Attachments: FTPSERVER-218-TEST.patch, FTPSERVER-218.patch
>
>
> Currently, there is no method by which manual updates to a "user list"
> properties file that backs the PropertiesUserManager class can be loaded into
> a running server. You have to stop and then restart the server to see any
> changes.
> We are using FTPServer in embedded mode, and we need the site administrator
> to be able to hand-edit the file and then issue a custom function in our
> application to get the running server to reload the properties file. Prior to
> FTPServer-187, we handled this use case by creating a new instance of the
> PropertiesUserManager class using the newly-updated properties file and then
> calling server.getListener("default").setUserManager(...) .
> My suggestion is to add a refresh() method to the PropertiesUserManager class
> that will reload the properties file directly. Only new calls to
> getUserByName() would return the updated information - existing BaseUser
> instances remain unchanged.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (FTPSERVER-218) Suggestion to enable user properties file to be updated without restarting server
[
https://issues.apache.org/jira/browse/FTPSERVER-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Bell updated FTPSERVER-218:
Attachment: FTPSERVER-218-TEST.patch
Modified Junit test.
> Suggestion to enable user properties file to be updated without restarting
> server
> -
>
> Key: FTPSERVER-218
> URL: https://issues.apache.org/jira/browse/FTPSERVER-218
> Project: FtpServer
> Issue Type: Improvement
> Components: Core
>Affects Versions: 1.0-M3
> Environment: Windows XP, JRE 1.5.0_11
>Reporter: Gary Bell
> Attachments: FTPSERVER-218-TEST.patch, FTPSERVER-218.patch
>
>
> Currently, there is no method by which manual updates to a "user list"
> properties file that backs the PropertiesUserManager class can be loaded into
> a running server. You have to stop and then restart the server to see any
> changes.
> We are using FTPServer in embedded mode, and we need the site administrator
> to be able to hand-edit the file and then issue a custom function in our
> application to get the running server to reload the properties file. Prior to
> FTPServer-187, we handled this use case by creating a new instance of the
> PropertiesUserManager class using the newly-updated properties file and then
> calling server.getListener("default").setUserManager(...) .
> My suggestion is to add a refresh() method to the PropertiesUserManager class
> that will reload the properties file directly. Only new calls to
> getUserByName() would return the updated information - existing BaseUser
> instances remain unchanged.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (FTPSERVER-219) The STOR command hangs thread in passive mode
[
https://issues.apache.org/jira/browse/FTPSERVER-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12646546#action_12646546
]
Mikael Svahn commented on FTPSERVER-219:
Yes, I hope this patch will solve the problem. I'm currently running some tests
to verify it.
Here is the patch:
Index: src/main/java/org/apache/ftpserver/impl/IODataConnectionFactory.java
===
--- src/main/java/org/apache/ftpserver/impl/IODataConnectionFactory.java
(revision 712407)
+++ src/main/java/org/apache/ftpserver/impl/IODataConnectionFactory.java
(working copy)
@@ -311,6 +311,7 @@
} else {
LOG.debug("Opening passive data connection");
dataSoc = servSoc.accept();
+dataSoc.setSoTimeout(dataConfig.getIdleTime() * 1000);
LOG.debug("Passive data connection opened");
}
} catch (Exception ex) {
> The STOR command hangs thread in passive mode
> -
>
> Key: FTPSERVER-219
> URL: https://issues.apache.org/jira/browse/FTPSERVER-219
> Project: FtpServer
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.0-M3, 1.0-M4
> Environment: Debian Linux
> Jdk 1.6.0_10
>Reporter: Mikael Svahn
>
> If a client does not disconnect a STOR command correct, for instance due to
> bad transmission the reader thread might hang. I think there must be a
> timeout on socket read.
> - java.net.SocketInputStream.socketRead0(java.io.FileDescriptor, byte[],
> int, int, int) @bci=0 (Interpreted frame)
> - java.net.SocketInputStream.read(byte[], int, int) @bci=84, line=129
> (Interpreted frame)
> - java.io.BufferedInputStream.fill() @bci=175, line=218 (Compiled frame)
> - java.io.BufferedInputStream.read1(byte[], int, int) @bci=44, line=258
> (Compiled frame)
> - java.io.BufferedInputStream.read(byte[], int, int) @bci=49, line=317
> (Interpreted frame)
> - java.io.FilterInputStream.read(byte[]) @bci=5, line=90 (Interpreted frame)
> -
> org.apache.ftpserver.impl.IODataConnection.transfer(org.apache.ftpserver.ftplet.FtpSession,
> boolean, java.io.InputStream, java.io.OutputStream, int) @bci=133, line=236
> (Interpreted frame)
> -
> org.apache.ftpserver.impl.IODataConnection.transferFromClient(org.apache.ftpserver.ftplet.FtpSession,
> java.io.OutputStream) @bci=51, line=129 (Interpreted frame)
> -
> org.apache.ftpserver.command.impl.STOR.execute(org.apache.ftpserver.impl.FtpIoSession,
> org.apache.ftpserver.impl.FtpServerContext,
> org.apache.ftpserver.ftplet.FtpRequest) @bci=344, line=147 (Interpreted frame)
> -
> org.apache.ftpserver.impl.DefaultFtpHandler.messageReceived(org.apache.ftpserver.impl.FtpIoSession,
> org.apache.ftpserver.ftplet.FtpRequest) @bci=160, line=135 (Interpreted
> frame)
> -
> org.apache.ftpserver.listener.nio.FtpHandlerAdapter.messageReceived(org.apache.mina.core.session.IoSession,
> java.lang.Object) @bci=33, line=62 (Interpreted frame)
> -
> org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(org.apache.mina.core.filterchain.IoFilter$NextFilter,
> org.apache.mina.core.session.IoSession, java.lang.Object) @bci=51, line=752
> (Inte
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[APR] behaviour of Socket.connect(remote,local)
Has anyone done any work with the APR stuff? (I am asking the same
question on the tomcat dev list...)
Thanks to the input I got from this list I managed to fix some issues
with my AprDatagramAcceptor and Connector. Now I experience the
following problem when using them. I am trying to send a message out on
every interface of the system, so I try this:
scenario 1)
- the receiver has a AprDatagramAcceptor up and running
- the sender uses "connector.connect(remoteaddr)", gets a session and
writes to it
- the receiver receives it just fine and can even write a reply to the
session which is received on the other side...
scenario 2)
- the receiver is unchanged
- the otherwise identical sender uses "connector.connect(remoteaddr, new
InetSocketAddress("127.0.0.1",0)), gets a session which looks ok (source
and dest ips and ports look good) and writes to it, no exception thrown...
- the receiver does not receive anything...
- wireshark lists the outgoing packet however...
- all the calls on the way, including newHandle(localAddress) and
connect(handle, remoteAddress) return APR_SUCCESS...
any ideas where the problem may lie?
cheers,
lorenz
[jira] Commented: (FTPSERVER-219) The STOR command hangs thread in passive mode
[ https://issues.apache.org/jira/browse/FTPSERVER-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12646531#action_12646531 ] David Latorre commented on FTPSERVER-219: - I don't have the code here but it should be easy - just use setSoTimeout , right ? a patch will be welcome if you have already fixed this! > The STOR command hangs thread in passive mode > - > > Key: FTPSERVER-219 > URL: https://issues.apache.org/jira/browse/FTPSERVER-219 > Project: FtpServer > Issue Type: Bug > Components: Core >Affects Versions: 1.0-M3, 1.0-M4 > Environment: Debian Linux > Jdk 1.6.0_10 >Reporter: Mikael Svahn > > If a client does not disconnect a STOR command correct, for instance due to > bad transmission the reader thread might hang. I think there must be a > timeout on socket read. > - java.net.SocketInputStream.socketRead0(java.io.FileDescriptor, byte[], > int, int, int) @bci=0 (Interpreted frame) > - java.net.SocketInputStream.read(byte[], int, int) @bci=84, line=129 > (Interpreted frame) > - java.io.BufferedInputStream.fill() @bci=175, line=218 (Compiled frame) > - java.io.BufferedInputStream.read1(byte[], int, int) @bci=44, line=258 > (Compiled frame) > - java.io.BufferedInputStream.read(byte[], int, int) @bci=49, line=317 > (Interpreted frame) > - java.io.FilterInputStream.read(byte[]) @bci=5, line=90 (Interpreted frame) > - > org.apache.ftpserver.impl.IODataConnection.transfer(org.apache.ftpserver.ftplet.FtpSession, > boolean, java.io.InputStream, java.io.OutputStream, int) @bci=133, line=236 > (Interpreted frame) > - > org.apache.ftpserver.impl.IODataConnection.transferFromClient(org.apache.ftpserver.ftplet.FtpSession, > java.io.OutputStream) @bci=51, line=129 (Interpreted frame) > - > org.apache.ftpserver.command.impl.STOR.execute(org.apache.ftpserver.impl.FtpIoSession, > org.apache.ftpserver.impl.FtpServerContext, > org.apache.ftpserver.ftplet.FtpRequest) @bci=344, line=147 (Interpreted frame) > - > org.apache.ftpserver.impl.DefaultFtpHandler.messageReceived(org.apache.ftpserver.impl.FtpIoSession, > org.apache.ftpserver.ftplet.FtpRequest) @bci=160, line=135 (Interpreted > frame) > - > org.apache.ftpserver.listener.nio.FtpHandlerAdapter.messageReceived(org.apache.mina.core.session.IoSession, > java.lang.Object) @bci=33, line=62 (Interpreted frame) > - > org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(org.apache.mina.core.filterchain.IoFilter$NextFilter, > org.apache.mina.core.session.IoSession, java.lang.Object) @bci=51, line=752 > (Inte -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: AW: [MessageSent] let's remove it... no---signature
Steve Ulrich wrote:
Hi!
AFAIK, the messageSent is the only way to react when a message is finally
sent.
Yes, but because no alternate solution was discussed. And even if it was
the only solution, it's a pretty atrocious one : having to go through
the chain a second time just to get some stats sounds silly to me. So
let's try to find a better way. And the fact that this is closely linked
to a filter is even worse (what if you don't use a ProtocolCodecFilter ?).
filterWrite is already called *before* the message is passed to the
cable.
How can I implement timings, like request/response timeout filters?
Using filterWrite for this could be problematic for decoding will consume
some undefined/-able amount of the time(out).
If there's another way to do this, let me know.
So let's think a second time about the way the protocolCodecFilter
works, when a message is to b sent back to the client. It receives a
Message, encode it, and write it to the cient. If you look at the
current implementation :
public void flushWithoutFuture(int index) throws Exception {
Queue bufferQueue = getMessageQueue();
for (;;) {
Object encodedMessage = bufferQueue.poll();
if (encodedMessage == null) {
break;
}
// Flush only when the buffer has remaining.
if (!(encodedMessage instanceof IoBuffer) ||
((IoBuffer) encodedMessage).hasRemaining()) {
SocketAddress destination =
writeRequest.getDestination();
WriteRequest writeRequest = new EncodedWriteRequest(
encodedMessage, null, destination);
IoFilter nextFilter = session.getFilterOut(index+1);
nextFilter.filterWrite(index+1, session, writeRequest);
}
}
}
you can see that we loop on the message Queue, flushing every message
one by one. Three things :
- first, if we have more than one message one the queue, I don't see how
we can generate this MessageSent message.
- second, as the encoder will generate a full IoBuffer for each separate
message, I don't see how it's necessary to send it again.
- third, this is not because we have generated an empty message and
faked to send it that the message has been sent. It's just a damn hack
to pretend the message has been sent.
Now, it's all about semantic : when do we want to *know* that a message
has been sent ? When the client has sent an ack ? There is no way to
enforce this.
What about considering that the message is sent as soon as we have
written in the chjain, associated with a writeFuture marked as 'done' ?
The problem is that the codec just send the data without creating a future.
At some point, we will need to get a feedback from the low level layers
telling us that the message (being a IoBuffer at this point) has been
successfully sent : a WriteFutuer in a 'completed' state should do the
trick. A filter checking able to check this write future when it's set
to 'don' should do the trick.
This is not simple : if we consider that we send data on a non-blocking
IO, we have to assume that the message has been sent even if the socket
is full, and we may perfectly write in a socket which will be close
before the full message has been sent. Let's say that it's a best effort
approach.
Anyway, I think it's feasible with a WriteFuture.
As usual, I may be wrong. May be I'm totally off rail, just tell me then :)
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re : [MessageSent] let's remove it...
lol
Emm did you pay Rajeshwari just to support your proposal ? DIRMINA-634 should
also be resolved by removing messageSent event
which seems to be an unnecessary event that makes code even more cloudy.
so +1
Cordialement, Regards,
-Edouard De Oliveira-
http://tedorg.free.fr/en/main.php
De : Mark Webb <[EMAIL PROTECTED]>
À : dev@mina.apache.org
Envoyé le : Mardi, 11 Novembre 2008, 4h18mn 53s
Objet : Re: [MessageSent] let's remove it...
spot on. +1. remove it.
On Mon, Nov 10, 2008 at 7:11 PM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
> Hi guys,
>
> a few days ago, Julien suggested that we should remove this event. I never
> used it, found it a bit cumbersome, but didn't had time to double check
> what's doing.
>
> Let's go back to the mailing list...
>
> Back in july, I posted a mail where I questionned some code :
>
> ProtocolCodecFilter.filterWrite() {
>>
>> ...
>> ProtocolEncoder encoder = getEncoder(session);
>> ProtocolEncoderOutputImpl encoderOut = getEncoderOut(session,
>> nextFilter, writeRequest);
>>
>> try {
>> encoder.encode(session, message, encoderOut);
>>
>> // Here, the encoded message is sent.
>> encoderOut.flush();
>>
>> // Here an empty message is sent...
>> nextFilter.filterWrite(session, new WriteRequest(
>> new MessageByteBuffer(writeRequest.getMessage()),
>> writeRequest.getFuture(),
>> writeRequest.getDestination()));
>
> There are two places in this code where the message is written : in the
> encoderOut.flush() and in the filterWrote() call.
>
> Trustin replied saying :
>
> "The two code blocks above are effectively same. The reason we call
> filterWrite once more with an empty buffer (MessageByteBuffer or
> MessageWriteRequest) is to generate a proper messageSent event which
> corresponds to the written message. Let me know if there's more efficient
> way to take care of messageSent events."
>
> There is an obvious way to be more efficient here : simply not sending this
> messageSent event !
>
>
> But this is not a good enough reason to remove it. Let's dig another mail.
>
> https://issues.apache.org/jira/browse/DIRMINA-574
>
> Steps to reproduce:
> 1) Connection is closed at the socket level.
> 2) A user writes a message.
> 3) the message is encoded by a ProtocolCodecFilter.
> 4) MINA notices the closed socket and fires a sessionClosed event.
> 5) After the sessionClosed event is fired, IoFilterChain.clear() is called.
> 6) MINA tries to write the user write request, but the session is closed
> already - all write requests are discarded.
> 7) Before MINA discards all write requests, MINA checks if the first item in
> the queue is an empty buffer, which means a special separator which is
> handled by ProtocolCodecFilter.
> 8) If there's an empty buffer in the head of the queue, MINA fires a
> messageSent event with the empty buffer in the hope that ProtocolCodecFilter
> will catch it.
> 9) However, the filter chain is empty and therefore IoHandler implementation
> gets ClassCastException.
>
>
> At step 8, we send a MessageSent event, which leads to an Exception.
> Clearly, this is not good. Removing the MessageSent event will immediatly
> solve this blocker issue.
>
> Last, not least, another mail states that :
>
> "Also, I'd like to make a plug for removing messageSent() callbacks and
> having the end-user API rely on WriteFutures instead. It's a hassle to
> write new filters when you have to worry about passing back the correct
> object."
>
> Using WriteFuture will clearly be a better way to get the message as it has
> been posted to the chain, instead to having to encode it back, as it's
> currently done.
>
> Anyone disagree ? Anything I missed ?
>
> Thanks !
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
[jira] Commented: (FTPSERVER-218) Suggestion to enable user properties file to be updated without restarting server
[
https://issues.apache.org/jira/browse/FTPSERVER-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12646519#action_12646519
]
Gary Bell commented on FTPSERVER-218:
-
No problem. I will do this in the next few days. Thanks very much.
> Suggestion to enable user properties file to be updated without restarting
> server
> -
>
> Key: FTPSERVER-218
> URL: https://issues.apache.org/jira/browse/FTPSERVER-218
> Project: FtpServer
> Issue Type: Improvement
> Components: Core
>Affects Versions: 1.0-M3
> Environment: Windows XP, JRE 1.5.0_11
>Reporter: Gary Bell
>
> Currently, there is no method by which manual updates to a "user list"
> properties file that backs the PropertiesUserManager class can be loaded into
> a running server. You have to stop and then restart the server to see any
> changes.
> We are using FTPServer in embedded mode, and we need the site administrator
> to be able to hand-edit the file and then issue a custom function in our
> application to get the running server to reload the properties file. Prior to
> FTPServer-187, we handled this use case by creating a new instance of the
> PropertiesUserManager class using the newly-updated properties file and then
> calling server.getListener("default").setUserManager(...) .
> My suggestion is to add a refresh() method to the PropertiesUserManager class
> that will reload the properties file directly. Only new calls to
> getUserByName() would return the updated information - existing BaseUser
> instances remain unchanged.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
AW: [MessageSent] let's remove it... no---signature
Hi!
AFAIK, the messageSent is the only way to react when a message is finally
sent. filterWrite is already called *before* the message is passed to the
cable.
How can I implement timings, like request/response timeout filters?
Using filterWrite for this could be problematic for decoding will consume
some undefined/-able amount of the time(out).
If there's another way to do this, let me know.
regards
Steve
> Emmanuel Lecharny [mailto:[EMAIL PROTECTED] wrote:
>
> Hi guys,
>
> a few days ago, Julien suggested that we should remove this event. I
> never used it, found it a bit cumbersome, but didn't had time to double
> check what's doing.
>
> Let's go back to the mailing list...
>
> Back in july, I posted a mail where I questionned some code :
>
> ProtocolCodecFilter.filterWrite() {
> >...
> >ProtocolEncoder encoder = getEncoder(session);
> >ProtocolEncoderOutputImpl encoderOut = getEncoderOut(session,
> >nextFilter, writeRequest);
> >
> >try {
> >encoder.encode(session, message, encoderOut);
> >
> >// Here, the encoded message is sent.
> >encoderOut.flush();
> >
> >// Here an empty message is sent...
> >nextFilter.filterWrite(session, new WriteRequest(
> >new MessageByteBuffer(writeRequest.getMessage()),
> >writeRequest.getFuture(),
> > writeRequest.getDestination()));
>
> There are two places in this code where the message is written : in the
> encoderOut.flush() and in the filterWrote() call.
>
> Trustin replied saying :
>
> "The two code blocks above are effectively same. The reason we call
> filterWrite once more with an empty buffer (MessageByteBuffer or
> MessageWriteRequest) is to generate a proper messageSent event which
> corresponds to the written message. Let me know if there's more
> efficient way to take care of messageSent events."
>
> There is an obvious way to be more efficient here : simply not sending
> this messageSent event !
>
>
> But this is not a good enough reason to remove it. Let's dig another
> mail.
>
> https://issues.apache.org/jira/browse/DIRMINA-574
>
> Steps to reproduce:
> 1) Connection is closed at the socket level.
> 2) A user writes a message.
> 3) the message is encoded by a ProtocolCodecFilter.
> 4) MINA notices the closed socket and fires a sessionClosed event.
> 5) After the sessionClosed event is fired, IoFilterChain.clear() is
> called.
> 6) MINA tries to write the user write request, but the session is
> closed already - all write requests are discarded.
> 7) Before MINA discards all write requests, MINA checks if the first
> item in the queue is an empty buffer, which means a special separator
> which is handled by ProtocolCodecFilter.
> 8) If there's an empty buffer in the head of the queue, MINA fires a
> messageSent event with the empty buffer in the hope that
> ProtocolCodecFilter will catch it.
> 9) However, the filter chain is empty and therefore IoHandler
> implementation gets ClassCastException.
>
>
> At step 8, we send a MessageSent event, which leads to an Exception.
> Clearly, this is not good. Removing the MessageSent event will
> immediatly solve this blocker issue.
>
> Last, not least, another mail states that :
>
> "Also, I'd like to make a plug for removing messageSent() callbacks and
> having the end-user API rely on WriteFutures instead. It's a hassle to
> write new filters when you have to worry about passing back the correct
> object."
>
> Using WriteFuture will clearly be a better way to get the message as it
> has been posted to the chain, instead to having to encode it back, as
> it's currently done.
>
> Anyone disagree ? Anything I missed ?
>
> Thanks !
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
Re: [FTPSERVER] The way of logging exceptions
On Tue, Nov 11, 2008 at 8:33 AM, Jiří Kuhn <[EMAIL PROTECTED]> wrote: > I thing, no, I believe that exceptions are not debugging messages. What do > you think? The reasoning, while it might not be a good one, is that these are exceptions that occur as part of "normal" user behavior, like disconnecting in the middle of a upload. Therefore we log them at a low level, but INFO might be a better choice than debug. I would like to use ERROR only for exceptions that will cause problems with FtpServer. /niklas
