Eric
To my knowledge I'm using keepalive connections and http 1.1, but I'm
not sure. Under load test options of soapUI I didn't checked the option
"close connections between each request".
The RAW response header information looks like that:
HTTP/*1.1* 200 OK
Transfer-Encoding: *chunked*
Yep you are using HTTP 1.1 and chunked encoding :-) .. Sometimes many
people use ApacheBench for its great raw performance, but fails to
realize that it doesn't support HTTP 1.1 and chunked encoding, and thus
sees poor results.. The HttpComponents project has a Java version of
ApacheBench that overcomes this if you are interested..
No problems to increase the heap space. The ESB is running under jdk1.6.0_02.
With JDK 1.6.x you will probably have issues when using the Script
mediator (and Javascript, Ruby, Groovy etc) in your configuration. This
is because JDK 1.6 has native support for scripting languages, and this
conflicts with the Apache BSF we have used for script language support.
We hope to address this with our next major release. However, everything
else should run smoothly
Up to now we have no registry, but we would like to have a central, high
available registry with version support. We are thinking about building
our own registry backed by a subversion repository.
How are changes to the configuration propagated between the nodes in
your cluster implementation?
Basically the ESB could connect to any URL based registry, and if you
provide the root of the registry as "file://somedir" etc, you could
configure your Unix file synchronization to keep your local copy of the
registry in sync with the actual registry. Else, you could use a shared
file system. If you are using a WebDav or Apache Web server as the
registry, you just point the above root URL to "http://reghost/rootpath";
and all nodes can pick up items from the remote registry
This sounds interesting. Maybe you could think of a new standard
component like JMSReport mediator as I think this is a quite typical
need.
By the way, why do you emphasize on "non-persistent" JMS destinations?
Sure, we can actually do this quickly since we have the code for it
already.. You could use a persistent queue as well - its just
configuration, but in general as JMS messages are typically persisted
into a File system or RDBMS etc, the in-memory non-persisted
destinations would have best performance. You should be able to easily
cluster the JMS non-persisted destinations for high availability ..
these are all details which you could think of after your implementation
and performance testing.. sometimes depending on your load, the
persisted destinations may work fine for you too
asankha
_______________________________________________
Esb-java-user mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/esb-java-user
