jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jmeter Wiki] Update of "FutureReleases" by fschumacher
Date Sun, 30 Aug 2015 13:47:30 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jmeter Wiki" for change notification.

The "FutureReleases" page has been changed by fschumacher:
https://wiki.apache.org/jmeter/FutureReleases?action=diff&rev1=37&rev2=38

  If you are not a JMeter committer, feel free to add comments (with initials please), but
please don't reorganise the release plan.
  
  = Possible enhancements =
- 
  This section is for listing possible enhancements. Describe them briefly. If necessary add
bug ids (or links) to clarify.
  
   * JDBC connection pooling - possible enhancements
    * use Apache DBCP instead of Excalibur?
   * JDBC sampler - use different cache sizes for connection and statement?
    * How do these really work?
-   * Should the connection cache be a Thread``Local item?
+   * Should the connection cache be a ThreadLocal item?
    * Need to add debugging to show when cache items are created and destroyed - difficult
for pooled resources
   * XPath Extractor - add user-declared namespaces
   * Rework HTTP GUI to make it easier to use and extend
@@ -21, +20 @@

    * Add unit tests for SOAP/XML-RPC sampler
    * Change name exposed to use to "SOAP/XML-RPC/REST sampler"
   * Make it possible to send file content for HTTP GET, PUT and DELETE using "HTTP Sampler"
and "HTTP Sampler 2", and therefore also "SOAP/XML-RPC sampler" <= some of this ha been
done
-  * Make Axis2 / XFire / CFX Sampler, and possible retire existing "Webservice(SOAP) sampler".

+  * Make Axis2 / XFire / CFX Sampler, and possible retire existing "Webservice(SOAP) sampler".
    * A bit unsure about this, not sure what benefit is over "SOAP/XML-RPC Sampler".
    * Will we really be testing Axis / XFire client side peformance here ?
    * Or could we make a nice GUI, so it is easier to test web services ?
@@ -34, +33 @@

     * Add shell scripts, for example jmeter_test_http, which just calls the standard jmeter
script, with additional "-J" arguments, for example "-Jiterations=10"
     * Need a way of getting the listener output to the console, need some investigation
      * on Windows one can use CON as the file name; /dev/tty for unix - but output is not
formatted nicely
-     * Summariser can already output to console - that may be enough 
+     * Summariser can already output to console - that may be enough
   * Restructure HTTP Sampler / Settings GUI. bugzilla 41917. A big job, but is becoming necessary,
if we are adding more options to the HTTP Sampler
   * Listeners:
    * make distinction between open file for read and write.
@@ -49, +48 @@

    * Does people really read the documentation ? Judging by posts on jmeter-user mailing
list, I sometime have my doubts.
    * Would be excellent to have documented steps for "view frontpage, log in, view a page,
log out" scenario for the following frameworks
     * Struts
-    * Spring 
+    * Spring
     * Spring Webflow
     * .net applications
     * others (please suggest)
@@ -57, +56 @@

     * the above could start out as Wiki pages
     * it would be useful to provide sample JMX files as well
   * Additional sample JMX files for the various scenarios that are FAQed
-    * Perhaps a giant example showing lots of different scripts?
+   * Perhaps a giant example showing lots of different scripts?
   * Support for uploading multiple files in HTTPSampler / HTTPSampler2. I think it the one
main missing functionality in HTTPSampler that browser provide, and JMeter not.
    * this is bugzilla 19128
    * I think this is dependent on bugzilla 41917, mentioned above
@@ -84, +83 @@

    * this can be done currently with BeanShell, but it would be simpler to have a dedicated
GUI.
   * Remote Mode selection: might be useful to be able to specify the remote mode for each
listener. This would allow the use of immediate mode for a few listeners and statistical mode
for most of traffic.
   * If Controller - allow functions and variables as alternative to Javascript
+  * Rework architecture to be able to use a pool of threads instead of thread or use Reactor
Pattern
+  * Introduce HTTP Client async feature
+  * Allow parallel HTTP requests for one simulated user
+  * Support Websocket and SPDY2 (HTTP/2)
+  * Fix known Bugs in REDO/UNDO feature
+  * Add a StreamProcessor to look at/modify the data of Samplers while they are retrieved/sent.
Could be used to verify that a large video stream is valid while not consuming a lot of memory.
+  * Extend the functionality of the imap sampler.
  
  = Non-functional improvements =
- 
  This section is for non-functional changes, e.g. code re-organisation etc.
  
   * Use Java 1.5 for building, but only require 1.4 for running. Is this easy to do? Can
it be done in Eclipse?
@@ -94, +99 @@

    * I looked into adding a GUI / dialog for "Help->View log" to easily view the jmeter
log file from the application itself.
     * Seems to be some open source tools available for log4j which does that out of the box.
    * Would we gain functionality by moving to log4j ?
-   * Alternatively, move to Commons Logging (as used by Http``Client currently)
+   * Alternatively, move to Commons Logging (as used by HttpClient currently)
    * Or perhaps SL4J - http://www.slf4j.org/
    * What are the risks with continuing to use Avalon, if Avalon is not maintained anymore
?
-   * Remark: Http``Components project is considering migrating Http``Client 4.0 branch off
Commons Logging to another logging framework as Commons Logging currently appears unmaintained
and the prospects of its further development remain unclear. [There has just been a new release:
sebb] It may be worthwhile to ensure both projects use the same logging framework / compatible
logging frameworks. [Agreed: sebb]
+   * Remark: HttpComponents project is considering migrating HttpClient 4.0 branch off Commons
Logging to another logging framework as Commons Logging currently appears unmaintained and
the prospects of its further development remain unclear. [There has just been a new release:
sebb] It may be worthwhile to ensure both projects use the same logging framework / compatible
logging frameworks. [Agreed: sebb]
   * Upgrade to httpclient4 ? httpclient4 is still only in Alpha. Should / could we have one
sampler class using httpclient3 and one httpclient4 ? HttpClient 4 will require Java 1.5,
and won't be available until Q2/Q3 2008.
   * Reorganise documentation
    * component_reference is getting much too big. This will require changes to the help system.
@@ -107, +112 @@

    * or extend the existing help menu to load just the individual page.
    * If there are combined and individual help pages, there would probably need to be two
copies. Maybe simplest just to split component reference by element type; keep current page
as an index into the subsections
    * Help could perhaps be extended to allow loading of linked pages (but one would probably
not want to allow external links to be loaded). There is some code in View Tree that might
help here.
-  * Re-write Class``Finder:
+  * Re-write ClassFinder:
    * needs general tidyup / javadoc
    * cache results - same classes may be requested multiple times
-  * Test``Bean:
+  * TestBean:
    * prepare is probably called too often; can it be done once per test?
    * need some more GUI types - eg. table
    * would be nice to be able to enable/disable fields depending on what else is selected
- e.g. JDBC parameters only needed for prepared statements
@@ -126, +131 @@

    * or should they be omitted as at present? - this is confusing at build time.
    * or perhaps generate a dummy entry in the list, with a message to say the jar is missing?
his would be tricky, as the class is needed to retrieve the name and the menu category. Perhaps
the way to do it is to handle it in the GUI by catching the errors, and changing the name
or screen comment? May be tedious to do.
   * Sort test tree according to JMeter processing order? This should probably be a separate
action, as it would be confusing for the tree to change as it was editted!
-  * introduce Generic HTTP Sampler which can do either Java or Http``Client or ...
+  * introduce Generic HTTP Sampler which can do either Java or HttpClient or ...
    * could be new sampler GUI with new underlying test elements
-   * but it would be nice if existing test plans were converted into the new sampler. Looked
at this a while back, but got stuck with XStream aliasing, which has to be one-to-one at present.
However, the code change to Save``Service to remove the class loading should make it possible
to have multiple aliases for a single class. That might be sufficient, otherwise we'll need
a suitable converter.
+   * but it would be nice if existing test plans were converted into the new sampler. Looked
at this a while back, but got stuck with XStream aliasing, which has to be one-to-one at present.
However, the code change to SaveService to remove the class loading should make it possible
to have multiple aliases for a single class. That might be sufficient, otherwise we'll need
a suitable converter.
    * I think the GUI should just contain a dropdown "Client implementation", with values
like "Java JRE", "HTTPClient 3.1", "HTTPClient 4.0" etc.
   * GUI code refactor
    * there are various table implementations, could they be combined?
    * perhaps the table models could also be combined?
   * Add SVN revision number to version? (already added to Manifests)
-  * Consider migration to Maven2 as a build tool for JMeter. This should help simply dependency
management and facilitate the use of JMeter for automatic load testing / integration into
tools like [[http://maven.apache.org/continuum/|Continuum]]  
+  * Consider migration to Maven2 as a build tool for JMeter. This should help simply dependency
management and facilitate the use of JMeter for automatic load testing / integration into
tools like [[http://maven.apache.org/continuum/|Continuum]]
    * Maven 1 was tried a couple of years ago, and seemed incompatible with the JMeter directory
layout and multiple jars; hopefully Maven 2 is more flexible.
-  * Consider renaming Thread``Group as JMeter``Thread``Group - or User``Group ? - to avoid
confusion with java.lang.Thread``Group
+  * Consider renaming ThreadGroup as JMeterThreadGroup - or UserGroup ? - to avoid confusion
with java.lang.ThreadGroup
   * Documentation refers to threads and/or users in different places; replace by users -
or users(threads) - everywhere?
-  * Test elements need access to Thread``Group and Test``Plan for co-ordinating counts etc
per-group and per-plan. Not much distinction is currently made between per-group and per-plan.
+  * Test elements need access to ThreadGroup and TestPlan for co-ordinating counts etc per-group
and per-plan. Not much distinction is currently made between per-group and per-plan.
  
  = Release strategy =
- 
  Only JMeter committers should change this section, though others may comment.
  
  == JMeter 2.3.1 ==
- 
  This will be the next release.
  
  The following have been implemented:
@@ -161, +164 @@

    * Assertions
    * Post-processors
    * Listeners
-  * Recode Save``Service so it does not load classes unnecessarily
+  * Recode SaveService so it does not load classes unnecessarily
   * Add SVN revision number to Manifests.
   * Prevent adding test elements to inappropriate parts of the tree - e.g. controller and
sampler must be under a thread group. Should also prevent drag and drop.
   * JDBC IN/OUT/INOUT parameters
@@ -190, +193 @@

     * Could we remove the "Write All Data to File" setting from all listeners, and instead
make a "Write All Data listener" ? [The simple data writer?]
   * Make menu options more context sensitive, so they are only enabled when they make sense
    * There seems to be some context sensitivity currently, but the code seems a bit odd,
with explicit methods used by various parts of the code (now fixed)
-  * Improve Http``Mirror``Thread class - done, but not submitted (Alf Hogemark)
+  * Improve HttpMirrorThread class - done, but not submitted (Alf Hogemark)
    * It should allow blocking reads where appropriate, at least when content-length is known
    * Do not use Reader/Writer classes, which uses JVM default character encoding, causing
mirrored content to differ
    * Add unit tests

Mime
View raw message