Few Problems

[Pawel Januszewicz <pj...@zefer.com>]

Gentlemen,

I have just started to use jmeter. It is a great tool so I would like to
provide the following problems for your consideration so you/we can fix
them.

1) The save functionality saves url from the urlSample without encoding. If
the url contains query string, e.g. www.home.com/test?a=1&b=2 SAX gets upset
by the & character and thinks it is an entity. I have patched the problem by
storing the url as a CDATA node but you may prefer other solution.

2) In the RemoteJMeterEngineImpl server uses bind to register with the
rmiregistry. If the server crashes the rmiregistry has to be restarted as
well because the subsequent bind fails. Using rebind would correct the
problem.

3) There is a design-type problem with use of the rmi server if client and
server run on different jvm implementations. I have fixed all classes
contained by the ThreadGroup which were not serializable. Unfortunately it
did not work for me because few components derive from DefaultTableModel or
AbstractTableModel. The problem is mentioned classes do not have
serialVersionUID assigned so jvm calculates it for them. However my 1.3.1
jvm on windows calculates it in a different way than 1.2 on solaris. That
results in a remote exception as serialization thinks those are different
versions of the classes.

Also, using Swing classes as parents makes the solaris jvm thing it has to
genereate some output, that causes a failure if the xwindows DISPLAY env.
variable is not set.

I would send you the fixes for 1 and 2 but they are trivial so you will
probably apply them easily. The problem 3 however looks tough for me, please
let me know if you have any advice regarding it.

Best regards,
Pawel.

Re: Few Problems

[Brendan Burns <bb...@apache.org>]

Sorry, I've been away for a while (finals ;-P...) 
On Sun, 13 May 2001, Pawel Januszewicz wrote:

> 1) The save functionality saves url from the urlSample without encoding. If
> the url contains query string, e.g. www.home.com/test?a=1&b=2 SAX gets upset
> by the & character and thinks it is an entity. I have patched the problem by
> storing the url as a CDATA node but you may prefer other solution.
Yeah, we should us CDATA (or us URLEncoder.encode())...

> 2) In the RemoteJMeterEngineImpl server uses bind to register with the
> rmiregistry. If the server crashes the rmiregistry has to be restarted as
> well because the subsequent bind fails. Using rebind would correct the
> problem.

Yeah, my bad, the rmi server/client is still very alpha...

> 3) There is a design-type problem with use of the rmi server if client and
> server run on different jvm implementations. I have fixed all classes
> contained by the ThreadGroup which were not serializable. Unfortunately it
> did not work for me because few components derive from DefaultTableModel or
> AbstractTableModel. The problem is mentioned classes do not have
> serialVersionUID assigned so jvm calculates it for them. However my 1.3.1
> jvm on windows calculates it in a different way than 1.2 on solaris. That
> results in a remote exception as serialization thinks those are different
> versions of the classes.

This strikes me as Sun's problem not ours, still we should work around
it...  Truthfully we shouldn't be passing any GUI classes over the
wire.  That's a mistake.  I'll look into fixing it...

> Also, using Swing classes as parents makes the solaris jvm thing it has to
> genereate some output, that causes a failure if the xwindows DISPLAY env.
> variable is not set.

Likewise, I'll try to eliminate GUI things over the wire that will fix
things...

> I would send you the fixes for 1 and 2 but they are trivial so you will
> probably apply them easily. The problem 3 however looks tough for me, please
> let me know if you have any advice regarding it.

If you wanted to re-engineer the classes passed over the wire feel free,
but its probably a little complicated.  Now that I am (almost) done with
finals I'll have more time to focus on JMeter.

brendan


---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org