Since I'm mentioned here... As Bill's vendor and support provider for mv.NET I feel bad when underlying technologies fail. Metaphorically speaking, the auto mechanic can't fix potholes, only help to improve the shock absorbers to make the bumps less painful. As Bill's friend, we frequently discuss the issues of multi-tier development and I get as frustrated as he does.
With UO.NET, exceptions are sometimes thrown which log errors with no detail. The exception is not passed up to the client. The net result is that "something" has failed, we don't know what it was, we don't have any way to control it, and we don't know if it has adversely affected our transaction processing. It "looks" like everything is OK, except for these mysterious logs. Symeon posted some great info here many months ago about setting tracking info for UO.NET in web.config. I passed that to Bill a while back but haven't heard back. In line with Bill's comments, error tracking like this is just another tier of time consuming aggravation. The burden of debugging issues like this is shared amongst many people, including those who don't know and should not have to know about the underlying technologies. When UO/UO.NET works, it's great. But frankly, over the long term, UO/UO.NET has been a chronic source of low-level pain, and it's Extremely difficult to get anyone to help diagnose or remedy related issues. Developers and end-users are left to scratch their heads for months wondering how to diagnose the black box. It would really be nice for Rocket to step up with a UO Trauma Center to quickly diagnose and resolve chronic, nagging communications issues. As Bill's mv.NET vendor I can't continue to spend hours trying to debug UO potholes - I have no code and can't interpret logs. Bill shouldn't have to do that either. The people with the code should be supporting that component. Regards, T > From: Bill Haskett > An interesting side note is debugging. When > technologists suggest we use a "black-box" technology > approach, all this does is create massive > investigation problems in a "layered" environment; > which most are today. For not-easily-reproducible > problems, logging exacerbates the problem because now > where we're looking for a needle problem located > somewhere in these large haystack logs. :-) _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
