Fixed a few more posts
This commit is contained in:
Chris Hodapp
parent
857359fd70
commit
30351a5c34
@ -1,12 +1,13 @@
|
|||||||
---
|
---
|
||||||
layout: post
|
|
||||||
title: I can never win that context back
|
title: I can never win that context back
|
||||||
|
date: June 10, 2011
|
||||||
|
author: Chris Hodapp
|
||||||
tags: Journal, rant
|
tags: Journal, rant
|
||||||
status: publish
|
|
||||||
type: post
|
|
||||||
published: true
|
|
||||||
---
|
---
|
||||||
I stumbled upon this: [http://www.soyoucode.com/2011/coding-giant-under-microscope-farbrausch](http://www.soyoucode.com/2011/coding-giant-under-microscope-farbrausch) . . . and promptly fell in love with the demos there from Farbrausch:
|
|
||||||
|
I stumbled upon this:
|
||||||
|
[http://www.soyoucode.com/2011/coding-giant-under-microscope-farbrausch](http://www.soyoucode.com/2011/coding-giant-under-microscope-farbrausch)
|
||||||
|
. . . and promptly fell in love with the demos there from Farbrausch:
|
||||||
|
|
||||||
[.the .product](http://www.youtube.com/watch?v=3ydAHt78v2M)
|
[.the .product](http://www.youtube.com/watch?v=3ydAHt78v2M)
|
||||||
|
|
||||||
@ -16,12 +17,29 @@ I stumbled upon this: [http://www.soyoucode.com/2011/coding-giant-under-microsco
|
|||||||
|
|
||||||
[Magellan](http://www.youtube.com/watch?v=00SdDZyWSEs)
|
[Magellan](http://www.youtube.com/watch?v=00SdDZyWSEs)
|
||||||
|
|
||||||
That melding of music and animated 3D graphics grabs a hold of me like nothing else. I don't really know why.
|
That melding of music and animated 3D graphics grabs a hold of me like
|
||||||
|
nothing else. I don't really know why.
|
||||||
|
|
||||||
The fact that it's done in such a small space (e.g. 64 KB for the first one) makes it more impressive, of course. Maybe that should be a sad reflection on just how formulaic the things I like are, if they're encoded that small (although, that ignores just how much is present in addition, in the CPU and the GPU and the OS and the drivers and in the design of the computer), but I don't much care - formulas encode patterns of sorts, and we're pattern-matching machines.
|
The fact that it's done in such a small space (e.g. 64 KB for the
|
||||||
|
first one) makes it more impressive, of course. Maybe that should be a
|
||||||
|
sad reflection on just how formulaic the things I like are, if they're
|
||||||
|
encoded that small (although, that ignores just how much is present in
|
||||||
|
addition, in the CPU and the GPU and the OS and the drivers and in the
|
||||||
|
design of the computer), but I don't much care - formulas encode
|
||||||
|
patterns of sorts, and we're pattern-matching machines.
|
||||||
|
|
||||||
But leaving aside the huge programming feat of making all this fit in such a small space, I still find it really impressive.
|
But leaving aside the huge programming feat of making all this fit in
|
||||||
|
such a small space, I still find it really impressive.
|
||||||
|
|
||||||
It's been a goal for awhile to make something that is on the scope of that (highly-compressed demo or not, I don't much care). I've just not made much progress to accomplishing that. My early attempts at Acidity were motivated by the same feelings that draw me to things like this.
|
It's been a goal for awhile to make something that is on the scope of
|
||||||
|
that (highly-compressed demo or not, I don't much care). I've just not
|
||||||
|
made much progress to accomplishing that. My early attempts at Acidity
|
||||||
|
were motivated by the same feelings that draw me to things like this.
|
||||||
|
|
||||||
(Obligatory [Second Reality](http://www.youtube.com/watch?v=8G_aUxbbqWU) as well. Maybe I am putting myself too much in the context that it came from - i.e. 1993 and rather slow DOS machines - but I still think it's damn impressive. Incidentally, this is also one of the only ones I've run on real hardware before, since apparently the only fast machine I have that runs Windows is my work computer.)
|
(Obligatory
|
||||||
|
[Second Reality](http://www.youtube.com/watch?v=8G_aUxbbqWU) as
|
||||||
|
well. Maybe I am putting myself too much in the context that it came
|
||||||
|
from - i.e. 1993 and rather slow DOS machines - but I still think it's
|
||||||
|
damn impressive. Incidentally, this is also one of the only ones I've
|
||||||
|
run on real hardware before, since apparently the only fast machine I
|
||||||
|
have that runs Windows is my work computer.)
|
||||||
|
|||||||
@ -1,43 +1,116 @@
|
|||||||
---
|
---
|
||||||
layout: post
|
|
||||||
title: OpenFrameworks, try 1...
|
title: OpenFrameworks, try 1...
|
||||||
tags: rant, Technobabble
|
date: June 13, 2011
|
||||||
status: publish
|
author: Chris Hodapp
|
||||||
type: post
|
tags: Technobabble, rant
|
||||||
published: true
|
|
||||||
---
|
---
|
||||||
My attempts at doing things with OpenFrameworks on MacOS X have been mildly disastrous. This is a bit of a shame, because I was really starting to like OpenFrameworks and it was not tough to pick up after being familiar with Processing.
|
|
||||||
|
|
||||||
I'm pretty new to XCode, but it's the "official" environment for OpenFrameworks on OS X, so it's the first thing I tried. The first few attempts at things (whether built-in examples, or my own code) went just fine, but today I started trying some things that were a little more complex - i.e. saving the last 30 frames from the camera and using them for some filtering operations. My code probably had some mistakes in it, I'm sure, and that's to be expected. The part where things became incredibly stupid was somewhere around when the mistakes caused the combination of XCode, GDB, and OpenFrameworks to hose the system in various ways.
|
My attempts at doing things with
|
||||||
|
[OpenFrameworks](http://openframeworks.cc/) on MacOS X have been
|
||||||
|
mildly disastrous. This is a bit of a shame, because I was really
|
||||||
|
starting to like OpenFrameworks and it was not tough to pick up after
|
||||||
|
being familiar with [Processing](https://processing.org/).
|
||||||
|
|
||||||
First, it was the Dock taking between 15 and 30 seconds to respond just so I could force-quit the application. Then it was the debugger taking several seconds to do 100 iterations of a loop that had nothing more than an array member assignment inside of it (and it had 640x480x3 = 921,600 iterations total) if I tried to set breakpoints, thus basically making interactive debugging impossible. The debugging was already a pain in the ass; I had reduced some code down to something like this:
|
I'm pretty new to XCode, but it's the "official" environment for
|
||||||
{% highlight c %}
|
OpenFrameworks on OS X, so it's the first thing I tried. The first few
|
||||||
|
attempts at things (whether built-in examples, or my own code) went
|
||||||
|
just fine, but today I started trying some things that were a little
|
||||||
|
more complex - i.e. saving the last 30 frames from the camera and
|
||||||
|
using them for some filtering operations. My code probably had some
|
||||||
|
mistakes in it, I'm sure, and that's to be expected. The part where
|
||||||
|
things became incredibly stupid was somewhere around when the mistakes
|
||||||
|
caused the combination of XCode, GDB, and OpenFrameworks to hose the
|
||||||
|
system in various ways.
|
||||||
|
|
||||||
|
First, it was the Dock taking between 15 and 30 seconds to respond
|
||||||
|
just so I could force-quit the application. Then it was the debugger
|
||||||
|
taking several seconds to do 100 iterations of a loop that had nothing
|
||||||
|
more than an array member assignment inside of it (and it had
|
||||||
|
640x480x3 = 921,600 iterations total) if I tried to set breakpoints,
|
||||||
|
thus basically making interactive debugging impossible. The debugging
|
||||||
|
was already a pain in the ass; I had reduced some code down to
|
||||||
|
something like this:
|
||||||
|
|
||||||
|
```c
|
||||||
int size = cam_width * cam_height * 3;
|
int size = cam_width * cam_height * 3;
|
||||||
for(int i = 0; i < frame_count; ++i) {
|
for(int i = 0; i < frame_count; ++i) {
|
||||||
unsigned char * blah = new unsigned char[size];
|
unsigned char * blah = new unsigned char[size];
|
||||||
for(int j = 0; j < size; ++j) blah[j] = 0;
|
for(int j = 0; j < size; ++j) blah[j] = 0;
|
||||||
}
|
}
|
||||||
{% endhighlight %}
|
```
|
||||||
|
|
||||||
...after a nearly identical `memset` call was smashing the stack and setting `frame_count` to a value in the billions, so I was really getting quite frazzled at this.
|
...after a nearly identical `memset` call was smashing the stack and
|
||||||
|
setting `frame_count` to a value in the billions, so I was really
|
||||||
|
getting quite frazzled at this.
|
||||||
|
|
||||||
Running it a few minutes ago without breakpoints enabled led to a bunch of extreme sluggishness, then flickering and flashing on the monitor and I was not able to interact with anything in the GUI (which was the 3rd or 4th time this had happened today, with all the Code::Blocks nonsense below). I SSHed in from another machine and killed XCode, but the monitor just continued to show the same image, and it appeared that the GUI was completely unresponsive except for a mouse cursor. I had to hold the power button to reboot, and saw this in the Console but nothing else clear before it:
|
Running it a few minutes ago without breakpoints enabled led to a
|
||||||
|
bunch of extreme sluggishness, then flickering and flashing on the
|
||||||
|
monitor and I was not able to interact with anything in the GUI (which
|
||||||
|
was the 3rd or 4th time this had happened today, with all the
|
||||||
|
Code::Blocks nonsense below). I SSHed in from another machine and
|
||||||
|
killed XCode, but the monitor just continued to show the same image,
|
||||||
|
and it appeared that the GUI was completely unresponsive except for a
|
||||||
|
mouse cursor. I had to hold the power button to reboot, and saw this
|
||||||
|
in the Console but nothing else clear before it:
|
||||||
|
|
||||||
|
```
|
||||||
6/13/11 1:11:19 AM [0x0-0x24024].com.google.Chrome[295] [463:24587:11560062687119:ERROR:gpu_watchdog_thread.cc(236)] The GPU process hung. Terminating after 10000 ms.
|
6/13/11 1:11:19 AM [0x0-0x24024].com.google.Chrome[295] [463:24587:11560062687119:ERROR:gpu_watchdog_thread.cc(236)] The GPU process hung. Terminating after 10000 ms.
|
||||||
|
```
|
||||||
|
|
||||||
A little before trying XCode for a 2nd time, I had also attempted to set up Code::Blocks since it's OpenFrameworks' "official" IDE for Linux and Windows and XCode was clearly having . First I painstakingly made it built from an SVN copy and finally got it to run (had to disable FileManager and NassiShneiderman plugins which would not build and make sure it was building for the same architecture as wxWidgets was built for). As soon as I tried to quit it, the Dock became totally unresponsive, then Finder itself followed along with the menu bar for the whole system. I was not able to SSH in. Despite the system being mostly responsive, I had to hard reset. I found a few things in the console:
|
A little before trying XCode for a 2nd time, I had also attempted to
|
||||||
|
set up Code::Blocks since it's OpenFrameworks' "official" IDE for
|
||||||
|
Linux and Windows and XCode was clearly having . First I painstakingly
|
||||||
|
made it built from an SVN copy and finally got it to run (had to
|
||||||
|
disable FileManager and NassiShneiderman plugins which would not build
|
||||||
|
and make sure it was building for the same architecture as wxWidgets
|
||||||
|
was built for). As soon as I tried to quit it, the Dock became totally
|
||||||
|
unresponsive, then Finder itself followed along with the menu bar for
|
||||||
|
the whole system. I was not able to SSH in. Despite the system being
|
||||||
|
mostly responsive, I had to hard reset. I found a few things in the
|
||||||
|
console:
|
||||||
|
|
||||||
|
```
|
||||||
6/12/11 9:43:54 PM com.apple.launchd[1] (com.apple.coreservicesd[66]) Job appears to have crashed: Segmentation fault
|
6/12/11 9:43:54 PM com.apple.launchd[1] (com.apple.coreservicesd[66]) Job appears to have crashed: Segmentation fault
|
||||||
6/12/11 9:43:54 PM com.apple.audio.coreaudiod[163] coreaudiod: CarbonCore.framework: coreservicesd process died; attempting to reconnect but future use may result in erroneous behavior
|
6/12/11 9:43:54 PM com.apple.audio.coreaudiod[163] coreaudiod: CarbonCore.framework: coreservicesd process died; attempting to reconnect but future use may result in erroneous behavior
|
||||||
6/12/11 9:43:55 PM com.apple.ReportCrash.Root[18181] 2011-06-12 21:43:55.011 ReportCrash[18181:2803] Saved crash report for coreservicesd[66] version ??? (???) to /Library/Logs/DiagnosticReports/coreservicesd_2011-06-12-214355_localhost.crash
|
6/12/11 9:43:55 PM com.apple.ReportCrash.Root[18181] 2011-06-12 21:43:55.011 ReportCrash[18181:2803] Saved crash report for coreservicesd[66] version ??? (???) to /Library/Logs/DiagnosticReports/coreservicesd_2011-06-12-214355_localhost.crash
|
||||||
6/12/11 9:44:26 PM com.apple.Dock.agent[173] Sun Jun 12 21:44:26 hodapple2.local Dock[173] Error: kCGErrorIllegalArgument: CGSSetWindowTransformsAtPlacement: Singular matrix at index 2: [0.000 0.000 0.000 0.000]
|
6/12/11 9:44:26 PM com.apple.Dock.agent[173] Sun Jun 12 21:44:26 hodapple2.local Dock[173] Error: kCGErrorIllegalArgument: CGSSetWindowTransformsAtPlacement: Singular matrix at index 2: [0.000 0.000 0.000 0.000]
|
||||||
|
```
|
||||||
|
|
||||||
It started up properly after a reset, but I couldn't do anything useful with it because despite there being a script that was supposed to take care of this while building the bundle the application was not able to see any of its plugins, which included a compiler plugin. I attempted a binary OS X release which had a functioning set of plugins, but was missing other dependencies set in the projects, which were Linux-specific. I could probably put together a working configuration if I worked in Code::Blocks a bit, but I have not tried yet.
|
It started up properly after a reset, but I couldn't do anything
|
||||||
|
useful with it because despite there being a script that was supposed
|
||||||
|
to take care of this while building the bundle the application was not
|
||||||
|
able to see any of its plugins, which included a compiler plugin. I
|
||||||
|
attempted a binary OS X release which had a functioning set of
|
||||||
|
plugins, but was missing other dependencies set in the projects, which
|
||||||
|
were Linux-specific. I could probably put together a working
|
||||||
|
configuration if I worked in Code::Blocks a bit, but I have not tried
|
||||||
|
yet.
|
||||||
|
|
||||||
This is all incredibly annoying. There is no reason a user process should be capable of taking down the whole system like this, especially inside of a debugger, yet apparently it's pretty trivial to make this happen. I've written more than enough horrible code in various different environments (CUDA-GDB on a Tesla C1060, perhaps?) to know what to expect. I guess I can try developing on Linux instead, and/or using Processing. I know it's not quite the same, but I've never had a Processing sketch hose the whole system at least.
|
This is all incredibly annoying. There is no reason a user process
|
||||||
|
should be capable of taking down the whole system like this,
|
||||||
|
especially inside of a debugger, yet apparently it's pretty trivial to
|
||||||
|
make this happen. I've written more than enough horrible code in
|
||||||
|
various different environments (CUDA-GDB on a Tesla C1060, perhaps?)
|
||||||
|
to know what to expect. I guess I can try developing on Linux instead,
|
||||||
|
and/or using Processing. I know it's not quite the same, but I've
|
||||||
|
never had a Processing sketch hose the whole system at least.
|
||||||
|
|
||||||
*Later addition (2011-06-20, but not written here until November because I'd buried the notes somewhere):*
|
*Later addition (2011-06-20, but not written here until November because I'd buried the notes somewhere):*
|
||||||
|
|
||||||
I attempted to make an OpenFrameworks project built with Qt Creator (which of course uses [QMake](http://doc.qt.nokia.com/latest/qmake-manual.html). OpenFrameworks relies on QuickTime, and as it happens, QuickTime is 32-bit only. If you take a look at some of the headers, the majority of it is just #ifdef'ed away if you try to build 64-bit and this completely breaks the OpenFrameworks build.
|
I attempted to make an OpenFrameworks project built with Qt Creator
|
||||||
|
(which of course uses
|
||||||
|
[QMake](http://doc.qt.nokia.com/latest/qmake-manual.html). OpenFrameworks
|
||||||
|
relies on QuickTime, and as it happens, QuickTime is 32-bit only. If
|
||||||
|
you take a look at some of the headers, the majority of it is just
|
||||||
|
#ifdef'ed away if you try to build 64-bit and this completely breaks
|
||||||
|
the OpenFrameworks build.
|
||||||
|
|
||||||
Ordinarily, this would not be an issue as I would just do a 32-bit build of everything else too. However, QMake refuses to do a 32-bit build on OS X for some unknown reason (and, yes, I talked to some Qt devs about this). It'll gladly do it on most other platforms, but not on OS X. Now, GCC has no problems building 32-bit, but this does no good when QMake keeps adding `-arch x86_64` no matter what. I attempted all sorts of options such as `CONFIG += x86`, `CONFIG -= x86_64`, `QMAKE_CXXFLAGS -= -arch x86_64`, or `+= -m32`, or `+= -arch i386`... but none of them to any avail.
|
Ordinarily, this would not be an issue as I would just do a 32-bit
|
||||||
|
build of everything else too. However, QMake refuses to do a 32-bit
|
||||||
|
build on OS X for some unknown reason (and, yes, I talked to some Qt
|
||||||
|
devs about this). It'll gladly do it on most other platforms, but not
|
||||||
|
on OS X. Now, GCC has no problems building 32-bit, but this does no
|
||||||
|
good when QMake keeps adding `-arch x86_64` no matter what. I
|
||||||
|
attempted all sorts of options such as `CONFIG += x86`, `CONFIG -=
|
||||||
|
x86_64`, `QMAKE_CXXFLAGS -= -arch x86_64`, or `+= -m32`, or `+= -arch i386`...
|
||||||
|
but none of them to any avail.
|
||||||
|
|||||||
@ -1,34 +1,124 @@
|
|||||||
---
|
---
|
||||||
layout: post
|
|
||||||
title: My experiences with Apache Axis2/C
|
title: My experiences with Apache Axis2/C
|
||||||
|
date: July 15, 2011
|
||||||
tags: Project, rant, Technobabble
|
tags: Project, rant, Technobabble
|
||||||
status: publish
|
author: Chris Hodapp
|
||||||
type: post
|
|
||||||
published: true
|
|
||||||
---
|
---
|
||||||
(This is an abridged version of a report I did at my job; I might post of copy of it once I remove anything that might be considered proprietary.)
|
|
||||||
|
|
||||||
I was tasked at my job with looking at ways of doing web services in our main application (which for an upcoming delivery is to be separated out into client and server portions). Said application is written primarily in C++, so naturally our first look was into frameworks written for C or C++ so that we would not need to bother with language bindings, foreign function interfaces, porting, new runtimes, or anything of the sort.
|
(This is an abridged version of a report I did at my job; I might post
|
||||||
|
of copy of it once I remove anything that might be considered
|
||||||
|
proprietary.)
|
||||||
|
|
||||||
Our search led us to [Apache Axis2/C](http://axis.apache.org/axis2/c/core/). We'd examined this last year at a basic level and found that it looked suitable. Its primary intended purpose was as the framework that the client and server communicated over in order to transfer our various DTOs; that it worked over SOAP and handled most HTTP details (so it appeared) was a bonus.
|
I was tasked at my job with looking at ways of doing web services in
|
||||||
|
our main application (which for an upcoming delivery is to be
|
||||||
|
separated out into client and server portions). Said application is
|
||||||
|
written primarily in C++, so naturally our first look was into
|
||||||
|
frameworks written for C or C++ so that we would not need to bother
|
||||||
|
with language bindings, foreign function interfaces, porting, new
|
||||||
|
runtimes, or anything of the sort.
|
||||||
|
|
||||||
I discovered after investing considerable effort that we were quite wrong about Axis2/C. I'll enumerate a partial list of issues here:
|
Our search led us to
|
||||||
- **Lack of support:** There was a distinct lack of good information online. I could find no real record of anyone using this framework in production anywhere. Mailing lists and message forums seemed nonexistent. I found a number of articles that were often pretty well-written, but almost invariably by WSO2 employees.
|
[Apache Axis2/C](http://axis.apache.org/axis2/c/core/). We'd examined
|
||||||
- **Development is largely stagnant:** The last update was in 2009. In and of itself this is not a critical issue, but combined with its extensive list of unsolved bugs and a very dense, undocumented code base, this is unacceptable.
|
this last year at a basic level and found that it looked suitable. Its
|
||||||
- **Lack of documentation:** Some documentation is online, but the vast majority of the extensive API lacks any documentation, whether a formal reference or a set of examples. The most troubling aspect of this is that not even the developers of Axis2/C seemed to comprehend its memory management (and indeed our own tests showed some extensive memory leaks).
|
primary intended purpose was as the framework that the client and
|
||||||
- **Large set of outstanding bugs:** When I encountered the bug-tracking website for Axis2/C (which I seem to have lost the link for), I discovered a multitude of troubling bugs. Most of them pertain to unfixed memory leaks (for code that will be running inside of a web server, this is really not good). On top of this, a 2-year-old unfixed bug had broken the functionality for binary MTOM transfers if you had enabled libcurl support, and this feature was rather essential to the application.
|
server communicated over in order to transfer our various DTOs; that
|
||||||
- **Necessity of repetitive code:** It lacked any production-ready means to automatically generate code for turning native C/C++ objects to and from SOAP. While it had WSDL2C, this still left considerable repetitive work for the programmer (in many cases causing more work rather than less) and its generated code was very ambiguous as to its memory-management habits.
|
it worked over SOAP and handled most HTTP details (so it appeared) was
|
||||||
- **Limited webserver support:** Axis2/C provided modules only for working with three web servers: Apache HTTPD, Microsoft IIS, and their built-in test server, *axis2_http_server*. Our intended target was Microsoft IIS, and the support for IIS was considerably less developed than the support for Apache HTTPD. To be honest, though, most of my woes came from Microsoft here - and the somewhat pathetic functionality for logging and configuration that IIS has. I'm sorry for anyone who loves IIS, but I should not be required to *manually search through a dump of Windows system calls* to determine that the reason for IIS silently failing is that I gave a 64-bit pool a 32-bit DLL, or that said DLL has unmet dependencies. Whether it's Axis2/C's fault or IIS's fault that the ISAPI DLL managed to either take IIS down or leave it an an indeterminate state no less than a hundred times doesn't much matter to me. *(However, on the upside, I did learn that [Process Monitor](http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) from Sysinternals can be very useful in cases where you have otherwise no real source of diagnostic information. This is not the first time I had to dump system calls to diagnose an Axis2/C problem.)*
|
a bonus.
|
||||||
- **Poor performance:** Even the examples provided in the Axis2/C source code itself had a tendency to fail to work properly.
|
|
||||||
- Their MTOM transfer example failed to work at all with Microsoft IIS and had horrid performance with Apache HTTPD.
|
|
||||||
- On top of this, the default configuration of Apache Axis2/C opens up a new TCP connection for every single request that is initiated. Each TCP connection, of course, occupies a port on the client side. On Windows, something like 240 seconds (by default) must pass upon that connection closing before the port may be reused; on Linux, I think it's 30 seconds. There are 16384 ports available for this purpose. Practical result of this: *A client with the default configuration of Axis2/C cannot sustain more than 68 requests per second on Windows or 273 requests per second on Linux.* If you exceed that rate, it will simply start failing. How did I eventually figure this out? By reading documentation carefully? By looking at an API reference? By looking at comments in the source code? No, *by looking at a packet dump in Wireshark,* which pointed out to me the steadily increasing port numbers and flagged that ports were being reused unexpectedly. I later found out that I needed to compile Axis2/C with libcurl support and then it would use a persistent HTTP connection (and also completely break MTOM support because of that unfixed bug I mentioned). None of this was documented anywhere, unless a cryptic mailing-list message from years ago counts.
|
|
||||||
|
|
||||||
So, I'm sorry, esteemed employees of [WSO2](http://wso2.org/), but to claim that Apache Axis2/C is enterprise ready is a horrid mockery of the term.
|
I discovered after investing considerable effort that we were quite
|
||||||
|
wrong about Axis2/C. I'll enumerate a partial list of issues here:
|
||||||
|
|
||||||
This concluded about 2 weeks of work on the matter. In approximately 6 hours (and I'll add that my starting point was knowing nothing about the Java technologies), I had a nearly identical version using Java web services (JAX-WS particularly) that was performing on the order of twice as fast and with none of the issues with memory leaks or stability.
|
- **Lack of support:** There was a distinct lack of good information
|
||||||
|
online. I could find no real record of anyone using this framework
|
||||||
|
in production anywhere. Mailing lists and message forums seemed
|
||||||
|
nonexistent. I found a number of articles that were often pretty
|
||||||
|
well-written, but almost invariably by WSO2 employees.
|
||||||
|
- **Development is largely stagnant:** The last update was in 2009. In
|
||||||
|
and of itself this is not a critical issue, but combined with its
|
||||||
|
extensive list of unsolved bugs and a very dense, undocumented code
|
||||||
|
base, this is unacceptable.
|
||||||
|
- **Lack of documentation:** Some documentation is online, but the
|
||||||
|
vast majority of the extensive API lacks any documentation, whether
|
||||||
|
a formal reference or a set of examples. The most troubling aspect
|
||||||
|
of this is that not even the developers of Axis2/C seemed to
|
||||||
|
comprehend its memory management (and indeed our own tests showed
|
||||||
|
some extensive memory leaks).
|
||||||
|
- **Large set of outstanding bugs:** When I encountered the
|
||||||
|
bug-tracking website for Axis2/C (which I seem to have lost the link
|
||||||
|
for), I discovered a multitude of troubling bugs. Most of them
|
||||||
|
pertain to unfixed memory leaks (for code that will be running
|
||||||
|
inside of a web server, this is really not good). On top of this, a
|
||||||
|
2-year-old unfixed bug had broken the functionality for binary MTOM
|
||||||
|
transfers if you had enabled libcurl support, and this feature was
|
||||||
|
rather essential to the application.
|
||||||
|
- **Necessity of repetitive code:** It lacked any production-ready
|
||||||
|
means to automatically generate code for turning native C/C++
|
||||||
|
objects to and from SOAP. While it had WSDL2C, this still left
|
||||||
|
considerable repetitive work for the programmer (in many cases
|
||||||
|
causing more work rather than less) and its generated code was very
|
||||||
|
ambiguous as to its memory-management habits.
|
||||||
|
- **Limited webserver support:** Axis2/C provided modules only for
|
||||||
|
working with three web servers: Apache HTTPD, Microsoft IIS, and
|
||||||
|
their built-in test server, *axis2_http_server*. Our intended target
|
||||||
|
was Microsoft IIS, and the support for IIS was considerably less
|
||||||
|
developed than the support for Apache HTTPD. To be honest, though,
|
||||||
|
most of my woes came from Microsoft here - and the somewhat pathetic
|
||||||
|
functionality for logging and configuration that IIS has. I'm sorry
|
||||||
|
for anyone who loves IIS, but I should not be required to *manually
|
||||||
|
search through a dump of Windows system calls* to determine that the
|
||||||
|
reason for IIS silently failing is that I gave a 64-bit pool a
|
||||||
|
32-bit DLL, or that said DLL has unmet dependencies. Whether it's
|
||||||
|
Axis2/C's fault or IIS's fault that the ISAPI DLL managed to either
|
||||||
|
take IIS down or leave it an an indeterminate state no less than a
|
||||||
|
hundred times doesn't much matter to me. *(However, on the upside, I
|
||||||
|
did learn that
|
||||||
|
[Process Monitor](http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx)
|
||||||
|
from Sysinternals can be very useful in cases where you have
|
||||||
|
otherwise no real source of diagnostic information. This is not the
|
||||||
|
first time I had to dump system calls to diagnose an Axis2/C
|
||||||
|
problem.)*
|
||||||
|
- **Poor performance:** Even the examples provided in the Axis2/C
|
||||||
|
source code itself had a tendency to fail to work properly.
|
||||||
|
- Their MTOM transfer example failed to work at all with Microsoft
|
||||||
|
IIS and had horrid performance with Apache HTTPD.
|
||||||
|
- On top of this, the default configuration of Apache Axis2/C
|
||||||
|
opens up a new TCP connection for every single request that is
|
||||||
|
initiated. Each TCP connection, of course, occupies a port on
|
||||||
|
the client side. On Windows, something like 240 seconds (by
|
||||||
|
default) must pass upon that connection closing before the port
|
||||||
|
may be reused; on Linux, I think it's 30 seconds. There are
|
||||||
|
16384 ports available for this purpose. Practical result of
|
||||||
|
this: *A client with the default configuration of Axis2/C cannot
|
||||||
|
sustain more than 68 requests per second on Windows or 273
|
||||||
|
requests per second on Linux.* If you exceed that rate, it will
|
||||||
|
simply start failing. How did I eventually figure this out? By
|
||||||
|
reading documentation carefully? By looking at an API reference?
|
||||||
|
By looking at comments in the source code? No, *by looking at a
|
||||||
|
packet dump in Wireshark,* which pointed out to me the steadily
|
||||||
|
increasing port numbers and flagged that ports were being reused
|
||||||
|
unexpectedly. I later found out that I needed to compile Axis2/C
|
||||||
|
with libcurl support and then it would use a persistent HTTP
|
||||||
|
connection (and also completely break MTOM support because of
|
||||||
|
that unfixed bug I mentioned). None of this was documented
|
||||||
|
anywhere, unless a cryptic mailing-list message from years ago
|
||||||
|
counts.
|
||||||
|
|
||||||
|
So, I'm sorry, esteemed employees of [WSO2](http://wso2.org/), but to
|
||||||
|
claim that Apache Axis2/C is enterprise ready is a horrid mockery of
|
||||||
|
the term.
|
||||||
|
|
||||||
|
This concluded about 2 weeks of work on the matter. In approximately 6
|
||||||
|
hours (and I'll add that my starting point was knowing nothing about
|
||||||
|
the Java technologies), I had a nearly identical version using Java
|
||||||
|
web services (JAX-WS particularly) that was performing on the order of
|
||||||
|
twice as fast and with none of the issues with memory leaks or
|
||||||
|
stability.
|
||||||
|
|
||||||
|
P.S. Is it unique to Windows-related forums that the pattern of
|
||||||
|
support frequently goes like this?
|
||||||
|
|
||||||
P.S. Is it unique to Windows-related forums that the pattern of support frequently goes like this?
|
|
||||||
- Me: This software is messed up. It's not behaving as it should.
|
- Me: This software is messed up. It's not behaving as it should.
|
||||||
- Them: It's not messed up; it works for me. You are just too dumb to use it. Try pressing this button, and it will work.
|
- Them: It's not messed up; it works for me. You are just too dumb to
|
||||||
|
use it. Try pressing this button, and it will work.
|
||||||
- Me: Okay, I pressed it. It's not working.
|
- Me: Okay, I pressed it. It's not working.
|
||||||
- Them: Oh. Your software is messed up. You should fix it.
|
- Them: Oh. Your software is messed up. You should fix it.
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user