Charlie:
Excuse the reply to such an old post, but it hits on a sore spot for me that I’d like to see if there’s current feedback on. Hopefully my comments are seen as constructive criticism. 
I just went through a testing period with Wowza and FMS, and chose Wowza because on a feature / price comparison, it wins, and it did perform slightly better in my configuration than FMS. So far, it is running well and doing what is needed, without too much installation or troubleshooting difficulty. Your performance hints in the forum have been most helpful in troubleshooting the issues I have experienced.
The problem I have is the complete lack of tools available for me as an administrator. I stress that I am an administrator, NOT a Java developer, XML developer, SOAP developer, etc. I can do shell scripting, I can write a batch file, but beyond that, I have neither the time, skills, nor interest in having to build an interface for a server to manage it and understand what it is doing. I use tools that someone else has built to do this kind of work, and I even pay for them (sometimes).
There needs to be a management / monitoring client built for this product similar to what FMS has, plain and simple. MC4J hasn’t had decent dev work done on it in years (and isn’t stable in my experience), the Jconsole apps require me to have a deeper understanding of Java than I want, much less have, and not knowing what the heck is going on, per stream, per VHost, just stinks when you’re trying to troubleshoot a problem. I don’t mind working with Open Source tools that maybe don’t have the pretty interface of something like FMS’ admin console, but I need it to be stable, and I need it to be documented in Admin-speak, not Developer-speak. None of the recommended tools meets these needs. I don’t need an IDE. I’m not a developer. I’m not building custom modules. I’ll let my developers do that, who do need an IDE. I need an administration console that provides me real time performance information, since this is such a performance sensitive environment.
If Wowza isn’t going to spend the cycles / $ to develop their own admin console, then they should alternatively spend those cycles documenting how to make these other tools provide the most important information for performance monitoring / tuning and overall system administration, without assuming the user is a Java developer and understands the intricacies of classes, Mbeans, JVM trace calls, etc. This was a major issue that almost swung my decision to FMS away from Wowza. Their documents are abundant, and they approach things from a system admin perspective in the user guides, install guides, performance tuning guides, and from a developer’s perspective in the API guides, etc. I understand the resource pool is larger at Adobe, and Wowza has grown quickly with a single User Guide document laid out the way it currently is and without a home grown console tool, but to take things to the next level, I think this is going to be important. Given what I know now, it may become an even more important issue when evaluating these two tools for my next client.
If I’m missing some documentation somewhere that makes using MC4J more stable and lays out how to get the most out of it, point me to it. I haven’t been able to find it, though.
I would also strongly suggest a move away from the current logging practice. I support a lot of servers doing various tasks, and you are the only application in use in my supported farm that doesn’t have some way to integrate into syslog. Unacceptable. The java logging mechanism you use may be great, but the fact that I am having to figure out these logs to get any relevant information out of them is just ridiculous. The documentation stinks, quite frankly, and pointing me to someone else to figure out how to log events from YOUR application, is not an Enterprise class approach. It is shifting the buck. Again, FMS does it the right way. They use standard syslog mechanisms to get you all the information you need. Of course, we could debate whether this is the ‘right way’ or not, but you can’t really argue that it is the ‘standard way’, and if you want better market penetration, falling into a standardized way of doing things helps you. System administrators don’t want multiple log mechanisms. It makes it harder to correlate problems when you have them.
I do appreciate the articles in the forum about using AWstats with your logging mechanism. That will be helpful as I move to the next phase of the implementation.
Of course, these are just one guy’s thoughts. Take them for what they’re worth. You’ve built an app that seems tuned well (despite it being java based), has been stable thus far in my environment, and seems secure. Kudos, and thanks.
