Re: Runtime diagnosability

瀏覽次數:14 次
跳到第一則未讀訊息
訊息已遭刪除

Sandra Muller

未讀,
2009年4月3日 凌晨4:24:032009/4/3
收件者:ADF Enterprise Methodology Group
Hi Chandu,

I came across Oracle Real User Experience Insight (Oracle RUEI) and
this is a different approach to runtime diagnosis: from the user point
of view. It sniffs the network communication packages before it gets
to the application server(s) and is able to trace a user session this
way. You can configure how to recognize an HTML response with an error
shown to the user, and get alerts when that happens. That allows you
to trace back the user session where the error occurred, and
understand what (s)he was doing. You can also zoom in on userid and
time.

I'm not sure if this helps with what you are looking for, but if you
want to know more, check out
http://www.oracle.com/technology/products/oem/prod_focus/realuserexperienceinsight.html

kind regards,
Sandra

On Apr 2, 10:33 pm, Chandu Bhavsar <chandu.bhav...@gmail.com> wrote:
> Hi all,
>
> I was thinking about runtime diagnosability in ADF of late, and was
> wondering if anyone had any thoughts to share about this.
> Specifically, I was interested in hearing if user community finds the
> current level of diagnosability adequate or there are recommendations
> for improvement here.
>
> There have been thoughts expressed elsewhere about diagnosis issues
> with JSF (and so by extension ADF Faces) elsewhere, such as this:
>
> http://sfjsf.blogspot.com/2006/02/usability-problems-in-jsf.html
>
> It is quite an old post, but most of the points is mentions are still
> valid. Unfortunately, there is a not a lot of control ADF has over
> issues in lower stacks such as JSF.
>
> I realise I look at it slightly differently than most of you in day-to-
> day dealings: Attempting to narrow down issue with a specific
> component/subcomponent within ADF; as opposed to "differentiating
> between issues with application itself, versus issues with ADF
> platform" which I suspect most here would be concerned with. That's
> why I feel your input on how easy it is to do this differentiation
> today is valuable here.
>
> BTW, when I mention diagnosability, I'm not necessarily referring only
> to reading exception stacks when things go wrong. I'm also referring
> to logging, configuring granularity of logs, filtering on logs using
> whatever JMX admin agents and being able to pinpoint specific
> configuration change based on this information. So both exception
> stacks and logging, if anybody has opinions/ideas for improvement, I
> would love to hear about it.
>
> Thx,
> Chandu
訊息已遭刪除

Nathalie Roman

未讀,
2009年4月8日 清晨7:27:192009/4/8
收件者:ADF Enterprise Methodology Group
Hi Chandu,

On the wiki-page, the members of this group have tried to answer
different FAQ's regarding ADF as well runtime debugging as
diagnostics, httpAnalyzer, etc.
I would suggest you have a look at the FAQ page and if you can't find
the answer you're looking for, we can create a new topic for this
matter.

The wiki-page: http://wiki.oracle.com/page/Oracle+ADF+FAQ

Kind regards,
Nathalie

On Apr 4, 1:46 am, Chandu Bhavsar <chandu.bhav...@gmail.com> wrote:
> Sandra,
>
> Thanks much for the information on Oracle RUEI. This looks like an
> extension to Oracle EM which I'm well familiar with conceptually, but
> wasn't aware of this specific extension. It will be interesting to
> learn more about application of this technology to ADF apps in
> production.
>
> Yes, you're correct; RUEI would be for looking at diagnosability from
> a different angle than my original post. It is more relevant to
> production deployments of already well-tested applications. I started
> the topic thinking more about runtime diagnosis of issues during
> application development phase itself : Exploring if there are avenues
> to improve upon current runtime diagnostic, for improvement in
> developer productivity.
>
> Let me try to clarify my original post a bit with some concrete example
> (s). I guess I'm coming from a bit of privileged position when it
> comes to troubleshooting, having access to complete debug ADF (and
> other tiers as well if I wanted to) sources during in-house
> application development. In spite of this, there are times when it's
> not immediately obvious looking at existing diagnostic where the
> problem is coming from. Case in point, when presented with following
> exception stack recently, I couldn't immediately say for sure whether
> it was due to something wrong with the application itself, or a bug in
> ADF. To make a long story short, it ended up as some buggy logic in
> one of the application managed bean itself. It did require at least an
> hour's investigation on my part. This had me thinking if user
> community has any thoughts on enhancements in this area.
>
> javax.servlet.ServletException: Target Unreachable, '1' returned null
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:277)
> at weblogic.servlet.internal.StubSecurityHelper
> $ServletServiceAction.run(StubSecurityHelper.java:227)
> at weblogic.servlet.internal.StubSecurityHelper.invokeServlet
> (StubSecurityHelper.java:125)
> at weblogic.servlet.internal.ServletStubImpl.execute
> (ServletStubImpl.java:292)
> at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
> at weblogic.servlet.internal.FilterChainImpl.doFilter
> (FilterChainImpl.java:56)
> at oracle.adf.model.servlet.ADFBindingFilter.doFilter
> (ADFBindingFilter.java:189)
> at weblogic.servlet.internal.FilterChainImpl.doFilter
> (FilterChainImpl.java:56)
> at
> oracle.adfinternal.view.faces.webapp.rich.RegistrationFilter.doFilter
> (RegistrationFilter.java:85)
> at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl
> $FilterListChain.doFilter(TrinidadFilterImpl.java:289)
> at oracle.adfinternal.view.faces.activedata.AdsFilter.doFilter
> (AdsFilter.java:54)
>
> BTW just as I was writing this up, I came across this recent Steve
> Muench's blog post about customizing application error handlers for
> informational messages. It seems relevant to the point I'm raising. I
> haven't had a chance to dig into it yet. Let me do just that, and
> revisit this topic after that if I feel it appropriate.
>
> http://radio.weblogs.com/0118231/2009/03/20.html#a944
>
> Thx.,
> Chandu
>
> On Apr 3, 1:24 am, Sandra Muller <sandra.mul...@oracle.com> wrote:
>
>
>
> > Hi Chandu,
>
> > I came across Oracle Real User Experience Insight (Oracle RUEI) and
> > this is a different approach to runtime diagnosis: from the user point
> > of view. It sniffs the network communication packages before it gets
> > to the application server(s) and is able to trace a user session this
> > way. You can configure how to recognize an HTML response with an error
> > shown to the user, and get alerts when that happens. That allows you
> > to trace back the user session where the error occurred, and
> > understand what (s)he was doing. You can also zoom in on userid and
> > time.
>
> > I'm not sure if this helps with what you are looking for, but if you
> > want to know more, check outhttp://www.oracle.com/technology/products/oem/prod_focus/realuserexpe...
> > > Chandu- Hide quoted text -
>
> - Show quoted text -

Nathalie Roman

未讀,
2009年4月14日 下午3:47:592009/4/14
收件者:ADF Enterprise Methodology Group
Chandu,

What's also very interesting to have a look at is the AD4J agent and
console (http://www.oracle.com/technology/software/products/oem/htdocs/
jade.html).

After the AD4J agent has been deployed, it'll be automatically
discovered in the console.

Using Grid Control functionality and the management packs available
will also give you more insight into the different transactions
boundaries, e.g. http://www.oracle.com/technology/products/oem/pdf/ds_as_dp.pdf

Kind regards,
Nathalie
> > - Show quoted text -- Hide quoted text -
回覆所有人
回覆作者
轉寄
0 則新訊息