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 "Noel J. Bergman" <no...@devtech.com> on 2003/09/02 00:48:40 UTC
RE: Useful error messages
> >As I understand it from your previous notes, Merlin is primarily short in
> > the area of log configuration?
> It's the reverse - well almost. The reverse would suggest that Merlin
> is long in the area of short configurations which doesn't really man
> anything to me.
Huh? Stephen, read it again. L-O-G, not l-o-N-g. I thought that you had
said that Merlin did not yet have the *L-O-G* configurability that Phoenix
provides.
> If you can reformulate the question I'll try and give you an answer.
I can reformulate it, or you can clean your monitor. :-p
> merlin is what you want it to be for whatever your configuration
> requirements are. Phoenix style "put it all together solution"
> - no problem (except that it doesn't scale). Merlin style - break
> out the different logical usage abstractions and package them
> accordingly - and your starting to move towards something scalable.
Example?
> Merlin will provide probably a higher level of deployment relability,
> but less frills at that system level of abstraction (e.g. you don't
> have the JMX and logging options currently available in Phonenix at
> this time) - but you do have more frills on finner grain abstractions
> such as ... component reuse.
Aha! See: "don't have the JMX and L-O-G-G-I-N-G options currently ..." I
did remember it correctly. OK, what are the differences for L-O-G-G-I-N-G?
We currently disable JMX, so until it is done properly, I don't think that's
an issue.
> Running James on Merlin means:
> 1. massive simplification of the system configuration
> 2. greater reliability during deployment
> 3. better error handling
> 4. ability to reuse James with other components
> 5. simplification of the development process
> 6. development time testing and validation of deployment
All of the above require justification. Good to know, but require
justification. I would be happy if startup and footprint were lighter, so
that we could run multiple processes, instead of one monolithic process
(e.g., separate protocol handling services into separate processes connected
via repositories/spool; and the pipeline processing in its own process,
too). As an optional configuration, it would be helpful. Personally, I am
very tempted to do it in my own deployment because it means I could
reconfigure & restart the pipeline without having to take down the SMTP and
POP3 services.
> I don't think the System.err output is really relevant - that's just a
> output target.
I was refering to what Phoenix does.
> Should Merlin be seperating these notion (e.g. using one logging
> channel for verbose dumping of full information and another
> channel for consolidated reposting)?
Interesting notion. Requires more thought than I have to spare at the
moment.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Useful error messages
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>>>As I understand it from your previous notes, Merlin is primarily short in
>>>the area of log configuration?
>>>
>
>>It's the reverse - well almost. The reverse would suggest that Merlin
>>is long in the area of short configurations which doesn't really man
>>anything to me.
>>
>
>Huh? Stephen, read it again. L-O-G, not l-o-N-g. I thought that you had
>said that Merlin did not yet have the *L-O-G* configurability that Phoenix
>provides.
>
Yes, yes - Steve was blind drunk at the time he posted that reply. See
the following message for the real response.
http://marc.theaimsgroup.com/?l=avalon-dev&m=106211727608122&w=2
>
>>If you can reformulate the question I'll try and give you an answer.
>>
>
>I can reformulate it, or you can clean your monitor. :-p
>
ROTFL (if you could only see my monitor)
>
>>merlin is what you want it to be for whatever your configuration
>>requirements are. Phoenix style "put it all together solution"
>>- no problem (except that it doesn't scale). Merlin style - break
>>out the different logical usage abstractions and package them
>>accordingly - and your starting to move towards something scalable.
>>
>
>Example?
>
If your build an application that requires a bunch of different
facilities and if you forced to bring together configuration information
for all of those facilities into one file - things become
non-managable. Imagine a framework composed of six major sub-systems of
which one is james. There are two problems here - firstly scalability
from a human management point of view, and secondly scalability from a
systems point of view.
The human scalability issue can be addressed by breaking out type,
deployment, and context aspects of a configuration and associating them
with different system artifacts. For example, type related
configuration information is normally a developer concerns and can be
associated with a release. Its the sort of information that would not
normally be modified. Deployment information is characterizing the
deployment of a component - this could reflect differences between a
file based deployment versus a RDMS based deployment scenarios. These
"scenario" related configurations can be presented as deployment
profiles and packaged with a release. Finally, the deployment context
aspect deals with things like usernames, passwords, host names, DNS
entries, etc. - i.e. stuff that really is the subject of the particular
context of deployment.
Merlin provides support for all of these aspects and handles the
packaging and ultimate integration of these multiple confiuration
sources into a consolidated configuration that is applied at runtime.
We still have work to do to handle the structural scalability question -
namely the ability to provide service management across multiple JVMs.
What we do have that is an important ingridient towards this is the
notion of virtual components. You can take the "james-system" and
declare the publication of specific services (e.g. the Mailet
services). This allows James to be viewed as just another component.
>>Merlin will provide probably a higher level of deployment relability,
>>but less frills at that system level of abstraction (e.g. you don't
>>have the JMX and logging options currently available in Phonenix at
>>this time) - but you do have more frills on finner grain abstractions
>>such as ... component reuse.
>>
>
>Aha! See: "don't have the JMX and L-O-G-G-I-N-G options currently ..." I
>did remember it correctly.
>
Yes you did remember correctly!!
>OK, what are the differences for L-O-G-G-I-N-G?
>
Phoenix provides support for the Excalibur Logging package (all of that
logging related XML). Merlin has a much smaller subset in terms of
functionality - however the functionality is better seperated in terms
of what are container concerns and what are component deployment
concerns. It probably would not take a lot effort to upgrade Merlin to
provide support for Excalibur Logging but its not terribly high on the
list of priorities (things like JMX intelligence are way higher).
>
>We currently disable JMX, so until it is done properly, I don't think that's
>an issue.
>
On the JMX side of things - the current thinking inside Merlin
development is to provide intelligent management based on the internal
Merlin component meta-model. What this will provide is management of
any component without the need for the component author to write a
single line of code (stuff like reconfiguration, recontextaulization,
etc.). Combine that with functionality along the lines of Phoenix JMX
support and we will have a really nice management solution. This is one
of things I would like to look at following a 3.0 release.
>>Running James on Merlin means:
>> 1. massive simplification of the system configuration
>> 2. greater reliability during deployment
>> 3. better error handling
>> 4. ability to reuse James with other components
>> 5. simplification of the development process
>> 6. development time testing and validation of deployment
>>
>
>All of the above require justification. Good to know, but require
>justification.
>
What sort of justification I you looking for? I can easily provide
information about my own experience and the underlying reasons why these
features were developed if that what you mean. On the otherhand, if
your looking for justification that they actually translate into a value
proposition then the best we to address this is to download Merlin and
setup a runtime James instance.
http://www.ibiblio.org/merlin/distributions/
I'm actually planning on putting James into deployment as the enterprise
messaging solution for "yet-to-be-announced" project - but before doing
this, a key aspect will be demonstrating the utility of James as a
virtual component. For this I'll be looking for some assistance here
;-). But that's a topic for another thread.
>I would be happy if startup and footprint were lighter, so
>that we could run multiple processes, instead of one monolithic process
>
Just comparing foootprints ...
Phoenix is about 4Mb. Merlin is a bit over 2Mb.
>
>(e.g., separate protocol handling services into separate processes connected
>via repositories/spool; and the pipeline processing in its own process,
>too).
>
I'm thinking along the same lines. The solution to this problem is
non-trivial. While Merlin can do all of the service deployment within a
single JVM, we don't have "standard" mechanisms for remote service
resolution or the related service interaction protocols in place
(manager to manager). However, this is top-of-the-agenda. What we want
is scalable, robust, fault-tolerant deployment and James is a hell of
good test case (in fact its been the main testcase for Merlin for the
past nine months).
>As an optional configuration, it would be helpful. Personally, I am
>very tempted to do it in my own deployment because it means I could
>reconfigure & restart the pipeline without having to take down the SMTP and
>POP3 services.
>
This is addressed under the JMX related appliance management plans.
What we want to be able to do is redeploy a manager (appliance) and have
the container handle the automation of the suspension and/or
decommissioning of consumers. This works locally but doing this with
remote services requires a federated service management protocol. For
example, if I have a user repository (identity and credentials) shared
by OpenIM and James, and if I need to redeploy that server I need to
signal to consumers that a suspension (or switch) is initiated and
subsequently resumed (re-swithed) to the updated service provider.
>>I don't think the System.err output is really relevant - that's just a
>>output target.
>>
>
>I was refering to what Phoenix does.
>
Sorry - I stopped using Phoneix about 6 months ago and my memory for
details is getting rusty already. Maybe I'm just too old!
>>Should Merlin be seperating these notion (e.g. using one logging
>>channel for verbose dumping of full information and another
>>channel for consolidated reposting)?
>>
>
>Interesting notion. Requires more thought than I have to spare at the
>moment.
>
Yep.
Cheers, Steve.
>
> --- Noel
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>For additional commands, e-mail: server-dev-help@james.apache.org
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Useful error messages
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>>>As I understand it from your previous notes, Merlin is primarily short in
>>>the area of log configuration?
>>>
>
>>It's the reverse - well almost. The reverse would suggest that Merlin
>>is long in the area of short configurations which doesn't really man
>>anything to me.
>>
>
>Huh? Stephen, read it again. L-O-G, not l-o-N-g. I thought that you had
>said that Merlin did not yet have the *L-O-G* configurability that Phoenix
>provides.
>
Yes, yes - Steve was blind drunk at the time he posted that reply. See
the following message for the real response.
http://marc.theaimsgroup.com/?l=avalon-dev&m=106211727608122&w=2
>
>>If you can reformulate the question I'll try and give you an answer.
>>
>
>I can reformulate it, or you can clean your monitor. :-p
>
ROTFL (if you could only see my monitor)
>
>>merlin is what you want it to be for whatever your configuration
>>requirements are. Phoenix style "put it all together solution"
>>- no problem (except that it doesn't scale). Merlin style - break
>>out the different logical usage abstractions and package them
>>accordingly - and your starting to move towards something scalable.
>>
>
>Example?
>
If your build an application that requires a bunch of different
facilities and if you forced to bring together configuration information
for all of those facilities into one file - things become
non-managable. Imagine a framework composed of six major sub-systems of
which one is james. There are two problems here - firstly scalability
from a human management point of view, and secondly scalability from a
systems point of view.
The human scalability issue can be addressed by breaking out type,
deployment, and context aspects of a configuration and associating them
with different system artifacts. For example, type related
configuration information is normally a developer concerns and can be
associated with a release. Its the sort of information that would not
normally be modified. Deployment information is characterizing the
deployment of a component - this could reflect differences between a
file based deployment versus a RDMS based deployment scenarios. These
"scenario" related configurations can be presented as deployment
profiles and packaged with a release. Finally, the deployment context
aspect deals with things like usernames, passwords, host names, DNS
entries, etc. - i.e. stuff that really is the subject of the particular
context of deployment.
Merlin provides support for all of these aspects and handles the
packaging and ultimate integration of these multiple confiuration
sources into a consolidated configuration that is applied at runtime.
We still have work to do to handle the structural scalability question -
namely the ability to provide service management across multiple JVMs.
What we do have that is an important ingridient towards this is the
notion of virtual components. You can take the "james-system" and
declare the publication of specific services (e.g. the Mailet
services). This allows James to be viewed as just another component.
>>Merlin will provide probably a higher level of deployment relability,
>>but less frills at that system level of abstraction (e.g. you don't
>>have the JMX and logging options currently available in Phonenix at
>>this time) - but you do have more frills on finner grain abstractions
>>such as ... component reuse.
>>
>
>Aha! See: "don't have the JMX and L-O-G-G-I-N-G options currently ..." I
>did remember it correctly.
>
Yes you did remember correctly!!
>OK, what are the differences for L-O-G-G-I-N-G?
>
Phoenix provides support for the Excalibur Logging package (all of that
logging related XML). Merlin has a much smaller subset in terms of
functionality - however the functionality is better seperated in terms
of what are container concerns and what are component deployment
concerns. It probably would not take a lot effort to upgrade Merlin to
provide support for Excalibur Logging but its not terribly high on the
list of priorities (things like JMX intelligence are way higher).
>
>We currently disable JMX, so until it is done properly, I don't think that's
>an issue.
>
On the JMX side of things - the current thinking inside Merlin
development is to provide intelligent management based on the internal
Merlin component meta-model. What this will provide is management of
any component without the need for the component author to write a
single line of code (stuff like reconfiguration, recontextaulization,
etc.). Combine that with functionality along the lines of Phoenix JMX
support and we will have a really nice management solution. This is one
of things I would like to look at following a 3.0 release.
>>Running James on Merlin means:
>> 1. massive simplification of the system configuration
>> 2. greater reliability during deployment
>> 3. better error handling
>> 4. ability to reuse James with other components
>> 5. simplification of the development process
>> 6. development time testing and validation of deployment
>>
>
>All of the above require justification. Good to know, but require
>justification.
>
What sort of justification I you looking for? I can easily provide
information about my own experience and the underlying reasons why these
features were developed if that what you mean. On the otherhand, if
your looking for justification that they actually translate into a value
proposition then the best we to address this is to download Merlin and
setup a runtime James instance.
http://www.ibiblio.org/merlin/distributions/
I'm actually planning on putting James into deployment as the enterprise
messaging solution for "yet-to-be-announced" project - but before doing
this, a key aspect will be demonstrating the utility of James as a
virtual component. For this I'll be looking for some assistance here
;-). But that's a topic for another thread.
>I would be happy if startup and footprint were lighter, so
>that we could run multiple processes, instead of one monolithic process
>
Just comparing foootprints ...
Phoenix is about 4Mb. Merlin is a bit over 2Mb.
>
>(e.g., separate protocol handling services into separate processes connected
>via repositories/spool; and the pipeline processing in its own process,
>too).
>
I'm thinking along the same lines. The solution to this problem is
non-trivial. While Merlin can do all of the service deployment within a
single JVM, we don't have "standard" mechanisms for remote service
resolution or the related service interaction protocols in place
(manager to manager). However, this is top-of-the-agenda. What we want
is scalable, robust, fault-tolerant deployment and James is a hell of
good test case (in fact its been the main testcase for Merlin for the
past nine months).
>As an optional configuration, it would be helpful. Personally, I am
>very tempted to do it in my own deployment because it means I could
>reconfigure & restart the pipeline without having to take down the SMTP and
>POP3 services.
>
This is addressed under the JMX related appliance management plans.
What we want to be able to do is redeploy a manager (appliance) and have
the container handle the automation of the suspension and/or
decommissioning of consumers. This works locally but doing this with
remote services requires a federated service management protocol. For
example, if I have a user repository (identity and credentials) shared
by OpenIM and James, and if I need to redeploy that server I need to
signal to consumers that a suspension (or switch) is initiated and
subsequently resumed (re-swithed) to the updated service provider.
>>I don't think the System.err output is really relevant - that's just a
>>output target.
>>
>
>I was refering to what Phoenix does.
>
Sorry - I stopped using Phoneix about 6 months ago and my memory for
details is getting rusty already. Maybe I'm just too old!
>>Should Merlin be seperating these notion (e.g. using one logging
>>channel for verbose dumping of full information and another
>>channel for consolidated reposting)?
>>
>
>Interesting notion. Requires more thought than I have to spare at the
>moment.
>
Yep.
Cheers, Steve.
>
> --- Noel
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>For additional commands, e-mail: server-dev-help@james.apache.org
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org