On 6 December 2010 21:45, Milamber <milam...@apache.org> wrote: > Hello, > > I have got last checkout last JMeter SVN, and executed ant's task dist. > With a simple test plan, I have this error with a new HTTP HC4 sampler: > > 2010/12/06 21:08:45 ERROR - jmeter.threads.JMeterThread: Error while > processing sampler 'Page2' : > org.apache.commons.lang.NotImplementedException: Code is not implemented > at > org.apache.jmeter.protocol.http.sampler.HTTPHC4Impl.sample(HTTPHC4Impl.java:43) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:62) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:970) > at > org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:956) > at > org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:369) > at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:262) > at java.lang.Thread.run(Thread.java:662) > > Have I forgot something?
No - I've not yet finished working on the HC4 sampler. > Milamber > > > > Le 06/12/2010 11:35, sebb a ecrit : >> >>>>>> Le 26/11/2010 00:28, sebb a ecrit : >>>>>> >>>>>> >>>>>>> On 25 November 2010 23:13, Milamber <milam...@apache.org> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> Your plan seems very well. >>>>>>>> >>>>>>>> Keep legacy samplers (Java, Hc3) is a good things, but perhaps if there >>>>>>>> has three http samplers thus will introduce some confusing for a new >>>>>>>> user? (what http sampler is the best for my test?) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> It will have to be documented. >>>>>>> >>>>>>> In theory, HC4 will be the best, but it may take a while to get the >>>>>>> JMeter interface code working correctly. >>>>>>> So I did not want to replace HC3 with HC4. >>>>>>> >>>>>>> Once it is well established, HC3 can be made optional, at which point >>>>>>> JMeter would revert to two choices again. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> (Actually, my understanding is the Java Http sampler is the legacy and >>>>>>>> reliable, and Hc3 is new challenger and is better for httpS request...) >>>>>>>> >>>>>>>> Another ask: what will be the default sampler? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Currently it is the Java sampler, but I plan to make it configurable >>>>>>> with a JMeter property. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> AJP sampler seems not very used like sampler. Keep his independence >>>>>>>> will >>>>>>>> be good for the evolution of federated http sampler. >>>>>>>> >>>>>>>> Milamber >>>>>>>> >>>>>>>> Le 25/11/2010 15:45, sebb a ecrit : >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Just a heads up that I'm currently working on trying to combine the >>>>>>>>> HTTP implementations (Java, HttpClient3) into a single GUI, with >>>>>>>>> run-time choice of implementation. >>>>>>>>> >>>>>>>>> The rationale for this is that HttpClient 4 is now available, and it >>>>>>>>> would be good to add that, but I think we should keep HttpClient for >>>>>>>>> backwards compatibility and comparison. >>>>>>>>> >>>>>>>>> Creating another GUI/Sampler set is easy enough, but it would be >>>>>>>>> useful to be able to switch implementations easily - currently that >>>>>>>>> requires switching samplers (e.g. by editting the JMX file). >>>>>>>>> >>>>>>>>> The current plan is to allow the implementation to be specified on the >>>>>>>>> HTTP Request Defaults config screen as well as on the HTTP Request >>>>>>>>> screen. >>>>>>>>> >>>>>>>>> The code is a bit involved, because the Config settings are processed >>>>>>>>> at run-time after the test plan has been built. >>>>>>>>> [But even the Sampler GUI needs to create the sampler before it can >>>>>>>>> store the sampler settings - and the implementation can then be >>>>>>>>> changed.] >>>>>>>>> Currently I use a Sampler Proxy that dispatches to the appropriate >>>>>>>>> implementation class. >>>>>>>>> These classes have to extend an abstract class that provides the >>>>>>>>> necessary methods to interface with the Proxy test element and thus >>>>>>>>> provide access to the test element properties. >>>>>>>>> That part seems to be working OK. >>>>>>>>> >>>>>>>>> The next phase is to ensure that existing JMX files can be converted >>>>>>>>> (during load) to use the new sampler. >>>>>>>>> >>>>>>>>> The intention is to keep the existing Java and HttpClient samplers, so >>>>>>>>> that subclasses will continue to work, but not expose them in the GUI. >>>>>>>>> >>>>>>>>> I've not finally decided about the AJP sampler - it can be easily >>>>>>>>> converted, but I don't think there's much of a use case for switching >>>>>>>>> between AJP and another implementation. >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org >>>>>>>>> For additional commands, e-mail: dev-h...@jakarta.apache.org >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@jakarta.apache.org >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org >>>>>>> For additional commands, e-mail: dev-h...@jakarta.apache.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org >>>>>> For additional commands, e-mail: dev-h...@jakarta.apache.org >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org >>>> For additional commands, e-mail: dev-h...@jakarta.apache.org >>>> >>>> >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org >>> For additional commands, e-mail: dev-h...@jakarta.apache.org >>> >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org >> For additional commands, e-mail: dev-h...@jakarta.apache.org >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org > For additional commands, e-mail: dev-h...@jakarta.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: dev-h...@jakarta.apache.org
