[jira] Updated: (FTPSERVER-344) Allow configuration of FileObserver and StatisticsObserver

[Niklas Gustavsson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FTPSERVER-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niklas Gustavsson updated FTPSERVER-344:


  Component/s: Core
Affects Version/s: 1.0.0
   1.0.1
   1.0.2
   1.0.3
Fix Version/s: 1.1.0

> Allow configuration of FileObserver and StatisticsObserver
> --
>
> Key: FTPSERVER-344
> URL: https://issues.apache.org/jira/browse/FTPSERVER-344
> Project: FtpServer
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 1.0.0, 1.0.1, 1.0.2, 1.0.3
>Reporter: Dave Roberts
> Fix For: 1.1.0
>
> Attachments: ftpStatistics.patch, ftpStatistics2.patch
>
>
> Setting this Observers currently involves a lot of casting and use of 
> "internal" classes and interfaces.
> These need to be exposed to the public interfaces.
> The simplest idea would seem to be to push the methods up to the 
> FtpStatistics interface.  However, these are only exposed through the Ftplet 
> which are runtime objects, so a better mechanism is required.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (FTPSERVER-339) Commands Dropped After Successful File Upload

[Niklas Gustavsson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FTPSERVER-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niklas Gustavsson updated FTPSERVER-339:


Fix Version/s: 1.1.0
   1.0.4
 Assignee: Niklas Gustavsson

> Commands Dropped After Successful File Upload
> -
>
> Key: FTPSERVER-339
> URL: https://issues.apache.org/jira/browse/FTPSERVER-339
> Project: FtpServer
>  Issue Type: Bug
>Affects Versions: 1.0.3
>Reporter: Nick Padgett
>Assignee: Niklas Gustavsson
>Priority: Critical
> Fix For: 1.0.4, 1.1.0
>
>
> After my ftp client successfully uploads a file, it sends a QUIT request.  
> This QUIT request doesn't always appear to be logged by the FtpServer which 
> results in the connection idling and the FtpServer subsequently closes the 
> connection.  We experience this issue often when uploading large files (2+GB) 
> or multiple medium size files (~1 GB).  When the QUIT is received before the 
> FtpServer issues a 226 transfer complete message, the server sends a 226 
> transfer complete message , the a 221 goodbye message before closing the 
> connection.  When the QUIT is received after the FtpServer issues a 226 
> transfer complete message, sometimes the QUIT is processed on the existing 
> thread and sometimes it is processed on a new thread.  In either case, the 
> server sends a 221 goodbye message and closed the connection.  This leads me 
> to believe that a QUIT message could be sent to the server in the time 
> between when the first thread is being closed and the second thread is being 
> opened.  Below are logs from my FtpServer that illustrate all of these 
> scenarios.
> This issue occurs very frequently and is resulting in the user believing 
> their uploads failed.
> QUIT received before 226 transfer complete sent:
> 2009-11-04 14:32:31,936 [pool-4-thread-8] INFO 
> org.apache.ftpserver.command.impl.STOR  - File uploaded 
> /1024/2009/11/02/7558_7W5oJqfN_event.wmv
> 2009-11-04 14:32:31,937 [pool-4-thread-8] INFO 
> org.apache.ftpserver.listener.nio.FtpLoggingFilter  - SENT: 150 File status 
> okay; about to open data connection.
> 2009-11-04 14:32:32,104 [pool-4-thread-8] INFO 
> org.apache.ftpserver.listener.nio.FtpLoggingFilter  - RECEIVED: QUIT
> 2009-11-04 14:32:32,104 [pool-4-thread-8] INFO 
> org.apache.ftpserver.listener.nio.FtpLoggingFilter  - SENT: 226 Transfer 
> complete.
> 2009-11-04 14:32:32,105 [pool-4-thread-8] INFO 
> org.apache.ftpserver.listener.nio.FtpLoggingFilter  - SENT: 221 Goodbye.
> 2009-11-04 14:32:32,105 [pool-4-thread-8] INFO 
> org.apache.ftpserver.listener.nio.FtpLoggingFilter  - CLOSED
> QUIT received after 226 transfer complete sent on the same thread:
> 2009-11-03 19:25:23,958 [pool-4-thread-697] INFO 
> org.apache.ftpserver.command.impl.STOR  - File uploaded 
> /1017/2009/10/09/7235_xVJpQ8tT_event.wmv
> 2009-11-03 19:25:23,958 [pool-4-thread-697] INFO 
> org.apache.ftpserver.listener.nio.FtpLoggingFilter  - SENT: 150 File status 
> okay; about to open data connection.
> 2009-11-03 19:25:23,968 [pool-4-thread-697] INFO 
> org.apache.ftpserver.listener.nio.FtpLoggingFilter  - SENT: 226 Transfer 
> complete.
> 2009-11-03 19:25:23,991 [pool-4-thread-697] INFO 
> org.apache.ftpserver.listener.nio.FtpLoggingFilter  - RECEIVED: QUIT
> 2009-11-03 19:25:23,992 [pool-4-thread-697] INFO 
> org.apache.ftpserver.listener.nio.FtpLoggingFilter  - SENT: 221 Goodbye.
> 2009-11-03 19:25:23,992 [pool-4-thread-697] INFO 
> org.apache.ftpserver.listener.nio.FtpLoggingFilter  - CLOSED
> QUIT received after the 226 transfer complete sent on a new thread:
> 2009-11-03 04:43:16,551 [pool-4-thread-662] INFO 
> org.apache.ftpserver.command.impl.STOR  - File uploaded 
> /1030/2009/11/02/7580_GxDwum7M_event.wmv
> 2009-11-03 04:43:16,552 [pool-4-thread-662] INFO 
> org.apache.ftpserver.listener.nio.FtpLoggingFilter  - SENT: 150 File status 
> okay; about to open data connection.
> 2009-11-03 04:43:16,552 [pool-4-thread-662] INFO 
> org.apache.ftpserver.listener.nio.FtpLoggingFilter  - SENT: 226 Transfer 
> complete.
> 2009-11-03 04:43:16,595 [pool-4-thread-667] INFO 
> org.apache.ftpserver.listener.nio.FtpLoggingFilter  - RECEIVED: QUIT
> 2009-11-03 04:43:16,598 [pool-4-thread-667] INFO 
> org.apache.ftpserver.listener.nio.FtpLoggingFilter  - SENT: 221 Goodbye.
> 2009-11-03 04:43:16,598 [pool-4-thread-667] INFO 
> org.apache.ftpserver.listener.nio.FtpLoggingFilter  - CLOSED
> QUIT NOT received because the FtpServer is between threads:
> 2009-11-04 02:05:18,328 [pool-4-thread-16] INFO 
> org.apache.ftpserver.command.impl.STOR  - File uploaded 
> /1051/2008/11/15/7400_NHftLRzu_event.mp4
> 2009-11-04 02:05:18,329 [pool-4-thread-16] INFO 
> org.apache.ftpserver.listener.nio.FtpLoggingFilter  - SENT: 150 File status 
> okay; about to open data connection.

[jira] Closed: (FTPSERVER-347) Multiline replies does not handle lines stariing with numbers

[Niklas Gustavsson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FTPSERVER-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Niklas Gustavsson closed FTPSERVER-347.
---

Resolution: Fixed

Fixed in rev 911609
commit -m "Fixing bug where we did not correctly handle multiline replies with 
lines starting with numbers (FTPSERVER-347)" 
/Users/niklas/Documents/svn/ftpserver-1.0.x/ftplet-api/src/main/java/org/apache/ftpserver/ftplet/DefaultFtpReply.java
 
/Users/niklas/Documents/svn/ftpserver-trunk/ftplet-api/src/main/java/org/apache/ftpserver/ftplet/DefaultFtpReply.java
 
/Users/niklas/Documents/svn/ftpserver-1.0.x/core/src/test/java/org/apache/ftpserver/impl/DefaultFtpReplyTest.java
 
/Users/niklas/Documents/svn/ftpserver-trunk/core/src/test/java/org/apache/ftpserver/impl/DefaultFtpReplyTest.java
Sending
/Users/niklas/Documents/svn/ftpserver-1.0.x/core/src/test/java/org/apache/ftpserver/impl/DefaultFtpReplyTest.java
Sending
/Users/niklas/Documents/svn/ftpserver-1.0.x/ftplet-api/src/main/java/org/apache/ftpserver/ftplet/DefaultFtpReply.java
Sending
/Users/niklas/Documents/svn/ftpserver-trunk/core/src/test/java/org/apache/ftpserver/impl/DefaultFtpReplyTest.java
Sending
/Users/niklas/Documents/svn/ftpserver-trunk/ftplet-api/src/main/java/org/apache/ftpserver/ftplet/DefaultFtpReply.java
Transmitting file data ...
Committed revision 911609.

> Multiline replies does not handle lines stariing with numbers
> -
>
> Key: FTPSERVER-347
> URL: https://issues.apache.org/jira/browse/FTPSERVER-347
> Project: FtpServer
>  Issue Type: Bug
>  Components: Core, Ftplets
>Affects Versions: 1.0.0, 1.0.1, 1.0.2, 1.0.3
>Reporter: Niklas Gustavsson
>Assignee: Niklas Gustavsson
> Fix For: 1.0.4, 1.1.0
>
>
> For multiline replies, any line staring with a number should be indented with 
> two spaces according to the example in the RFC. We do not currently do that, 
> instead printing the line without any prefix, making it potentially confusing 
> clients.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (FTPSERVER-347) Multiline replies does not handle lines stariing with numbers

[Niklas Gustavsson (JIRA)]

Multiline replies does not handle lines stariing with numbers
-

 Key: FTPSERVER-347
 URL: https://issues.apache.org/jira/browse/FTPSERVER-347
 Project: FtpServer
  Issue Type: Bug
  Components: Core, Ftplets
Affects Versions: 1.0.3, 1.0.2, 1.0.1, 1.0.0
Reporter: Niklas Gustavsson
Assignee: Niklas Gustavsson
 Fix For: 1.0.4, 1.1.0


For multiline replies, any line staring with a number should be indented with 
two spaces according to the example in the RFC. We do not currently do that, 
instead printing the line without any prefix, making it potentially confusing 
clients.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Hudson build is unstable: MINA-trunk-jdk1.6-windows #10

[Apache Hudson Server]

See 

Hudson build is still unstable: MINA-tru nk-jdk1.6-windows » Apache MINA Core #10

[Apache Hudson Server]

See 

Hudson build is back to normal : MINA-trun k-jdk1.6-windows » Apache MINA Examples #10

[Apache Hudson Server]

See 

Hudson build became unstable: MINA-trunk-jdk1.5-ubuntu #6

[Apache Hudson Server]

See 

Hudson build became unstable: MINA-tr unk-jdk1.5-ubuntu » Apache MINA Core #6

[Apache Hudson Server]

See 

ProtocolCodecFilter and private getDecoder(IoSession) method

[Norman Maurer]

Hi all,

why is this method declared private ?


/**
 * Get the decoder instance from a given session.
 *
 * @param session The associated session we will get the decoder from
 * @return The decoder instance
 */
private ProtocolDecoder getDecoder(IoSession session) {
return (ProtocolDecoder) session.getAttribute(DECODER);
}


The getEncoder method is declared public.

Bye,
Norman

[jira] Commented: (DIRMINA-764) DDOS possible in only a few seconds...

[Omry Yadan (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12835156#action_12835156
 ] 

Omry Yadan commented on DIRMINA-764:


checked with latest from trunk, and the problem still exists (although 
performance is _slightly_ better).

> DDOS possible in only a few seconds...
> --
>
> Key: DIRMINA-764
> URL: https://issues.apache.org/jira/browse/DIRMINA-764
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 2.0.0-RC1
>Reporter: Emmanuel Lecharny
>Assignee: Emmanuel Lecharny
>Priority: Blocker
> Fix For: 2.0.0
>
> Attachments: screenshot-1.jpg, screenshot-2.jpg
>
>
> We can kill a server in just a few seconds using the stress test found in 
> DIRMINA-762.
> If we inject messages with no delay, using 50 threads to do that, the 
> ProtocolCodecFilter$MessageWriteRequest is stuffed with hundred of thousands 
> messages waiting to be written back to the client, with no success.
> On the client side, we receive almost no messages :
> 0 messages/sec (total messages received 1)
> 2 messages/sec (total messages received 11)
> 8 messages/sec (total messages received 55)
> 8 messages/sec (total messages received 95)
> 9 messages/sec (total messages received 144)
> 3 messages/sec (total messages received 162)
> 1 messages/sec (total messages received 169)
> ...
> On the server side, the memory is totally swamped in 20 seconds, with no way 
> to recover :
> Exception in thread "pool-1-thread-1" java.lang.OutOfMemoryError: Java heap 
> space
> (see graph attached)
> On the server, ConcurrentLinkedQueue contain the messages to be written (in 
> my case, 724 499 Node are present). There are also 361629 
> DefaultWriteRequests, 361628 DefaultWriteFutures, 361625 SimpleBuffer, 361 
> 618 ProtocolCodecFilter$MessageWriteRequest and 361 614 
> ProtocolCodecFilter$EncodedWriteRequests.
> That mean we don't flush them to the client at all. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.