REST service not starting at server startup


#1

I have a web context that has REST set-up and working just fine. However, when I restart the server that Lucee is running on, I get a 404 "no rest service for [restPath] in mapping [restMapping]. Once I hit any cfm related page on the web context (/index.cfm or even just going to the login page for Lucee admin), then the rest call works just fine. So it seems as though the context isn’t being initialized automatically at server startup, and until it’s initialized the rest service handler isn’t picking up requests.

Lucee Version: Lucee 5.2.9.31
Server OS: Ubuntu 18.04.1 LTS


#2

Hi @eddie_b,

I’ve checked it. After restarting the lucee server (without hitting the login page of lucee admin), rest service works fine for me.

URL: http://localhost:8888/rest/test/system/os
virtual: test
Physical path: C:\Portables\lucee-express-5.2.9.31\webapps\ROOT\rest\


#3

Perhaps this is linux specific then? Because I also don’t encounter this issue when running Lucee on Windows, but when I run it on Ubuntu it seems to surface


#4

I think this is the same as Scheduled Tasks afte Restart
I don’t think any internal lucee stuff is functioning correctly until the tomcat context has been created by mod_cfml as they do not persist through restarts.


#5

Thanks for the response, and seems like you’re onto something. Any thoughts on a workaround? Was considering writing a custom start-up script to just send a request to /index.cfm after lucee starts so the tomcat context gets created, but would love if there was a cleaner solution


#6

by any chance is the first request to the REST service a POST?

https://luceeserver.atlassian.net/browse/LDEV-1988


#7

No, it’s a GET request that returns a 404. But as soon as I may a request to any *.cfm page (even one that doesn’t exist), the rest service starts working as expected again.


#8

but isn’t that the default context which always starts when lucee is started? every other lucee context is only loaded after the first request, as this problem demonstrates


#9

My current workaround is a cronjob on a sister machine that hits a wakeup url on the target and vice-versa (they are our dev boxes that get shutdown overnight.

I couldn’t get it to wake itself up (probably something to do with the internal apache mod_cfml proxy stuff) so doing it on a different machine with a sleep 60 seems to work (eg @reboot sleep 60 && wget http://blah.com/wakeup )