Discussion: Application Metrics Feature

[Adrian Crum-3]

I have an application metrics feature working on my local copy and I was
wondering if there would be any interest in including it in the project.

A metric is a measure of average execution time. Each metric is given a
unique name.

I modified the control servlet and service dispatcher to use metrics. To
add a metric to a request, just include an XML element:

<metric name="URL: webtools/main" />

to the request map and the average response time for the URL will be
maintained. Likewise, to add a metric to a service, just include an XML
element:

<metric name="Service: createMaintsFromTimeInterval" />

to the service definition and the average execution time for the service
will be maintained.

Metrics are kept in memory. There is a service to retrieve all metrics.
There is also a Web Tools page to view all metrics.

A heartbeat server could retrieve the metrics to check on server load or
to provide histograms.

The metric element has an optional threshold attribute, so some action
could be taken when the metric crosses a threshold. For example, in the
following request map:

<request-map uri="ViewMetrics">
     <security https="true" auth="true"/>
     <metric name="URL: webtools/ViewMetrics" threshold="1000"/>
     <response name="success" type="view" value="ViewMetrics"/>
     <response name="threshold-exceeded" type="view"
value="ServerBusy"/><!-- displays a friendly 'server busy' page -->
</request-map>

the ServerBusy view would be rendered if the average response time
exceeded 1000 mS. This can be useful for providing a lively web
experience on a heavy-traffic web page.

The service dispatcher does not use the threshold. I could not think of
a use case where service behavior should be modified based on average
execution time.

The metrics code is very small - two java files. Also, the modifications
to the webapp component and service component are very small.

What do you think?

-Adrian

[Jacopo Cappellato-4]

Adrian,

thank you for the clear description and proposal; I like it very much and I would be happy to see it in OFBiz.

Regards,

Jacopo

On Jul 14, 2012, at 12:38 PM, Adrian Crum wrote:

> I have an application metrics feature working on my local copy and I was wondering if there would be any interest in including it in the project.
>
> A metric is a measure of average execution time. Each metric is given a unique name.
>
> I modified the control servlet and service dispatcher to use metrics. To add a metric to a request, just include an XML element:
>
> <metric name="URL: webtools/main" />
>
> to the request map and the average response time for the URL will be maintained. Likewise, to add a metric to a service, just include an XML element:
>
> <metric name="Service: createMaintsFromTimeInterval" />
>
> to the service definition and the average execution time for the service will be maintained.
>
> Metrics are kept in memory. There is a service to retrieve all metrics. There is also a Web Tools page to view all metrics.
>
> A heartbeat server could retrieve the metrics to check on server load or to provide histograms.
>
> The metric element has an optional threshold attribute, so some action could be taken when the metric crosses a threshold. For example, in the following request map:
>
> <request-map uri="ViewMetrics">
>    <security https="true" auth="true"/>
>    <metric name="URL: webtools/ViewMetrics" threshold="1000"/>
>    <response name="success" type="view" value="ViewMetrics"/>
>    <response name="threshold-exceeded" type="view" value="ServerBusy"/><!-- displays a friendly 'server busy' page -->
> </request-map>
>
> the ServerBusy view would be rendered if the average response time exceeded 1000 mS. This can be useful for providing a lively web experience on a heavy-traffic web page.
>
> The service dispatcher does not use the threshold. I could not think of a use case where service behavior should be modified based on average execution time.
>
> The metrics code is very small - two java files. Also, the modifications to the webapp component and service component are very small.
>
> What do you think?
>
> -Adrian
>

[Jacques Le Roux]

+1, looks quite good to me!

Jacques

From: "Jacopo Cappellato" <[hidden email]>

> Adrian,
>
> thank you for the clear description and proposal; I like it very much and I would be happy to see it in OFBiz.
>
> Regards,
>
> Jacopo
>
> On Jul 14, 2012, at 12:38 PM, Adrian Crum wrote:
>
>> I have an application metrics feature working on my local copy and I was wondering if there would be any interest in including it
>> in the project.
>>
>> A metric is a measure of average execution time. Each metric is given a unique name.
>>
>> I modified the control servlet and service dispatcher to use metrics. To add a metric to a request, just include an XML element:
>>
>> <metric name="URL: webtools/main" />
>>
>> to the request map and the average response time for the URL will be maintained. Likewise, to add a metric to a service, just
>> include an XML element:
>>
>> <metric name="Service: createMaintsFromTimeInterval" />
>>
>> to the service definition and the average execution time for the service will be maintained.
>>
>> Metrics are kept in memory. There is a service to retrieve all metrics. There is also a Web Tools page to view all metrics.
>>
>> A heartbeat server could retrieve the metrics to check on server load or to provide histograms.
>>
>> The metric element has an optional threshold attribute, so some action could be taken when the metric crosses a threshold. For
>> example, in the following request map:
>>
>> <request-map uri="ViewMetrics">
>>    <security https="true" auth="true"/>
>>    <metric name="URL: webtools/ViewMetrics" threshold="1000"/>
>>    <response name="success" type="view" value="ViewMetrics"/>
>>    <response name="threshold-exceeded" type="view" value="ServerBusy"/><!-- displays a friendly 'server busy' page -->
>> </request-map>
>>
>> the ServerBusy view would be rendered if the average response time exceeded 1000 mS. This can be useful for providing a lively
>> web experience on a heavy-traffic web page.
>>
>> The service dispatcher does not use the threshold. I could not think of a use case where service behavior should be modified
>> based on average execution time.
>>
>> The metrics code is very small - two java files. Also, the modifications to the webapp component and service component are very
>> small.
>>
>> What do you think?
>>
>> -Adrian
>>
>
>

[Adrian Crum-3]

At first glance, this might seem like a duplication of
ServerHitBin.java, but it isn't. The metrics Java code will be in the
base component, and it is designed to be used to measure any part of the
project, not just web app requests.

-Adrian

On 7/14/2012 12:28 PM, Jacopo Cappellato wrote:

> Adrian,
>
> thank you for the clear description and proposal; I like it very much and I would be happy to see it in OFBiz.
>
> Regards,
>
> Jacopo
>
> On Jul 14, 2012, at 12:38 PM, Adrian Crum wrote:
>
>> I have an application metrics feature working on my local copy and I was wondering if there would be any interest in including it in the project.
>>
>> A metric is a measure of average execution time. Each metric is given a unique name.
>>
>> I modified the control servlet and service dispatcher to use metrics. To add a metric to a request, just include an XML element:
>>
>> <metric name="URL: webtools/main" />
>>
>> to the request map and the average response time for the URL will be maintained. Likewise, to add a metric to a service, just include an XML element:
>>
>> <metric name="Service: createMaintsFromTimeInterval" />
>>
>> to the service definition and the average execution time for the service will be maintained.
>>
>> Metrics are kept in memory. There is a service to retrieve all metrics. There is also a Web Tools page to view all metrics.
>>
>> A heartbeat server could retrieve the metrics to check on server load or to provide histograms.
>>
>> The metric element has an optional threshold attribute, so some action could be taken when the metric crosses a threshold. For example, in the following request map:
>>
>> <request-map uri="ViewMetrics">
>>     <security https="true" auth="true"/>
>>     <metric name="URL: webtools/ViewMetrics" threshold="1000"/>
>>     <response name="success" type="view" value="ViewMetrics"/>
>>     <response name="threshold-exceeded" type="view" value="ServerBusy"/><!-- displays a friendly 'server busy' page -->
>> </request-map>
>>
>> the ServerBusy view would be rendered if the average response time exceeded 1000 mS. This can be useful for providing a lively web experience on a heavy-traffic web page.
>>
>> The service dispatcher does not use the threshold. I could not think of a use case where service behavior should be modified based on average execution time.
>>
>> The metrics code is very small - two java files. Also, the modifications to the webapp component and service component are very small.
>>
>> What do you think?
>>
>> -Adrian
>>

[Jacopo Cappellato-4]

On Jul 14, 2012, at 4:18 PM, Adrian Crum wrote:

> At first glance, this might seem like a duplication of ServerHitBin.java, but it isn't. The metrics Java code will be in the base component, and it is designed to be used to measure any part of the project, not just web app requests.
>
> -Adrian
>

I know that there are features in the ServerHitBin class to gather stats about services and entities, but I don't remember how they are implemented and if they are fully used.

Jacopo

[Michael Brohl-2]

Hi Adrian,

that sounds like an interesting feature for OFBiz.
I would like to have it available in the project.

Thanks and regards,

Michael

Am 14.07.2012 12:38, schrieb Adrian Crum:

> I have an application metrics feature working on my local copy and I
> was wondering if there would be any interest in including it in the
> project.
>
> A metric is a measure of average execution time. Each metric is given
> a unique name.
>
> I modified the control servlet and service dispatcher to use metrics.
> To add a metric to a request, just include an XML element:
>
> <metric name="URL: webtools/main" />
>
> to the request map and the average response time for the URL will be
> maintained. Likewise, to add a metric to a service, just include an
> XML element:
>
> <metric name="Service: createMaintsFromTimeInterval" />
>
> to the service definition and the average execution time for the
> service will be maintained.
>
> Metrics are kept in memory. There is a service to retrieve all
> metrics. There is also a Web Tools page to view all metrics.
>
> A heartbeat server could retrieve the metrics to check on server load
> or to provide histograms.
>
> The metric element has an optional threshold attribute, so some action
> could be taken when the metric crosses a threshold. For example, in
> the following request map:
>
> <request-map uri="ViewMetrics">
>     <security https="true" auth="true"/>
>     <metric name="URL: webtools/ViewMetrics" threshold="1000"/>
>     <response name="success" type="view" value="ViewMetrics"/>
>     <response name="threshold-exceeded" type="view"
> value="ServerBusy"/><!-- displays a friendly 'server busy' page -->
> </request-map>
>
> the ServerBusy view would be rendered if the average response time
> exceeded 1000 mS. This can be useful for providing a lively web
> experience on a heavy-traffic web page.
>
> The service dispatcher does not use the threshold. I could not think
> of a use case where service behavior should be modified based on
> average execution time.
>
> The metrics code is very small - two java files. Also, the
> modifications to the webapp component and service component are very
> small.
>
> What do you think?
>
> -Adrian
>

[Adrian Crum-3]

On 7/14/2012 3:40 PM, Jacopo Cappellato wrote:
> On Jul 14, 2012, at 4:18 PM, Adrian Crum wrote:
>
>> At first glance, this might seem like a duplication of ServerHitBin.java, but it isn't. The metrics Java code will be in the base component, and it is designed to be used to measure any part of the project, not just web app requests.
>>
>> -Adrian
>>
> I know that there are features in the ServerHitBin class to gather stats about services and entities, but I don't remember how they are implemented and if they are fully used.
>
> Jacopo

The ServerHitBin entity and service methods are not used currently.
Metrics could be kept for entities, but I don't think that they would be
meaningful - so I didn't add them. If someone comes up with a need for
entity metrics, then the capability can be added easily.

In a nutshell, the ServerHitBin code is quite heavy - it uses the entity
engine to store the metrics. The design I used is from SEDA - it is
meant to be used in a "feedback loop" that is used to control web
application response times, so it is small and fast. Also, ServerHitBin
stats are kept for every request, but the metrics code is more strategic
- you maintain metrics only in the areas you are concerned with.

-Adrian

[Ruth Hoffman-2]

Hi Adrian:
Shouldn't this be discussed on the "user" list? IMHO Words like
"applications" and "stats about services and entities"...those are all
indicative of user requirements, not developer requirements.

Users should be driving requirements gathering and analysis for OFBiz
and not developers.
Just my 2 cents.
Regards,
Ruth
On 7/15/12 4:41 AM, Adrian Crum wrote:

> On 7/14/2012 3:40 PM, Jacopo Cappellato wrote:
>> On Jul 14, 2012, at 4:18 PM, Adrian Crum wrote:
>>
>>> At first glance, this might seem like a duplication of
>>> ServerHitBin.java, but it isn't. The metrics Java code will be in
>>> the base component, and it is designed to be used to measure any
>>> part of the project, not just web app requests.
>>>
>>> -Adrian
>>>
>> I know that there are features in the ServerHitBin class to gather
>> stats about services and entities, but I don't remember how they are
>> implemented and if they are fully used.
>>
>> Jacopo
>
> The ServerHitBin entity and service methods are not used currently.
> Metrics could be kept for entities, but I don't think that they would
> be meaningful - so I didn't add them. If someone comes up with a need
> for entity metrics, then the capability can be added easily.
>
> In a nutshell, the ServerHitBin code is quite heavy - it uses the
> entity engine to store the metrics. The design I used is from SEDA -
> it is meant to be used in a "feedback loop" that is used to control
> web application response times, so it is small and fast. Also,
> ServerHitBin stats are kept for every request, but the metrics code is
> more strategic - you maintain metrics only in the areas you are
> concerned with.
>
> -Adrian
>
>

[Adrian Crum-3]

Ruth,

I understand your viewpoint. Personally, I prefer to present my ideas to
the dev list to see if it is something the dev community wants included
in the project. Users might like a new feature, but that doesn't mean
the dev community wants it in the project. If there was no interest from
the dev community, then I would offer it as an add-on product and
announce it on the user list.

I am also a user, and the design was based on the requirement to monitor
and control server performance. I suppose I could go to the user list
for more ideas, but the code I'm planning to commit is pretty basic, and
users will be free to enhance it in whatever way they please.

-Adrian

On 7/15/2012 12:13 PM, Ruth Hoffman wrote:

> Hi Adrian:
> Shouldn't this be discussed on the "user" list? IMHO Words like
> "applications" and "stats about services and entities"...those are all
> indicative of user requirements, not developer requirements.
>
> Users should be driving requirements gathering and analysis for OFBiz
> and not developers.
> Just my 2 cents.
> Regards,
> Ruth
> On 7/15/12 4:41 AM, Adrian Crum wrote:
>> On 7/14/2012 3:40 PM, Jacopo Cappellato wrote:
>>> On Jul 14, 2012, at 4:18 PM, Adrian Crum wrote:
>>>
>>>> At first glance, this might seem like a duplication of
>>>> ServerHitBin.java, but it isn't. The metrics Java code will be in
>>>> the base component, and it is designed to be used to measure any
>>>> part of the project, not just web app requests.
>>>>
>>>> -Adrian
>>>>
>>> I know that there are features in the ServerHitBin class to gather
>>> stats about services and entities, but I don't remember how they are
>>> implemented and if they are fully used.
>>>
>>> Jacopo
>>
>> The ServerHitBin entity and service methods are not used currently.
>> Metrics could be kept for entities, but I don't think that they would
>> be meaningful - so I didn't add them. If someone comes up with a need
>> for entity metrics, then the capability can be added easily.
>>
>> In a nutshell, the ServerHitBin code is quite heavy - it uses the
>> entity engine to store the metrics. The design I used is from SEDA -
>> it is meant to be used in a "feedback loop" that is used to control
>> web application response times, so it is small and fast. Also,
>> ServerHitBin stats are kept for every request, but the metrics code
>> is more strategic - you maintain metrics only in the areas you are
>> concerned with.
>>
>> -Adrian
>>
>>
>
>

[Pierre Smits]

I agree with Ruth. This sounds like a user requirement. And the community
should decide on this.

Furthermore, the remark 'users might like a new feature, but that doesn't
mean the dev community wants it in the project' smells like measuring with
double standards; as if the meritocratic principle doesn't apply when the
committers don't want it in. Or as if changes always get in, when only the
committers want it.

2012/7/15 Adrian Crum <[hidden email]>

> Ruth,
>
> I understand your viewpoint. Personally, I prefer to present my ideas to
> the dev list to see if it is something the dev community wants included in
> the project. Users might like a new feature, but that doesn't mean the dev
> community wants it in the project. If there was no interest from the dev
> community, then I would offer it as an add-on product and announce it on
> the user list.
>
> I am also a user, and the design was based on the requirement to monitor
> and control server performance. I suppose I could go to the user list for
> more ideas, but the code I'm planning to commit is pretty basic, and users
> will be free to enhance it in whatever way they please.
>
> -Adrian
>
>
> On 7/15/2012 12:13 PM, Ruth Hoffman wrote:
>
>> Hi Adrian:
>> Shouldn't this be discussed on the "user" list? IMHO Words like
>> "applications" and "stats about services and entities"...those are all
>> indicative of user requirements, not developer requirements.
>>
>> Users should be driving requirements gathering and analysis for OFBiz and
>> not developers.
>> Just my 2 cents.
>> Regards,
>> Ruth
>>
>

[Adrian Crum-3]

No, it smells like the current goal of moving things we don't want in
the main project to external projects. This type of decision-making has
been going on for years.

-Adrian

On 7/16/2012 9:45 AM, Pierre Smits wrote:

> I agree with Ruth. This sounds like a user requirement. And the community
> should decide on this.
>
> Furthermore, the remark 'users might like a new feature, but that doesn't
> mean the dev community wants it in the project' smells like measuring with
> double standards; as if the meritocratic principle doesn't apply when the
> committers don't want it in. Or as if changes always get in, when only the
> committers want it.
>
> 2012/7/15 Adrian Crum <[hidden email]>
>
>> Ruth,
>>
>> I understand your viewpoint. Personally, I prefer to present my ideas to
>> the dev list to see if it is something the dev community wants included in
>> the project. Users might like a new feature, but that doesn't mean the dev
>> community wants it in the project. If there was no interest from the dev
>> community, then I would offer it as an add-on product and announce it on
>> the user list.
>>
>> I am also a user, and the design was based on the requirement to monitor
>> and control server performance. I suppose I could go to the user list for
>> more ideas, but the code I'm planning to commit is pretty basic, and users
>> will be free to enhance it in whatever way they please.
>>
>> -Adrian
>>
>>
>> On 7/15/2012 12:13 PM, Ruth Hoffman wrote:
>>
>>> Hi Adrian:
>>> Shouldn't this be discussed on the "user" list? IMHO Words like
>>> "applications" and "stats about services and entities"...those are all
>>> indicative of user requirements, not developer requirements.
>>>
>>> Users should be driving requirements gathering and analysis for OFBiz and
>>> not developers.
>>> Just my 2 cents.
>>> Regards,
>>> Ruth
>>>

[Pierre Smits]

You mean excluding parts of the community from participating in the
decision-taking processes?

2012/7/16 Adrian Crum <[hidden email]>

> No, it smells like the current goal of moving things we don't want in the
> main project to external projects. This type of decision-making has been
> going on for years.
>
> -Adrian
>
>
> On 7/16/2012 9:45 AM, Pierre Smits wrote:
>
>> I agree with Ruth. This sounds like a user requirement. And the community
>> should decide on this.
>>
>> Furthermore, the remark 'users might like a new feature, but that doesn't
>> mean the dev community wants it in the project' smells like measuring with
>> double standards; as if the meritocratic principle doesn't apply when the
>> committers don't want it in. Or as if changes always get in, when only the
>> committers want it.
>>
>> 2012/7/15 Adrian Crum <adrian.crum@sandglass-**software.com<[hidden email]>
>> >
>>
>>  Ruth,
>>>
>>> I understand your viewpoint. Personally, I prefer to present my ideas to
>>> the dev list to see if it is something the dev community wants included
>>> in
>>> the project. Users might like a new feature, but that doesn't mean the
>>> dev
>>> community wants it in the project. If there was no interest from the dev
>>> community, then I would offer it as an add-on product and announce it on
>>> the user list.
>>>
>>> I am also a user, and the design was based on the requirement to monitor
>>> and control server performance. I suppose I could go to the user list for
>>> more ideas, but the code I'm planning to commit is pretty basic, and
>>> users
>>> will be free to enhance it in whatever way they please.
>>>
>>> -Adrian
>>>
>>>
>>> On 7/15/2012 12:13 PM, Ruth Hoffman wrote:
>>>
>>>  Hi Adrian:
>>>> Shouldn't this be discussed on the "user" list? IMHO Words like
>>>> "applications" and "stats about services and entities"...those are all
>>>> indicative of user requirements, not developer requirements.
>>>>
>>>> Users should be driving requirements gathering and analysis for OFBiz
>>>> and
>>>> not developers.
>>>> Just my 2 cents.
>>>> Regards,
>>>> Ruth
>>>>
>>>>
>
>

[Adrian Crum-3]

Please take some time to understand the purpose of the mailing lists:

https://cwiki.apache.org/OFBADMIN/mailing-lists.html

If a user wants to be involved in the design of OFBiz, then they need to
be subscribed to the dev list. We do not discuss requirements and
designs on the user list.

No one is excluded from participation. I proposed an idea. Others
commented on it. If there had been any objections to including it in the
project, then I would offer it as an add-on. Excluding a proposal from
the project does not equal exclusion from participation.

-Adrian

On 7/16/2012 10:11 AM, Pierre Smits wrote:

> You mean excluding parts of the community from participating in the
> decision-taking processes?
>
> 2012/7/16 Adrian Crum <[hidden email]>
>
>> No, it smells like the current goal of moving things we don't want in the
>> main project to external projects. This type of decision-making has been
>> going on for years.
>>
>> -Adrian
>>
>>
>> On 7/16/2012 9:45 AM, Pierre Smits wrote:
>>
>>> I agree with Ruth. This sounds like a user requirement. And the community
>>> should decide on this.
>>>
>>> Furthermore, the remark 'users might like a new feature, but that doesn't
>>> mean the dev community wants it in the project' smells like measuring with
>>> double standards; as if the meritocratic principle doesn't apply when the
>>> committers don't want it in. Or as if changes always get in, when only the
>>> committers want it.
>>>
>>> 2012/7/15 Adrian Crum <adrian.crum@sandglass-**software.com<[hidden email]>
>>>   Ruth,
>>>> I understand your viewpoint. Personally, I prefer to present my ideas to
>>>> the dev list to see if it is something the dev community wants included
>>>> in
>>>> the project. Users might like a new feature, but that doesn't mean the
>>>> dev
>>>> community wants it in the project. If there was no interest from the dev
>>>> community, then I would offer it as an add-on product and announce it on
>>>> the user list.
>>>>
>>>> I am also a user, and the design was based on the requirement to monitor
>>>> and control server performance. I suppose I could go to the user list for
>>>> more ideas, but the code I'm planning to commit is pretty basic, and
>>>> users
>>>> will be free to enhance it in whatever way they please.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> On 7/15/2012 12:13 PM, Ruth Hoffman wrote:
>>>>
>>>>   Hi Adrian:
>>>>> Shouldn't this be discussed on the "user" list? IMHO Words like
>>>>> "applications" and "stats about services and entities"...those are all
>>>>> indicative of user requirements, not developer requirements.
>>>>>
>>>>> Users should be driving requirements gathering and analysis for OFBiz
>>>>> and
>>>>> not developers.
>>>>> Just my 2 cents.
>>>>> Regards,
>>>>> Ruth
>>>>>
>>>>>
>>

[Scott Gray-2]

It all comes back to a general misunderstanding of the difference between the user and dev lists.

The user list is for people who are using OFBiz as a business user or developing customized applications.  When these types of people have a question, the user list is definitely appropriate.  They don't necessarily care about the ongoing development of OFBiz itself, they need to discuss how to use what has been released.
The dev list is for people who are interested in the ongoing development of OFBiz and wish to contribute code, documentation and ideas.  If you care about the future of OFBiz then this is where you come and contribute.

No one is attempting to exclude OFBiz users from any discussions, if they want to be involved in the development of OFBiz then they subscribe to the dev list just like everyone else.  I feel like a broken record though, is there some way that we can more clearly articulate the distinction to the community?

Regards
Scott

On 16/07/2012, at 9:11 PM, Pierre Smits wrote:

> You mean excluding parts of the community from participating in the
> decision-taking processes?
>
> 2012/7/16 Adrian Crum <[hidden email]>
>
>> No, it smells like the current goal of moving things we don't want in the
>> main project to external projects. This type of decision-making has been
>> going on for years.
>>
>> -Adrian
>>
>>
>> On 7/16/2012 9:45 AM, Pierre Smits wrote:
>>
>>> I agree with Ruth. This sounds like a user requirement. And the community
>>> should decide on this.
>>>
>>> Furthermore, the remark 'users might like a new feature, but that doesn't
>>> mean the dev community wants it in the project' smells like measuring with
>>> double standards; as if the meritocratic principle doesn't apply when the
>>> committers don't want it in. Or as if changes always get in, when only the
>>> committers want it.
>>>
>>> 2012/7/15 Adrian Crum <adrian.crum@sandglass-**software.com<[hidden email]>
>>>>
>>>
>>> Ruth,
>>>>
>>>> I understand your viewpoint. Personally, I prefer to present my ideas to
>>>> the dev list to see if it is something the dev community wants included
>>>> in
>>>> the project. Users might like a new feature, but that doesn't mean the
>>>> dev
>>>> community wants it in the project. If there was no interest from the dev
>>>> community, then I would offer it as an add-on product and announce it on
>>>> the user list.
>>>>
>>>> I am also a user, and the design was based on the requirement to monitor
>>>> and control server performance. I suppose I could go to the user list for
>>>> more ideas, but the code I'm planning to commit is pretty basic, and
>>>> users
>>>> will be free to enhance it in whatever way they please.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> On 7/15/2012 12:13 PM, Ruth Hoffman wrote:
>>>>
>>>> Hi Adrian:
>>>>> Shouldn't this be discussed on the "user" list? IMHO Words like
>>>>> "applications" and "stats about services and entities"...those are all
>>>>> indicative of user requirements, not developer requirements.
>>>>>
>>>>> Users should be driving requirements gathering and analysis for OFBiz
>>>>> and
>>>>> not developers.
>>>>> Just my 2 cents.
>>>>> Regards,
>>>>> Ruth
>>>>>
>>>>>
>>
>>

[Pierre Smits]

This isn't about what the mailing lists are for.

Don't try to fill in what others care about or need. But it would
definitely help if you would be a community member first, in stead of
placing yourself above it.


2012/7/16 Scott Gray <[hidden email]>

> It all comes back to a general misunderstanding of the difference between
> the user and dev lists.
>
> The user list is for people who are using OFBiz as a business user or
> developing customized applications.  When these types of people have a
> question, the user list is definitely appropriate.  They don't necessarily
> care about the ongoing development of OFBiz itself, they need to discuss
> how to use what has been released.
> The dev list is for people who are interested in the ongoing development
> of OFBiz and wish to contribute code, documentation and ideas.  If you care
> about the future of OFBiz then this is where you come and contribute.
>
> No one is attempting to exclude OFBiz users from any discussions, if they
> want to be involved in the development of OFBiz then they subscribe to the
> dev list just like everyone else.  I feel like a broken record though, is
> there some way that we can more clearly articulate the distinction to the
> community?
>
> Regards
> Scott
>
> On 16/07/2012, at 9:11 PM, Pierre Smits wrote:
>
> > You mean excluding parts of the community from participating in the
> > decision-taking processes?
> >
> > 2012/7/16 Adrian Crum <[hidden email]>
> >
> >> No, it smells like the current goal of moving things we don't want in
> the
> >> main project to external projects. This type of decision-making has been
> >> going on for years.
> >>
> >> -Adrian
> >>
> >>
> >> On 7/16/2012 9:45 AM, Pierre Smits wrote:
> >>
> >>> I agree with Ruth. This sounds like a user requirement. And the
> community
> >>> should decide on this.
> >>>
> >>> Furthermore, the remark 'users might like a new feature, but that
> doesn't
> >>> mean the dev community wants it in the project' smells like measuring
> with
> >>> double standards; as if the meritocratic principle doesn't apply when
> the
> >>> committers don't want it in. Or as if changes always get in, when only
> the
> >>> committers want it.
> >>>
> >>> 2012/7/15 Adrian Crum <adrian.crum@sandglass-**software.com<
> [hidden email]>
> >>>>
> >>>
> >>> Ruth,
> >>>>
> >>>> I understand your viewpoint. Personally, I prefer to present my ideas
> to
> >>>> the dev list to see if it is something the dev community wants
> included
> >>>> in
> >>>> the project. Users might like a new feature, but that doesn't mean the
> >>>> dev
> >>>> community wants it in the project. If there was no interest from the
> dev
> >>>> community, then I would offer it as an add-on product and announce it
> on
> >>>> the user list.
> >>>>
> >>>> I am also a user, and the design was based on the requirement to
> monitor
> >>>> and control server performance. I suppose I could go to the user list
> for
> >>>> more ideas, but the code I'm planning to commit is pretty basic, and
> >>>> users
> >>>> will be free to enhance it in whatever way they please.
> >>>>
> >>>> -Adrian
> >>>>
> >>>>
> >>>> On 7/15/2012 12:13 PM, Ruth Hoffman wrote:
> >>>>
> >>>> Hi Adrian:
> >>>>> Shouldn't this be discussed on the "user" list? IMHO Words like
> >>>>> "applications" and "stats about services and entities"...those are
> all
> >>>>> indicative of user requirements, not developer requirements.
> >>>>>
> >>>>> Users should be driving requirements gathering and analysis for OFBiz
> >>>>> and
> >>>>> not developers.
> >>>>> Just my 2 cents.
> >>>>> Regards,
> >>>>> Ruth
> >>>>>
> >>>>>
> >>
> >>
>
>

[Adrian Crum-3]

If anyone is placing themselves over anyone else, it is you. Scott and I
are trying to help you understand how this community works, but you are
not interested in being taught - you are only interested in railroading
through your opinions.

-Adrian

On 7/16/2012 10:59 AM, Pierre Smits wrote:

> This isn't about what the mailing lists are for.
>
> Don't try to fill in what others care about or need. But it would
> definitely help if you would be a community member first, in stead of
> placing yourself above it.
>
>
> 2012/7/16 Scott Gray <[hidden email]>
>
>> It all comes back to a general misunderstanding of the difference between
>> the user and dev lists.
>>
>> The user list is for people who are using OFBiz as a business user or
>> developing customized applications.  When these types of people have a
>> question, the user list is definitely appropriate.  They don't necessarily
>> care about the ongoing development of OFBiz itself, they need to discuss
>> how to use what has been released.
>> The dev list is for people who are interested in the ongoing development
>> of OFBiz and wish to contribute code, documentation and ideas.  If you care
>> about the future of OFBiz then this is where you come and contribute.
>>
>> No one is attempting to exclude OFBiz users from any discussions, if they
>> want to be involved in the development of OFBiz then they subscribe to the
>> dev list just like everyone else.  I feel like a broken record though, is
>> there some way that we can more clearly articulate the distinction to the
>> community?
>>
>> Regards
>> Scott
>>
>> On 16/07/2012, at 9:11 PM, Pierre Smits wrote:
>>
>>> You mean excluding parts of the community from participating in the
>>> decision-taking processes?
>>>
>>> 2012/7/16 Adrian Crum <[hidden email]>
>>>
>>>> No, it smells like the current goal of moving things we don't want in
>> the
>>>> main project to external projects. This type of decision-making has been
>>>> going on for years.
>>>>
>>>> -Adrian
>>>>
>>>>
>>>> On 7/16/2012 9:45 AM, Pierre Smits wrote:
>>>>
>>>>> I agree with Ruth. This sounds like a user requirement. And the
>> community
>>>>> should decide on this.
>>>>>
>>>>> Furthermore, the remark 'users might like a new feature, but that
>> doesn't
>>>>> mean the dev community wants it in the project' smells like measuring
>> with
>>>>> double standards; as if the meritocratic principle doesn't apply when
>> the
>>>>> committers don't want it in. Or as if changes always get in, when only
>> the
>>>>> committers want it.
>>>>>
>>>>> 2012/7/15 Adrian Crum <adrian.crum@sandglass-**software.com<
>> [hidden email]>
>>>>> Ruth,
>>>>>> I understand your viewpoint. Personally, I prefer to present my ideas
>> to
>>>>>> the dev list to see if it is something the dev community wants
>> included
>>>>>> in
>>>>>> the project. Users might like a new feature, but that doesn't mean the
>>>>>> dev
>>>>>> community wants it in the project. If there was no interest from the
>> dev
>>>>>> community, then I would offer it as an add-on product and announce it
>> on
>>>>>> the user list.
>>>>>>
>>>>>> I am also a user, and the design was based on the requirement to
>> monitor
>>>>>> and control server performance. I suppose I could go to the user list
>> for
>>>>>> more ideas, but the code I'm planning to commit is pretty basic, and
>>>>>> users
>>>>>> will be free to enhance it in whatever way they please.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>>
>>>>>> On 7/15/2012 12:13 PM, Ruth Hoffman wrote:
>>>>>>
>>>>>> Hi Adrian:
>>>>>>> Shouldn't this be discussed on the "user" list? IMHO Words like
>>>>>>> "applications" and "stats about services and entities"...those are
>> all
>>>>>>> indicative of user requirements, not developer requirements.
>>>>>>>
>>>>>>> Users should be driving requirements gathering and analysis for OFBiz
>>>>>>> and
>>>>>>> not developers.
>>>>>>> Just my 2 cents.
>>>>>>> Regards,
>>>>>>> Ruth
>>>>>>>
>>>>>>>
>>>>
>>

[Pierre Smits]

Thank you, Adrian, for your opinion.

2012/7/16 Adrian Crum <[hidden email]>

> If anyone is placing themselves over anyone else, it is you. Scott and I
> are trying to help you understand how this community works, but you are not
> interested in being taught - you are only interested in railroading through
> your opinions.
>
> -Adrian
>
>
> On 7/16/2012 10:59 AM, Pierre Smits wrote:
>
>> This isn't about what the mailing lists are for.
>>
>> Don't try to fill in what others care about or need. But it would
>> definitely help if you would be a community member first, in stead of
>> placing yourself above it.
>>
>>
>> 2012/7/16 Scott Gray <[hidden email]>
>>
>>  It all comes back to a general misunderstanding of the difference between
>>> the user and dev lists.
>>>
>>> The user list is for people who are using OFBiz as a business user or
>>> developing customized applications.  When these types of people have a
>>> question, the user list is definitely appropriate.  They don't
>>> necessarily
>>> care about the ongoing development of OFBiz itself, they need to discuss
>>> how to use what has been released.
>>> The dev list is for people who are interested in the ongoing development
>>> of OFBiz and wish to contribute code, documentation and ideas.  If you
>>> care
>>> about the future of OFBiz then this is where you come and contribute.
>>>
>>> No one is attempting to exclude OFBiz users from any discussions, if they
>>> want to be involved in the development of OFBiz then they subscribe to
>>> the
>>> dev list just like everyone else.  I feel like a broken record though, is
>>> there some way that we can more clearly articulate the distinction to the
>>> community?
>>>
>>> Regards
>>> Scott
>>>
>>> On 16/07/2012, at 9:11 PM, Pierre Smits wrote:
>>>
>>>  You mean excluding parts of the community from participating in the
>>>> decision-taking processes?
>>>>
>>>> 2012/7/16 Adrian Crum <adrian.crum@sandglass-**software.com<[hidden email]>
>>>> >
>>>>
>>>>  No, it smells like the current goal of moving things we don't want in
>>>>>
>>>> the
>>>
>>>> main project to external projects. This type of decision-making has been
>>>>> going on for years.
>>>>>
>>>>> -Adrian
>>>>>
>>>>>
>>>>> On 7/16/2012 9:45 AM, Pierre Smits wrote:
>>>>>
>>>>>  I agree with Ruth. This sounds like a user requirement. And the
>>>>>>
>>>>> community
>>>
>>>> should decide on this.
>>>>>>
>>>>>> Furthermore, the remark 'users might like a new feature, but that
>>>>>>
>>>>> doesn't
>>>
>>>> mean the dev community wants it in the project' smells like measuring
>>>>>>
>>>>> with
>>>
>>>> double standards; as if the meritocratic principle doesn't apply when
>>>>>>
>>>>> the
>>>
>>>> committers don't want it in. Or as if changes always get in, when only
>>>>>>
>>>>> the
>>>
>>>> committers want it.
>>>>>>
>>>>>> 2012/7/15 Adrian Crum <adrian.crum@sandglass-**softw**are.com<http://software.com>
>>>>>> <
>>>>>>
>>>>> adrian.crum@sandglass-**software.com<[hidden email]>
>>> >
>>>
>>>> Ruth,
>>>>>>
>>>>>>> I understand your viewpoint. Personally, I prefer to present my ideas
>>>>>>>
>>>>>> to
>>>
>>>> the dev list to see if it is something the dev community wants
>>>>>>>
>>>>>> included
>>>
>>>> in
>>>>>>> the project. Users might like a new feature, but that doesn't mean
>>>>>>> the
>>>>>>> dev
>>>>>>> community wants it in the project. If there was no interest from the
>>>>>>>
>>>>>> dev
>>>
>>>> community, then I would offer it as an add-on product and announce it
>>>>>>>
>>>>>> on
>>>
>>>> the user list.
>>>>>>>
>>>>>>> I am also a user, and the design was based on the requirement to
>>>>>>>
>>>>>> monitor
>>>
>>>> and control server performance. I suppose I could go to the user list
>>>>>>>
>>>>>> for
>>>
>>>> more ideas, but the code I'm planning to commit is pretty basic, and
>>>>>>> users
>>>>>>> will be free to enhance it in whatever way they please.
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>>
>>>>>>> On 7/15/2012 12:13 PM, Ruth Hoffman wrote:
>>>>>>>
>>>>>>> Hi Adrian:
>>>>>>>
>>>>>>>> Shouldn't this be discussed on the "user" list? IMHO Words like
>>>>>>>> "applications" and "stats about services and entities"...those are
>>>>>>>>
>>>>>>> all
>>>
>>>> indicative of user requirements, not developer requirements.
>>>>>>>>
>>>>>>>> Users should be driving requirements gathering and analysis for
>>>>>>>> OFBiz
>>>>>>>> and
>>>>>>>> not developers.
>>>>>>>> Just my 2 cents.
>>>>>>>> Regards,
>>>>>>>> Ruth
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>
>
>

[Pierre Smits]

And for expressing that you think of it as if I need to be taught something
as a little child.

2012/7/16 Pierre Smits <[hidden email]>

> Thank you, Adrian, for your opinion.
>
>
> 2012/7/16 Adrian Crum <[hidden email]>
>
>> If anyone is placing themselves over anyone else, it is you. Scott and I
>> are trying to help you understand how this community works, but you are not
>> interested in being taught - you are only interested in railroading through
>> your opinions.
>>
>> -Adrian
>>
>>
>> On 7/16/2012 10:59 AM, Pierre Smits wrote:
>>
>>> This isn't about what the mailing lists are for.
>>>
>>> Don't try to fill in what others care about or need. But it would
>>> definitely help if you would be a community member first, in stead of
>>> placing yourself above it.
>>>
>>>
>>> 2012/7/16 Scott Gray <[hidden email]>
>>>
>>>  It all comes back to a general misunderstanding of the difference
>>>> between
>>>> the user and dev lists.
>>>>
>>>> The user list is for people who are using OFBiz as a business user or
>>>> developing customized applications.  When these types of people have a
>>>> question, the user list is definitely appropriate.  They don't
>>>> necessarily
>>>> care about the ongoing development of OFBiz itself, they need to discuss
>>>> how to use what has been released.
>>>> The dev list is for people who are interested in the ongoing development
>>>> of OFBiz and wish to contribute code, documentation and ideas.  If you
>>>> care
>>>> about the future of OFBiz then this is where you come and contribute.
>>>>
>>>> No one is attempting to exclude OFBiz users from any discussions, if
>>>> they
>>>> want to be involved in the development of OFBiz then they subscribe to
>>>> the
>>>> dev list just like everyone else.  I feel like a broken record though,
>>>> is
>>>> there some way that we can more clearly articulate the distinction to
>>>> the
>>>> community?
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> On 16/07/2012, at 9:11 PM, Pierre Smits wrote:
>>>>
>>>>  You mean excluding parts of the community from participating in the
>>>>> decision-taking processes?
>>>>>
>>>>> 2012/7/16 Adrian Crum <adrian.crum@sandglass-**software.com<[hidden email]>
>>>>> >
>>>>>
>>>>>  No, it smells like the current goal of moving things we don't want in
>>>>>>
>>>>> the
>>>>
>>>>> main project to external projects. This type of decision-making has
>>>>>> been
>>>>>> going on for years.
>>>>>>
>>>>>> -Adrian
>>>>>>
>>>>>>
>>>>>> On 7/16/2012 9:45 AM, Pierre Smits wrote:
>>>>>>
>>>>>>  I agree with Ruth. This sounds like a user requirement. And the
>>>>>>>
>>>>>> community
>>>>
>>>>> should decide on this.
>>>>>>>
>>>>>>> Furthermore, the remark 'users might like a new feature, but that
>>>>>>>
>>>>>> doesn't
>>>>
>>>>> mean the dev community wants it in the project' smells like measuring
>>>>>>>
>>>>>> with
>>>>
>>>>> double standards; as if the meritocratic principle doesn't apply when
>>>>>>>
>>>>>> the
>>>>
>>>>> committers don't want it in. Or as if changes always get in, when only
>>>>>>>
>>>>>> the
>>>>
>>>>> committers want it.
>>>>>>>
>>>>>>> 2012/7/15 Adrian Crum <adrian.crum@sandglass-**softw**are.com<http://software.com>
>>>>>>> <
>>>>>>>
>>>>>> adrian.crum@sandglass-**software.com<[hidden email]>
>>>> >
>>>>
>>>>> Ruth,
>>>>>>>
>>>>>>>> I understand your viewpoint. Personally, I prefer to present my
>>>>>>>> ideas
>>>>>>>>
>>>>>>> to
>>>>
>>>>>  the dev list to see if it is something the dev community wants
>>>>>>>>
>>>>>>> included
>>>>
>>>>>  in
>>>>>>>> the project. Users might like a new feature, but that doesn't mean
>>>>>>>> the
>>>>>>>> dev
>>>>>>>> community wants it in the project. If there was no interest from the
>>>>>>>>
>>>>>>> dev
>>>>
>>>>>  community, then I would offer it as an add-on product and announce it
>>>>>>>>
>>>>>>> on
>>>>
>>>>>  the user list.
>>>>>>>>
>>>>>>>> I am also a user, and the design was based on the requirement to
>>>>>>>>
>>>>>>> monitor
>>>>
>>>>>  and control server performance. I suppose I could go to the user list
>>>>>>>>
>>>>>>> for
>>>>
>>>>>  more ideas, but the code I'm planning to commit is pretty basic, and
>>>>>>>> users
>>>>>>>> will be free to enhance it in whatever way they please.
>>>>>>>>
>>>>>>>> -Adrian
>>>>>>>>
>>>>>>>>
>>>>>>>> On 7/15/2012 12:13 PM, Ruth Hoffman wrote:
>>>>>>>>
>>>>>>>> Hi Adrian:
>>>>>>>>
>>>>>>>>> Shouldn't this be discussed on the "user" list? IMHO Words like
>>>>>>>>> "applications" and "stats about services and entities"...those are
>>>>>>>>>
>>>>>>>> all
>>>>
>>>>>  indicative of user requirements, not developer requirements.
>>>>>>>>>
>>>>>>>>> Users should be driving requirements gathering and analysis for
>>>>>>>>> OFBiz
>>>>>>>>> and
>>>>>>>>> not developers.
>>>>>>>>> Just my 2 cents.
>>>>>>>>> Regards,
>>>>>>>>> Ruth
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>
>>>>
>>
>>
>

[BJ Freeman]

What would be great is if we had a Dev map that showed a design plan
The Goal, Scope, and effect on the current design.
having all these in one place on the wiki would help in over all design.
my 2 cents.

Adrian Crum sent the following on 7/14/2012 3:38 AM:

> I have an application metrics feature working on my local copy and I was
> wondering if there would be any interest in including it in the project.
>
> A metric is a measure of average execution time. Each metric is given a
> unique name.
>
> I modified the control servlet and service dispatcher to use metrics. To
> add a metric to a request, just include an XML element:
>
> <metric name="URL: webtools/main" />
>
> to the request map and the average response time for the URL will be
> maintained. Likewise, to add a metric to a service, just include an XML
> element:
>
> <metric name="Service: createMaintsFromTimeInterval" />
>
> to the service definition and the average execution time for the service
> will be maintained.
>
> Metrics are kept in memory. There is a service to retrieve all metrics.
> There is also a Web Tools page to view all metrics.
>
> A heartbeat server could retrieve the metrics to check on server load or
> to provide histograms.
>
> The metric element has an optional threshold attribute, so some action
> could be taken when the metric crosses a threshold. For example, in the
> following request map:
>
> <request-map uri="ViewMetrics">
> <security https="true" auth="true"/>
> <metric name="URL: webtools/ViewMetrics" threshold="1000"/>
> <response name="success" type="view" value="ViewMetrics"/>
> <response name="threshold-exceeded" type="view" value="ServerBusy"/><!--
> displays a friendly 'server busy' page -->
> </request-map>
>
> the ServerBusy view would be rendered if the average response time
> exceeded 1000 mS. This can be useful for providing a lively web
> experience on a heavy-traffic web page.
>
> The service dispatcher does not use the threshold. I could not think of
> a use case where service behavior should be modified based on average
> execution time.
>
> The metrics code is very small - two java files. Also, the modifications
> to the webapp component and service component are very small.
>
> What do you think?
>
> -Adrian
>
>

[Adrian Crum-3]

Having a Wiki page that describes the new feature would be great, but it
needs to be created after the commit and some review. Creating a Wiki
page before there is any interest expressed in the proposal could be a
waste of time. So, I cover the goal, scope, and effect on the current
design in the emailed proposal.

-Adrian

On 7/16/2012 11:32 AM, BJ Freeman wrote:

> What would be great is if we had a Dev map that showed a design plan
> The Goal, Scope, and effect on the current design.
> having all these in one place on the wiki would help in over all design.
> my 2 cents.
>
> Adrian Crum sent the following on 7/14/2012 3:38 AM:
>> I have an application metrics feature working on my local copy and I was
>> wondering if there would be any interest in including it in the project.
>>
>> A metric is a measure of average execution time. Each metric is given a
>> unique name.
>>
>> I modified the control servlet and service dispatcher to use metrics. To
>> add a metric to a request, just include an XML element:
>>
>> <metric name="URL: webtools/main" />
>>
>> to the request map and the average response time for the URL will be
>> maintained. Likewise, to add a metric to a service, just include an XML
>> element:
>>
>> <metric name="Service: createMaintsFromTimeInterval" />
>>
>> to the service definition and the average execution time for the service
>> will be maintained.
>>
>> Metrics are kept in memory. There is a service to retrieve all metrics.
>> There is also a Web Tools page to view all metrics.
>>
>> A heartbeat server could retrieve the metrics to check on server load or
>> to provide histograms.
>>
>> The metric element has an optional threshold attribute, so some action
>> could be taken when the metric crosses a threshold. For example, in the
>> following request map:
>>
>> <request-map uri="ViewMetrics">
>> <security https="true" auth="true"/>
>> <metric name="URL: webtools/ViewMetrics" threshold="1000"/>
>> <response name="success" type="view" value="ViewMetrics"/>
>> <response name="threshold-exceeded" type="view" value="ServerBusy"/><!--
>> displays a friendly 'server busy' page -->
>> </request-map>
>>
>> the ServerBusy view would be rendered if the average response time
>> exceeded 1000 mS. This can be useful for providing a lively web
>> experience on a heavy-traffic web page.
>>
>> The service dispatcher does not use the threshold. I could not think of
>> a use case where service behavior should be modified based on average
>> execution time.
>>
>> The metrics code is very small - two java files. Also, the modifications
>> to the webapp component and service component are very small.
>>
>> What do you think?
>>
>> -Adrian
>>
>>