Stover, Michael wrote:
> Berin,
> Couple of questions/observations:
>
> First, I just extended DefaultConfigurationBuilder and
> SAXConfigurationHandler to handle my custom Configuration class
> (SampleResult). It was easy to do, but you might want to look into making
> SAXConfigurationHandler more supportive of extending. It's members are
> private, and there are no protected getXXX() methods to allow inheritors
> access to those members. So, in order to extend it, I simply copied and
> pasted all of it's code into my class, and then modified what I needed to
> (which was very little). But that's not ideal.
:) Ok.
I am copying the Avalon list, so that they can have the benefit of this
conversation. This way they can see it as a legit user need as opposed
to a "It would be nice if...".
> What I changed - I simply added some code to instantiate the right kind of
> object in place of DefaultConfiguration (this is in the startElement
> method), based on what the tag name was. You might consider breaking that
> code out into a protected method that is easily overridden by extenders -
> that might handle a good percentage of customization needs.
Ok. That seems reasonable. We may come up with something even better,
but this is good.
>
> Second, I'm doing a lot of processing of SampleResults, and I'm a little
> worried about performance. I'm not one to care overly much about
> performance, but in the case of JMeter and issues during test runs, I have
> to be careful. I was wondering about easing the amount of processing that
> goes on by delaying the storing of data into the Configuration-style areas
> (ie attributes and values) until it's time for the SampleResult to be
> serialized to file.
I'm not sure what you are getting at here.
>
> One reason for this is that some data is binary, and I convert it to Hex
> prior to stuffing it into a child Configuration object (perhaps this is
> something Avalon could support - ie setValueAsHex(byte[]), byte[]
> getValueAsBinary()). I do this because response data from a server may be
> binary (ie and image). But, that's a fair amount of processing for every
> sample, and if I can delay it until serialization then A)the user has more
> control over whether it happens at all - ie if they choose not to save to
> file, and B)it can happen on the controlling machine and not the sampling
> machine in a distributed JMeter environment, and B)when the visualizers
> extract the data from the SampleResult, they're not converting it back from
> Hex - a double whammy.
Ok. Another option would be to save a reference to the file, and store
the binaries separately. Many times, it's the same binary, with
different response times. In that case, it doesn't make sense to store
1,000 copies of a 10k image if they are all the same. That would also
speed things up for you.
I'm not against the binary encoding of info--it would help with
encrypted values like passwords and such.
>
> Instead, data would be preliminarily stored in normal Java ways (ie as a
> byte[]), and I'd write a custom ConfigurationSerializer that would work with
> SampleResult to get everything squared away prior to serialization.
>
> Any thoughts on this? Maybe you can see a better approach?
It's a good question. Choosing which Configuration object is returned
is not a problem--assuming we have the same "interface" or abstract
object to create config elements.
The binary config elements are a bit more than what is the norm for
configuring projects. I don't want to loose the option though.
Maybe we can get a good idea going on the Avalon developer's list.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
