netzooid

XOM 1.1 has been released! Its now even faster and has XPath support. Congrats to Elliotte and everyone else who participated. If you are working with DOM there is no better way than XOM. Now if only we could get something like this into the JDK…

Alexander talks about reasons “to SOAP or not to SOAP”. Now, for the sake of everyone listening (and to keep myself from getting bored), I won’t get into the whole SOAP vs. REST thing. I’d like to pick out one thing, his chart. I don’t think its fair to use the public services (EBay, Amazon, Paypal, etc) as examples for enterprise software. If they use REST or SOAP, does that mean it is appropriate for us? I would be much more interested in a survey of how many enterprises are using SOAP or REST.

I feel that current SOA developments still fall far short of where we could be. I think we need to get rid of XML Schema and WSDL down the line. They’re both abominations. Instead I would like to see Relax NG and something like SSDL.

In case you missed it on the XFire blog, Tim Pokorny has posted some numbers on XFire’s SOAP performance. He is showing 80+ transactions per second with 4K messages and notes that the bottleneck is probably the Axis client. All reports seem to be coincinding very well and with very positive results. If you’re are having high latencies or low transactions per second, I think you could realize real gains by switching to XFire.

Since we’ve started to get a lot of performance reports recently, I’ve started a performance page on our website to collect them all. If you’re using XFire we’d love to hear from you as well.

Susie over at the Apache Marketing Blog (is this official???) writes some thoughts on why your project should be at the ASF.. While I like the ASF and I work on some projects there, I feel like the article is both horribly idealistic and one sided.

My main gripe is the idea that community results in a better product. Susie tries to convince the ActiveGrid project that Apache is the place to be.

Why not foster the kind of community that could create the kind of momentum you’d want to spread a message of this magnitude? A well marshalled community usually trumps one single voice (no matter how articulate it is) in beating the drum.

I don’t agree with this at all. One only needs to look at Apache to find this is not the case. Cosinder the Avalon project. Too many voices couldn’t create a coherent vision. As Eliotte Harold from XOM has demonstrated cathedral development can result in a much cleaner API and much better software.

This isn’t to say I don’t like Apache. I use software from Apache all the time and am a committer there. It just isn’t for everyone and doesn’t necessarily result in better software.

I ran across this entry on XFire performance from Tim Pokorny by accident yesterday. While I feel my numbers speak for themselves, its always good to hear it from a user:

…I decided to run only one client for 60 seconds and only on the AMD. It was able to get 3919 iterations completed in those 60 seconds. That is more than 65 updates per second. Perhaps the most amazing thing about this is the actual performance of web services (XFire in this case). These were not small updates either; two entities, each with something like eight attributes were being serialised into XML, sent over the wire and de-serialised into Java objects 65 times per second! That is HUGE. To put this in perspective, when previously asked by people about the real performance of web services (in the simulation context) I estimated that I could consistently get about 8 updates a second. Needless to say, 65 is almost an order of magnitude faster than that.

Eat that Axis!

(NOTE: I like the Axis guys and even recommend Axis in certain scenarios, I just like to jab them about their performance. :-))

Here is a quick guide on how to shrink/reduce a physical volume on linux:

First backup the configuration so we can edit and restore it.

# vgcfgbackup

Now you need to edit the backup config file. Go to the physical volume you want to resize (in my case pv0) and change the block size to what you want it to be. In my case I changed it from 4708 to 2874. Also take note of the ID.

# vi /etc/lvm/backup/VolGroup00

Next you need to commit the changes to the partition: The UUID is the id from the step above. You’ll also want to use the correct hard drive - which is most likely not /dev/hdd2. Run the “pvdisplay” command to figure out which one it is.

# pvcreate --restorefile ./VolGroup00 --uuid "l4wJi3-JDQb-7sjZ-B3oH-Va0D-v2Sp-FX2s3q" /dev/hdd2 -ff

Last, you need to restore your edited backup file:

# vgcfgrestore

And presto, your volume should be smaller now.