JDBC Connections
Aaron Greenlee
Darren Pywell
I don't think we generate an event that you can consume. I'll talk to
the devs and see what they say. Can you give me an idea of what you
are aiming to do? Are you just looking for logging or something that
you want to trigger based upon the event.
Cheers,
Darren
Marko Simic
Which driver/db do you use?
Best Regards,
--
You received this message because you are subscribed to the Google Groups "FusionReactor" group.
To post to this group, send email to fusion...@googlegroups.com.
To unsubscribe from this group, send email to fusionreacto...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fusionreactor?hl=en.
Pozdrav,
Marko Simić
-------------------------------------------------------------------------------
Garbage collector only runs on Chuck Norris code to collect the bodies
charlie arehart
Hey folks, I just found what seems a hidden gem in FR, but I don’t quite understand it and can’t find it documented. Hopefully one of the engineers or someone else can explain it and perhaps when it became available, as well as when it does and does not appear in a request. I'd never noticed it until today, and maybe this will help others too.
I was helping someone and noticed on the Details page for a request of their that at the very bottom, in the "thread" section, above the "thread name", that there was a "thread CPU time" with a count in ms. I’d never noticed that before, and I looked on my own server in a request and did not see it. At first I thought it was that it was added in the 4.0.9 update that I’d not yet applied.
But then suddenly I *did* see it in another request:
At first I thought maybe it was related to requests that had CFTHREAD processing, but now I’m doubting that. I searched my codebase for files related to the page that was running and don’t see any using CFTHREAD. So unless that’s it and I simply missed it somehow in my search, can anyone say what that “thread cpu time” IS about. Again, it’s not on all requests. And I can confirm I (and the customer) do NOT have enabled (in request settings) the new FR 4 “cpu threading” feature.
Any thoughts appreciated. Thanks.
/charlie
charlie arehart
In the spirit of my last “hidden gem”, here’s a “trap” to beware. It may not be a problem for all who apply FR 4 updates, but it’s happened a couple of times to me and may be an issue for some others.
As of FR4, if we apply any updates (such as if going from 4.0.x to the latest 4.0.9), the installer first updates the FRAM instance. It then SHOULD offer you the option to update any other FR instances on that box.
But I’ve had problems on more than a couple of machines where the FRAM instance page that the installer tried to load (to do that update of the other instances) failed. And it took a while to fail. And my fear is that some users may get antsy and close that page before waiting for it to end, thinking that “it’s just loading FR and I’m happy to move on if the installer is done”…in which case they will be left with only the FRAM instance updated, but not any of the others. That would be unfortunate.
So the error that I got (when the installer finished and tried to load the FRAM page) was this:
FusionReactor Redirection Failed
ERR_BADHASH: Bad hashed value - either the redirection location or the secure password is incorrect.
And the URL that it tried to load was this:
http://127.0.0.1:8087/fusionreactor/fredirect.cfm?role=administrator&location=http://127.0.0.1:8087/fusionreactor/finstance.cfm&initial=update&hash=xxx (where xxx is a 32-char alphanumeric string)
Now, I’ll note that I’ve mentioned this issue to the FR engineers before privately, and they said no one else had reported it. But since this happened to me on a couple of machines, and on previous updates for me, and now tonight on the 4.0.9 one, I just thought I’d mention it, because I can see perhaps someone not thinking it was significant, and not realizing that it left only the FRAM instance updated.
But here’s more good news, if you’re in doubt: just go to the FRAM instance (typically at port 8087, as in http://[server]:8087/fusionreactor/fhtml.cfm) and there you can see all your instances, and it shows clearly what FR version they’re at. There’s even an easy button to apply the update one or all instances (if FRAM has been updated but an instance has not been). (These guys are good!)
Just wanted to offer this info in case it may help someone else. And if you HAVE had this problem (and either noticed the error, or didn’t but found now that you did have only the FRAM instance updated), then please do speak up so that the engineers know how many others may be hit with this. :-) (No need to reply that you did not have the problem. That may be everyone else!) They’re always wonderful about fixing problems, especially when they know that they are happening to many others. Until then, I leave this for any it may help.
/charlie
Darren Pywell
FusionReactor 4 tracks the amount of time that a request has been on
the CPU on Java 1.5+ environments. In fact you don't have to go in the
request details to see it, it's made visible on the Request History
for example underneath the Time(ms) column. If you see two values in
the Time(ms) column on a request, the top value is the time that the
request was executing and the bottom value is the amount of that time
that the request was on the CPU. If you only see one value then the
time on the CPU was less than 1ms which is the smallest resolution
that we capture/display. This data is also sent to FusionAnalytics and
allows you to see which requests consume the most CPU (good for
identifying CPU bound pages and applications) - and you're right, this
needs updating in the documentation!
Thanks,
Darren
On Apr 13, 3:47 am, "charlie arehart" <charlie_li...@carehart.org>
wrote:
> understand it and can't find it documented. Hopefully one of the engineers
> or someone else can explain it and perhaps when it became available, as well
> as when it does and does not appear in a request. I'd never noticed it until
> today, and maybe this will help others too.
>
> I was helping someone and noticed on the Details page for a request of their
> that at the very bottom, in the "thread" section, above the "thread name",
> that there was a "thread CPU time" with a count in ms. I'd never noticed
> that before, and I looked on my own server in a request and did not see it.
> At first I thought it was that it was added in the 4.0.9 update that I'd not
> yet applied.
>
> But then suddenly I *did* see it in another request:
>
> processing, but now I'm doubting that. I searched my codebase for files
> related to the page that was running and don't see any using CFTHREAD. So
> unless that's it and I simply missed it somehow in my search, can anyone say
> what that "thread cpu time" IS about. Again, it's not on all requests. And I
> can confirm I (and the customer) do NOT have enabled (in request settings)
> the new FR 4 "cpu threading" feature.
>
> Any thoughts appreciated. Thanks.
>
> /charlie
>
> 5KViewDownload
charlie arehart
wasn't at all obvious in the bottom of the details page. At least there,
might you consider always listing the label and just say <=1ms? I understand
why you may not want to show 0, but having something would be less confusing
than there being nothing. :-) Thanks.
/charlie