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

Fabio Berchtold updated CAMEL-5459:
-----------------------------------

    Description: 
When using a MailConsumer connected with IMAP to a mailserver and routing the 
messages to SEDA or any other asynchronous endpoint, 
it can cause a com.sun.mail.util.FolderClosedIOException or 
javax.mail.FolderClosedException to happen if you are trying to process the 
mails/messages attachments.

This is because the IMAP folder gets closed at the end of each 
MailConsumer.poll()
I propose to add a new MailConfiguration option "closeFolder", which can 
override this behaviour.


Here's an example on how to reproduce the problem. (Scala code, sorry! But it 
should be self-explanatory)
You need a couple of mails with attachments in your mailbox to test this. 
~10 mails should be enough to cause the exceptions.



import javax.mail.internet.MimeMultipart
import org.apache.camel.impl.DefaultCamelContext
import org.apache.camel.scala.dsl.builder.RouteBuilder
import scala.io.Source

object Main { 
  def main(args: Array[String]): Unit = {
    val camelContext = new DefaultCamelContext
  
    val host = "imap.gmail.com"
    val username = "*****@gmail.com"
    val password = "*****"
    
    // this will cause com.sun.mail.util.FolderClosedIOException or 
javax.mail.FolderClosedException
    val endpoint = 
"imaps://"+host+"?password="+password+"&username="+username+"&folderName=INBOX&unseen=false&disconnect=false&mapMailMessage=true&connectionTimeout=60000"
    
    // with fix / new feature 'closeFolder' set to false
    //val endpoint = 
"imaps://"+host+"?password="+password+"&username="+username+"&folderName=INBOX&unseen=false&disconnect=false&mapMailMessage=true&connectionTimeout=60000&closeFolder=false"
    
    camelContext.addRoutes(
      new RouteBuilder {
        endpoint
        .to("seda:process")
         
        from("seda:process?concurrentConsumers=5") ==> {
          process { ex => 
            val att = 
ex.getIn.getBody.asInstanceOf[MimeMultipart].getBodyPart(1)
            println("Attachment Name:" + att.getFileName)
            println("Attachment Content:" + att.getDataHandler.getContent)
            println("Attachment Content:" + 
Source.fromInputStream(att.getDataHandler.getInputStream).mkString)
            Thread.sleep(2500) // simulate some work being done here with the 
attachment, takes time..
          }
        }
      }
    )

    camelContext.start()
    Thread.sleep(45 * 1000)
    camelContext.stop()
  }
}


  was:
When using a MailConsumer connected with IMAP to a mailserver and routing the 
messages to SEDA or any other asynchronous endpoint, 
it can cause a com.sun.mail.util.FolderClosedIOException or 
javax.mail.FolderClosedException to happen if you are trying to process the 
mails/messages attachments.

This is because the IMAP folder gets closed at the end of each 
MailConsumer.poll()
I propose to add a new MailConfiguration option "closeFolder", which can 
override this behaviour.


Here's an example on how to reproduce the problem. (Scala code, sorry! But it 
should be self-explanatory)
You need a couple of mails with attachments in your mailbox to test this. 
~10 mails should be enough to cause the exceptions.


import javax.mail.internet.MimeMultipart
import org.apache.camel.impl.DefaultCamelContext
import org.apache.camel.scala.dsl.builder.RouteBuilder
import scala.io.Source

object Main { 
  def main(args: Array[String]): Unit = {
    val camelContext = new DefaultCamelContext
  
    val host = "imap.gmail.com"
    val username = "*****@gmail.com"
    val password = "*****"
    
    // this will cause com.sun.mail.util.FolderClosedIOException or 
javax.mail.FolderClosedException
    val endpoint = 
"imaps://"+host+"?password="+password+"&username="+username+"&folderName=INBOX&unseen=false&disconnect=false&mapMailMessage=true&connectionTimeout=60000"
    
    // with fix / new feature 'closeFolder' set to false
    //val endpoint = 
"imaps://"+host+"?password="+password+"&username="+username+"&folderName=INBOX&unseen=false&disconnect=false&mapMailMessage=true&connectionTimeout=60000&closeFolder=false"
    
    camelContext.addRoutes(
      new RouteBuilder {
        endpoint
        .to("seda:process")
         
        from("seda:process?concurrentConsumers=5") ==> {
          process { ex => 
            val att = 
ex.getIn.getBody.asInstanceOf[MimeMultipart].getBodyPart(1)
            println("Attachment Name:" + att.getFileName)
            println("Attachment Content:" + att.getDataHandler.getContent)
            println("Attachment Content:" + 
Source.fromInputStream(att.getDataHandler.getInputStream).mkString)
            Thread.sleep(2500) // simulate some work being done here with the 
attachment, takes time..
          }
        }
      }
    )

    camelContext.start()
    Thread.sleep(45 * 1000)
    camelContext.stop()
  }
}


    
> Folder closed too early when working asynchronously
> ---------------------------------------------------
>
>                 Key: CAMEL-5459
>                 URL: https://issues.apache.org/jira/browse/CAMEL-5459
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-mail
>    Affects Versions: 2.10.0
>         Environment: IMAP connection to mailserver
>            Reporter: Fabio Berchtold
>            Priority: Minor
>              Labels: patch
>         Attachments: camel-mail-closeFolder.patch
>
>
> When using a MailConsumer connected with IMAP to a mailserver and routing the 
> messages to SEDA or any other asynchronous endpoint, 
> it can cause a com.sun.mail.util.FolderClosedIOException or 
> javax.mail.FolderClosedException to happen if you are trying to process the 
> mails/messages attachments.
> This is because the IMAP folder gets closed at the end of each 
> MailConsumer.poll()
> I propose to add a new MailConfiguration option "closeFolder", which can 
> override this behaviour.
> Here's an example on how to reproduce the problem. (Scala code, sorry! But it 
> should be self-explanatory)
> You need a couple of mails with attachments in your mailbox to test this. 
> ~10 mails should be enough to cause the exceptions.
> import javax.mail.internet.MimeMultipart
> import org.apache.camel.impl.DefaultCamelContext
> import org.apache.camel.scala.dsl.builder.RouteBuilder
> import scala.io.Source
> object Main { 
>   def main(args: Array[String]): Unit = {
>     val camelContext = new DefaultCamelContext
>   
>     val host = "imap.gmail.com"
>     val username = "*****@gmail.com"
>     val password = "*****"
>     
>     // this will cause com.sun.mail.util.FolderClosedIOException or 
> javax.mail.FolderClosedException
>     val endpoint = 
> "imaps://"+host+"?password="+password+"&username="+username+"&folderName=INBOX&unseen=false&disconnect=false&mapMailMessage=true&connectionTimeout=60000"
>     
>     // with fix / new feature 'closeFolder' set to false
>     //val endpoint = 
> "imaps://"+host+"?password="+password+"&username="+username+"&folderName=INBOX&unseen=false&disconnect=false&mapMailMessage=true&connectionTimeout=60000&closeFolder=false"
>     
>     camelContext.addRoutes(
>       new RouteBuilder {
>         endpoint
>         .to("seda:process")
>          
>         from("seda:process?concurrentConsumers=5") ==> {
>           process { ex => 
>             val att = 
> ex.getIn.getBody.asInstanceOf[MimeMultipart].getBodyPart(1)
>             println("Attachment Name:" + att.getFileName)
>             println("Attachment Content:" + att.getDataHandler.getContent)
>             println("Attachment Content:" + 
> Source.fromInputStream(att.getDataHandler.getInputStream).mkString)
>             Thread.sleep(2500) // simulate some work being done here with the 
> attachment, takes time..
>           }
>         }
>       }
>     )
>     camelContext.start()
>     Thread.sleep(45 * 1000)
>     camelContext.stop()
>   }
> }

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to