[
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.
