You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Chamikara Jayalath <ch...@gmail.com> on 2006/12/01 01:45:00 UTC
Re: [AXIS2] Proposal for saving the message context
Hi Ann,
On 11/30/06, Ann Robinson <ro...@us.ibm.com> wrote:
>
> Hi, Sanjiva,
> Thanks for the comments. I have tagged your comments with
> <sanjiva>text</sanjiva> to keep the indentation from getting too deep and
> put my responses below your comments with the tags <amr2>text</amr2>.
> Ann
>
> > <amr>
> > The save/restore of a MessageContext object hierarchy attempts to
> > reduce the duplication of parent-child objects in that MessageContext
> > object graph. The re-established MessageContext object graph keeps
> > the *Context objects to a single set and gets the Axis* objects
> > through the ConfigurationContext object associated with the AxisEngine
> > where the MessageContext was restored. So, the *Context objects are
> > unique across restored MessageContexts but the Axis* objects are
> > easily shared/re-used across restored MessageContexts. A future
> > refinement for the save/restore of the MessageContext is to find a way
> > to share *Context objects across restored MessageContexts. This is
> > actually a fairly small set of objects and involves the
> > OperationContext, ServiceContext, and ServiceGroupContext objects.
> > </amr>
>
> <sanjiva>
> Hmm. I don't think your approach will work if there's any serializable
> state the user has put into say ServiceContext and if that state gets
> modified by handlers after message reincarnation. There will be two
> different service contexts around and the "shared" value will no longer
> be shared.
> </sanjiva>
>
> <amr2>
> You have a good point. In particular, I think this would apply to
> properties that are set on the ServiceContext. I think that figuring out
> how to reconcile a restored ServiceContext with an existing ServiceContext
> would be worthwhile to add to the proposal.
> </amr2>
>
I guess this applies not only to ServiceContexts but all the contexts that
get serialized. When two messages that share some top level contexts get
serialized, two seperate instances of the same top level context will be
serialized. These two will be in two different stages. Now the problem is
how to reconstruct the system. What top level context should we choose.
This reconstruction problem was one reason for the Sandesha2 to go for a
model where the MessageContext get saved only after it goes through the full
Handler chain.
Chamikara
Re: [AXIS2] Proposal for saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Matt,
On 12/1/06, Matthew Lovett <ML...@uk.ibm.com> wrote:
>
> Hi all,
>
> Just a quick response to Chamikara's comments:
>
> "Chamikara Jayalath" <ch...@gmail.com> wrote on 01/12/2006 00:45:00:
>
> >
> > I guess this applies not only to ServiceContexts but all the
> > contexts that get serialized. When two messages that share some top
> > level contexts get serialized, two seperate instances of the same
> > top level context will be serialized. These two will be in two
> > different stages. Now the problem is how to reconstruct the system.
> > What top level context should we choose.
> >
> > This reconstruction problem was one reason for the Sandesha2 to go
> > for a model where the MessageContext get saved only after it goes
> > through the full Handler chain.
> >
>
> Well, yes, but the current Sandesha approach has it's own issues too. I
> think that this proposal gives us an alternative, and we should get it
> into axis2 so that we can see what it enables in Sandesha. There is no
> problem with having 2 in-memory storage managers for a while... one that
> forces in the dummy transport and runs the message through
> 'retransmittable phases', and one that calls the serialise code.
>
> All we'd need to do is move some of the transport-changing logic from
> SandeshaUtil into something associated with the storage manager.
> StorageManager.getUtil().executeAndStore(), etc...
>
> We could also generalise the unit tests so that we try them with both
> storage managers. That's no bad thing... for a while I've wanted to be
> able to run the tests with security turned on, and the same general
> mechanism would be handy there too.
I think having two InMemory Storage Managers in the same system will make it
unnecessarily complex. All we have to do is picking up a good solution and
going for it. And I dont agree on haking the StorageManager interface to
fascilitate that.
What we should do is trying to figure out a way to reconstruct the system
correctly. That aproach should not be wasting the storage unnecessarily and
should not be putting the system into any inconsistent states. If we can
come up with a solution to this problem I am ok with going with Anns
approach. But I dont think we should change the current working code,
thinking of a solution that will be found later.
Chamikara
---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
Re: [AXIS2] Proposal for saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Matt,
On 12/1/06, Matthew Lovett <ML...@uk.ibm.com> wrote:
>
> Hi all,
>
> Just a quick response to Chamikara's comments:
>
> "Chamikara Jayalath" <ch...@gmail.com> wrote on 01/12/2006 00:45:00:
>
> >
> > I guess this applies not only to ServiceContexts but all the
> > contexts that get serialized. When two messages that share some top
> > level contexts get serialized, two seperate instances of the same
> > top level context will be serialized. These two will be in two
> > different stages. Now the problem is how to reconstruct the system.
> > What top level context should we choose.
> >
> > This reconstruction problem was one reason for the Sandesha2 to go
> > for a model where the MessageContext get saved only after it goes
> > through the full Handler chain.
> >
>
> Well, yes, but the current Sandesha approach has it's own issues too. I
> think that this proposal gives us an alternative, and we should get it
> into axis2 so that we can see what it enables in Sandesha. There is no
> problem with having 2 in-memory storage managers for a while... one that
> forces in the dummy transport and runs the message through
> 'retransmittable phases', and one that calls the serialise code.
>
> All we'd need to do is move some of the transport-changing logic from
> SandeshaUtil into something associated with the storage manager.
> StorageManager.getUtil().executeAndStore(), etc...
>
> We could also generalise the unit tests so that we try them with both
> storage managers. That's no bad thing... for a while I've wanted to be
> able to run the tests with security turned on, and the same general
> mechanism would be handy there too.
I think having two InMemory Storage Managers in the same system will make it
unnecessarily complex. All we have to do is picking up a good solution and
going for it. And I dont agree on haking the StorageManager interface to
fascilitate that.
What we should do is trying to figure out a way to reconstruct the system
correctly. That aproach should not be wasting the storage unnecessarily and
should not be putting the system into any inconsistent states. If we can
come up with a solution to this problem I am ok with going with Anns
approach. But I dont think we should change the current working code,
thinking of a solution that will be found later.
Chamikara
---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
Re: [AXIS2] Proposal for saving the message context
Posted by Chamikara Jayalath <ch...@gmail.com>.
Hi Matt,
On 12/1/06, Matthew Lovett <ML...@uk.ibm.com> wrote:
>
> Hi all,
>
> Just a quick response to Chamikara's comments:
>
> "Chamikara Jayalath" <ch...@gmail.com> wrote on 01/12/2006 00:45:00:
>
> >
> > I guess this applies not only to ServiceContexts but all the
> > contexts that get serialized. When two messages that share some top
> > level contexts get serialized, two seperate instances of the same
> > top level context will be serialized. These two will be in two
> > different stages. Now the problem is how to reconstruct the system.
> > What top level context should we choose.
> >
> > This reconstruction problem was one reason for the Sandesha2 to go
> > for a model where the MessageContext get saved only after it goes
> > through the full Handler chain.
> >
>
> Well, yes, but the current Sandesha approach has it's own issues too. I
> think that this proposal gives us an alternative, and we should get it
> into axis2 so that we can see what it enables in Sandesha. There is no
> problem with having 2 in-memory storage managers for a while... one that
> forces in the dummy transport and runs the message through
> 'retransmittable phases', and one that calls the serialise code.
>
> All we'd need to do is move some of the transport-changing logic from
> SandeshaUtil into something associated with the storage manager.
> StorageManager.getUtil().executeAndStore(), etc...
>
> We could also generalise the unit tests so that we try them with both
> storage managers. That's no bad thing... for a while I've wanted to be
> able to run the tests with security turned on, and the same general
> mechanism would be handy there too.
I think having two InMemory Storage Managers in the same system will make it
unnecessarily complex. All we have to do is picking up a good solution and
going for it. And I dont agree on haking the StorageManager interface to
fascilitate that.
What we should do is trying to figure out a way to reconstruct the system
correctly. That aproach should not be wasting the storage unnecessarily and
should not be putting the system into any inconsistent states. If we can
come up with a solution to this problem I am ok with going with Anns
approach. But I dont think we should change the current working code,
thinking of a solution that will be found later.
Chamikara
---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
Re: [AXIS2] Proposal for saving the message context
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Fri, 2006-12-01 at 10:34 +0000, Matthew Lovett wrote:
> Well, yes, but the current Sandesha approach has it's own issues too. I
> think that this proposal gives us an alternative, and we should get it
> into axis2 so that we can see what it enables in Sandesha. There is no
> problem with having 2 in-memory storage managers for a while... one that
> forces in the dummy transport and runs the message through
> 'retransmittable phases', and one that calls the serialise code.
>
> All we'd need to do is move some of the transport-changing logic from
> SandeshaUtil into something associated with the storage manager.
> StorageManager.getUtil().executeAndStore(), etc...
>
> We could also generalise the unit tests so that we try them with both
> storage managers. That's no bad thing... for a while I've wanted to be
> able to run the tests with security turned on, and the same general
> mechanism would be handy there too.
My concerns have nothing to do with Sandesha- the code that's proposed
for Axis2 doesn't work as advertised because it reconstructs the system
in an inconsistent state.
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Fri, 2006-12-01 at 10:34 +0000, Matthew Lovett wrote:
> Well, yes, but the current Sandesha approach has it's own issues too. I
> think that this proposal gives us an alternative, and we should get it
> into axis2 so that we can see what it enables in Sandesha. There is no
> problem with having 2 in-memory storage managers for a while... one that
> forces in the dummy transport and runs the message through
> 'retransmittable phases', and one that calls the serialise code.
>
> All we'd need to do is move some of the transport-changing logic from
> SandeshaUtil into something associated with the storage manager.
> StorageManager.getUtil().executeAndStore(), etc...
>
> We could also generalise the unit tests so that we try them with both
> storage managers. That's no bad thing... for a while I've wanted to be
> able to run the tests with security turned on, and the same general
> mechanism would be handy there too.
My concerns have nothing to do with Sandesha- the code that's proposed
for Axis2 doesn't work as advertised because it reconstructs the system
in an inconsistent state.
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Fri, 2006-12-01 at 10:34 +0000, Matthew Lovett wrote:
> Well, yes, but the current Sandesha approach has it's own issues too. I
> think that this proposal gives us an alternative, and we should get it
> into axis2 so that we can see what it enables in Sandesha. There is no
> problem with having 2 in-memory storage managers for a while... one that
> forces in the dummy transport and runs the message through
> 'retransmittable phases', and one that calls the serialise code.
>
> All we'd need to do is move some of the transport-changing logic from
> SandeshaUtil into something associated with the storage manager.
> StorageManager.getUtil().executeAndStore(), etc...
>
> We could also generalise the unit tests so that we try them with both
> storage managers. That's no bad thing... for a while I've wanted to be
> able to run the tests with security turned on, and the same general
> mechanism would be handy there too.
My concerns have nothing to do with Sandesha- the code that's proposed
for Axis2 doesn't work as advertised because it reconstructs the system
in an inconsistent state.
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Matthew Lovett <ML...@uk.ibm.com>.
Hi all,
Just a quick response to Chamikara's comments:
"Chamikara Jayalath" <ch...@gmail.com> wrote on 01/12/2006 00:45:00:
>
> I guess this applies not only to ServiceContexts but all the
> contexts that get serialized. When two messages that share some top
> level contexts get serialized, two seperate instances of the same
> top level context will be serialized. These two will be in two
> different stages. Now the problem is how to reconstruct the system.
> What top level context should we choose.
>
> This reconstruction problem was one reason for the Sandesha2 to go
> for a model where the MessageContext get saved only after it goes
> through the full Handler chain.
>
Well, yes, but the current Sandesha approach has it's own issues too. I
think that this proposal gives us an alternative, and we should get it
into axis2 so that we can see what it enables in Sandesha. There is no
problem with having 2 in-memory storage managers for a while... one that
forces in the dummy transport and runs the message through
'retransmittable phases', and one that calls the serialise code.
All we'd need to do is move some of the transport-changing logic from
SandeshaUtil into something associated with the storage manager.
StorageManager.getUtil().executeAndStore(), etc...
We could also generalise the unit tests so that we try them with both
storage managers. That's no bad thing... for a while I've wanted to be
able to run the tests with security turned on, and the same general
mechanism would be handy there too.
Thanks
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Matthew Lovett <ML...@uk.ibm.com>.
Hi all,
Just a quick response to Chamikara's comments:
"Chamikara Jayalath" <ch...@gmail.com> wrote on 01/12/2006 00:45:00:
>
> I guess this applies not only to ServiceContexts but all the
> contexts that get serialized. When two messages that share some top
> level contexts get serialized, two seperate instances of the same
> top level context will be serialized. These two will be in two
> different stages. Now the problem is how to reconstruct the system.
> What top level context should we choose.
>
> This reconstruction problem was one reason for the Sandesha2 to go
> for a model where the MessageContext get saved only after it goes
> through the full Handler chain.
>
Well, yes, but the current Sandesha approach has it's own issues too. I
think that this proposal gives us an alternative, and we should get it
into axis2 so that we can see what it enables in Sandesha. There is no
problem with having 2 in-memory storage managers for a while... one that
forces in the dummy transport and runs the message through
'retransmittable phases', and one that calls the serialise code.
All we'd need to do is move some of the transport-changing logic from
SandeshaUtil into something associated with the storage manager.
StorageManager.getUtil().executeAndStore(), etc...
We could also generalise the unit tests so that we try them with both
storage managers. That's no bad thing... for a while I've wanted to be
able to run the tests with security turned on, and the same general
mechanism would be handy there too.
Thanks
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Re: [AXIS2] Proposal for saving the message context
Posted by Matthew Lovett <ML...@uk.ibm.com>.
Hi all,
Just a quick response to Chamikara's comments:
"Chamikara Jayalath" <ch...@gmail.com> wrote on 01/12/2006 00:45:00:
>
> I guess this applies not only to ServiceContexts but all the
> contexts that get serialized. When two messages that share some top
> level contexts get serialized, two seperate instances of the same
> top level context will be serialized. These two will be in two
> different stages. Now the problem is how to reconstruct the system.
> What top level context should we choose.
>
> This reconstruction problem was one reason for the Sandesha2 to go
> for a model where the MessageContext get saved only after it goes
> through the full Handler chain.
>
Well, yes, but the current Sandesha approach has it's own issues too. I
think that this proposal gives us an alternative, and we should get it
into axis2 so that we can see what it enables in Sandesha. There is no
problem with having 2 in-memory storage managers for a while... one that
forces in the dummy transport and runs the message through
'retransmittable phases', and one that calls the serialise code.
All we'd need to do is move some of the transport-changing logic from
SandeshaUtil into something associated with the storage manager.
StorageManager.getUtil().executeAndStore(), etc...
We could also generalise the unit tests so that we try them with both
storage managers. That's no bad thing... for a while I've wanted to be
able to run the tests with security turned on, and the same general
mechanism would be handy there too.
Thanks
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org