David:
First off, this isn't a "reproducible" problem. If it were, we'd all
have a solution. I have a hard time submitting something to UO support
that they can't reproduce. Their support is good, but what can they
do? For instance, several years ago one of our hosted clients would
produce a spooler entry that increased in size until the partition UD
was on ran out of disk space, and our hosted environment came crashing
down! UD support (aka Wally) was very good at getting back with me but
we couldn't reproduce the problem. It was a single page report loading
over, and over, and over again until the spooler entry ended up being
20Gb. The solution was to move the "_HOLD_" file off the UD partition
and off the O/S partition (luckily we build all machines with a C: -
O/S, D: - win apps, and E: - UD and data). But we never did find out
what the problem was caused by. It occurred again a couple of times but
we never could come close to reproducing it.
Regarding UO, I've got some Windows event logs and I have no idea what
in the world I'm looking for. Secondly, our resources are always
strained with the multi-layered technology environment we find ourselves
in these days. Our employees don't wait for their paychecks while we
try to track down UO problems. So, we spend our time monitoring if
anything bad percolates through to our clients accounts. If we can't
find anything we move on, but keep monitoring. What more can we do?
Finally, when someone on this list asks if anyone knows of problems
about...yada, yada, yada, we try to be helpful, and often reply
off-list. We aren't casting aspersions toward RS support, we're just
trying to answer users questions and discuss common themes that thread
themselves throughout our technology environment.
HTH,
Bill
------------------------------------------------------------------------
----- Original Message -----
*From:* [email protected]
*To:* 'U2 Users List' <[email protected]>
*Date:* 5/4/2011 1:08 PM
*Subject:* Re: [U2] uv v ud
SO... what does Rocket say when you ask for Support on UO?
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Tony Gravagno
Sent: Wednesday, May 04, 2011 1:15 PM
To: [email protected]
Subject: Re: [U2] uv v ud
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
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users
