Wiki Markup*Navigation trail:* \["JMeterProjectPages"\] - \["JMeterDevelopment"\] - \["JMeterDevelopment"\]/LongTerm

...

How can we improve the remote testing experience?

...

re remote testing and firewall issues, just modified jmeter source based on v2.1.1. with the modification, a new property 'server.service.port' could be used for the jmeter service port (pls note this is different from the rmi registry port which could also be configured by 'server.rmi.port') in jmeter.properties. current jmeter release uses a random port number which may cause some trouble for sysadmin to adjust firewall rules (especially if you sysadmin is very much concerned about any potential security issues). so you could give jmeter a static port number for the service and let sysadmin know the port as well.

...

• if you only need binary (working copy), download ApacheJMeter_core.jar \[http://wiki.apache.org/jakarta-jmeter-data/attachments/JMeterRemoteTestingEnhancements/attachments/ApacheJMeter_core.jar\] which is recompiled with my change; and as an option, feel free to download new jmeter.properties \[http://wiki.apache.org/jakarta-jmeter-data/attachments/JMeterRemoteTestingEnhancements/attachments/jmeter.properties\]. \\unmigrated-wiki-markup
  
• for source code, pls download two patches, one for src/core/org/apache/jmeter/engine/RemoteJMeterEngineImpl.java \[http://wiki.apache.org/jakarta-jmeter-data/attachments/JMeterRemoteTestingEnhancements/attachments/RemoteJMeterEngineImpl.java.patch.txt\] and the other for bin/jmeter.properties \[http://wiki.apache.org/jakarta-jmeter-data/attachments/JMeterRemoteTestingEnhancements/attachments/jmeter.properties.patch.txt\]. simply apply them and job done. \\
  

(I have been looking for any chance contribute that modification back to main development tree, so feel free to use it if it could be included in a future release)

...

– KeivnHurley 01/27/2005

...

Serialisation

Wiki MarkupAt present, when a script is sent to the remote server for execution, AFAIK the entire tree is serialised and reconstructed at the other end. This places a lot of burden on developers to make sure that objects are serialisable. Since there is already a convenient representation for a test (i.e. the JMX format) it seems to me that we should make use of it and ship that across instead. It would mean that the remote installation would need to have all the appropriate classes present, but that is probably true anyway. It should reduce the amount of data sent. It would probably get rid of some of the incompatibilities that occur. I read somewhere recently (probably Effective Java by Joshua Bloch) that hash values are not _guaranteed_ to be the same for different JVMs, nor even between runs of a JVM, which might explain some problems users have reported.\["sebb"\]

Similar considerations apply to the Sample data that is returned, and it would be useful to be able to batch this and/or just send back aggregrate data during a test run, and allow the client to request the full data when required.