JMeter proxy and java serialization in HTTP/POST?

We have an applet-servlet communication that we'd like to record with JMeter's HTTP proxy. It works with GET messages until the applet sends an HTTP POST message which includes some serialized Java objects (built-in types), then we get this error in the Applet:

alt text http://img339.imageshack.us/img339/9238/appletservletjmeterhttp.png

OK, so there's some JVM version conflict somewhere in the queue. But where?

The communication runs OK without JMeter, that is: Applet -> Tomcat -> Servlet. Al开发者_如何学Pythonl on my local machine.

But it doesn't work through JMeter: Applet -> JMeter proxy -> Tomcat -> Servlet. Also all on my machine.

It is as if JMeter was modifying the POST message content...

I tested it with the Apache proxy as well, working fine.

Even funnier thing is that I have only one version of Java installed, one JDK and one JRE. Both 1.6.0_07...

Thought I'd ask before starting digging deeper in the rabbit hole ;-)

Here is the hex dump of the POST data sent directly to Tomcat:

00000348  ac ed 00 05 73 72 00 11  6a 61 76 61 2e 6c 61 6e ....sr.. java.lan
00000358  67 2e 49 6e 74 65 67 65  72 12 e2 a0 a4 f7 81 87 g.Intege r.......
00000368  38 02 00 01 49 00 05 76  61 6c 75 65 78 72 00 10 8...I..v aluexr..
00000378  6a 61 76 61 2e 6c 61 6e  67 2e 4e 75 6d 62 65 72 java.lan g.Number
00000388  86 ac 95 1d 0b 94 e0 8b  02 00 00 78 70 00 00 01 ........ ...xp...
00000398  7b                                               {

And here is the data when sent through JMeter:

00000128  ac ed 00 05 73 72 00 11  6a 61 76 61 2e 6c 61 6e ....sr.. java.lan
00000138  67 2e 49 6e 74 65 67 65  72 12 e2 a0 a4 f7 3f 3f g.Intege r.....??
00000148  38 02 00 01 49 00 05 76  61 6c 75 65 78 72 00 10 8...I..v aluexr..
00000158  6a 61 76 61 2e 6c 61 6e  67 2e 4e 75 6d 62 65 72 java.lan g.Number
00000168  3f ac 3f 1d 0b 3f e0 3f  02 00 00 78 70 00 00 01 ?.?..?.? ...xp...
00000178  7b                                               {

A lot of "3f"s in the second dump... So this is definitely some kind of an encoding problem. The content type is set correctly in the header:

POST /ABCOrder/ABCServlet?cmd=getNetworkConnection HTTP/1.1
Connection: keep-alive
Content-Type: application/octet-stream
Host: 109.107.148.164:8443
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
User-Agent: Mozilla/4.0 (Windows Vista 6.0) Java/1.6.0_14
Content-Length: 81

Here is the solution: JMeter has a config file, bin/jmeter.properties. Here you can find an option where you can set the binary content types:

# Binary content-type handling
# These content-types will be handled by saving the request in a file:
proxy.binary.types=application/x-amf,application/x-java-serialized-object

Now I don't know why application/octet-stream isn't included by default, but you can simply add it to the list, and you are done.

proxy.binary.types=application/x-amf,application/x-java-serialized-object,application/octet-stream

This is how I found it out: https://issues.apache.org/bugzilla/show_bug.cgi?id=44808

Did a search on JMeter closed bugs... :-)

Someone else is reporting a very similar: http://markmail.org/message/pl5erin2isehm5q6. I can't find any issue related to this problem in their bug tracker though. It looks like you won the privilege to dig deeper in the rabbit hole :)

The accepted answer only allows recording static requests. This will not be realistic as it will not allow any variabilisation of requests (for example changing the searched word, ...) so you will always be stress testing the same bunch of data.

To make it a real test, you need to use a third party plugin.

A commercial JMeter plugin allows this, see:

• http://ubikloadpack.com/

To make your tests realistic, you will need to variabilize content in the serialized objects.

This Java Serialization plugin will allow the following:

• Easy recording of traffic with JMeter Proxy Server, a Test Plan using custom Sampler will be created

• Easy variabilization of requests (which will appear as XML) through as easy syntax as for example ${searchedWord} where searchedWord can come from a CSV or any user defined variable.

• Easy extraction of data from responses using JMeter standard Post Processors

• Easy debugging of Request/Responses through standard JMeter View Results Tree element

Disclaimer :I work for this company.