[jira] Commented: (SYNAPSE-434) Concurrency level provided by the mail and VFS transports listeners is insufficient
[
https://issues.apache.org/jira/browse/SYNAPSE-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688103#action_12688103
]
Amila Chinthaka Suriarachchi commented on SYNAPSE-434:
--
I have also seen this same issue and it is a serious problem for RM synchronize
invocations.
In the earlier Axis2 SMTP transport it also polls the SMTP server using one
thread. But after creating the message context it starts a new thread to send
it through the Axis Engine.
synchronized (receiver) {
receiver.connect();
Message[] msgs = receiver.receiveMessages();
if ((msgs != null) && (msgs.length > 0)) {
log.info(msgs.length + " Message(s) Found");
for (int i = 0; i < msgs.length; i++) {
MimeMessage msg = (MimeMessage) msgs[i];
try {
MessageContext mc =
createMessageContextToMailWorker(msg);
msg.setFlag(Flags.Flag.DELETED, true);
if(mc==null){
continue;
}
MailWorker worker = new
MailWorker(configurationContext,mc);
this.configurationContext.getThreadPool().execute(worker);
} catch (Exception e) {
log.error("Error in SimpleMailListener -
processing mail", e);
} finally {
// delete mail in any case
}
}
}
receiver.disconnect();
}
Can't we do the same thing here as well.
thanks,
Amila.
> Concurrency level provided by the mail and VFS transports listeners is
> insufficient
> ---
>
> Key: SYNAPSE-434
> URL: https://issues.apache.org/jira/browse/SYNAPSE-434
> Project: Synapse
> Issue Type: Bug
> Components: Transports
>Affects Versions: 1.2
>Reporter: Andreas Veithen
>Assignee: Andreas Veithen
>Priority: Minor
>
> Scenario:
> * Two services are configured to use the (mail or VFS) transport.
> * Two messages are sent two each of these services.
> In this case, one would expect that the transport listener will be able to
> process at least 2 (better 4) messages concurrently. However the listener
> currently only processes one message at a time, i.e. the listener behaves as
> if it was single-threaded.
> There are two reasons for this:
> 1. AbstractPollingTransportListener contains the following code:
> workerPool.execute(new Runnable() {
> public void run() {
> synchronized (pollLock) {
> pollInProgress = true;
> try {
> onPoll();
> } finally {
> pollInProgress = false;
> }
> }
> }
> });
> Since pollLock is a member of AbstractPollingTransportListener, there can
> only be one poll in progress at a time, even if several services are
> configured to use the transport (in which case nothing would prevent the
> transport from executing the polls for the different services in parallel).
> 2. Both MailTransportListener and VFSTransportListener process incoming
> messages sequentially. Here again, the transport could process several
> messages in parallel during the execution of the onPoll method.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org
[jira] Commented: (SYNAPSE-434) Concurrency level provided by the mail and VFS transports listeners is insufficient
[
https://issues.apache.org/jira/browse/SYNAPSE-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12688011#action_12688011
]
Andreas Veithen commented on SYNAPSE-434:
-
Of course we need to avoid to process the same message twice. This can be
achieved if me make sure that for a given service, a new poll is only scheduled
when the current poll is completed. For the moment the mail and VFS transports
work as follows:
1. Start poll (open mail folder and read message list; read directory).
2. Sequentially process each message.
3. Schedule the next poll.
The idea is to change that (as an option) to:
1. Start poll
2. Process the messages in parallel (with a configurable level of concurrency)
3. Wait until all messages have been processed and schedule the next poll.
Note that this solution probably doesn't provide enough concurrency for what is
requested in the linked issue WSCOMMONS-454.
> Concurrency level provided by the mail and VFS transports listeners is
> insufficient
> ---
>
> Key: SYNAPSE-434
> URL: https://issues.apache.org/jira/browse/SYNAPSE-434
> Project: Synapse
> Issue Type: Bug
> Components: Transports
>Affects Versions: 1.2
>Reporter: Andreas Veithen
>Assignee: Andreas Veithen
>Priority: Minor
>
> Scenario:
> * Two services are configured to use the (mail or VFS) transport.
> * Two messages are sent two each of these services.
> In this case, one would expect that the transport listener will be able to
> process at least 2 (better 4) messages concurrently. However the listener
> currently only processes one message at a time, i.e. the listener behaves as
> if it was single-threaded.
> There are two reasons for this:
> 1. AbstractPollingTransportListener contains the following code:
> workerPool.execute(new Runnable() {
> public void run() {
> synchronized (pollLock) {
> pollInProgress = true;
> try {
> onPoll();
> } finally {
> pollInProgress = false;
> }
> }
> }
> });
> Since pollLock is a member of AbstractPollingTransportListener, there can
> only be one poll in progress at a time, even if several services are
> configured to use the transport (in which case nothing would prevent the
> transport from executing the polls for the different services in parallel).
> 2. Both MailTransportListener and VFSTransportListener process incoming
> messages sequentially. Here again, the transport could process several
> messages in parallel during the execution of the onPoll method.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org
Re: svn commit: r756406 - in /synapse/trunk/java/modules/experimental/src/main: java/org/apache/synapse/experimental/ resources/ resources/META-INF/ resources/META-INF/services/
On Sat, Mar 21, 2009 at 05:37, Asankha C. Perera wrote: > Hi Andreas >> >> Log: >> Added experimental mediator implementations that allow to store part of >> the message in a property (without converting it to string) and to insert an >> OM node from a property into the message, as suggested in SYNAPSE-503. >> > > This looks very useful.. shall we include them right away into the core [and > state in the documentation if required that they are experimental] ? My intention is actually to start a discussion on the mailing list to get some feedback about what are the needs and what should these mediators look like from a user perspective. Let's start a new thread on the user list for that. Andreas - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
RE: [jira] Resolved: (SYNAPSE-521) Send Synapse generated Hessian faults with HTTP status 200
Hi, It seems like we have a Jira downtime so I answer directly on the list. > Asankha C. Perera resolved SYNAPSE-521. > --- > > Resolution: Fixed > Assignee: Asankha C. Perera > > Thanks Eric for the fix. I just removed an unused constant "HTTP_SC_OK" > from the NhttpConstants Asankha, thanks for reviewing and committing and sorry about forgetting to remove the now unused constant. This has been a remaining of the alternative solution using the FaultMediator to set the HTTP 200 status code. With the latest approach it was possible to use the int constants of HttpStatus directly. Regards, Eric
