You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by bu...@apache.org on 2002/07/27 21:11:54 UTC
DO NOT REPLY [Bug 11235] New: -
Extensive use of string concatenation operator throughout code base
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11235>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11235
Extensive use of string concatenation operator throughout code base
Summary: Extensive use of string concatenation operator
throughout code base
Product: James
Version: 2.0a3
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: James Core
AssignedTo: james-dev@jakarta.apache.org
ReportedBy: farsight@alum.mit.edu
This bug is really a performance/scalability/resources issue. The code is
full (especially in the handlers) of string concatenation operators. This is
a very resource intensive operation when concatenating anything more than 2
string (i.e. "a" + "b" + "c" + "d") because of the temporary objects created
and then discarded with each concatenation. It is very preferable to use a
single StringBuffer instance to do this type of concatenation. This
eliminates the temporary object creation and hence improves performance. This
is especially critical in the assorted handlers, where the use of the
concatenation operator is most prevalent, because these classes are going to
be your bottlenecks for client interaction.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Sequrity & xdoclet: Re: Contribution: Re: Handlers' streams RE:
[Bug 11235]
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>Stephen,
>
>What are the relationships between Merlin, Fortress and Phoenix?
>
In the beginning there was ECM (Excalibur Component Manager) and
Phoenix. ECM was basically a component manager implementation running
on steroids. It came about as a result of the needs of the Cocoon
community for dynamic service activation. Phoenix went in a different
direction, focussing much more of well structured service management
(dependency control, etc). About twleve months ago Fortress emerged -
the next generation of the Cocoon style dynamic service management but
formally structured as a container. About the same time, Merlin 1.0
arrived on the scene - basically a compoent runner along the lines of
Phoneix (xinfo based management and so on - but with auto assembly
abilities). Three months ago some work was initiated on a common
meta-model for all of these containers in a package called Containerkit.
That got forked as part of the work relating to Merlin 2.0 - a next
generation service management platform. Merlin 2.0 is progressivly
incorporating Fortress features concerning lifecycle and lifestlke
management and Fortress is adopting the Merlin 2.0 meta-model.
>Are they all containers for Avalon Frameworks components?
>
Yes - but with variations.
* Fortress supports different component lifestyles (threadsafe,
per-thread, pooled, etc.) but weak in respect to dependency
management and formal meta-model.
* Phoenix provides a reasonably complete app-server framework
for a linear service management model.
* Merlin provides a container hierachy, automated assembly,
dynamic component installation, automated context management,
package deployment profiles, and more.
>Cornerstone and Excalibre classes work with any of them?
>
Merlin will provide support for Phoenix blocks reasonably soon. The DTD
for Merlin xinfo files is very similar to a block info (but more stuff
concerning lifecycle extensions, and extension depedencies). In the
near future Merlin will automatically build a meta-model from a Phoenix
block defintion. Things like BlockListeners may be provided as
lifecycle extensions. As Fortress moves forward with implemetation
above the Merlin meta-model it will aquire the ability to run blocks as
well.
Merlin 2.0 lives in the following CVS:
akarta-avalon-excalibur/assembly
>Feel free to post a link to an FAQ.
>
Merlin Home Page
----------------
http://home.osm.net/doc/merlin
Merlin FAQ
----------
http://home.osm.net/doc/merlin/faq.html
Cheers, Steve.
>
>
> --- Noel
>
>-----Original Message-----
>From: Stephen McConnell [mailto:mcconnell@apache.org]
>Sent: Tuesday, August 13, 2002 23:24
>To: James Developers List
>Subject: Re: Sequrity & xdoclet: Re: Contribution: Re: Handlers' streams
>RE: [Bug 11235]
>
>Andrei Ivanov wrote:
>
>
>>2. what has to be done long ago: is GETTING RIDE OF xinfo files (xdoclet
>>rules!!!)
>>
>>
>
>You may want to hold off on this for a little while. Currently over in
>Avalon land there is work going on concerning a standard "meta model"
>that will be described using an xinfo resource that has the potential to
>enable component deployment across a number of different containers.
> Currently James uses Phoenix as its container and describes component
>meta-info in a blockinfo descriptor. It is expected that Phoenix will
>be enhanced to support a more standard meta info DTD in the near future.
> In the meantime there is work on-going with two other containers -
>Fortress and Merlin. The authors of these containers are working
>together to ensure the establishment of a meta-model that completely
>addresses not only the defintions of component services and depenedecies
>along the lines of the blockinfo model, but addition contextn such as
>lifecycle extensions, lifestyle management, and so on. When this all
>settles down I expect we will see support in Phoenix for the
>Fortress/Merlin meta-model and support for blockinfo declarations inside
>Merlin.
>
>Cheers, Steve.
>
>--
>
>Stephen J. McConnell
>
>OSM SARL
>digital products for a global economy
>mailto:mcconnell@osm.net
>http://www.osm.net
>
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Sequrity & xdoclet: Re: Contribution: Re: Handlers' streams RE: [Bug 11235]
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stephen,
What are the relationships between Merlin, Fortress and Phoenix? Are they
all containers for Avalon Frameworks components? Cornerstone and Excalibre
classes work with any of them?
Feel free to post a link to an FAQ.
--- Noel
-----Original Message-----
From: Stephen McConnell [mailto:mcconnell@apache.org]
Sent: Tuesday, August 13, 2002 23:24
To: James Developers List
Subject: Re: Sequrity & xdoclet: Re: Contribution: Re: Handlers' streams
RE: [Bug 11235]
Andrei Ivanov wrote:
>2. what has to be done long ago: is GETTING RIDE OF xinfo files (xdoclet
>rules!!!)
>
You may want to hold off on this for a little while. Currently over in
Avalon land there is work going on concerning a standard "meta model"
that will be described using an xinfo resource that has the potential to
enable component deployment across a number of different containers.
Currently James uses Phoenix as its container and describes component
meta-info in a blockinfo descriptor. It is expected that Phoenix will
be enhanced to support a more standard meta info DTD in the near future.
In the meantime there is work on-going with two other containers -
Fortress and Merlin. The authors of these containers are working
together to ensure the establishment of a meta-model that completely
addresses not only the defintions of component services and depenedecies
along the lines of the blockinfo model, but addition contextn such as
lifecycle extensions, lifestyle management, and so on. When this all
settles down I expect we will see support in Phoenix for the
Fortress/Merlin meta-model and support for blockinfo declarations inside
Merlin.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Sequrity & xdoclet: Re: Contribution: Re: Handlers' streams RE:
[Bug 11235]
Posted by Stephen McConnell <mc...@apache.org>.
Andrei Ivanov wrote:
>2. what has to be done long ago: is GETTING RIDE OF xinfo files (xdoclet
>rules!!!)
>
You may want to hold off on this for a little while. Currently over in
Avalon land there is work going on concerning a standard "meta model"
that will be described using an xinfo resource that has the potential to
enable component deployment across a number of different containers.
Currently James uses Phoenix as its container and describes component
meta-info in a blockinfo descriptor. It is expected that Phoenix will
be enhanced to support a more standard meta info DTD in the near future.
In the meantime there is work on-going with two other containers -
Fortress and Merlin. The authors of these containers are working
together to ensure the establishment of a meta-model that completely
addresses not only the defintions of component services and depenedecies
along the lines of the blockinfo model, but addition contextn such as
lifecycle extensions, lifestyle management, and so on. When this all
settles down I expect we will see support in Phoenix for the
Fortress/Merlin meta-model and support for blockinfo declarations inside
Merlin.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Sequrity & xdoclet: Re: Contribution: Re: Handlers' streams RE:
[Bug 11235]
Posted by Paul Hammant <Pa...@yahoo.com>.
Andrei,
>2. what has to be done long ago: is GETTING RIDE OF xinfo files (xdoclet
>rules!!!)
>
>
It does but it bloats the download by 700K and adds multiple seconds to
the build times. I personally prefer hand crafted xinfo files, but
understand that many do not.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Sequrity & xdoclet: Re: Contribution: Re: Handlers' streams RE: [Bug 11235]
Posted by Andrei Ivanov <my...@surfeu.fi>.
WOW!
And next things I would like to do
1. securing the SMTP remote delivery. Now I have answers to Serges's
questions he asked me long ago. After this we will be able really to secure
everything in James and make it even more attractive for business!
2. what has to be done long ago: is GETTING RIDE OF xinfo files (xdoclet
rules!!!)
Andrei
----- Original Message -----
From: "Peter M. Goldstein" <pe...@yahoo.com>
To: "'James Developers List'" <ja...@jakarta.apache.org>
Sent: Wednesday, August 14, 2002 1:09 AM
Subject: RE: Contribution: Re: Handlers' streams RE: [Bug 11235]
>
> All,
>
> I'm going to be taking these files, making some alterations to bring
> them into line with James code standards, and basically getting them in
> the standard form for submission. In addition to these modifications, I
> will be unifying all of the server/handlers under this connection
> paradigm. At that point I'll discuss with Andrei, and resubmit the
> modified code to the list for discussion. Hopefully we'll get that
> taken care of in a week or so, as I'd really like to see this code
> incorporated into the code base.
>
> --Peter
>
> > -----Original Message-----
> > From: Andrei Ivanov [mailto:myfam@surfeu.fi]
> > Sent: Tuesday, August 13, 2002 3:09 PM
> > To: James Developers List
> > Subject: Contribution: Re: Handlers' streams RE: [Bug 11235]
> >
> > Hi,
> > finally it's done (see attachment)
> >
> > Comments:
> >
> > Attached are only modified and new files for current James.
> > If you check out new james and copy src directory from zip over
> existing
> > src
> > dir and build james distribution it will run right away.
> > When you'll look at sources you'll see what I've done. It is not well
> > commented in the code though...
> >
> > There are two things you have to pay attention first of all
> >
> > 1. "connection" package structure doesn't correspond james structure
> where
> > interfaces defined in "services" and implementation is spread over
> other
> > packages (I've been always wandering why James originators hadn't
> adapted
> > cornerstone package structure from very beginning). So you may want to
> > modify connection package structure (move interfaces and
> implementations)
> >
> > 2. About SMTPHandler. I adapted only doAUTH(..) method from the latest
> > James
> > (you will see it because it is shifted right). I think that most of
> the
> > recent changes were done to this method so I copied it from current
> James
> > and modified it according to my changes. If other methods have changed
> > recently you'll have to add those modifications to new SMTPHandler
> (use
> > doAUTH(..) as an example).
> >
> >
> > Andrei
> >
> > ----- Original Message -----
> > From: "Andrei Ivanov" <my...@surfeu.fi>
> > To: "James Developers List" <ja...@jakarta.apache.org>
> > Sent: Monday, July 29, 2002 12:14 AM
> > Subject: Handlers' streams RE: [Bug 11235]
> >
> >
> > > Ok, then there will be
> > >
> > > 1. new AbstractServer
> > > 2. modified SMTPServer
> > > 3. modified SMTPHandler
> > > 4. modified MimeMessageInputStreamSource
> > > 5. modified SmsImpl (only one new constructor)
> > >
> > > There will be no changes in configs so that no compatibility
> hazards.
> > Hope
> > > it will not be so little slow to apply these changes.
> > >
> > > How does this sound now?
> > >
> > > Heh, I would like to add to this logging levels for mailets, but
> this is
> > > totally another story ;-). I am just recalling broken lances over
> > mailet
> > > logging :-( ...to no avail.
> > >
> > > Andrei
> > >
> > > ----- Original Message -----
> > > From: "Danny Angus" <da...@apache.org>
> > > To: "James Developers List" <ja...@jakarta.apache.org>
> > > Sent: Sunday, July 28, 2002 11:51 PM
> > > Subject: RE: [Bug 11235] Extensive use of string concatenation
> > throughout
> > > code base
> > >
> > >
> > > >
> > > >
> > > > > I can
> > > > > provide fixed SMTPHandler (since I ve been working a lot with
> this
> > part
> > > of
> > > > > James for my project) so that other handlers can be fixed as
> well
> > > similar
> > > > > way. How does this sound?
> > > >
> > > > Andrei,
> > > > We're *always* happy to accept contributions.
> > > > If a little slow, at times, to apply them.
> > > >
> > > > d.
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Contribution: Re: Handlers' streams RE: [Bug 11235]
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
All,
I'm going to be taking these files, making some alterations to bring
them into line with James code standards, and basically getting them in
the standard form for submission. In addition to these modifications, I
will be unifying all of the server/handlers under this connection
paradigm. At that point I'll discuss with Andrei, and resubmit the
modified code to the list for discussion. Hopefully we'll get that
taken care of in a week or so, as I'd really like to see this code
incorporated into the code base.
--Peter
> -----Original Message-----
> From: Andrei Ivanov [mailto:myfam@surfeu.fi]
> Sent: Tuesday, August 13, 2002 3:09 PM
> To: James Developers List
> Subject: Contribution: Re: Handlers' streams RE: [Bug 11235]
>
> Hi,
> finally it's done (see attachment)
>
> Comments:
>
> Attached are only modified and new files for current James.
> If you check out new james and copy src directory from zip over
existing
> src
> dir and build james distribution it will run right away.
> When you'll look at sources you'll see what I've done. It is not well
> commented in the code though...
>
> There are two things you have to pay attention first of all
>
> 1. "connection" package structure doesn't correspond james structure
where
> interfaces defined in "services" and implementation is spread over
other
> packages (I've been always wandering why James originators hadn't
adapted
> cornerstone package structure from very beginning). So you may want to
> modify connection package structure (move interfaces and
implementations)
>
> 2. About SMTPHandler. I adapted only doAUTH(..) method from the latest
> James
> (you will see it because it is shifted right). I think that most of
the
> recent changes were done to this method so I copied it from current
James
> and modified it according to my changes. If other methods have changed
> recently you'll have to add those modifications to new SMTPHandler
(use
> doAUTH(..) as an example).
>
>
> Andrei
>
> ----- Original Message -----
> From: "Andrei Ivanov" <my...@surfeu.fi>
> To: "James Developers List" <ja...@jakarta.apache.org>
> Sent: Monday, July 29, 2002 12:14 AM
> Subject: Handlers' streams RE: [Bug 11235]
>
>
> > Ok, then there will be
> >
> > 1. new AbstractServer
> > 2. modified SMTPServer
> > 3. modified SMTPHandler
> > 4. modified MimeMessageInputStreamSource
> > 5. modified SmsImpl (only one new constructor)
> >
> > There will be no changes in configs so that no compatibility
hazards.
> Hope
> > it will not be so little slow to apply these changes.
> >
> > How does this sound now?
> >
> > Heh, I would like to add to this logging levels for mailets, but
this is
> > totally another story ;-). I am just recalling broken lances over
> mailet
> > logging :-( ...to no avail.
> >
> > Andrei
> >
> > ----- Original Message -----
> > From: "Danny Angus" <da...@apache.org>
> > To: "James Developers List" <ja...@jakarta.apache.org>
> > Sent: Sunday, July 28, 2002 11:51 PM
> > Subject: RE: [Bug 11235] Extensive use of string concatenation
> throughout
> > code base
> >
> >
> > >
> > >
> > > > I can
> > > > provide fixed SMTPHandler (since I ve been working a lot with
this
> part
> > of
> > > > James for my project) so that other handlers can be fixed as
well
> > similar
> > > > way. How does this sound?
> > >
> > > Andrei,
> > > We're *always* happy to accept contributions.
> > > If a little slow, at times, to apply them.
> > >
> > > d.
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Contribution: Re: Handlers' streams RE: [Bug 11235]
Posted by Andrei Ivanov <my...@surfeu.fi>.
Hi,
finally it's done (see attachment)
Comments:
Attached are only modified and new files for current James.
If you check out new james and copy src directory from zip over existing src
dir and build james distribution it will run right away.
When you'll look at sources you'll see what I've done. It is not well
commented in the code though...
There are two things you have to pay attention first of all
1. "connection" package structure doesn't correspond james structure where
interfaces defined in "services" and implementation is spread over other
packages (I've been always wandering why James originators hadn't adapted
cornerstone package structure from very beginning). So you may want to
modify connection package structure (move interfaces and implementations)
2. About SMTPHandler. I adapted only doAUTH(..) method from the latest James
(you will see it because it is shifted right). I think that most of the
recent changes were done to this method so I copied it from current James
and modified it according to my changes. If other methods have changed
recently you'll have to add those modifications to new SMTPHandler (use
doAUTH(..) as an example).
Andrei
----- Original Message -----
From: "Andrei Ivanov" <my...@surfeu.fi>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Monday, July 29, 2002 12:14 AM
Subject: Handlers' streams RE: [Bug 11235]
> Ok, then there will be
>
> 1. new AbstractServer
> 2. modified SMTPServer
> 3. modified SMTPHandler
> 4. modified MimeMessageInputStreamSource
> 5. modified SmsImpl (only one new constructor)
>
> There will be no changes in configs so that no compatibility hazards. Hope
> it will not be so little slow to apply these changes.
>
> How does this sound now?
>
> Heh, I would like to add to this logging levels for mailets, but this is
> totally another story ;-). I am just recalling broken lances over mailet
> logging :-( ...to no avail.
>
> Andrei
>
> ----- Original Message -----
> From: "Danny Angus" <da...@apache.org>
> To: "James Developers List" <ja...@jakarta.apache.org>
> Sent: Sunday, July 28, 2002 11:51 PM
> Subject: RE: [Bug 11235] Extensive use of string concatenation throughout
> code base
>
>
> >
> >
> > > I can
> > > provide fixed SMTPHandler (since I ve been working a lot with this
part
> of
> > > James for my project) so that other handlers can be fixed as well
> similar
> > > way. How does this sound?
> >
> > Andrei,
> > We're *always* happy to accept contributions.
> > If a little slow, at times, to apply them.
> >
> > d.
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
RE: Handlers' streams RE: [Bug 11235]
Posted by Danny Angus <da...@apache.org>.
I believe that this argument was settled with the commiters deciding not to
include logging in the API.
Of course you are entitled to produce your own extensions/frameowrks and
whatever you need to allow you to make useful mailet applications, but they
are not part of the API.
d.
> I will provide patches and difs for logging.
> When we can
> review this and put it to the scratch (or whatever cvs) branch.
> So ones who
> badly need fine grained logging in mailet (like me for example)
> will be able
> to take it and test it. This change doesn't break mailet API, it
> just extend
> it a little bit, so there should be NO compatibility risk. After testing
> (and time) this can go into main code. And when new mailet API will be
> developed this change can be adopted or dropped out but still this will be
> done when there is at least one implemented and tested approach.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Handlers' streams RE: [Bug 11235]
Posted by Andrei Ivanov <my...@surfeu.fi>.
Hi
> LOL Yeah, because no one could agree how to expose fine-grained logging
in
> the Mailet API. :-) One of these days, I'm sure it will be revisited.
Agree, let's do so: I will provide patches and difs for logging. When we can
review this and put it to the scratch (or whatever cvs) branch. So ones who
badly need fine grained logging in mailet (like me for example) will be able
to take it and test it. This change doesn't break mailet API, it just extend
it a little bit, so there should be NO compatibility risk. After testing
(and time) this can go into main code. And when new mailet API will be
developed this change can be adopted or dropped out but still this will be
done when there is at least one implemented and tested approach.
Andrei
>
> > Heh, I would like to add to this logging levels for mailets, but this is
> > totally another story ;-). I am just recalling broken lances over
mailet
> > logging :-( ...to no avail.
>
> LOL Yeah, because no one could agree how to expose fine-grained logging
in
> the Mailet API. :-) One of these days, I'm sure it will be revisited.
>
> --- Noel
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Handlers' streams RE: [Bug 11235]
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Heh, I would like to add to this logging levels for mailets, but this is
> totally another story ;-). I am just recalling broken lances over mailet
> logging :-( ...to no avail.
LOL Yeah, because no one could agree how to expose fine-grained logging in
the Mailet API. :-) One of these days, I'm sure it will be revisited.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Handlers' streams RE: [Bug 11235]
Posted by Danny Angus <da...@apache.org>.
> Heh, I would like to add to this logging levels for mailets, but this is
> totally another story ;-). I am just recalling broken lances over mailet
> logging :-( ...to no avail.
;)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Handlers' streams RE: [Bug 11235]
Posted by Andrei Ivanov <my...@surfeu.fi>.
Ok, then there will be
1. new AbstractServer
2. modified SMTPServer
3. modified SMTPHandler
4. modified MimeMessageInputStreamSource
5. modified SmsImpl (only one new constructor)
There will be no changes in configs so that no compatibility hazards. Hope
it will not be so little slow to apply these changes.
How does this sound now?
Heh, I would like to add to this logging levels for mailets, but this is
totally another story ;-). I am just recalling broken lances over mailet
logging :-( ...to no avail.
Andrei
----- Original Message -----
From: "Danny Angus" <da...@apache.org>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Sunday, July 28, 2002 11:51 PM
Subject: RE: [Bug 11235] Extensive use of string concatenation throughout
code base
>
>
> > I can
> > provide fixed SMTPHandler (since I ve been working a lot with this part
of
> > James for my project) so that other handlers can be fixed as well
similar
> > way. How does this sound?
>
> Andrei,
> We're *always* happy to accept contributions.
> If a little slow, at times, to apply them.
>
> d.
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Bug 11235] Extensive use of string concatenation throughout code base
Posted by Danny Angus <da...@apache.org>.
> I can
> provide fixed SMTPHandler (since I ve been working a lot with this part of
> James for my project) so that other handlers can be fixed as well similar
> way. How does this sound?
Andrei,
We're *always* happy to accept contributions.
If a little slow, at times, to apply them.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Java Performance Tuning RE: [Bug 11235]
Posted by Andrei Ivanov <my...@surfeu.fi>.
Hi Peter,
Yes, yes, I keep this book under my pillow ("Java Performance Tuning"), even
though it annoys my wife some times ;-) . What I would really like is to try
same examples with JDK 1.4xxx... Sorry for off topic.
Andrei
----- Original Message -----
From: "Peter M. Goldstein" <pe...@yahoo.com>
To: "'James Developers List'" <ja...@jakarta.apache.org>
Sent: Sunday, July 28, 2002 11:54 PM
Subject: RE: [Bug 11235] Extensive use of string concatenation throughout
code base
>
> Andrei,
>
> That would be great to see a standardized set of closes for the custom
> streams (as well as a specified order of closure).
>
> I'm going to have to disagree with both you and Noel on the severity and
> performance impact of string concatenation. HotSpot or not, the
> performance penalty for that type of code is immense (especially in some
> of the looped retrieves from the POP3 server). An excellent (if
> slightly dated) reference on the topic is Jack Shirazi's "Java
> Performance Tuning".
>
> --Peter
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Bug 11235] Extensive use of string concatenation throughout code base
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Andrei,
That would be great to see a standardized set of closes for the custom
streams (as well as a specified order of closure).
I'm going to have to disagree with both you and Noel on the severity and
performance impact of string concatenation. HotSpot or not, the
performance penalty for that type of code is immense (especially in some
of the looped retrieves from the POP3 server). An excellent (if
slightly dated) reference on the topic is Jack Shirazi's "Java
Performance Tuning".
--Peter
-----Original Message-----
From: Andrei Ivanov [mailto:myfam@surfeu.fi]
Sent: Sunday, July 28, 2002 1:29 PM
To: James Developers List
Subject: Re: [Bug 11235] Extensive use of string concatenation
throughout code base
Hi, Noel, it is very nice to hear at last about good habits and
especially
in relation to handlers. Your points about stings concatenation and
corresponding performance impact is a very good one, but it is not as
serious this moment (when we have HotSpot :-) ) as how various streams
are
created and closed in, for example, SMTPHandler. SMTPHandler utilizes a
number of "custom" streams and also uses several streams from java.io. I
can
bet that not many of current James developers can clearly say which
stream
is created at which moment, and what is the order of closing of streams
(if
there should be one :-) ). I can state that there is no such order in
SMTPHandler (not every custom steam implements close() method so that
underlying steam will be never closed which is not very good...). I can
provide fixed SMTPHandler (since I ve been working a lot with this part
of
James for my project) so that other handlers can be fixed as well
similar
way. How does this sound?
Best regards,
Andrei
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Sunday, July 28, 2002 10:51 PM
Subject: [Bug 11235] Extensive use of string concatenation throughout
code
base
> re: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11235
>
> "This bug is really a performance/scalability/resources issue. The
code
is
> full (especially in the handlers) of string concatenation operators.
This
> is
> a very resource intensive operation when concatenating anything more
than
2
> string (i.e. "a" + "b" + "c" + "d") because of the temporary objects
created
> and then discarded with each concatenation. It is very preferable to
use
a
> single StringBuffer instance to do this type of concatenation. This
> eliminates the temporary object creation and hence improves
performance.
> This
> is especially critical in the assorted handlers, where the use of the
> concatenation operator is most prevalent, because these classes are
going
to
> be your bottlenecks for client interaction."
>
> I suppose that this would be a good project for people who want to
help
out
> without getting too deep into intricacies. Not the highest of
priorities,
> but the changes should be clear and isolated. The patches should be
fairly
> easy for people to vet, and the maintainers to commit.
>
> Peter, do you want to pick a single file, make the changes, and post
it as
a
> sample for what you think others should do? Not that this is more
than
rote
> conversion, but we might as use something as simple as this to start
trying
> to adopt good habits.
>
> --- Noel
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Bug 11235] Extensive use of string concatenation throughout code base
Posted by Andrei Ivanov <my...@surfeu.fi>.
Hi, Noel, it is very nice to hear at last about good habits and especially
in relation to handlers. Your points about stings concatenation and
corresponding performance impact is a very good one, but it is not as
serious this moment (when we have HotSpot :-) ) as how various streams are
created and closed in, for example, SMTPHandler. SMTPHandler utilizes a
number of "custom" streams and also uses several streams from java.io. I can
bet that not many of current James developers can clearly say which stream
is created at which moment, and what is the order of closing of streams (if
there should be one :-) ). I can state that there is no such order in
SMTPHandler (not every custom steam implements close() method so that
underlying steam will be never closed which is not very good...). I can
provide fixed SMTPHandler (since I ve been working a lot with this part of
James for my project) so that other handlers can be fixed as well similar
way. How does this sound?
Best regards,
Andrei
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Sunday, July 28, 2002 10:51 PM
Subject: [Bug 11235] Extensive use of string concatenation throughout code
base
> re: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11235
>
> "This bug is really a performance/scalability/resources issue. The code
is
> full (especially in the handlers) of string concatenation operators. This
> is
> a very resource intensive operation when concatenating anything more than
2
> string (i.e. "a" + "b" + "c" + "d") because of the temporary objects
created
> and then discarded with each concatenation. It is very preferable to use
a
> single StringBuffer instance to do this type of concatenation. This
> eliminates the temporary object creation and hence improves performance.
> This
> is especially critical in the assorted handlers, where the use of the
> concatenation operator is most prevalent, because these classes are going
to
> be your bottlenecks for client interaction."
>
> I suppose that this would be a good project for people who want to help
out
> without getting too deep into intricacies. Not the highest of priorities,
> but the changes should be clear and isolated. The patches should be
fairly
> easy for people to vet, and the maintainers to commit.
>
> Peter, do you want to pick a single file, make the changes, and post it as
a
> sample for what you think others should do? Not that this is more than
rote
> conversion, but we might as use something as simple as this to start
trying
> to adopt good habits.
>
> --- Noel
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Bug 11235] Extensive use of string concatenation throughout code base
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Danny,
> 1/ get a life mate ;-)
Only took a few hours. :) I went out the next night. Always willing to
sacrifice a night or two for better performing code.
>2/ check very carefully that you have diff'd the HEAD and send them all
in
>one go (if you send a single big file with them all concatenated I can
>*try* to apply them in one fell swoop, try diffing them all at once and
>capturing the whole output)
Ok. I can do that.
> 3/ You'd better make sure it really all works first time.
Agreed. That's one reason I want to manually review the code again
before I send it in. Rushing the diff modifications on the bug #6340
(and screwing them up) was rather embarrassing. I've promised myself no
repeats.
I've been running it on my mail server for the past three weeks without
a problem. You can probably expect a patch late this week.
--Peter
-----Original Message-----
From: Danny Angus [mailto:danny@apache.org]
Sent: Sunday, July 28, 2002 1:49 PM
To: James Developers List; farsight@alum.mit.edu
Subject: RE: [Bug 11235] Extensive use of string concatenation
throughout code base
Peter, if you've cured every instance of string concatenation in james
three
things spring to mind,
1/ get a life mate ;-)
2/ check very carefully that you have diff'd the HEAD and send them all
in
one go (if you send a single big file with them all concatenated I can
*try*
to apply them in one fell swoop, try diffing them all at once and
capturing
the whole output)
3/ You'd better make sure it really all works first time.
d.
> -----Original Message-----
> From: Peter M. Goldstein [mailto:peter_m_goldstein@yahoo.com]
> Sent: 28 July 2002 21:16
> To: 'James Developers List'
> Subject: RE: [Bug 11235] Extensive use of string concatenation
> throughout code base
>
>
>
> Noel,
>
> I've actually had all of this done for a few weeks now. My biggest
> question has been how to post it in a way that it doesn't overload the
> capacity of the list to vet the changes. It's a pretty wide-spread
set
> of changes.
>
> I guess I could start by submitting a couple of the more substantively
> changed files (i.e. POP3Handler.java and SMTPHandler.java) for general
> consideration), following up with a file or two a day. Or do we want
to
> try and digest it all in one lump? There are ~40 affected files.
>
> --Peter
>
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: Sunday, July 28, 2002 12:51 PM
> To: James Developers List
> Subject: [Bug 11235] Extensive use of string concatenation throughout
> code base
>
> re: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11235
>
> "This bug is really a performance/scalability/resources issue. The
code
> is
> full (especially in the handlers) of string concatenation operators.
> This
> is
> a very resource intensive operation when concatenating anything more
> than 2
> string (i.e. "a" + "b" + "c" + "d") because of the temporary objects
> created
> and then discarded with each concatenation. It is very preferable to
> use a
> single StringBuffer instance to do this type of concatenation. This
> eliminates the temporary object creation and hence improves
performance.
> This
> is especially critical in the assorted handlers, where the use of the
> concatenation operator is most prevalent, because these classes are
> going to
> be your bottlenecks for client interaction."
>
> I suppose that this would be a good project for people who want to
help
> out
> without getting too deep into intricacies. Not the highest of
> priorities,
> but the changes should be clear and isolated. The patches should be
> fairly
> easy for people to vet, and the maintainers to commit.
>
> Peter, do you want to pick a single file, make the changes, and post
it
> as a
> sample for what you think others should do? Not that this is more
than
> rote
> conversion, but we might as use something as simple as this to start
> trying
> to adopt good habits.
>
> --- Noel
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Bug 11235] Extensive use of string concatenation throughout code base
Posted by Danny Angus <da...@apache.org>.
Peter, if you've cured every instance of string concatenation in james three
things spring to mind,
1/ get a life mate ;-)
2/ check very carefully that you have diff'd the HEAD and send them all in
one go (if you send a single big file with them all concatenated I can *try*
to apply them in one fell swoop, try diffing them all at once and capturing
the whole output)
3/ You'd better make sure it really all works first time.
d.
> -----Original Message-----
> From: Peter M. Goldstein [mailto:peter_m_goldstein@yahoo.com]
> Sent: 28 July 2002 21:16
> To: 'James Developers List'
> Subject: RE: [Bug 11235] Extensive use of string concatenation
> throughout code base
>
>
>
> Noel,
>
> I've actually had all of this done for a few weeks now. My biggest
> question has been how to post it in a way that it doesn't overload the
> capacity of the list to vet the changes. It's a pretty wide-spread set
> of changes.
>
> I guess I could start by submitting a couple of the more substantively
> changed files (i.e. POP3Handler.java and SMTPHandler.java) for general
> consideration), following up with a file or two a day. Or do we want to
> try and digest it all in one lump? There are ~40 affected files.
>
> --Peter
>
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: Sunday, July 28, 2002 12:51 PM
> To: James Developers List
> Subject: [Bug 11235] Extensive use of string concatenation throughout
> code base
>
> re: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11235
>
> "This bug is really a performance/scalability/resources issue. The code
> is
> full (especially in the handlers) of string concatenation operators.
> This
> is
> a very resource intensive operation when concatenating anything more
> than 2
> string (i.e. "a" + "b" + "c" + "d") because of the temporary objects
> created
> and then discarded with each concatenation. It is very preferable to
> use a
> single StringBuffer instance to do this type of concatenation. This
> eliminates the temporary object creation and hence improves performance.
> This
> is especially critical in the assorted handlers, where the use of the
> concatenation operator is most prevalent, because these classes are
> going to
> be your bottlenecks for client interaction."
>
> I suppose that this would be a good project for people who want to help
> out
> without getting too deep into intricacies. Not the highest of
> priorities,
> but the changes should be clear and isolated. The patches should be
> fairly
> easy for people to vet, and the maintainers to commit.
>
> Peter, do you want to pick a single file, make the changes, and post it
> as a
> sample for what you think others should do? Not that this is more than
> rote
> conversion, but we might as use something as simple as this to start
> trying
> to adopt good habits.
>
> --- Noel
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Bug 11235] Extensive use of string concatenation throughout code base
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Noel,
I've actually had all of this done for a few weeks now. My biggest
question has been how to post it in a way that it doesn't overload the
capacity of the list to vet the changes. It's a pretty wide-spread set
of changes.
I guess I could start by submitting a couple of the more substantively
changed files (i.e. POP3Handler.java and SMTPHandler.java) for general
consideration), following up with a file or two a day. Or do we want to
try and digest it all in one lump? There are ~40 affected files.
--Peter
-----Original Message-----
From: Noel J. Bergman [mailto:noel@devtech.com]
Sent: Sunday, July 28, 2002 12:51 PM
To: James Developers List
Subject: [Bug 11235] Extensive use of string concatenation throughout
code base
re: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11235
"This bug is really a performance/scalability/resources issue. The code
is
full (especially in the handlers) of string concatenation operators.
This
is
a very resource intensive operation when concatenating anything more
than 2
string (i.e. "a" + "b" + "c" + "d") because of the temporary objects
created
and then discarded with each concatenation. It is very preferable to
use a
single StringBuffer instance to do this type of concatenation. This
eliminates the temporary object creation and hence improves performance.
This
is especially critical in the assorted handlers, where the use of the
concatenation operator is most prevalent, because these classes are
going to
be your bottlenecks for client interaction."
I suppose that this would be a good project for people who want to help
out
without getting too deep into intricacies. Not the highest of
priorities,
but the changes should be clear and isolated. The patches should be
fairly
easy for people to vet, and the maintainers to commit.
Peter, do you want to pick a single file, make the changes, and post it
as a
sample for what you think others should do? Not that this is more than
rote
conversion, but we might as use something as simple as this to start
trying
to adopt good habits.
--- Noel
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[Bug 11235] Extensive use of string concatenation throughout code base
Posted by "Noel J. Bergman" <no...@devtech.com>.
re: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11235
"This bug is really a performance/scalability/resources issue. The code is
full (especially in the handlers) of string concatenation operators. This
is
a very resource intensive operation when concatenating anything more than 2
string (i.e. "a" + "b" + "c" + "d") because of the temporary objects created
and then discarded with each concatenation. It is very preferable to use a
single StringBuffer instance to do this type of concatenation. This
eliminates the temporary object creation and hence improves performance.
This
is especially critical in the assorted handlers, where the use of the
concatenation operator is most prevalent, because these classes are going to
be your bottlenecks for client interaction."
I suppose that this would be a good project for people who want to help out
without getting too deep into intricacies. Not the highest of priorities,
but the changes should be clear and isolated. The patches should be fairly
easy for people to vet, and the maintainers to commit.
Peter, do you want to pick a single file, make the changes, and post it as a
sample for what you think others should do? Not that this is more than rote
conversion, but we might as use something as simple as this to start trying
to adopt good habits.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>