[ https://issues.apache.org/jira/browse/WSCOMMONS-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12693618#action_12693618 ]
Andreas Veithen commented on WSCOMMONS-454: ------------------------------------------- Asankha, Your solution involves tasks (the ones responsible for polling) that add new tasks (the ones that process the messages) to the task queue and then wait for their completion. Considering that all these tasks are executed using a single thread pool and that the number of threads in this pool is bounded, how can you guarantee that the transport never gets into a state where all threads are allocated to tasks of the first kind waiting for tasks of the second kind (which can never complete because all threads are taken by tasks of the first kind)? When I started working on SYNAPSE-434 I didn't find any convincing argument showing that this could never happen, except if concurrent polls are disallowed and the size of the thread pool is at least N+1, where N is the number of services listening on the transport. Now that concurrent polls are allowed this argument breaks down too. To avoid this problem I started to implemented a different pattern (but I never completed the refactoring of AbstractPollingTransportListener), where the polling task terminates early and then let the processing tasks coordinate themselves such that the last one that completes does the cleanup job (closes the connection, etc.). Since in that approach there are no tasks waiting for other tasks to complete, it can be easily proven that no deadlock will ever occur. > 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 > Fix For: Transports 1.0 > > > 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.