[jira] [Commented] (IMAP-351) ACL Support
[ https://issues.apache.org/jira/browse/IMAP-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13503156#comment-13503156 ] Eric Charles commented on IMAP-351: --- After applying the patch, the unit test were successful, however, the mailbox-integration test were failing. I fixed many of the issues for the inmemory mailbox test, but have more issue with the maildir store. Fixing the integration tests, I had to some workaround which are not in line with what we want to have as a final implementation, but which was needed if I didn't want to change to many things. Unfortunately, I was not able to got to the end and will not commit this for the time being. I also just wonder if this would have been a good thing to commit at once such huge changes. We should go more incrementally to allow everyone (developers and users) to review and comment the commits. The good think is that I have now a better view of Gazda work. ACL Support --- Key: IMAP-351 URL: https://issues.apache.org/jira/browse/IMAP-351 Project: JAMES Imap Issue Type: New Feature Components: JCR Mailbox, JPA Mailbox, Mailbox, Maildir Mailbox, Parser, Processor, Protocol Affects Versions: 0.3 Reporter: Jochen Gazda Labels: ACL, IMAP Fix For: 0.3 Attachments: ImapGetACLTest.java, IMAP-GETACL.txt, master...MAILBOX-175.diff Original Estimate: 672h Remaining Estimate: 672h Support for RFC 4314 IMAP4 Access Control List (ACL) Extension -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (PROTOCOLS-98) Decouple POP3 UID forming logic from protocol implementation
[ https://issues.apache.org/jira/browse/PROTOCOLS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13503158#comment-13503158 ] Eric Charles commented on PROTOCOLS-98: --- Hi Rustam, Finally I will not commit the IMAP-351 patch, so it will be good that you attach your patch here. Thx, Eric Decouple POP3 UID forming logic from protocol implementation Key: PROTOCOLS-98 URL: https://issues.apache.org/jira/browse/PROTOCOLS-98 Project: JAMES Protocols Issue Type: Improvement Components: pop3 Affects Versions: 1.6.1 Reporter: Rustam Aliyev Assignee: Norman Maurer Fix For: 1.6.2 Currently, it seems that UID string formation logic is hardcoded into POP3 protocol. For example, UidlCmdHandler in a number of places forms UID using Long field from MessageMetaData. However, RFC1939 defined UID as an arbitrary server-determined string, consisting of one to 70 characters in the range 0x21 to 0x7E (http://tools.ietf.org/html/rfc1939#page-12). POP3 protocol implementation should be able to specify arbitrary UID String as a part of MessageMetaData alongside with Size. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-1436) APPEND IMAP command can result in JAMES IMAP waiting indefinitely for data
[ https://issues.apache.org/jira/browse/JAMES-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13503165#comment-13503165 ] Eric Charles commented on JAMES-1436: - Hi Samant, Thx for the patch. Have you got a test which shows the error before the patch and shows the resolution after the patch. I know that it is really not easy to provide that kind of test (or nearly impossible), but I just want to ask here how you can be sure your patch fixes the issue. Also, will the synchronization on the methods slow down the decoding? Thx, Eric APPEND IMAP command can result in JAMES IMAP waiting indefinitely for data -- Key: JAMES-1436 URL: https://issues.apache.org/jira/browse/JAMES-1436 Project: JAMES Server Issue Type: Bug Components: IMAPServer Affects Versions: Trunk, 3.0-beta4, 3.0-beta5 Environment: Ubuntu 12.04 x86_64 Reporter: Samant Maharaj Attachments: JAMES-1436.patch When processing an IMAP APPEND command, the Netty stack in JAMES IMAP can get into a state where the ImapRequestFrameDecoder will wait for a number message bytes that will never arrive. This has the effect of causing the IMAP client to also block indefinitely waiting for a response from the server. Root Cause: This is due to a race condition when the DelimiterBasedFrameDecoder is removed from the Netty pipeline by the ImapRequestFrameDecoder. If the DelimiterBasedFrameDecoder still contains less than one line of data in its buffer, that data will never be flushed and forwarded down the pipeline. The effect of this is that a small number of bytes, typically from the early part of the message are omitted and the final byte count does not match the value calculated from the APPEND command. This results in the APPEND command never being completely decoded and hence no append actually takes place nor does a response get sent to the client. In order to reliably trigger this bug, JAMES was configured to accept a remote debugging connection and a conditional breakpoint set at org.jboss.netty.handler.codec.frame.FrameDecoder:439. The condition was set to 'Thread.sleep(200l); false'. This results in introducing a 200ms delay on each frame decoding loop without actually hitting the breakpoint. The effect of this is to allow the threadpool running ImapRequestFrameDecoder time to consume the individual frames and remove the DelimiterBasedFrameDecoder from the pipeline. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
svn commit: r1412832 - /james/current/pom.xml
Author: eric Date: Fri Nov 23 11:23:46 2012 New Revision: 1412832 URL: http://svn.apache.org/viewvc?rev=1412832view=rev Log: imap project is no more a subproject, remove it from the current pom.xml Modified: james/current/pom.xml Modified: james/current/pom.xml URL: http://svn.apache.org/viewvc/james/current/pom.xml?rev=1412832r1=1412831r2=1412832view=diff == --- james/current/pom.xml (original) +++ james/current/pom.xml Fri Nov 23 11:23:46 2012 @@ -35,7 +35,6 @@ modulemailbox/module modulemailbox-integration-tester/module moduleprotocols/module -moduleimap/module modulehupa/module modulejdkim/module modulejspf/module - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (MAILBOX-186) Missing indices on JPA mailstore database results in poor mailbox listing as the number of messages grows
[ https://issues.apache.org/jira/browse/MAILBOX-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13503168#comment-13503168 ] Eric Charles commented on MAILBOX-186: -- Sounds like a good plan. 2 comments: - In trunk, JPAProperty entity has only 'PROPERTY_LINE_NUMBER' attributed, but not PROPERTY_MSG_ID (which version are you using?) - We should fix this by adding @Index on the attributed for which we want an index in the JPAProperty class. Thx, Eric Missing indices on JPA mailstore database results in poor mailbox listing as the number of messages grows - Key: MAILBOX-186 URL: https://issues.apache.org/jira/browse/MAILBOX-186 Project: James Mailbox Issue Type: Bug Components: jpa Affects Versions: 0.4 Reporter: Craig George We have an application which queries the IMAP store of Apache James 3 in the following manner: final Message[] messages = this.folder.getMessages(); final FetchProfile fetchProfile = new FetchProfile(); fetchProfile.add(Item.ENVELOPE); fetchProfile.add(Item.FLAGS); fetchProfile.add(Item.CONTENT_INFO); fetchProfile.add(IMAPFolder.FetchProfileItem.HEADERS); fetchProfile.add(IMAPFolder.FetchProfileItem.SIZE); fetchProfile.add(UIDFolder.FetchProfileItem.UID); this.folder.fetch(messages, fetchProfile); When this query is performed on a folder with a large number of messages the response times degrade very quickly. This is due to the following query being run *for each* message: SELECT t0.PROPERTY_ID, t0.PROPERTY_LINE_NUMBER, t0.PROPERTY_LOCAL_NAME, t0.PROPERTY_NAME_SPACE, t0.PROPERTY_VALUE FROM MA_DIRECT_APACHE_JAMES.JAMES_MAIL_PROPERTY t0 WHERE t0.MAILBOX_ID = :1 AND t0.MAIL_UID = :2 ORDER BY t0.PROPERTY_LINE_NUMBER ASC The problem is that in the JAMES_MAIL_PROPERTY table only the PROPERTY_LINE_ID column is indexed, implicity by virtue of the fact that it is the primary key. The workaround is to add the following indexes on the table: CREATE INDEX I_JMS_MIL_PROPERTY_MSG_ID ON JAMES_MAIL_PROPERTY (MAILBOX_ID, MAIL_UID); CREATE INDEX I_JMS_MIL_PROPERTY_LINE_NUMBER ON JAMES_MAIL_PROPERTY (PROPERTY_LINE_NUMBER); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-1436) APPEND IMAP command can result in JAMES IMAP waiting indefinitely for data
[ https://issues.apache.org/jira/browse/JAMES-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13503188#comment-13503188 ] Andrzej Rusin commented on JAMES-1436: -- The patch EMPIRICALLY works even without synchronized on createCumulationDynamicBuffer(). No idea however how it maps to concurrency correctness. I will provide some more details on reproducing (after I get more systematic about it). For sure it's easy with MS Outlook by editing a existing message TWICE IN A ROW on SSL or STARTTLS connection. I think it has to do with APPENDed message being started sending in the same packet as the command itself. Thank you Samant, you are a life saver. APPEND IMAP command can result in JAMES IMAP waiting indefinitely for data -- Key: JAMES-1436 URL: https://issues.apache.org/jira/browse/JAMES-1436 Project: JAMES Server Issue Type: Bug Components: IMAPServer Affects Versions: Trunk, 3.0-beta4, 3.0-beta5 Environment: Ubuntu 12.04 x86_64 Reporter: Samant Maharaj Attachments: JAMES-1436.patch When processing an IMAP APPEND command, the Netty stack in JAMES IMAP can get into a state where the ImapRequestFrameDecoder will wait for a number message bytes that will never arrive. This has the effect of causing the IMAP client to also block indefinitely waiting for a response from the server. Root Cause: This is due to a race condition when the DelimiterBasedFrameDecoder is removed from the Netty pipeline by the ImapRequestFrameDecoder. If the DelimiterBasedFrameDecoder still contains less than one line of data in its buffer, that data will never be flushed and forwarded down the pipeline. The effect of this is that a small number of bytes, typically from the early part of the message are omitted and the final byte count does not match the value calculated from the APPEND command. This results in the APPEND command never being completely decoded and hence no append actually takes place nor does a response get sent to the client. In order to reliably trigger this bug, JAMES was configured to accept a remote debugging connection and a conditional breakpoint set at org.jboss.netty.handler.codec.frame.FrameDecoder:439. The condition was set to 'Thread.sleep(200l); false'. This results in introducing a 200ms delay on each frame decoding loop without actually hitting the breakpoint. The effect of this is to allow the threadpool running ImapRequestFrameDecoder time to consume the individual frames and remove the DelimiterBasedFrameDecoder from the pipeline. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-1436) APPEND IMAP command can result in JAMES IMAP waiting indefinitely for data
[ https://issues.apache.org/jira/browse/JAMES-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13503194#comment-13503194 ] Eric Charles commented on JAMES-1436: - Hi Andrzeij, Good you can confirm the patch fixes issue you had with MSOutlook. Let's wait Samant's feedback to see if we are talking on the same issue and if the synchronization is need on methods. Thx, Eric APPEND IMAP command can result in JAMES IMAP waiting indefinitely for data -- Key: JAMES-1436 URL: https://issues.apache.org/jira/browse/JAMES-1436 Project: JAMES Server Issue Type: Bug Components: IMAPServer Affects Versions: Trunk, 3.0-beta4, 3.0-beta5 Environment: Ubuntu 12.04 x86_64 Reporter: Samant Maharaj Attachments: JAMES-1436.patch When processing an IMAP APPEND command, the Netty stack in JAMES IMAP can get into a state where the ImapRequestFrameDecoder will wait for a number message bytes that will never arrive. This has the effect of causing the IMAP client to also block indefinitely waiting for a response from the server. Root Cause: This is due to a race condition when the DelimiterBasedFrameDecoder is removed from the Netty pipeline by the ImapRequestFrameDecoder. If the DelimiterBasedFrameDecoder still contains less than one line of data in its buffer, that data will never be flushed and forwarded down the pipeline. The effect of this is that a small number of bytes, typically from the early part of the message are omitted and the final byte count does not match the value calculated from the APPEND command. This results in the APPEND command never being completely decoded and hence no append actually takes place nor does a response get sent to the client. In order to reliably trigger this bug, JAMES was configured to accept a remote debugging connection and a conditional breakpoint set at org.jboss.netty.handler.codec.frame.FrameDecoder:439. The condition was set to 'Thread.sleep(200l); false'. This results in introducing a 200ms delay on each frame decoding loop without actually hitting the breakpoint. The effect of this is to allow the threadpool running ImapRequestFrameDecoder time to consume the individual frames and remove the DelimiterBasedFrameDecoder from the pipeline. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (MAILBOX-186) Missing indices on JPA mailstore database results in poor mailbox listing as the number of messages grows
[ https://issues.apache.org/jira/browse/MAILBOX-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13503293#comment-13503293 ] Craig George commented on MAILBOX-186: -- We are using 0.4 (as part of server 3.0 beta4). PROPERTY_MSG_ID is just (part of) the index name I decided to use when applying the index to our Oracle database (given it is an index across 2 columns - MAILBOX_ID and MAIL_UID) so isn't one of the existing properties in JPAProperty. I'm not familiar with OpenJPA so unsure how to annotate the class in order to produce an index across these 2 columns - I do know in Hibernate you can use http://docs.jboss.org/hibernate/stable/annotations/api/index.html?org/hibernate/annotations/Index.html on the entity - is there something similar in OpenJPA / standard JPA? Missing indices on JPA mailstore database results in poor mailbox listing as the number of messages grows - Key: MAILBOX-186 URL: https://issues.apache.org/jira/browse/MAILBOX-186 Project: James Mailbox Issue Type: Bug Components: jpa Affects Versions: 0.4 Reporter: Craig George We have an application which queries the IMAP store of Apache James 3 in the following manner: final Message[] messages = this.folder.getMessages(); final FetchProfile fetchProfile = new FetchProfile(); fetchProfile.add(Item.ENVELOPE); fetchProfile.add(Item.FLAGS); fetchProfile.add(Item.CONTENT_INFO); fetchProfile.add(IMAPFolder.FetchProfileItem.HEADERS); fetchProfile.add(IMAPFolder.FetchProfileItem.SIZE); fetchProfile.add(UIDFolder.FetchProfileItem.UID); this.folder.fetch(messages, fetchProfile); When this query is performed on a folder with a large number of messages the response times degrade very quickly. This is due to the following query being run *for each* message: SELECT t0.PROPERTY_ID, t0.PROPERTY_LINE_NUMBER, t0.PROPERTY_LOCAL_NAME, t0.PROPERTY_NAME_SPACE, t0.PROPERTY_VALUE FROM MA_DIRECT_APACHE_JAMES.JAMES_MAIL_PROPERTY t0 WHERE t0.MAILBOX_ID = :1 AND t0.MAIL_UID = :2 ORDER BY t0.PROPERTY_LINE_NUMBER ASC The problem is that in the JAMES_MAIL_PROPERTY table only the PROPERTY_LINE_ID column is indexed, implicity by virtue of the fact that it is the primary key. The workaround is to add the following indexes on the table: CREATE INDEX I_JMS_MIL_PROPERTY_MSG_ID ON JAMES_MAIL_PROPERTY (MAILBOX_ID, MAIL_UID); CREATE INDEX I_JMS_MIL_PROPERTY_LINE_NUMBER ON JAMES_MAIL_PROPERTY (PROPERTY_LINE_NUMBER); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Updated] (PROTOCOLS-98) Decouple POP3 UID forming logic from protocol implementation
[ https://issues.apache.org/jira/browse/PROTOCOLS-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rustam Aliyev updated PROTOCOLS-98: --- Attachment: protocols98.patch Hi Eric, attached, see protocols98.patch Decouple POP3 UID forming logic from protocol implementation Key: PROTOCOLS-98 URL: https://issues.apache.org/jira/browse/PROTOCOLS-98 Project: JAMES Protocols Issue Type: Improvement Components: pop3 Affects Versions: 1.6.1 Reporter: Rustam Aliyev Assignee: Norman Maurer Fix For: 1.6.2 Attachments: protocols98.patch Currently, it seems that UID string formation logic is hardcoded into POP3 protocol. For example, UidlCmdHandler in a number of places forms UID using Long field from MessageMetaData. However, RFC1939 defined UID as an arbitrary server-determined string, consisting of one to 70 characters in the range 0x21 to 0x7E (http://tools.ietf.org/html/rfc1939#page-12). POP3 protocol implementation should be able to specify arbitrary UID String as a part of MessageMetaData alongside with Size. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
svn commit: r1412832 - /james/current/pom.xml
Author: eric Date: Fri Nov 23 11:23:46 2012 New Revision: 1412832 URL: http://svn.apache.org/viewvc?rev=1412832view=rev Log: imap project is no more a subproject, remove it from the current pom.xml Modified: james/current/pom.xml Modified: james/current/pom.xml URL: http://svn.apache.org/viewvc/james/current/pom.xml?rev=1412832r1=1412831r2=1412832view=diff == --- james/current/pom.xml (original) +++ james/current/pom.xml Fri Nov 23 11:23:46 2012 @@ -35,7 +35,6 @@ modulemailbox/module modulemailbox-integration-tester/module moduleprotocols/module -moduleimap/module modulehupa/module modulejdkim/module modulejspf/module - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
