http://coldfusion.com logo
Join Slack
Powered by
Hello - been trying to track down some JDBCRequest...
# box-products
a
Hello - been trying to track down some JDBCRequest requests seen in FusionReact which are hanging. If I remove the 
coldbox.system.logging.appenders.DBAppender
from my ColdBox 6.5 app then the queries do not appear. I'm pretty sure this is due to 
cfdbinfo
use in 
DBAppender
. Our setup is MariaDB with ACF2018.
This is what I see in FusionReactor:
Those queries are not in the code at all (out code or Coldbox) which is why I believe it's 
cfdbinfo
that's doing it.
The other odd thing is that the application name is "MyApplication" and yet that isn't a name we've assigned. I am running the 
DBAppender
as async so I don't know if that would cause that?
Appender config:
Copy code
rotatingDBAppender : {
	levelMin   : "FATAL",
	levelMax   : "DEBUG",
	class      : "coldbox.system.logging.appenders.DBAppender",
	properties : {
		async        : true,
		dsn          : settings.dsn,
		table        : "tbllogbox",
		autoCreate   : false,
		rotationDays : 7
	}
},
The 
DBAppender
uses 
cfdbinfo
to detect the DB engine and return the appropriate datatype.
What I'm thinking is could the 
database_productName
be passed in as a property so the dialect doesn't need to be detected.
w
@aliaspooryorik Are you using a recent version of logbox? I am asking because the handling of appenders in coldbox 6 have changed. The dbappenders are always async
a
ColdBox 6.5
now that you say that - I can see that the 
async
property is ignored. Must have got that from a doc / example somewhere.
w
Yes, I discussed this recently with Luis. We have to modify the docs. The async property might be needed for some appenders, but not for the dbappender anymore.
đź‘Ť 1
a
I've solved my production issue by extending and overridding the methods (which is a horrible hack but I wasn't going to change core Coldbox code!)
Copy code
component accessors="true" extends="coldbox.system.logging.appenders.DBAppender" {

	private function getDateTimeDBType(){
		return "cf_sql_timestamp";
	}

	private function getTextColumnType(){
		return "LONGTEXT";
	}

	private function getDateTimeColumnType(){
		return "DATETIME";
	}

}
That stops it calling cfdbinfo
w
It is quite easy to create your own appender, so you don’t have to hack box code, where you remove the detection stuff. I wrote some blogpost on creating my own dbappender where you can see which methods are important https://shiftinsert.nl/logbox-modify-your-message-format/
Well, it might be a hack, but it is your code and it is probably still there if you upgrade coldbox
Ok, I was looking where the cfdbinfo was called. I think it is mainly called on rotations where getDateTimeDBType is needed. I think it should be possible to create some properties, store the dbinfo in there and thus only call cfdbinfo on initialization instead of every rotation try.
Not sure why these request are hanging though.
a
They are accessing sys tables so are likely not allowed.
I think all it needs is a 
dialect
property and then the cfdbinfo stuff can be largely skipped (it also uses it to create the table if missing but that can be done with a migration)
w
ok, and you don’t need it at all. Because your tables are already there and your datetime and textcolumntype functions don’t need dynamic detection. So perfectly valid to override the db appender, remove the cfdbinfo stuff.
a
Yeah - my "solution" will work fine. Ideally I think that a 
dialect
property would be nice to add to the one in ColdBox so it'll detect if that not set, else it'll use the dialect to get the appropriate datatype. I don't mind doing a PR if it's something that would be useful for others rather than just me!
w
yes, that’s another way to solve it. Create a dialect property and some defaults . If you don’t specify it you could still use cfdbinfo but as long as you have your dialect specified cfdbinfo can totally be avoided.
Ok, not totally true. You still need it in ensureTable but that’s only once. And there are other simple ways to find out if a table is there. Maybe we can just submit a PR for this.
b
@aliaspooryorik If you open those transactions directly in FR, there should be a stack trace that shows you were in the code they were called.
I think for long DB calls, you can expand them right in the JDBC tab for the main request
w
@bdw429s Do you know if cfdbinfo will be cached? I know it can be slow on the first request, but I am not sure if is is still slow on the subsequent requests
b
I don't know anything about how the cfdbinfo calls work
I doubt they cache
But I've also never seen them take that long
Identifying the exact line of CFML code should allow John to at least create a stand alone repro case
w
I agree, he just has to know if this is really caused by cfdbinfo. But I guess it is. Not in all databases this info is available. It might be restricted, so if you ask for something not accessible it can slow you down. And actually you really don’t need it. There are other ways to get your info.
Open in Slack
PreviousNext
Powered by