You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by sa...@gte.net on 2004/08/18 03:52:20 UTC
Some Design Questions...
Hi AxisCpp folks.
I'm studying the AxisCpp code investigating the possibility
of using it in my environment. I'm hoping some of you more
experienced folks will be able to answer the following questions...
(1) Has the axis server engine accommodated the possibility
of asynchronous handlers in either the Request or Response chains?
(2) What is the plan for allowing AxisCpp integrators to plug-in
their own logging subsystem?
(3) Similarly, what is the plan for custom memory managers?
Thank you,
-Scott
PS - Related to item (3) above...I saw in your TODO list that
you would like to walk away from STL. FWIW, this is wise.
I've had to cut out all STL in my own projects because of many
leaks and inconsistencies amongst different STL implementations.
Sad, but true.
RE: Some Design Questions...
Posted by sa...@gte.net.
Hi Susantha,
> What kind of information do you want to log ?
I'll leave that up to the core engine developers. My interest is
in being able to "intercept" the logging so I can apply buffering
tactics, etc. In my environment we have a robust logging subsystem
that supports runtime filtering, splitting, and even throwing logging
messages over to a collecting log daemon. We do this for performance,
and management concerns (which are significant in my environment).
So, the run-of-the-mill file based logging is not ideal.
> > (3) Similarly, what is the plan for custom memory managers?
>
> You mean Axis code to expect an external memory management
> context which you provide when compiling Axis in your
> environment ? (Like expat do ?).
Yeah. I usually use type-specific memory pools. Allows
for significant memory management and aids debugging in many ways.
That is more important for my code than yours. So, at the very least,
what I am hoping for is the following. Some way to spin up the
AxisCpp engine and tell what function to call to allocate some chunk
of bytes, and what funtion to call to free chunks of bytes.
I'm not particular about how this is accomplished. As long as the
capability is there. So, do your worst! ;-)
Cheers,
-Scott
RE: Some Design Questions...
Posted by Susantha Kumara <su...@opensource.lk>.
Hi Scott
> -----Original Message-----
> From: saguyer@gte.net [mailto:saguyer@gte.net]
> Sent: Wednesday, August 18, 2004 7:52 AM
> To: axis-c-dev@ws.apache.org
> Subject: Some Design Questions...
>
> Hi AxisCpp folks.
>
> I'm studying the AxisCpp code investigating the possibility
> of using it in my environment. I'm hoping some of you more
> experienced folks will be able to answer the following questions...
>
> (1) Has the axis server engine accommodated the possibility
> of asynchronous handlers in either the Request or Response chains?
>
> (2) What is the plan for allowing AxisCpp integrators to plug-in
> their own logging subsystem?
What kind of information do you want to log ?
>
> (3) Similarly, what is the plan for custom memory managers?
You mean Axis code to expect an external memory management context which
you provide when compiling Axis in your environment ? (Like expat do ?).
>
>
> Thank you,
> -Scott
>
>
> PS - Related to item (3) above...I saw in your TODO list that
> you would like to walk away from STL. FWIW, this is wise.
> I've had to cut out all STL in my own projects because of many
> leaks and inconsistencies amongst different STL implementations.
> Sad, but true.
RE: Some Design Questions...
Posted by sa...@gte.net.
Hi Susantha,
> -----Original Message-----
> From: Susantha Kumara [mailto:susantha@opensource.lk]
>
> Hi Scott,
>
> IMO using an external memory management context is very
> important if Axis C++ is going to be used in portable
> devices. But in this case the memory foot print of Axis C++
> is important which is too large at the moment. What platforms
> that you think this feature will be used if provided by Axis C++ ?.
I'm thinking of UNIX servers, custom hosts. I'm not expecting
to host Axis in Apache, perhaps that is a meaningful distinction.
I'm not interested in devices, though I encourage you to keep
considering that possibility :-)
> IMO I would like to eliminate STL completely. But at the
> moment that is not the focus because there are other
> priorities like performance/code quality/features.
Fair enough, I understand.
Cheers,
-Scott
RE: Some Design Questions...
Posted by Susantha Kumara <su...@opensource.lk>.
Hi Scott,
IMO using an external memory management context is very important if
Axis C++ is going to be used in portable devices. But in this case the
memory foot print of Axis C++ is important which is too large at the
moment. What platforms that you think this feature will be used if
provided by Axis C++ ?.
IMO I would like to eliminate STL completely. But at the moment that is
not the focus because there are other priorities like performance/code
quality/features.
Your suggestions/contributions in eliminating STL/external MMContext is
warmly welcome.
Regards,
Susantha.
> -----Original Message-----
> From: saguyer@gte.net [mailto:saguyer@gte.net]
> Sent: Thursday, August 19, 2004 6:50 AM
> To: 'Apache AXIS C Developers List'
> Subject: RE: Some Design Questions...
>
>
> Thanks for the info Samisa.
>
> I see I came to the STL party late. I reviewed the
> thread on this subject. I would like to add to the
> discussion (albeit a little late).
>
> First, I think Lahiru's perspective on this is spot on.
> (message quoted below for convenience.) I only differ
> in that I don't care if the STL is exposed or hidden in
> the engine. If it is anywhere, I am concerned (reasons
> stated below).
>
>
> > I suggest eliminate stl so that it is not exposed to
> > client although it is used inside the engine. There are several
> > advantages by doing this.
> >
> > 1) Ability to support C. Other wise we need extra wrappers.
> > 2) Some times users may face portability challenges if STL is
exposed.
> > 3) It is easier to manipulate an STL string, but char* is the
standard
> > string format in C/C++. so giving char* instead of STL string, gives
the
> > user more flexibility.
> >
> > Lahiru Wimalasiri
>
>
> Second, when it comes to the STL, I'm less worried about performance
> than I am reliability. There's no secrets to these data structures.
> You can pull a book off the shelf to see how to implement them.
> I've just seen too many internal leaks from STL containers.
>
> Third, using STL complicates the matter of allowing folks to
> provide their own memory management routines. Indeed, the STL
> provides the allocator mechanism. But in my experience that
> has been the least portable aspect of the STL. I can't see a
> clean way for me as a technology integrator to replace all your
> STL container declarations with ones that include my allocator.
>
> I would love to be able to use the STL. I'm a huge fan of generic
> programming. But the reality is that the leading 'S' in STL is a
> falsehood. I know C++-98 added much of the STL to the ISO C++
> standard. But the problem is not with the spec so much as it is
> with the buggy/inconsistent implementations.
>
>
> Having said all that...let me simplify things... if you folks are
> confident you can provide leak free usage of the STL, AND, you can
> provide a means to allow me to provide memory management routines,
> then I would go away a happy camper. But my comments above support
> my perspective that I don't believe the former assertion is feasible
> since STLs vary and you have no control to fix them. Yet I concede
> the possibility that you may be using a subset of the STL that is
> reliable across platforms (tough to prove, but possible; lest that
> be the empty-subset ;-) ).
>
>
> In there interest of full disclosure, I will reveal that I have been
> fortunate to use some of the more exotic compilers around...Cygnus,
> HPUX, eeek! But these are falling away. What is the opinion of the
> AxisCpp group on what compiler and platform combinations you are
> aiming to support? Maybe that is an easier way to approach this
> issue. I could see reasonable arguments being made that only VC++
> and GCC compilers of certain versions and above will be supported.
>
> Anyway, I've been too long winded already. It is a meaty subject.
> Curious to hear your folks perspectives on these matters.
>
> Cheers,
> -Scott
>
>
>
RE: Some Design Questions...
Posted by sa...@gte.net.
Thanks for the info Samisa.
I see I came to the STL party late. I reviewed the
thread on this subject. I would like to add to the
discussion (albeit a little late).
First, I think Lahiru's perspective on this is spot on.
(message quoted below for convenience.) I only differ
in that I don't care if the STL is exposed or hidden in
the engine. If it is anywhere, I am concerned (reasons
stated below).
> I suggest eliminate stl so that it is not exposed to
> client although it is used inside the engine. There are several
> advantages by doing this.
>
> 1) Ability to support C. Other wise we need extra wrappers.
> 2) Some times users may face portability challenges if STL is exposed.
> 3) It is easier to manipulate an STL string, but char* is the standard
> string format in C/C++. so giving char* instead of STL string, gives the
> user more flexibility.
>
> Lahiru Wimalasiri
Second, when it comes to the STL, I'm less worried about performance
than I am reliability. There's no secrets to these data structures.
You can pull a book off the shelf to see how to implement them.
I've just seen too many internal leaks from STL containers.
Third, using STL complicates the matter of allowing folks to
provide their own memory management routines. Indeed, the STL
provides the allocator mechanism. But in my experience that
has been the least portable aspect of the STL. I can't see a
clean way for me as a technology integrator to replace all your
STL container declarations with ones that include my allocator.
I would love to be able to use the STL. I'm a huge fan of generic
programming. But the reality is that the leading 'S' in STL is a
falsehood. I know C++-98 added much of the STL to the ISO C++
standard. But the problem is not with the spec so much as it is
with the buggy/inconsistent implementations.
Having said all that...let me simplify things... if you folks are
confident you can provide leak free usage of the STL, AND, you can
provide a means to allow me to provide memory management routines,
then I would go away a happy camper. But my comments above support
my perspective that I don't believe the former assertion is feasible
since STLs vary and you have no control to fix them. Yet I concede
the possibility that you may be using a subset of the STL that is
reliable across platforms (tough to prove, but possible; lest that
be the empty-subset ;-) ).
In there interest of full disclosure, I will reveal that I have been
fortunate to use some of the more exotic compilers around...Cygnus,
HPUX, eeek! But these are falling away. What is the opinion of the
AxisCpp group on what compiler and platform combinations you are
aiming to support? Maybe that is an easier way to approach this
issue. I could see reasonable arguments being made that only VC++
and GCC compilers of certain versions and above will be supported.
Anyway, I've been too long winded already. It is a meaty subject.
Curious to hear your folks perspectives on these matters.
Cheers,
-Scott
RE: Some Design Questions...
Posted by Roshan Weerasuriya <ro...@opensource.lk>.
hi Scott,
> I'm thinking of the scenario where a handler in the pipeline
> > may have to query a remote resource via IPC based on async-IO.
> > So the engine would have to pause and then be resumed when
> > the response to the query has returned.
Why don't you try this writing a Handler. Handler examples are available
in the site doc.
Roshan
On Thu, 2004-08-19 at 11:25, Susantha Kumara wrote:
> Are you thinking of a handler that routes the SOAP message to another
> SOAP processor (an intermediary) ?.
>
> > -----Original Message-----
> > From: saguyer@gte.net [mailto:saguyer@gte.net]
> > Sent: Thursday, August 19, 2004 6:09 AM
> > To: 'Apache AXIS C Developers List'
> > Subject: RE: Some Design Questions...
> >
> >
> > I'm thinking of the scenario where a handler in the pipeline
> > may have to query a remote resource via IPC based on async-IO.
> > So the engine would have to pause and then be resumed when
> > the response to the query has returned.
> >
> > Make sense?
> >
> > Cheers,
> > -Scott
> >
> >
> > -----Original Message-----
> > From: Roshan Weerasuriya [mailto:roshan@opensource.lk]
> > Sent: Wednesday, August 18, 2004 9:51 AM
> > To: Apache AXIS C Developers List
> > Subject: Re: Some Design Questions...
> >
> > hi Scott,
> >
> > > (1) Has the axis server engine accommodated the possibility
> > > > of asynchronous handlers in either the Request or Response chains?
> >
> > What do you mean by "asynchronous handlers" here?
> >
> > Roshan
>
>
>
RE: Some Design Questions...
Posted by sa...@gte.net.
> -----Original Message-----
> From: Susantha Kumara [mailto:susantha@opensource.lk]
> Subject: RE: Some Design Questions...
>
> Are you thinking of a handler that routes the SOAP message to
> another SOAP processor (an intermediary) ?.
>
No. As I understand the SOAP processing model that would
terminate processing. So there would be no reason (and indeed,
nothing) to resume.
In the scenario I'm envisioning, my server is the endpoint.
But perhaps the server needs to query a remote service for
assistance to complete processing of SOAP message.
And, I'm embedded in a server that uses an event-driven
concurrency model (hence, async-IO) not thread-based
concurrency. So when I said "pause", I didn't mean just
holding up the thread waiting on synchronous-IO. I can't
imagine you not supporting that. :-)
Yeah, I know, I'm out on the fringe. Perhaps even outside
that magical 80%. But a guy has to take a shot.
Thanks,
-Scott
RE: Some Design Questions...
Posted by Susantha Kumara <su...@opensource.lk>.
Are you thinking of a handler that routes the SOAP message to another
SOAP processor (an intermediary) ?.
> -----Original Message-----
> From: saguyer@gte.net [mailto:saguyer@gte.net]
> Sent: Thursday, August 19, 2004 6:09 AM
> To: 'Apache AXIS C Developers List'
> Subject: RE: Some Design Questions...
>
>
> I'm thinking of the scenario where a handler in the pipeline
> may have to query a remote resource via IPC based on async-IO.
> So the engine would have to pause and then be resumed when
> the response to the query has returned.
>
> Make sense?
>
> Cheers,
> -Scott
>
>
> -----Original Message-----
> From: Roshan Weerasuriya [mailto:roshan@opensource.lk]
> Sent: Wednesday, August 18, 2004 9:51 AM
> To: Apache AXIS C Developers List
> Subject: Re: Some Design Questions...
>
> hi Scott,
>
> > (1) Has the axis server engine accommodated the possibility
> > > of asynchronous handlers in either the Request or Response chains?
>
> What do you mean by "asynchronous handlers" here?
>
> Roshan
RE: Some Design Questions...
Posted by sa...@gte.net.
I'm thinking of the scenario where a handler in the pipeline
may have to query a remote resource via IPC based on async-IO.
So the engine would have to pause and then be resumed when
the response to the query has returned.
Make sense?
Cheers,
-Scott
-----Original Message-----
From: Roshan Weerasuriya [mailto:roshan@opensource.lk]
Sent: Wednesday, August 18, 2004 9:51 AM
To: Apache AXIS C Developers List
Subject: Re: Some Design Questions...
hi Scott,
> (1) Has the axis server engine accommodated the possibility
> > of asynchronous handlers in either the Request or Response chains?
What do you mean by "asynchronous handlers" here?
Roshan
Re: Some Design Questions...
Posted by Roshan Weerasuriya <ro...@opensource.lk>.
hi Scott,
> (1) Has the axis server engine accommodated the possibility
> > of asynchronous handlers in either the Request or Response chains?
What do you mean by "asynchronous handlers" here?
Roshan
On Wed, 2004-08-18 at 13:34, John Hawkins wrote:
>
>
> Hi,
>
> Update on trace -
>
> AspectC++ for entry and exit trace - I think we have to declare this a
> non-starter. Having looked into it - the AspectC++ code is simply not
> capable of doing the simple things we need to do. I get compile errors all
> over the place. I'm still investigating but will not be able to implement
> in the 1.3/1.4 timeframe. I intend to introduce some other way of adding
> entry and exit trace (java pre--parser or the like) - we have a first
> version but it needs improving. I'll keep in contact with the AspectC folks
> and try to get aspects working in the future.
>
>
>
> John Hawkins
>
>
>
> Samisa Abeysinghe
> <samisa_abeysingh
> e@yahoo.com> To
> Apache AXIS C Developers List
> 18/08/2004 06:05 <ax...@ws.apache.org>
> cc
>
> Please respond to Subject
> "Apache AXIS C Re: Some Design Questions...
> Developers List"
>
>
>
>
>
>
>
>
>
> Hi Scott,
> At the moment none of the features you are looking for are available in
> Axis C++.
> However the good news is that there are plans for a new version. Your
> ideas could be taken as
> input for the new design.
>
>
> > (1) Has the axis server engine accommodated the possibility
> > of asynchronous handlers in either the Request or Response chains?
>
> Not at the moment.
>
> >
> > (2) What is the plan for allowing AxisCpp integrators to plug-in
> > their own logging subsystem?
> >
>
> This would require a 'logging abstraction layer'. This will be food for
> thought for the new
> design.
> Hopefully plans would be available soon.
> At the moment there is an effort going on to use Aspect C++ for tracing.
> However, as I understand
> this is not what you are looking for.
>
> > (3) Similarly, what is the plan for custom memory managers?
> >
>
> Memory management has been identified as one of the areas to be improved.
> The palns would be laid
> down soon.
>
> >
> > Thank you,
> > -Scott
> >
> >
> > PS - Related to item (3) above...I saw in your TODO list that
> > you would like to walk away from STL. FWIW, this is wise.
> > I've had to cut out all STL in my own projects because of many
> > leaks and inconsistencies amongst different STL implementations.
> > Sad, but true.
> >
>
> There has been much debate on dropping vs keeping STL. However, the
> community decided to keep
> it within the engine as it is believed to be efficient and easy to use.
> There had been some effort
> to eliminate STL at client stub level.
> Considering the amount of STL being used in the core code at the
> moment, it is not an easy
> task to drop all STL overnight.
> I too have had bad experiance with STL in the past. I hope the future
> versions would take the
> concerns into account.
>
> Samisa...
>
> >
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail Address AutoComplete - You start. We finish.
> http://promotions.yahoo.com/new_mail
>
>
>
Re: Some Design Questions...
Posted by John Hawkins <HA...@uk.ibm.com>.
Hi,
Update on trace -
AspectC++ for entry and exit trace - I think we have to declare this a
non-starter. Having looked into it - the AspectC++ code is simply not
capable of doing the simple things we need to do. I get compile errors all
over the place. I'm still investigating but will not be able to implement
in the 1.3/1.4 timeframe. I intend to introduce some other way of adding
entry and exit trace (java pre--parser or the like) - we have a first
version but it needs improving. I'll keep in contact with the AspectC folks
and try to get aspects working in the future.
John Hawkins
Samisa Abeysinghe
<samisa_abeysingh
e@yahoo.com> To
Apache AXIS C Developers List
18/08/2004 06:05 <ax...@ws.apache.org>
cc
Please respond to Subject
"Apache AXIS C Re: Some Design Questions...
Developers List"
Hi Scott,
At the moment none of the features you are looking for are available in
Axis C++.
However the good news is that there are plans for a new version. Your
ideas could be taken as
input for the new design.
> (1) Has the axis server engine accommodated the possibility
> of asynchronous handlers in either the Request or Response chains?
Not at the moment.
>
> (2) What is the plan for allowing AxisCpp integrators to plug-in
> their own logging subsystem?
>
This would require a 'logging abstraction layer'. This will be food for
thought for the new
design.
Hopefully plans would be available soon.
At the moment there is an effort going on to use Aspect C++ for tracing.
However, as I understand
this is not what you are looking for.
> (3) Similarly, what is the plan for custom memory managers?
>
Memory management has been identified as one of the areas to be improved.
The palns would be laid
down soon.
>
> Thank you,
> -Scott
>
>
> PS - Related to item (3) above...I saw in your TODO list that
> you would like to walk away from STL. FWIW, this is wise.
> I've had to cut out all STL in my own projects because of many
> leaks and inconsistencies amongst different STL implementations.
> Sad, but true.
>
There has been much debate on dropping vs keeping STL. However, the
community decided to keep
it within the engine as it is believed to be efficient and easy to use.
There had been some effort
to eliminate STL at client stub level.
Considering the amount of STL being used in the core code at the
moment, it is not an easy
task to drop all STL overnight.
I too have had bad experiance with STL in the past. I hope the future
versions would take the
concerns into account.
Samisa...
>
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail
Re: Some Design Questions...
Posted by Samisa Abeysinghe <sa...@yahoo.com>.
Hi Scott,
At the moment none of the features you are looking for are available in Axis C++.
However the good news is that there are plans for a new version. Your ideas could be taken as
input for the new design.
> (1) Has the axis server engine accommodated the possibility
> of asynchronous handlers in either the Request or Response chains?
Not at the moment.
>
> (2) What is the plan for allowing AxisCpp integrators to plug-in
> their own logging subsystem?
>
This would require a 'logging abstraction layer'. This will be food for thought for the new
design.
Hopefully plans would be available soon.
At the moment there is an effort going on to use Aspect C++ for tracing. However, as I understand
this is not what you are looking for.
> (3) Similarly, what is the plan for custom memory managers?
>
Memory management has been identified as one of the areas to be improved. The palns would be laid
down soon.
>
> Thank you,
> -Scott
>
>
> PS - Related to item (3) above...I saw in your TODO list that
> you would like to walk away from STL. FWIW, this is wise.
> I've had to cut out all STL in my own projects because of many
> leaks and inconsistencies amongst different STL implementations.
> Sad, but true.
>
There has been much debate on dropping vs keeping STL. However, the community decided to keep
it within the engine as it is believed to be efficient and easy to use. There had been some effort
to eliminate STL at client stub level.
Considering the amount of STL being used in the core code at the moment, it is not an easy
task to drop all STL overnight.
I too have had bad experiance with STL in the past. I hope the future versions would take the
concerns into account.
Samisa...
>
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail