[ 
https://issues.apache.org/jira/browse/WSCOMMONS-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689093#action_12689093
 ] 

Andreas Veithen commented on WSCOMMONS-454:
-------------------------------------------

I think that for most use cases it is OK not to start a new poll before all 
messages in the current poll have been processed. However there is value in 
enhancing the POP3/IMAP transport listener to allow processing of these 
messages in parallel (as I suggested in SYNAPSE-434). I really mean concurrent 
processing here, and not concurrent polls or concurrent downloading.

For the RM use case, I have some doubts that people really want to do RM over 
POP3/IMAP and I would suggest a completely different approach, which is to 
implement an SMTP transport listener. To me, this would make much more sense 
because such a transport would not use polling but be able to accept messages 
as they arrive. Probably it would even be easier to implement this SMTP 
transport from scratch than to sort out all the possible concurrency issues 
that may arise in the POP3/IMAP transport. I remember that there has been a 
discussion between Paul and me where we identified at least two Java 
implementations of the SMTP protocol that could be used for this.

> SMTP transport can receive more than one message at same time
> -------------------------------------------------------------
>
>                 Key: WSCOMMONS-454
>                 URL: https://issues.apache.org/jira/browse/WSCOMMONS-454
>             Project: WS-Commons
>          Issue Type: Bug
>            Reporter: Amila Chinthaka Suriarachchi
>            Assignee: Asankha C. Perera
>            Priority: Blocker
>
> hi all,
> recently I started some RM tests with the commons mail transport.
> Mail transport listener runs in a timer task.
> TimerTask timerTask = new TimerTask() {
>             @Override
>             public void run() {
>                  workerPool.execute(new Runnable() {
>                     public void run() {
>                          if (state == BaseConstants.PAUSED) {
>                             if (log.isDebugEnabled()) {
>                                 log.debug("Transport " + getTransportName() +
>                                         " poll trigger : Transport is 
> currently paused..");
>                             }
>                         } else {
>                             poll(entry);
>                         }
>                         synchronized (entry) {
>                             if (!entry.canceled) {
>                                 schedulePoll(entry, pollInterval);
>                             }
>                         }
>                     }
>                 });
>             }
>         };
>         entry.timerTask = timerTask;
>         timer.schedule(timerTask, pollInterval)
> As I saw timer task only  re activates only after  earlier invocation finish. 
> i.e  after completing the message.
> In RM inorder delivery case lets say we receive message number 2 before 1. 
> then the initial thread does not return and
> it can not receive the message number 1.
> I tested this this the following sample.
> TimerTask timerTask = new TimerTask(){
>             public void run() {
>                 System.out.println("In the timer task");
>                 try {
>                     Thread.sleep(60000);
>                 } catch (InterruptedException e) {
>                     e.printStackTrace();  //To change body of catch statement 
> use File | Settings | File Templates.
>                 }
>                 System.out.println("Going out of timer task");
>             }
>         };
>         Timer timer = new Timer("Testtimer");
>         timer.schedule(timerTask,0, 1000);
> And I saw timer task does not run until it finishes the first task.
> Can we start a new thread to each new message? That is how earlier SMTP 
> transport had done that.

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

Reply via email to