CBWire 20+ Second Random Loading Delays

To preface, I am not having this issue on my dev machine at all. In my staging server I am having random 20+ second loading times when I have any call to CBWire functions wireStyles(), wireScripts(), or wire(). The strange thing is that it does not happen with every page load, usually about every 3-4 page loads have the delay. Once a wire is loaded on the page the wire functions as expected and has no issues with refreshing of the wire on changes, events, etc.

1. I narrowed it down to CBWire by using cbDebugger. I wrapped the wireStyles(), wireScripts(), and wire() with timers. In a request that takes 20+ seconds to load and it is always one of these functions causing the delays.
2. If remove wireStyles(), wireScripts(), and wire() from pages they load as expected with no delays.
3. If I have wire() on the page but not wireStyles() or wireScripts() in the template it renders the initial view but as expected it is not “interactive” without the scripts loaded and still has the random delays.
4. I have tried multiple java versions as well and have the same results.
5. I am get the exact same results using both going through IIS with the AJP connector or hitting the CommandBox embedded server directly

Dev Setup:
ColdBox: 7.1.0-snapshot
CBWire: 3.0.0
CommandBox: 5.9.0+00721
Server: Lucee 5.4.1.8
Java: 11.0.18 (Oracle Corporation) 64bit
OS: Mac OS X (13.3.1) 64bit

Staging Setup:
ColdBox: 7.1.0-snapshot
CBWire: 3.0.0
CommandBox: 5.9.0+00721
Server: Lucee 5.4.1.8
Java: 11.0.18 (Oracle Corporation) 64bit
OS: Windows Server 2022 (10.0) 64bit

Anyone have any insights or next steps to figure out what’s going on? TIA

I narrowed down my issue. It seems to be an issue with using qb and/or quick entities inside a wire while having qb debugging turned on. I tested with both cbWire versions 3.0.0 and 2.3.9-snapshot as well as Lucee 6 and got the same results.

There are some strange behaviors:

cbDebugger > qb > enabled=false:

wire with multiple quick entities : No Delays
wire with quick entities loading relationship : 20-25 second loading delays every ~10 seconds
wire with qb queries : No Delays
wire without qb queries or quick entities : No Delays

cbDebugger > qb > enabled=true;

wire with multiple quick entities : 20-25 second loading delays every ~10 seconds
wire with quick entities loading relationship : 20-25 second loading delays every ~10 seconds
wire with qb queries : 20-25 second loading delays every ~10 seconds
wire without qb queries or quick entities : No Delays

  1. I don’t ever get any errors displayed on the page when there is a loading delay

  2. When I get the delays in loading I have about a ~10 second window where if I refresh the page I don’t get the delay then after that ~10 second window I get the loading delay.

  3. Even when the page loads with the delays the cbwire does not have any delays using the livewire functionality. The refreshes of the wire load very fast as expected. The delay seems to happen only on the initial rendering of the wire.

  4. Using the dbDebugger Timer I put a timer at the very top and bottom of my cfoutput in my wire. The timer does not show the delay even though the calls to qb and quick are between the timer start and stop.

  5. I often get this error after I have the delay in cbDebugger when I refresh the cbdebugger page:

{
	"data":{
		"environment":{
			"currentRoutedUrl":"cbdebugger/",
			"timestamp":"2023-07-21T18:09:07-07:00",
			"currentRoute":"/",
			"currentEvent":"cbdebugger:Main.index"
		},
		"exception":{
			"stack":[
				"D:\HOME\staging\wt-om\wwwroot\modules\cbdebugger\views\main\partials\profilers.cfm:295",
				"D:\HOME\staging\wt-om\wwwroot\coldbox\system\web\RendererEncapsulator.cfm:57",
				"D:\HOME\staging\wt-om\wwwroot\coldbox\system\web\Renderer.cfc:452",
				"D:\HOME\staging\wt-om\wwwroot\coldbox\system\web\Renderer.cfc:337",
				"D:\HOME\staging\wt-om\wwwroot\modules\cbdebugger\views\main\panels\requestTrackerPanel.cfm:224",
				"D:\HOME\staging\wt-om\wwwroot\modules\cbdebugger\views\main\debugger.cfm:23",
				"D:\HOME\staging\wt-om\wwwroot\coldbox\system\web\RendererEncapsulator.cfm:57",
				"D:\HOME\staging\wt-om\wwwroot\coldbox\system\web\Renderer.cfc:452",
				"D:\HOME\staging\wt-om\wwwroot\coldbox\system\web\Renderer.cfc:337",
				"D:\HOME\staging\wt-om\wwwroot\modules\cbdebugger\layouts\Monitor.cfm:32",
				"D:\HOME\staging\wt-om\wwwroot\coldbox\system\web\RendererEncapsulator.cfm:57",
				"D:\HOME\staging\wt-om\wwwroot\coldbox\system\web\Renderer.cfc:452",
				"D:\HOME\staging\wt-om\wwwroot\coldbox\system\web\Renderer.cfc:668",
				"D:\HOME\staging\wt-om\wwwroot\coldbox\system\web\Renderer.cfc:582",
				"D:\HOME\staging\wt-om\wwwroot\coldbox\system\FrameworkSupertype.cfc:243",
				"D:\HOME\staging\wt-om\wwwroot\modules\cbdebugger\handlers\Main.cfc:91",
				"D:\HOME\staging\wt-om\wwwroot\modules\cbdebugger\handlers\Main.cfc:46",
				"D:\HOME\staging\wt-om\wwwroot\coldbox\system\RestHandler.cfc:58",
				"D:\HOME\staging\wt-om\wwwroot\coldbox\system\web\Controller.cfc:998",
				"D:\HOME\staging\wt-om\wwwroot\coldbox\system\web\Controller.cfc:713",
				"D:\HOME\staging\wt-om\wwwroot\coldbox\system\Bootstrap.cfc:290",
				"D:\HOME\staging\wt-om\wwwroot\coldbox\system\Bootstrap.cfc:506",
				"D:\HOME\staging\wt-om\wwwroot\Application.cfc:79"
			],
			"detail":"",
			"type":"java.lang.ArithmeticException",
			"extendedInfo":""
		}
	},
	"error":true,
	"pagination":{
		"totalPages":1,
		"maxRows":0,
		"offset":0,
		"page":1,
		"totalRecords":0
	},
	"messages":[
		"An exception ocurred: Division by zero is not possible"
	]
}

and this in the CommandBox Log:

[ERROR] runwar.context: 2023-07-21 09:15:34 modules.cbdebugger.handlers.Main Error calling cbdebugger:Main.index: Division by zero is not possible | ExtraInfo: {
	"_stacktrace":"lucee.runtime.exp.NativeException: Division by zero is not possible\r\n\tat lucee.runtime.op.Operator.divRef(
	Operator.java:1024)
	\r\n\tat modules.cbdebugger.views.main.partials.profilers_cfm$cf.call(
	/modules/cbdebugger/views/main/partials/profilers.cfm:295)
	\r\n\tat lucee.runtime.PageContextImpl._doInclude(
	PageContextImpl.java:1056)
	\r\n\tat lucee.runtime.PageContextImpl._doInclude(
	PageContextImpl.java:948)
	\r\n\tat lucee.runtime.PageContextImpl.doInclude(
	PageContextImpl.java:929)
	\r\n\tat coldbox.system.web.rendererencapsulator_cfm$cf.call(
	/coldbox/system/web/RendererEncapsulator.cfm:57)
	\r\n\tat lucee.runtime.PageContextImpl._doInclude(
	PageContextImpl.java:1056)
	\r\n\tat lucee.runtime.PageContextImpl._doInclude(
	PageContextImpl.java:948)
	\r\n\tat lucee.runtime.PageContextImpl.doInclude(
	PageContextImpl.java:940)
	\r\n\tat lucee.runtime.tag.CFTag.doInclude(
	CFTag.java:319)
	\r\n\tat lucee.runtime.tag.CFTag.cfmlStartTag(
	CFTag.java:245)
	\r\n\tat lucee.runtime.tag.CFTag.doStartTag(
	CFTag.java:179)
	\r\n\tat coldbox.system.web.renderer_cfc$cf.udfCall2(
	/coldbox/system/web/Renderer.cfc:452)
	\r\n\tat coldbox.system.web.renderer_cfc$cf.udfCall(
	/coldbox/system/web/Renderer.cfc)
	\r\n\tat lucee.runtime.type.UDFImpl.implementation(
	UDFImpl.java:112)
	\r\n\tat lucee.runtime.type.UDFImpl._call(
	UDFImpl.java:350)
	\r\n\tat lucee.runtime.type.UDFImpl.call(
	UDFImpl.java:223)
	\r\n\tat lucee.runtime.type.scope.UndefinedImpl.call(
	UndefinedImpl.java:786)
	\r\n\tat lucee.runtime.util.VariableUtilImpl.callFunctionWithoutNamedValues(
	VariableUtilImpl.java:787)
	\r\n\tat lucee.runtime.PageContextImpl.getFunction(
	PageContextImpl.java:1775)
	\r\n\tat coldbox.system.web.renderer_cfc$cf.udfCall1(
	/coldbox/system/web/Renderer.cfc:337)
	\r\n\tat coldbox.system.web.renderer_cfc$cf.udfCall(
	/coldbox/system/web/Renderer.cfc)
	\r\n\tat lucee.runtime.type.UDFImpl.implementation(
	UDFImpl.java:112)
	\r\n\tat lucee.runtime.type.UDFImpl._call(
	UDFImpl.java:350)
	\r\n\tat lucee.runtime.type.UDFImpl.callWithNamedValues(
	UDFImpl.java:213)
	\r\n\tat lucee.runtime.type.scope.UndefinedImpl.callWithNamedValues(
	UndefinedImpl.java:804)
	\r\n\tat lucee.runtime.util.VariableUtilImpl.callFunctionWithNamedValues(
	VariableUtilImpl.java:866)
	\r\n\tat lucee.runtime.PageContextImpl.getFunctionWithNamedValues(
	PageContextImpl.java:1794)
	\r\n\tat modules.cbdebugger.views.main.panels.requesttrackerpanel_cfm$cf.call(
	/modules/cbdebugger/views/main/panels/requestTrackerPanel.cfm:224)
	\r\n\tat lucee.runtime.PageContextImpl._doInclude(
	PageContextImpl.java:1056)
	\r\n\tat lucee.runtime.PageContextImpl._doInclude(
	PageContextImpl.java:948)
	\r\n\tat lucee.runtime.PageContextImpl.doInclude(
	PageContextImpl.java:929)
	\r\n\tat modules.cbdebugger.views.main.debugger_cfm$cf.call(
	/modules/cbdebugger/views/main/debugger.cfm:23)
	\r\n\tat lucee.runtime.PageContextImpl._doInclude(
	PageContextImpl.java:1056)
	\r\n\tat lucee.runtime.PageContextImpl._doInclude(
	PageContextImpl.java:948)
	\r\n\tat lucee.runtime.PageContextImpl.doInclude(
	PageContextImpl.java:929)
	\r\n\tat coldbox.system.web.rendererencapsulator_cfm$cf.call(
	/coldbox/system/web/RendererEncapsulator.cfm:57)
	\r\n\tat lucee.runtime.PageContextImpl._doInclude(
	PageContextImpl.java:1056)
	\r\n\tat lucee.runtime.PageContextImpl._doInclude(
	PageContextImpl.java:948)
	\r\n\tat lucee.runtime.PageContextImpl.doInclude(
	PageContextImpl.java:940)
	\r\n\tat lucee.runtime.tag.CFTag.doInclude(
	CFTag.java:319)
	\r\n\tat lucee.runtime.tag.CFTag.cfmlStartTag(
	CFTag.java:245)
	\r\n\tat lucee.runtime.tag.CFTag.doStartTag(
	CFTag.java:179)
	\r\n\tat coldbox.system.web.renderer_cfc$cf.udfCall2(
	/coldbox/system/web/Renderer.cfc:452)
	\r\n\tat coldbox.system.web.renderer_cfc$cf.udfCall(
	/coldbox/system/web/Renderer.cfc)
	\r\n\tat lucee.runtime.type.UDFImpl.implementation(
	UDFImpl.java:112)
	\r\n\tat lucee.runtime.type.UDFImpl._call(
	UDFImpl.java:350)
	\r\n\tat lucee.runtime.type.UDFImpl.call(
	UDFImpl.java:223)
	\r\n\tat lucee.runtime.type.scope.UndefinedImpl.call(
	UndefinedImpl.java:786)
	\r\n\tat lucee.runtime.util.VariableUtilImpl.callFunctionWithoutNamedValues(
	VariableUtilImpl.java:787)
	\r\n\tat lucee.runtime.PageContextImpl.getFunction(
	PageContextImpl.java:1775)
	\r\n\tat coldbox.system.web.renderer_cfc$cf.udfCall1(
	/coldbox/system/web/Renderer.cfc:337)
	\r\n\tat coldbox.system.web.renderer_cfc$cf.udfCall(
	/coldbox/system/web/Renderer.cfc)
	\r\n\tat lucee.runtime.type.UDFImpl.implementation(
	UDFImpl.java:112)
	\r\n\tat lucee.runtime.type.UDFImpl._call(
	UDFImpl.java:350)
	\r\n\tat lucee.runtime.type.UDFImpl.call(
	UDFImpl.java:223)
	\r\n\tat lucee.runtime.type.scope.UndefinedImpl.call(
	UndefinedImpl.java:786)
	\r\n\tat lucee.runtime.util.VariableUtilImpl.callFunctionWithoutNamedValues(
	VariableUtilImpl.java:787)
	\r\n\tat lucee.runtime.PageContextImpl.getFunction(
	PageContextImpl.java:1775)
	\r\n\tat modules.cbdebugger.layouts.monitor_cfm$cf.call(
	/modules/cbdebugger/layouts/Monitor.cfm:32)
	\r\n\tat lucee.runtime.PageContextImpl._doInclude(
	PageContextImpl.java:1056)
	\r\n\tat lucee.runtime.PageContextImpl._doInclude(
	PageContextImpl.java:948)
	\r\n\tat lucee.runtime.PageContextImpl.doInclude(
	PageContextImpl.java:929)
	\r\n\tat coldbox.system.web.rendererencapsulator_cfm$cf.call(
	/coldbox/system/web/RendererEncapsulator.cfm:57)
	\r\n\tat lucee.runtime.PageContextImpl._doInclude(
	PageContextImpl.java:1056)
	\r\n\tat lucee.runtime.PageContextImpl._doInclude(
	PageContextImpl.java:948)
	\r\n\tat lucee.runtime.PageContextImpl.doInclude(
	PageContextImpl.java:940)
	\r\n\tat lucee.runtime.tag.CFTag.doInclude(
	CFTag.java:319)
	\r\n\tat lucee.runtime.tag.CFTag.cfmlStartTag(
	CFTag.java:245)
	\r\n\tat lucee.runtime.tag.CFTag.doStartTag(
	CFTag.java:179)
	\r\n\tat coldbox.system.web.renderer_cfc$cf.udfCall2(
	/coldbox/system/web/Renderer.cfc:452)
	\r\n\tat coldbox.system.web.renderer_cfc$cf.udfCall(
	/coldbox/system/web/Renderer.cfc)
	\r\n\tat lucee.runtime.type.UDFImpl.implementation(
	UDFImpl.java:112)
	\r\n\tat lucee.runtime.type.UDFImpl._call(
	UDFImpl.java:350)
	\r\n\tat lucee.runtime.type.UDFImpl.callWithNamedValues(
	UDFImpl.java:213)
	\r\n\tat lucee.runtime.type.scope.UndefinedImpl.callWithNamedValues(
	UndefinedImpl.java:804)
	\r\n\tat lucee.runtime.util.VariableUtilImpl.callFunctionWithNamedValues(
	VariableUtilImpl.java:866)
	\r\n\tat lucee.runtime.PageContextImpl.getFunctionWithNamedValues(
	PageContextImpl.java:1794)
	\r\n\tat coldbox.system.web.renderer_cfc$cf.udfCall2(
	/coldbox/system/web/Renderer.cfc:668)
	\r\n\tat coldbox.system.web.renderer_cfc$cf.udfCall(
	/coldbox/system/web/Renderer.cfc)
	\r\n\tat lucee.runtime.type.UDFImpl.implementation(
	UDFImpl.java:112)
	\r\n\tat lucee.runtime.type.UDFImpl._call(
	UDFImpl.java:350)
	\r\n\tat lucee.runtime.type.UDFImpl.callWithNamedValues(
	UDFImpl.java:213)
	\r\n\tat lucee.runtime.ComponentImpl._call(
	ComponentImpl.java:699)
	\r\n\tat lucee.runtime.ComponentImpl._call(
	ComponentImpl.java:586)
	\r\n\tat lucee.runtime.ComponentImpl.callWithNamedValues(
	ComponentImpl.java:1952)
	\r\n\tat lucee.runtime.util.VariableUtilImpl.callFunctionWithNamedValues(
	VariableUtilImpl.java:866)
	\r\n\tat lucee.runtime.PageContextImpl.getFunctionWithNamedValues(
	PageContextImpl.java:1794)
	\r\n\tat coldbox.system.web.renderer_cfc$cf.udfCall2(
	/coldbox/system/web/Renderer.cfc:582)
	\r\n\tat coldbox.system.web.renderer_cfc$cf.udfCall(
	/coldbox/system/web/Renderer.cfc)
	\r\n\tat lucee.runtime.type.UDFImpl.implementation(
	UDFImpl.java:112)
	\r\n\tat lucee.runtime.type.UDFImpl._call(
	UDFImpl.java:350)
	\r\n\tat lucee.runtime.type.UDFImpl.callWithNamedValues(
	UDFImpl.java:213)
	\r\n\tat lucee.runtime.ComponentImpl._call(
	ComponentImpl.java:699)
	\r\n\tat lucee.runtime.ComponentImpl._call(
	Compon

The issue seems to be related to qb and having cbdebugger qb debugging enabled, however I still get it when it is disabled and retrieve a quick entities relationship.

I am using the same version of CommandBox, Lucee and Java on my dev machine. The only difference is dev is on a Mac and staging is Windows.

Anyone have any insights, suggestions, or pointers?

I’m no CBWire expert, but I do have a few thoughts and questions…

You state this, but your " cbDebugger > qb > enabled=false:" section shows you still experience the issue when loading a relationship, yes? So is this, or is this not exclusive to QB debugging?

This is good to know, but it doesn’t measure component construction/injection time. Hard to say what else could be going on there. You could try putting this timer start in your onRequestStart() in Application.cfc , and put the end in onRequestEnd(). That would get a better feel of the entire request.

A random list of things to check:

  1. Does the issue persist if you uninstall cbDebugger?
  2. If you set a very low connection timeout on your datasource, does the delay decrease?

Finally, it’s worth noting that Fusion Reactor makes any performance issue MUCH easier to debug. You’re kinda looking blind here because you’re not using it.

I was heading in the same direction. I got Fusion Reactor installed and in all my stack traces of requests with the delay it always boiled down to an issue with java.io.WinNTFileSystem.getBooleanAttributes() taking about ~20 seconds.

I can post a full stack trace if you would be interested, however searching “java.io.WinNTFileSystem.getBooleanAttributes() performance” results a great deal of results, many having similar issues with threads hanging.

It’s real head scratcher. My DB times are extremely fast, no delays at all and it only manifests when loading a relationship in quick (which uses qb) on the initial load of a wire. Subsequent requests to the wire “over the wire” run extremely fast with no issues. I am also able to use quick and load MANY relationships in normal page requests with no issue.

For the time being I have re-written my wires to work around this. Thank you for your help, I would be happy to try any other suggestions you might have.

Hi @MikeR , apologies I’m just now seeing this. Would you mind sharing your Wire component code with me so I can look into this and try to replicate it on my end?

Ah, an IO issue? That changes things dramatically.

I would look into:

  1. Your antivirus program. I’ve seen severe performance issues during module installations, as the antivirus program will scan each new file. You’ll want to make sure you’re excluding your entire development directory.
  2. Locking - is there concurrent access to this file? I don’t see any locking calls, but Lucee does a good bit of locking on file IO for obvious reasons, and there could be a bit of locking failure and/or lock retry going on.
  3. Malformed file - Try copying your wire code to a different file and delete the original file. Just thinking out loud here, there could be some unexpected file properties or permissions, perhaps something is malformed.
  4. Symlinks - is this file inside a symlink?
  5. Docker container - is this in a docker container? Any special flags on the volume mount?
  6. File location - is the file on a separate drive? A custom mount? A network file? Located at root? In any directory separate from your CF application code, running locally on your local Windows machine?

I would venture to say this is not a cbwire issue at all. It may not even be a CF-specific issue, but instead looks to me like a basic file I/O issue… though I am curious if the callStackGet() call in your BaseEntity model is CFML code, or just part of the Lucee-generated java code.

Sure, not a problem, thanks for helping. I have tried both the newer style (single file) and older style (separate. cfc and .cfm file) with the same results. I currently have it in the two-file style.

/wires/tabShipping.cfc

component extends="cbwire.models.Component" {

    data = { 
        "order_id" : 0,
        "shipLink" : "" 
    };

    computed = {
        "getShippingScreenURL": function() {
            return data.shipLink & data.order_id;
        }
    };

    function onMount( event, rc, prc, parameters ) {
        data.order_id = parameters.order_id;
        data.shipLink = event.buildLink("orders.prepareShipping.order.");
    }

}

/wires/tabShipping.cfm

Note: At one point I had the wirebox calls to load the entities wrapped in computed functions however it did not seem to make any difference. You can also see inside the cfscript if( !isNull( oShipment ) ) I tried using the relationship method, direct wirebox and just setting an empty array. The relationship getter always results in the delay with the java.io.WinNTFileSystem.getBooleanAttributes() taking ~20 seconds

<cfoutput>
    <div class="row">
        <cfscript>
            cbRenderer = application.wirebox.getInstance("provider:coldbox:renderer");
            oShipment = application.wirebox.getInstance( "shippingShipments" ).where( "order_id", order_id ).first();
            if( !isNull( oShipment ) ){
                // Get Relationship = DELAY
                // oPackages = oShipment.getPackages();

                // use wirebox directly = NO DELAY!
                oPackages = application.wirebox.getInstance( "shippingPackages" )
                    .where( "order_id", order_id )
                    .andWhere( "shipment_id", oShipment.getID() )
                    .andWhere( "active", 1 )
                    .get();

                // set to empty array = NO DELAY!
                // oPackages = [];
            }
        </cfscript>
        <cfif order_id AND !isNull( oShipment ) >
            <cfif oShipment.isLabelCreated() >
                <div class="col-sm-4 col-md-4 mg-t-30 mg-md-t-0">
                    <h5 class="mg-t-15 tx-primary bd-b bd-2 bd-primary">Shipment Details</h5>
                    <div class="row">
                        <div class="col-sm-12">
                            #cbRenderer.view(
                                view= 'orders/shipping/shipment_info_shipped',
                                args= { 
                                    "oShipment" : oShipment 
                                }
                            )#
                        </div>
                    </div>
                    <div class="col-sm-12 col-md-12 mg-t-10 mg-md-t-10">
                        <button type="button" wire:click="$refresh" class="btn btn-block btn-purple"><i class="fa-solid fa-arrows-rotate"></i> Refresh Shipping</button>
                    </div>
                </div>
                <div class="col-sm8 col-md-8 mg-t-10 mg-md-t-10">
                    <h5 class="mg-t-15 tx-primary bd-b bd-2 bd-primary">Package(s) In Shipment</h5>
                    #cbRenderer.view(
                        view= 'orders/shipping/packages_shipped_table',
                        args= { 
                            "thePackages" :  oPackages, 
                            "oShipment" : oShipment, 
                            "isFullfilment" : false 
                        }
                    )#
                </div>
            <cfelse>
                <div class="col-sm-12 col-md-12 mg-t-10 mg-md-t-10">
                    <h5 class="mg-t-15 tx-primary">Order has not yet been shipped.</h5>
                    <a href="#getShippingScreenURL()#" class="btn btn-primary mg-10">
                        <i class="fas fa-shipping-fast lh-0"></i> Go To Shipping Screen
                    </a>
                </div>
            </cfif>
        <cfelse>
            <div class="col-sm-12 col-md-12 mg-t-30 mg-md-t-0">
                <h5 class="mg-t-15 tx-primary">No shipping data avilable for this order at the moment.</h5>
                    <a href="#getShippingScreenURL()#" class="btn btn-info mg-10">
                        <i class="fas fa-shipping-fast lh-0"></i> Go To Shipping Screen
                    </a>
            </div>
        </cfif>
        <script>
            document.addEventListener("livewire:load", function() {
                window.__omwires_order_tabShipping = cbwire.find('#args._id#'); 
                console.log( "livewire:load" );
            } );
        </script>
    </div>
</cfoutput>

shippingShipments Entity shippingPackages relationship definition:

	function packages(){
		return hasMany( "shippingPackages", "shipment_id", "id" )
	}

Just let me know if there is anything else you want that might help.

I have disabled Anti-Virus and tested with same results

I am leaning towards it being a locking issue, however I am no Java expert. I know that in some cases cbwire does some file parsing and building of a temp file, I don’t know if that could play a role in the issue. It is strange that I can only get it to happen when I use quick relationship loaders.

Done multiple times, specifically since I currentlyly have three files, the old style that uses tabShipping.cfc and tabShipping.cfm and the new style that uses manageOrder_tabShipping.cfm (combined style) and they both have the same results.

Nope

Nope

The files are on a secondary SSD drive on the server. Nothing special, NOT a network drive. Inside the current site root under /wires/tabShipping.cfc & /wires/tabShipping.cfm.

It’s not mine, so if it is CFML then it’s part of Quick.

I am leaning that way too. What is very strange is that it only happens when using the quick relationship getter. See my code I posted for @gcopley simply by changing how I set oPackages I can bypass the delay. When you google java.io.WinNTFileSystem.getBooleanAttributes() you see a lot of other systems having similar issues.

@MikeR I tried replicating your code with the same module versions and I’m not seeing any speed differences between calling the hasMany relation on the QuickEntity versus using WireBox and query builder. I did notice though that your queries above are not exactly the same. In the oPackages query that is creating the delay, you are adding an additional constraint of active = 1. Can you check if that column is indexed in the database? This shouldn’t matter on a small table of data as far as load times, but if you are working with a table with a large number of rows, and if you haven’t indexed the active column, I could see where that might cause a significant slowdown rendering the component. This doesn’t seem to be what’s causing the slowdown from the FusionReactor stacktrace, but it’s something I noticed.

@MikeR Can I see how you are including the component on the page? Are you looping and then including the component? Something like this? And if so, how many times roughly are you looping and rendering each component?

<cfloop array="#orders#" index="order">
	#wire( "tabShipping", { "order_id": order.getId() } )#
</cfloop>

It’s not in a loop. It is happening on a page that is viewing a single order and it renders the content for the tab that shows the Shipment info and packages associated with the shipment.

Orders.cfc (handler) > order.cfm (view) >

<div class="tab-pane" id="tabShipping">
	#wire( "tabShipping", { "order_id": prc.oOrder.getid() } )#
</div>

Just so there isn’t confusion, this does not have a “delay”

It is only when using
oPackages = oShipment.getPackages();
that I get a delay

The packages table is indexed, however at the moment it only has 47 records in it. Also, FusionReactor reports that query took 6ms.

I appreciate the help, it really is a head scratcher. To confirm, you are testing on windows? I haven’t run into the issue during development since I am using a mac.

@MikeR Sorry I had it backward on which one was causing the delay. I’m on Mac also. That’s really bizarre. I don’t think it’s CBWIRE causing the issues, but to be sure, could you move this code outside of a CBWIRE component and see if the problem still occurs there?

I agree, very bizarre :man_shrugging: :confused: I am leaning towards a Java/Windows issue, but I am no java expert. It’s very bizare how this is the only way I can get it to manifest itself.

I am using this code in a couple other places. I will verify it’s the same code, test it, and get back to you.

I originally loaded this info on a page via a jQuery .load() request from my order.cfc handler and eventually wanted to use CBWire to simplify it. The first example below is how I had the event originally, I also changed it to the second block of code below and tested it. Both loaded from a jQuery .load() in under 200ms every time with no delay.

function prepareShipingPackageList( event, rc, prc ){
	prc.oShipment = getInstance( "shippingShipments" )
		.where( "id", rc.shipment_id )
		.andWhere( "order_id", rc.order )
		.withCount( "packages" )
		.firstOrFail();
	prc.oPackages = prc.oShipment.packages().where( "active", 1 ).get();
	event.setView( view: "orders/shipping/packageList", noLayout: true );
}
function prepareShipingPackageList( event, rc, prc ){
	prc.oShipment = getInstance( "shippingShipments" )
		.where( "id", rc.shipment_id )
		.andWhere( "order_id", rc.order )
		.withCount( "packages" )
		.firstOrFail();
	prc.oPackages = prc.oShipment.getPackages();
	event.setView( view: "orders/shipping/packageList", noLayout: true );
}

Neither blocks show any sign of the delay. :man_shrugging: :confused:

At least I know I can work around the issue for the time being!