I think @zackster reworked it, but possibly for Lucee 6

The one that used to ship with Lucee, was basically a no-op. It looked like someone had taken a once-working example and stripped out a bunch of code to the point where it no longer did anything

Mind you, this was quite some time ago

Actually that ticket is still marked "new" so maybe nothing was fixed ever?

Hmm, comments claim the issues were fixed in this commit https://github.com/lucee/Lucee/commit/d92786a43709b637193d1d711141726e3c89b0b0#diff-55ed46576b217f4354b6394d42e4564da869ac2bc96ba5c52a250f2eb69b06a7 Which is part of Lucee 6

The async component is a big cfthread equivalent 🙂

Lucee's event gateways have no actual queuing mechanism like Adobe's does

They are much simpler

With Adobe, if you called

sendGatewayMessage()

100,000 times in a row, Adobe would queue up those events and then process them out of that queue using a preset number of threads (limited by wither you're on CF Enterprise or CF Standard 😆 )

But on Lucee, when you call sendGatewayMessage(), its imply fires off the sendMessage() method in a thread right then

There is no internal queuing of events or threadpools, unless you build all of that yourself into your CFC

So if there's a chunk of logic you want to run where the main thread doesn't wait for it, you may as well just write this code

thread {
  myComponent.doSomething()
}

I don't even understand all of the code in Lucee async gateway-- for instance, what on earth is this line doing? https://github.com/lucee/Lucee/blob/d92786a43709b637193d1d711141726e3c89b0b0/core/src/main/cfml/context/gateway/AsynchronousEvents.cfc#L24

Lucee internally spawns the thread

which is not the same as the worthless thread from the start function which just sits there for no apparent reason.

When it says:

getListener().onIncomingMessage(local.event);

Is that referring to:

AsynchronousEventsListener.cfc -> onIncomingMessage()

Or:

CustomCFC -> onIncomingMessage()

I'm fairly sure you can use the asyncronoueventlistener or create your own, but I don't think there's actually any reason to use the baked in one

I honestly just think it's an example

The entire thing is example-quality 🙂

Yeah, that listener file bundled with Lucee is simply an example listener that does nothing but log the info

you'd want to provide your own listener that actually did something with the message

But I'm 94% certain it's not currently actually async. You can test easily by putting a

sleep(10000)

in your listener and see if the

sendGatewayMessage()

blocks for 10 seconds or returns right away

Ahh yes, I'm pretty sure the CFC path isn't actually used

Just the listener

Like I said, this example was all sorts of cobbled together the last time I looked at it

I think someone had the original idea of • the gateway CFC • which calls the listener • which delegates to another CFC of your design but when you step back and think about it for a sec, you realize the third bullet is pretty pointless

Ignore it add add your custom CF as the listener

Then this code

getListener().onIncomingMessage(local.event);

will actually call your code

The form fields on that page are dynamic based on the config here

core\src\main\java\resource\context\admin\gdriver\AsynchronousEvents.cfc

I have added my Custom CFC Listener to both fields:

/la_reporting/model/RunReport.cfc

Is a mapping path, by the way. It is one directory above the webroot, which is why I cannot use normal CFC path dot notation. And now I get:

"INFO","XNIO-1 task-2","04/18/2023","21:28:27","lucee_context5.3.9.166","Event Gateway reportinggateway stopping"
"INFO","Thread-144","04/18/2023","21:28:27","lucee_context5.3.9.166","Event Gateway reportinggateway stopped"
"INFO","XNIO-1 task-2","04/18/2023","21:28:27","lucee_context5.3.9.166","Asyn CFC initialized path /la_reporting/model/RunReport.cfc"
"INFO","Thread-279","04/18/2023","21:28:28","lucee_context5.3.9.166","Event Gateway reportinggateway started"
"INFO","Thread-286","04/18/2023","21:28:31","lucee_context5.3.9.166","Event Gateway reportinggateway stopping"
"INFO","Thread-279","04/18/2023","21:28:31","lucee_context5.3.9.166","Event Gateway reportinggateway stopped"
"INFO","Thread-286","04/18/2023","21:28:31","lucee_context5.3.9.166","Event Gateway reportinggateway started"
"INFO","XNIO-1 task-9","04/18/2023","21:28:47","lucee_context5.3.9.166","sendMessage - Event Listener"
"INFO","XNIO-1 task-9","04/18/2023","21:28:47","lucee_context5.3.9.166","Event Gateway Component [lucee.extension.gateway.AsynchronousEvents] has no accessible Member with name [LISTENER]"

It may need to be dot.path.to.component

old listener value

lucee.extension.gateway.AsynchronousEventsListener

OK. I have been playing around with multiple combinations and I cannot get it to work. The Web Admin seems to only play nicely with the example files. If you try and add your own events & listeners, it just says that it cannot find the file. I have tried putting stuff in the webroot. I have tried using CFC dot notation and absolute file paths, with no success. I suspect the Event Gateway module in Lucee 5+ is broken. I will just use a

cfthread

in situ.

firstly, it has an endless loop that chews your CPU

until you add a sleep into the while loop in the start method of this file

C:\Users\Brad\.CommandBox\server\8A7BBDE95D7EC758F1D472B86AF89506-asyncgateway\lucee-5.3.10.120\WEB-INF\lucee-web\components\lucee\extension\gateway\AsynchronousEvents.cfc

The default listener does work though out of the box (despite the CPU-killing loop). Runnning

sendGatewayMessage( 'test', { 'brad' : 'wood' } )

puts the following message

"INFO","XNIO-1 task-5","04/18/2023","16:52:21","lucee_context5.3.10.120","CFMLAysncListener onIncomingMessage -Event Listener"

in the this log file

C:\Users\Brad\.CommandBox\server\8A7BBDE95D7EC758F1D472B86AF89506-asyncgateway\lucee-5.3.10.120\WEB-INF\lucee-web\logs\AsynGateWay.log

I created a file in my web root called

listener.cfc

and created this config

Note, the CFC path DOES NOTHING AT ALL, but you have to put a valid file there just to make the stupid form save

The listener path is the dot-notation path using a mapping if necessary, but a serer-level mapping. An Application.cfc mapping won't work here.

I put this method in my listener

public void function onIncomingMessage(struct CFEVENT={}){
		systemOutput( arguments, 1 )
	}

and running the same code as above put this in my console

[INFO ] {"CFEVENT":{"DATA":{"brad":"wood"},"ORIGINATORID":"1BAB936D-2C2E-4965-9E145804DF9E931B","GATEWAYTYPE":"","HOSTNAME":"DESKTOP-IAN6MSO","CFCPATH":"","CFCMETHOD":"","TIMEOUT":"","METHOD":""}}

Also note, you must restart Lucee (which can be via the button in the server admin) to pick up any changes to the listener CFC

If you wanted to make async gateway that didn't suck, you'd need to create your own version of

C:\Users\Brad\.CommandBox\server\8A7BBDE95D7EC758F1D472B86AF89506-asyncgateway\lucee-5.3.10.120\WEB-INF\lucee-web\components\lucee\extension\gateway\AsynchronousEvents.cfc
and
C:\Users\Brad\.CommandBox\server\8A7BBDE95D7EC758F1D472B86AF89506-asyncgateway\lucee-5.3.10.120\WEB-INF\lucee-server\context\context\admin\gdriver\AsynchronousEvents.cfc

which removed the superfluous CFC path and fixed the stupid while/true loop of doom

Those files also must go directly in the Lucee server home which makes shipping a custom event gateway type a total pain in the butt like no one ever thought through how that would work in an automated deploy.

The while loop can be entirely removed from the start method and the status simply set to

running

. I honestly have no clue what the purpose of that ever was for.

Confirmed, it's defo not async with the thread commented out

You can't simply uncomment the thread tag however, as the code doesn't pass

data

into a visible scope-- likekly why someone commented it out in the first place because they wouldn't get it working, lol

You'd need to do this in order for it to work and actually be async

thread data=data{
                local.event ={
                    ...
                    Data = attributes.data,
                    ...
                };
                    log text="sendMessage - Event Listener HostName..." file=this.logfile;
                getListener().onIncomingMessage(local.event);

             }

Which, even that isn't fantastic as the try catch won't capture errors in the actual listener.

Anyway, you get the picture- it all can be made to work. But the async gateway as it ships is pretty worthless, and I don't think it got much better in 6.0

OK. This is why nothing worked for me. I only did a server restart, not a Lucee restart. 🥴 I will try again tomorrow. Wait a second? I am using CommandBox. Surely a server restart is a Lucee restart? I used the restart function in the Lucee server tray icon? Surely this is the same thing?

OK. I feel something is being cached. I am getting this:

"INFO","main","04/19/2023","11:07:59","lucee_context5.3.9.166","Asyn CFC initialized path /la_reporting/model/RunReport.cfc"
"INFO","main","04/19/2023","11:07:59","lucee_context5.3.9.166","Asyn CFC initialized path C:\domains\acf-lucee-shared\shared\la\CF-INF\cfcomponents\la\RefreshCandidateManagerCache.cfc"
"INFO","Thread-4","04/19/2023","11:07:59","lucee_context5.3.9.166","Event Gateway reportinggateway started"
"INFO","Thread-5","04/19/2023","11:07:59","lucee_context5.3.9.166","Event Gateway refreshcandidatemanagercache started"
"INFO","XNIO-1 task-7","04/19/2023","11:14:24","lucee_context5.3.9.166","sendMessage - Event Listener"
"INFO","XNIO-1 task-7","04/19/2023","11:14:24","lucee_context5.3.9.166","Event Gateway Component [lucee.extension.gateway.AsynchronousEvents] has no accessible Member with name [LISTENER]"

But there is no mention of

lucee.extension.gateway.AsynchronousEvents

in the:

Web admin -> Event Gateway -> reportinggateway

I have stopped and started the server using the CommandBox tray icon

I think that:

C:\Users\ADMCharlesr\.CommandBox\server\A39A87EE2EFB28FAFA02EAB99EA6149F-system_learningassistant_lucee\lucee-5.3.9.166\WEB-INF\lucee-web\components\lucee\extension\gateway\AsynchronousEvents.cfc

Is having problems, finding my listener:

la\Reporting\model\RunReport.cfc

Now let me explain my custom listener's path:

Listener Component = la_reporting.model.RunReport

la_reporting

is a server level mapping:

It may have something to do with the fact that my listener is one directory above the webroot:

webroot = la\Code

But I have tested with a custom listener that is in the webroot, and it still cannot find it?

Even when I add the custom listener under the webroot, I still get:

"INFO","XNIO-1 task-11","04/19/2023","12:17:25","lucee_context5.3.9.166","Event Gateway ERROR Component [lucee.extension.gateway.AsynchronousEvents] has no accessible Member with name [LISTENER]"

When I added a dump of the listener in the:

C:\Users\ADMCharlesr\.CommandBox\server\A39A87EE2EFB28FAFA02EAB99EA6149F-system_learningassistant_lucee\lucee-5.3.9.166\WEB-INF\lucee-web\components\lucee\extension\gateway\AsynchronousEvents.cfc -> init()

It spits out the default listener rather than the custom listener?

I am using EHCache, so I wonder if that is affecting things?

I am also beginning to wonder whether the name of the listener must contain the word

Listener

, in it?

The error about the listener variable not being defined is one I saw as well and it always went away when I restarted Lucee. I don't understand how the error happens, but I assume there is an error happening in the CFC's constructor.

Are you watching the specific log file for the gateway, it's full of information.

Also, did you remove this code

writeDump(var="#arguments#", output="C:\Users\HP\Desktop\test.html", format ="classic");

that will error on your machine 🙂

No, the word "listener" is not required.

I really wasn't trying to talk you back into using the gateway-- cfthread is still the same thing-- I just wanted to be clear that the gateway does work with some adjustments.

I really have no idea what you've got going on without spending more time than I have right now to understand all the changes you've made and where.

All I know is I spun up a successful async event gateway last night on Lucee 5.3 with the steps I detailed