You are viewing a plain text version of this content. The canonical link for it is here.
Posted to sandesha-dev@ws.apache.org by "Damitha Kumarage (JIRA)" <ji...@apache.org> on 2008/06/22 06:37:45 UTC
[jira] Created: (SANDESHA2C-52) Improvements in the branch
https://svn.apache.org/repos/asf/webservices/sandesha/tags/sandesha2/c/worker_thread_removed-23may2008
Improvements in the branch https://svn.apache.org/repos/asf/webservices/sandesha/tags/sandesha2/c/worker_thread_removed-23may2008
---------------------------------------------------------------------------------------------------------------------------------
Key: SANDESHA2C-52
URL: https://issues.apache.org/jira/browse/SANDESHA2C-52
Project: Sandesha2/C
Issue Type: Improvement
Reporter: Damitha Kumarage
Assignee: Damitha Kumarage
I have done significant changes to the Sandesha2/C code base in the branch
https://svn.apache.org/repos/asf/webservices/sandesha/tags/sandesha2/c/worker_thread_removed-23may2008
The intention is
1. To make it very stable/reliable as expected from a reliable messaging implementation.
2. To minimize the additional overhead added when messages are sent reliably.
3. To improve the performance.
4. To fix the memory leaks.
To achieve the above goals I have worked on the following.
1. In single channel one/two way scenario's completely avoid using Sandesha2/C specfic threads to send
messages. Instead send the messages in the same thread as the thread that invoked the Sandesha2/C handler.
Let me explain this in more detail. Suppose that application client send an application message that
need to be sent reliably. When this hit the Sandesha2/C out handler in the client side what it
do is prepare a Sandesha2/C specific create sequence message(CS) and send it to the server in the same
thread. Now it block for specified amount of time until a create sequence response(CSR) arrive.
If necessary it resend the CS as specified in the configuration.
Once the CSR arrives it sends the held in application message to the server. Then it blocks until a
application response message arrives for a specified amount of time and do resends if neccessary as
specified in the configuration.
In dual channel scenario it is not possible to completely get rid of the Sandesha2/C specific threads.
However in all happy scenario where there is no network/server crash it does not use any Sandesha2/C
specific threads avoiding any complexity. However if there needs resends then those resends are done
in a Sandesha2/C specific thread.
2. In single channel one/two way scenario always piggyback the acknowledgment messages on application/terminate
messages. This minimize the RM specific messages only to CS/CSR and Terminate messages.
3. Reducing the complexity which resulted in more clean environment.
These measures has resulted in vast improvements over the existing Sandesha2/C. In addition all the changes
are purely implementational. There is no API changes, no configuration changes.
Also currently only RM 1.0 single channel one/two way is completed which means it is ready for scripting languages.
I have tested it with 100 messages in a sequence in Linux platform successfully.
--
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: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
[jira] Closed: (SANDESHA2C-52) Improvements in the branch
https://svn.apache.org/repos/asf/webservices/sandesha/tags/sandesha2/c/worker_thread_removed-23may2008
Posted by "Damitha Kumarage (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SANDESHA2C-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Damitha Kumarage closed SANDESHA2C-52.
--------------------------------------
Resolution: Fixed
This branch is now merged into the trunk.
> Improvements in the branch https://svn.apache.org/repos/asf/webservices/sandesha/tags/sandesha2/c/worker_thread_removed-23may2008
> ---------------------------------------------------------------------------------------------------------------------------------
>
> Key: SANDESHA2C-52
> URL: https://issues.apache.org/jira/browse/SANDESHA2C-52
> Project: Sandesha2/C
> Issue Type: Improvement
> Reporter: Damitha Kumarage
> Assignee: Damitha Kumarage
>
> I have done significant changes to the Sandesha2/C code base in the branch
> https://svn.apache.org/repos/asf/webservices/sandesha/tags/sandesha2/c/worker_thread_removed-23may2008
> The intention is
> 1. To make it very stable/reliable as expected from a reliable messaging implementation.
> 2. To minimize the additional overhead added when messages are sent reliably.
> 3. To improve the performance.
> 4. To fix the memory leaks.
> To achieve the above goals I have worked on the following.
> 1. In single channel one/two way scenario's completely avoid using Sandesha2/C specfic threads to send
> messages. Instead send the messages in the same thread as the thread that invoked the Sandesha2/C handler.
> Let me explain this in more detail. Suppose that application client send an application message that
> need to be sent reliably. When this hit the Sandesha2/C out handler in the client side what it
> do is prepare a Sandesha2/C specific create sequence message(CS) and send it to the server in the same
> thread. Now it block for specified amount of time until a create sequence response(CSR) arrive.
> If necessary it resend the CS as specified in the configuration.
> Once the CSR arrives it sends the held in application message to the server. Then it blocks until a
> application response message arrives for a specified amount of time and do resends if neccessary as
> specified in the configuration.
> In dual channel scenario it is not possible to completely get rid of the Sandesha2/C specific threads.
> However in all happy scenario where there is no network/server crash it does not use any Sandesha2/C
> specific threads avoiding any complexity. However if there needs resends then those resends are done
> in a Sandesha2/C specific thread.
> 2. In single channel one/two way scenario always piggyback the acknowledgment messages on application/terminate
> messages. This minimize the RM specific messages only to CS/CSR and Terminate messages.
> 3. Reducing the complexity which resulted in more clean environment.
> These measures has resulted in vast improvements over the existing Sandesha2/C. In addition all the changes
> are purely implementational. There is no API changes, no configuration changes.
> Also currently only RM 1.0 single channel one/two way is completed which means it is ready for scripting languages.
> I have tested it with 100 messages in a sequence in Linux platform successfully.
--
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: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org