Hi Andy,
On 12/18/06, Andrew K Gatford <[EMAIL PROTECTED]> wrote:
Hi Chamikara,
There are several reasons for moving the sender/invoker to the storage
manager:
1) I've not actually changed any of the Sender/Invoker impl code, and in
most cases the storage manager can just new up and return the Sender and
Invoker inside the Sandesha code. This means that for storage managers
which require the defaults then they can just new and return the existing
Sender and Invoker code.
Ok. Only the problem I had was the need to do this extra bit of work.
2) If there are multiple configuration contexts - there will be multiple
Sender instances. This means that if there is a singleton storage manager
shared between these instances, then there will be multiple Sender threads
servicing the same underlying storage and Sending the same messages as the
work lock is only held for the Sender.
3) Also by moving the Sender/Invoker to the StorageManager allows for the
creation of a Sender and Invoker which may be specific to the particular
storage manager. Although the storage interface is generic and would work
with any storage manager, there are cases where knowing the implementation
of the storage manager can mean that there are more optimal ways of
retrieving the RM data.
4) Potential class loading issues. If there are several classloaders
present inside an application server where the system classloader loads
the
Axis2 and the Sandesha classes. There is then an application classloader
which loads the application code and threads which are then used by this
application will use an application classloader. This means that when a
new Sender is created, the class loader for the application will be used
by
this Sender thread. When this "Sender" actually attempts to do some work,
the Thread may not have the privileges to actually send the message
outbound.
I agree with these points. Thanks for the clarification.
On a different topic, now that we have an RMS and RMD Bean which in theory
contain the properties for a sequence, is it worth starting to move some
of
these properties to these beans?
Good idea.
Chamikara
Andrew Gatford
Hursley MP211
Telephone :
Internal (7) 245743
External 01962 815743
Internet : [EMAIL PROTECTED]
"Chamikara
Jayalath (JIRA)"
<[EMAIL PROTECTED]> To
[email protected]
18/12/2006 03:13 cc
Subject
[jira] Commented: (SANDESHA2-61)
share logic between sender and
invoker
[
http://issues.apache.org/jira/browse/SANDESHA2-61?page=comments#action_12459171
]
Chamikara Jayalath commented on SANDESHA2-61:
---------------------------------------------
Hi Andy,
Sorry I missed a part of this. What is the reason for moving the Sender
and
Invoker to the InMemoryStorageManaer. These two are not a part of the
storage and should work with any storage impl. I think these better be out
of the Storage.
Chamikara
> share logic between sender and invoker
> --------------------------------------
>
> Key: SANDESHA2-61
> URL: http://issues.apache.org/jira/browse/SANDESHA2-61
> Project: Apache Sandesha2
> Issue Type: Bug
> Reporter: Thomas McKiernan
> Priority: Minor
> Attachments: senderInvoker.patch, senderInvoker.patch,
senderInvoker2.patch
>
>
> There is much logic that is common to both sender and invoker threads.
It
would be good if this could be aggregated into a single place.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
