http://coldfusion.com logo
Powered by
#box-products
Title
# box-products
a

aliaspooryorik

03/15/2022, 9:25 AM
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

wil-shiftinsert

03/15/2022, 12:43 PM
@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

aliaspooryorik

03/15/2022, 12:44 PM
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

wil-shiftinsert

03/15/2022, 12:46 PM
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

aliaspooryorik

03/15/2022, 12:47 PM
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

wil-shiftinsert

03/15/2022, 12:48 PM
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

aliaspooryorik

03/15/2022, 12:55 PM
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

wil-shiftinsert

03/15/2022, 12:57 PM
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

aliaspooryorik

03/15/2022, 12:58 PM
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

wil-shiftinsert

03/15/2022, 1:00 PM
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

bdw429s

03/15/2022, 7:26 PM
@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

wil-shiftinsert

03/15/2022, 7:32 PM
@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

bdw429s

03/15/2022, 7:34 PM
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

wil-shiftinsert

03/15/2022, 7:37 PM
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.
Powered by