Our system administration team takes the approach of looking for any
ERROR lines and any stack traces. Not saying stacktraces are the
easiest thing in the world to 'grep' for, but that's what they typically
look for. I can definitely see a benefit in somehow writing a line to
the log file that is an ERROR for any unexpected exception that uPortal
catches a channel producing.
---- Cris J H
Paul Gazda wrote:
I see your point. Maybe the problem is that too many different types of
rendering errors are wrapped inside the WARNING status of this particular
message.
I have looked at the logs more, and see a wider variety of errors than I
thought. For example, one of these contains a
java.lang.StringIndexOutOfBoundsException as the root cause, another
contains java.lang.NullPointerException. These, I would definitely call
errors. Wrapping so many different situations inside a WARNING category
makes it very difficult to monitor the operational state of the portal. It
is easy to find all messages starting with 'ERROR' either automatically or
manually to look for trends, but it is difficult to if you have to examine
the internal details of messages inside of WARNING categories.
Paul Gazda
Senior Web Developer
Information Technology Services
Northern Arizona University
[EMAIL PROTECTED]
(928) 523-6844
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Cris J Holdorph
Sent: Wednesday, August 15, 2007 4:21 PM
To: [email protected]
Subject: Re: [uportal-dev] Change unsuccessful rendering message to ERROR?
I disagree. Channel timeout is a warning, because the timeout value was
exceeded. You (as the administrator) may be fine with that. If you
want to know about WARNINGs you can certainly bump up the logs to
display them. Think about the situation where, possibly an RSS reader
is configurable by an end user to point to an RSS feed of their
choosing. They could choose a feed with very poor connectivity. I do
not want to see ERRORS just because a user picked an RSS feed that takes
a long time to respond. Other similar user errors can cause channel
timeouts. Therefore I think it's only a WARNING.
And uPortal is open source, so if you completely disagree you can change
the code for your own environment.
I can see both sides to it being a WARNING or and ERROR, but if it comes
to voting, I cast my vote for keeping it a WARNING.
---- Cris J H
Paul Gazda wrote:
When a channel does not render, often due to timeout, the log message
(see below) indicates a WARNING rather than an error, even though the
message details refer to "ErrorDocument", "error channel", and "error
code". It also seems that when a channel does not render, that should be
an error rather than a warning. If a channel is timing out, I want to
know about it. It may indicate a database or ldap connectivity issue,
for example. When I scan logs for problems either programmatically or
manually, I look for "ERROR". The "Replacing channel" WARNING always
slips through the cracks.
I am thinking of creating a JIRA issue to change the message category to
"ERROR". Are there any reasons not to do this that I am not aware of?
WARN [TP-Processor16] portal.ChannelManager.[] Aug/15 09:53:31 -
Replacing channel [BaseChannel: st
aticData = [.channel static data here .] isGuest:false] ] runtimeData =
[null]],
which had subscribeId [u43520l1n80] with error channel because of error
code Rendering timeout mess
age: unsuccessful rendering and throwable [null]
WARN [Thread-10770] error.CError.[] Aug/15 09:53:31 - ErrorDocument XML
is
<error code="4">
<message>unsuccessful rendering</message>
<channel>
<id>u43520l1n80</id>
<name>PortalMail</name>
</channel>
</error>
Paul Gazda
Senior Web Developer
Information Technology Services
Northern Arizona University
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
(928) 523-6844
--
You are currently subscribed to [email protected] as:
[EMAIL PROTECTED]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
--
You are currently subscribed to [email protected] as: [EMAIL
PROTECTED]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
