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]
