FusionReactor Version: 3.0.1 - Longest JDBC request is empty.

[Ajas Mohammed]

Hi,

I am evaluating FusionReactor Version: 3.0.1 for ColdFusion 7 and I am able to see all kinds of activity which is super. However, the Longest JDBC requests page doesnt show anything. It says There are no JDBC requests in the list. This morning, I changed these settings mentioned below (also shown in attached snapshot ). Also, attached is a snapshot of template result which calls a stored procedure and took 37 seconds to process.

I changed these values for JDBC settings :

Under SQL Statement Recording (Request Detail Page)
1. Only queries slower than (ms): 5000

Under JDBC Logging (Log Files)
2. JDBC Logging:  Enabled
3. Only queries slower than (ms) : 5000

So, the idea was to record any query or any stored procedure that might take more than 5 seconds to execute.

Is there something which I am missing or doing wrong?

Thanks,

<Ajas Mohammed />
http://ajashadi.blogspot.com
We cannot become what we need to be, remaining what we are.
No matter what, find a way. Because thats what winners do.
You can't improve what you don't measure.
Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives.

[Darren Pywell]

Hi Ajas,

To get FusionReactor to monitor a JDBC connection you need to "wrap"
the JDBC connection with the FusionReactor JDBC Driver Wrapper.

We have a tool (ColdFusion page) that can perform this action for you
for most kinds of JDBC driver:

http://www.fusion-reactor.com/community/developers/autodev_detailed.cfm?article=FRS-234

We also have two documents that cover JDBC wrapping in detail:

http://www.fusion-reactor.com/fr/helpdocs/jdbc_tutorial.pdf
http://www.fusion-reactor.com/fr/helpdocs/jdbc_driver_wrapper_userguide.pdf


Hope that helps,
Darren

>  JDBC_Settings.jpg
> 65KViewDownload
>
>  Request_37_seconds.jpg
> 69KViewDownload

[Ajas Mohammed]

Thanks. I will look at it.

<Ajas Mohammed />
http://ajashadi.blogspot.com
We cannot become what we need to be, remaining what we are.
No matter what, find a way. Because thats what winners do.
You can't improve what you don't measure.
Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives.

[charlie arehart]

Hey Ajas, welcome to the list. As for your challenge, it’s just that you have missed a critical step—not entirely your fault, as I now see it’s not mentioned in the Installation Guide.

 

In order for FR to monitor a datasource, you need to modify it in the CF admin. While it’s not covered in the Installation Guide, you can find it discussed quite succinctly in the JDBC Wrapper Tutorial, and/or the JDBC Wrapper User Guide, both available at http://www.fusion-reactor.com/fr/support.cfm#doc. Better still, you can now automate the process using the tool, discussed and downloadable at http://www.fusion-reactor.com/community/developers/autodev_detailed.cfm?article=FRS-234. It’s not a fully supported tool, but many have used it to great satisfaction.

 

I hope the FR folks will consider modifying the Install Guide to point out this needed step and where to find the docs and the tool. I did a search in both the 3.0.1 and 3.5 Install Guides, for “jdbc” and found a reference only on the Trademarks and Warranties section at the top.

 

BTW, you say you’re looking at 3.0.1. If you downloaded that before last week, note that there is now 3.5 available. You can easily update that 3.0.1 edition, even while in the trial, or you can just wait and if you decide to buy, be sure to get 3.5 when you do. More on that at http://www.fusion-reactor.com/support/kb/FRS-230.cfm.

 

Again, welcome to FR, Ajas. I hope you’ll find this list a warm, welcoming, and informative place, just the Atlanta CFUG list (which is how I know Ajas from previous interactions.)

 

/charlie

[Ajas Mohammed]

Hi Charlie,

 

Thanks for the information. I will have a look and update about my progress.

 

You touched the point already but I will mention it again that FR folks need to add this JDBC wrapper information in help/installation manuals. I am surprised such a critical item is not mentioned in installation manual. Indeed, google search pointed me to links Darren and Charlie mentioned, but I doubted myself saying well manual didnt say anything, so why should I go for this. To the very least, the jdbc settings page should have an asterisk saying these settings will work *only with jdbc wrapper* or something on those lines.

 

Anyway, coming back to original topic. We would have to install FR on production systems and I dont know if my team will like the idea of fiddling with DSN's in production.

 

1. Can someone confirm that there are *NO ISSUES* whatsoever using jdbc wrapper in production systems?

 

2. Also, using the automated tool to *WRAP* & *UNWRAP* DSN is not going to break anything.

 

Thanks,

 

Ajas.

[charlie arehart]

Sorry to see my note arrived later than Darren, who had basically answered the question.

 

But to your points, Ajas, I would agree as well that the JDBC settings page (and online help) could help point one to the need to have wrapped a datasource in order to expect the features to report output.

 

That said, I will note that we ought not get too “surprised that such a critical item is not mentioned in the installation manual”. A reasonable argument could be made that it wasn’t mentioned because it’s not really part of the installation process. Technically, it’s really not. Now, we could assert that for a newcomer, looking only at that manual, it may help them to be notified. And you make an even more interesting point: that you found the other docs but since the installation manual didn’t point to it, you weren’t sure whether to trust that they applied.

 

What this points out is that the Installation Guide isn’t really a “guide to getting started with FusionReactor”. There’s no such specific doc, and that could be helpful. Perhaps the community could help develop it. There are ample resources on the FR web site, as well as the help files, where Intergral could argue they’ve provided lots of info. But yes, in some situations this additional level of info could help. I just am trying to temper things since you’re new to the list and to FR. It has a very loyal and satisfied following of customers, and the fact that others haven’t pressed for this would suggest that not everyone has really felt the need for such a document (or better discussion in the Installation Guide). I pointed out because it did seem reasonable to take this opp to see it as a modest improvement that could be made. Creating more than that would be an interesting community exercise. I’d enjoy working on it myself.

 

As for your point about “coming back to original topic. We would have to install FR on production systems and I dont know if my team will like the idea of fiddling with DSN's in production.” Well, just to be clear, you were describing having installed FR onto some CF server, and you saw running requests. What server was that? Not production? In that case, since you’re saying that server does have DSNs and requests that did queries that you couldn’t see, why not just wrap them? It gives you a chance to at least see how the process of setting things up for DSN monitoring would work.

 

To that end, I would NOT recommend “just doing it on production” as your first attempt, if you can avoid it. That’s true of anything, of course, not a FR-specific warning.

 

As for your last 2 questions, on the first, there are no guarantees. That said, the wrapper is very lightweight. It just watches queries as they leave CF and go to the real datasource (by way of the wrapper), and it tracks when the query starts, then passes the query on, then when it returns it tracks when it stops and how many records were returned. That’s it. Very lightweight. It logs the info (if you have logging enabled) and it puts it in memory (for the recent or long-running requests that FR keeps in memory).

 

Now, there’s a feature in the FR JDBC Settings page called “query location” that can be enabled/disabled. If enabled, it causes FR to track (in the logs and the info shown on screen) the exact line of code where the query takes place. Doing that requires obtaining a stack trace of the request. In a very high load environment that could cause a burden. Many sites (including my own) leave it on in production with no ill effect. As with so many things in IT, there are no absolute answers. If you were worried, then disable that feature and see how things go, and if you want/need to know the line numbers for queries, then enable it in some planned way, perhaps overnight, to assess the impact.

 

I’ll add that this potential pain in doing the query location tracking is not something widely known or discussed (I found it one day working with someone and meant to write here, but never got around to it), but the fact that it’s not come up before is a testament to it not being so severe an issue that it’s a hot topic. Certainly if anyone ever said, “I’ve turned on wrapping and it’s causing problems”, then I or the FR folks would have stepped in to point this out. The fact that it’s not happened should give you some consolation.

 

One other gotcha to be careful about is that there was a time when if you enabled the wrapper, during the FR trial period, when the trial ended, you might get errors on the DSNs (that remain wrapped). I do think that’s been fixed, and in such a situation the wrappers would just pass the request through without incident. Perhaps the FR folks may speak to this.

 

As for whether the automated tool is “not going to break anything”, that has even less of a guarantee. It’s not a supported tool, so you do use it at your own risk, and again it would be wise not only to try it in test first, but further to try only one DSN at a time if one is cautious. Further, there is an option to overwrite the current DSN or take a backup. Naturally the latter is the more prudent step when first using the tool. Still, again, many have used it and love it.

 

So just keep these common sense IT perspectives in mind as you would normally and I think you should find FR to be a tremendous tool that does far more in the long run to help you with problems. Like any powerful tool, its use entail responsibility and as you get started, it’s wise to be cautious and careful. Again, the list here is a tremendous source of help.

 

 

…and most people provide answers in just a sentence or two. Sadly, I have an affliction (ok, an addictive need to share info carefully) that precludes that! :-)

[Darren Pywell]

Wow, Charlie thanks for all that!

We are listening. I've entered tickets for the documentation updates
and hints for the JDBC screens. Currently we don't register the JDBC
wrapped data sources with FR because for different engines there are
many ways in which you can wrap a JDBC driver, but we do have tickets
to look at making the JDBC wrapping easier.

After the trail period the FR JDBC wrapper just passes database
requests though; you should experience no problems with that unless
you uninstall FusionReactor and don't switch back to using the
unwrapped JDBC data sources.

The JDBC wrapper is used in production on many thousands of servers
and has been in use with most of our customers for years. When we
recently updated our demo site to FR 3.5 it had been running non-stop
for 9 months and had complete over 600 million JDBC requests without
any errors being logged. We test it very carefully but like any
software there is no way to rule out completely that it's not
perfect.

The JDBC Wrapper tool was actually started by us but is receiving
inputs and contributions from the community. Due to the complexity of
the different types of JDBC driver and wrapping them, we saw this as a
good way to go. The tool does get updated and has just recently moved
to version 0.8 adding CF9 and Railo 3.1.1.

We're really glad to see community involement and I'd like to say a
really BIG thank you to Charlie who contributes more than anyone can
imagine!!!


Darren


On Oct 13, 2:41 am, "charlie arehart" <charlie_li...@carehart.org>
wrote:

> .and most people provide answers in just a sentence or two. Sadly, I have an

[charlie arehart]

Thanks for all that, Darren.

Darren does make a point that's worth clarifying, especially for someone new
to FR like Ajas, when he says "Currently we don't register the JDBC wrapped

data sources with FR because for different engines there are many ways in

which you can wrap a JDBC driver".

While most view FR as a "CF monitor", it is in fact a J2EE/Java EE server
monitor. It works identically with monitoring servlets/JSPs on Tomcat,
JBoss, WebSphere, etc as it does monitoring CF requests. That said, by far
the most common users of FR are CF users. So that's just something to keep
in mind while viewing/using the tool, if one ever wonders why there aren't
more CF-specific features or even references in the help/docs/. Once one
hear this, they may start to notice it more. It's not a bad thing. It just
explains some little things one may see sometimes. :-)

Finally, as for my contributions, thanks for the kind regards, Darren.
They're driven as much by the fact that you guys have always been so
receptive to feedback and suggestions. It's been great working with you all
as an FR customer and partner for 3 years. And again this is such a great
list for helping each other out. Very glad to be here, helping and learning
from others.

/charlie

> -----Original Message-----
> From: fusion...@googlegroups.com
> [mailto:fusion...@googlegroups.com] On Behalf Of Darren Pywell
> Sent: Tuesday, October 13, 2009 5:56 AM
> To: FusionReactor
> Subject: FusionReactor Group: Re: FusionReactor Version: 3.0.1 -
> Longest JDBC request is empty.
>
>

[Ajas Mohammed]

Hi,

First of all, big thanks to Charlie and Darren for the follow up and detailed instructions. Charlie, your input and service to the community is amazing. Thanks a lot for all your help. As always, I look for your feedback, pretty much in *ANY* group. :-) .

Let me give details about my setup since you asked some questions. I installed the FR in our development/testing environment. I do not have any problems using jdbc wrapper in this test environment. I used it today on the test environment and I could see JDBC query info. Also, using the automated tool, I was able to *WRAP* and *UNWRAP*  DSN very easily... Eventually, we plan to setup FR on production system, thats why I asked the question in advance about setting up jdbc wrapper in production. You gave a thorough explanation and it cleared my doubts, i.e. if I was going in right direction or not.

As for the community help, I will create a document outlining Getting Started with FusionReactor. I do not mind at all if anyone uses it or even FR folks use it for Community DevNet Section where they have guides and tips/hints for FR or anywhere for that matter.

Finally, before I end and before I forget, I think FR is a very handy tool and I am very impressed with it. My input about the documentation or on jdbc settings page was *really* a suggestion and I didnt mean to take anything away from FR. If it appeared that way, I apologize for that.

Thanks, Let me know if I missed anything from your big email. ;-)

Ajas.

[charlie arehart]

Thanks for the update, Ajas (and the kind regards).

 

As for your plan to create a getting started guide, if you don’t have a place/preference in mind, I’d recommend doing it on the google group here, using the “pages” feature (http://groups.google.com/group/fusionreactor/web). In fact, to save you the trouble of figuring that out, I just went ahead and created a page there as a placeholder, with some shell content. If you like it (and it doesn’t conflict with anything you’d planned), feel free to start contributing, and confirm this is ok so that others can join in if they’d like.

 

http://groups.google.com/group/fusionreactor/web/getting-started-with-fusionreactor---community-driven-guide

 

As for whether your earlier feedback may have construed as anything other than helpful, I don’t think so. But I just thought I’d respond as I did either in case you had concerns, or also to address if any others may have interpreted things that way. We’re all good. :-) Looking forward to what we’ve started here.

 

/charlie

 

From: fusion...@googlegroups.com [mailto:fusion...@googlegroups.com] On Behalf Of Ajas Mohammed
Sent: Tuesday, October 13, 2009 12:50 PM
To: fusion...@googlegroups.com
Subject: FusionReactor Group: Re: FusionReactor Version: 3.0.1 - Longest JDBC request is empty.

 

Hi,

[Darren Pywell]

Hi Ajas,

Many thanks for the update. It's really great when people share their
findings... it helps everyone so much.

Ajas, we would be more than happy to publish your Getting Started
guide to the DevNet! I think this would be a great resource for FR
users. Many many thanks for that too!

If you need any help or information please let me know.

Looking Fowards,
Darren

> On Tue, Oct 13, 2009 at 9:03 AM, charlie arehart <charlie_li...@carehart.org

[charlie arehart]

And now that I reread Ajas' note, if you meant to just do such a guide on
your own Ajas, please do feel free. I misinterpreted things and assumed it
might be a community project, but Darren's words caused me to reread. If
you're prepared to go it alone, I have no problem either deleting the one I
started, or if you like that as a place to put it during the draft process,
we could remove my name from it. Definitely wasn't trying to take an
unwanted step of involvement. Just was trying to help get it started. :-)
But I could see how it may come across as otherwise. No offense intended.
Just let us know how you want to proceed.

/charlie

> -----Original Message-----
> From: fusion...@googlegroups.com
> [mailto:fusion...@googlegroups.com] On Behalf Of Darren Pywell
> Sent: Tuesday, October 13, 2009 3:42 PM
> To: FusionReactor
> Subject: FusionReactor Group: Re: FusionReactor Version: 3.0.1 -
> Longest JDBC request is empty.
>
>

[Ajas Mohammed]

Hi there,

After couple of weeks of gathering information and snapshots, I am please to say that I have come up with Version 1.0 of the Getting Started Guide.

Please feel free to make changes as you like.

If you have any suggestions or additions or Edits to make, then let me know. I will be more than happy to include them. Any kind of feedback is welcome. :-)

Thanks,

<Ajas Mohammed />
http://ajashadi.blogspot.com
We cannot become what we need to be, remaining what we are.
No matter what, find a way. Because thats what winners do.
You can't improve what you don't measure.
Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives.

[Darren Pywell]

Hi Ajas,

Wow! This looks great. I'll get the wheels in motion to get this onto
the DevNet and see about have it placed into other locations on the
site. Do you have a photo of you that we can use for the DevNet
article?

Many thanks!
Darren

On Oct 28, 5:31 pm, Ajas Mohammed <ajash...@gmail.com> wrote:
> Hi there,
>
> After couple of weeks of gathering information and snapshots, I am please to
> say that I have come up with Version 1.0 of the Getting Started Guide.
>
> Please feel free to make changes as you like.
>
> If you have any suggestions or additions or Edits to make, then let me know.
> I will be more than happy to include them. Any kind of feedback is welcome.
> :-)
>
> Thanks,
>
> <Ajas Mohammed />http://ajashadi.blogspot.com
> We cannot become what we need to be, remaining what we are.
> No matter what, find a way. Because thats what winners do.
> You can't improve what you don't measure.
> Quality is never an accident; it is always the result of high intention,
> sincere effort, intelligent direction and skillful execution; it represents
> the wise choice of many alternatives.
>

> On Tue, Oct 13, 2009 at 5:06 PM, charlie arehart <charlie_li...@carehart.org

>  Getting_Started_With_FusionReactor.pdf
> 1438KViewDownload- Hide quoted text -
>
> - Show quoted text -

[Ajas Mohammed]

Hi Darren,

Thanks for the feedback. I am glad you liked it. :-)

I will send you my picture in another email @ dapywell at googlemail dot com. I dont want to spam the group email. ;-)

Thanks,

<Ajas Mohammed />
http://ajashadi.blogspot.com
We cannot become what we need to be, remaining what we are.
No matter what, find a way. Because thats what winners do.
You can't improve what you don't measure.
Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives.