[
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
