I've found issue or lack of documentation around using environment variables with the queue trigger while running under Linux, specifically around nested app settings.
Under a Windows function host, no issues are encountered. For example, the app settings has a setting named "QueueSettings:QueueName" and within the trigger attribute I call it as "%QueueSettings:QueueName" - this works as expected.
When I changed the function host to Linux and update the app settings to be "QueueSettings__QueueName" and the trigger attribute to be "%QueueSettings__QueueName%", the function fails to start.
I'm not sure if I have a syntax error here or if there might be an issue in the resolver under Linux. Thanks in advance!
Related
Please forgive me since I'm rather new to this, but I'll try to explain the situation as best as I can.
The current system is running on ColdFusion 9 and ActiveMQ 5.3.1. We are trying to upgrade the system to ColdFusion 11 and I'm running into some issues. In ColdFusion 9 ActiveMQ appears to run fine on Beta and Production (we also have a local and alpha environment) however in ColdFusion 11 I get the following error: http://puu.sh/gVp1L/d77453416f.png This happens in the /CFIDE/adminapi/eventgateway.cfc:204 which of course is a file that has been abstracted to not be readable.
I have tried the following:
Three different ActiveMQ servers
Two different installs of CF11
Going step by step through the eventgateway api
When I manually try to start the Gateway Instance in CFIDE, it goes to a white page, and nothing shows up in the eventgateway log. The only error I've managed to see was actually in CF9 and it was:
Cannot instantiate class: org.apache.activemq.jndi.ActiveMQInitialContextFactory
I'm assuming that's just a goofy ActiveMQ install locally though. I did some googling on this error and it says that I might be missing a .jar file within ActiveMQ, but when I view the /lib directory I can see the file they claim must be missing. Within CF9, I can actually see errors in the eventgateway log, but like I said, I get a white screen and nothing happens in CF11.
Any ideas?
Thanks,
Nick
This was due to the activemq.jar not being including in the cfusion/lib folder for CF11, but was for CF9.
We are using hawtio to have a fancy and nice web interface for seeing JMX MBeans and Camel Route in our project. However, we have noticed that after weeks running Hawtio stops working and we are getting a Jetty error when trying to access it.
We are using hawtio in standalone mode, version 1.2.0/offline. Also I guess it worth to mention that our Camel routes are pretty heavy and consume many resources (not sure if that impacts hawtio). When trying to access we get this:
HTTP ERROR 404
Problem accessing /ourContextPath/. Reason:
Not Found
Powered by Jetty://
It seems like there is no active resource for our context path and I something went wrong like a thread stopped working or something.
Does anybody have any idea how to solve this or how to find what's causing this? Also, is this a known bug fixed in the latest version (1.2.1)?
Jetty needs a work/temp directory to operate.
Default behavior is to use whatever java.io.tmpdir points to.
However, on many unix installations, this points to /tmp, and that directory is often cleaned out by other processes.
To fix, either specify a java.io.tmpdir to be somewhere other than /tmp
$ java -Djava.io.tmpdir=/var/run/jetty -jar start.jar
or create a ${jetty.base}/work/ directory (if running Jetty 9.1+)
or create a ${jetty.home}/work/ directory (if running versions of Jetty prior to 9.1)
See the answer at Jetty: Starts in C:\Temp for more details on how this work/temp directory operates and is configured.
I'm running a Django site on Apache2.2 with mod_wsgi 3.3 in daemon mode (on Debian Wheezy).
When I use the touch wsgi.py command on my WSGI script from my shell, the process is reloaded and everything works fine. But, when I modify the wsgi.py file from the web-application code, the modification time is correctly changed (checked by stat) but WSGI process is not restarted. I'm using the same user account when manually touching the file as WSGI-daemon runs under.
I've tried the following two methods for "touching" the file from the web-app code, none of which works:
os.system('touch /abs/path/to/wsgi.py')
using django-rosetta's ROSETTA_WSGI_AUTO_RELOAD setting to do the job for me
Both options above actually do seem to work exactly as when I execute touch manually from the shell. They update all Access, Modify and Change file attributes (I'm using ext4, if that could matter).
I know it's really strange behavior and after I've read all docs I'm hopeless. Does anyone have at least a clue what could be the reason?
Do be aware that the reload only occurs on the next request received by the web application. It is not instantaneous at the point that you touch the wsgi.py file. Although you seem to suggest this isn't the issue, Apache would also normally run as a special user and would not have the ability to modify the WSGI script file unless you had specifically set up permissions to allow it to.
To better determine what is going on, ensure that LogLevel is set to info in Apache configuration and look at what log messages mod_wsgi generates in the Apache error log.
For more details and other ways of triggering reload see:
http://code.google.com/p/modwsgi/wiki/ReloadingSourceCode
Alright, finally found the solution. I was using a custom middleware changing the locale for some URLs. The middleware, however, wasn't calling translation.deactivate() at the end of the request (process_response method) which obviously led to some weird inter-thread sharing of locale selection, thus affecting also all further requests. This was happening only when the middleware changed the locale on the first request after process start.
More info here: set language within a django view
I managed to run Django using IIS as webserver (using PyISAPIe) and everything goes well in my test server, mounting Windows 2008 Server R2 64bit.
Then I installed the application on another server with the same configuration and it works fine for the first request. Then when I reload the page, I get a "Service not working" page.
On the event log I see an Application error saying that python26.dll had some problems:
Faulting application name: w3wp.exe
Faulting module name: python26.dll
Exception code: 0x40000015
Faulting application path: C:\Windows\SysWOW64\inetsrv\w3wp.exe
Faulting module path: C:\Windows\system32\python26.dll
Can you give me some hint on how to solve that problem?
UPDATE: "Rapid-Fail Protection" in the Advanced Settings of the Application Pool was set to 5 failures; disabling it, all worked well.
So, now the question is: how can I detect what caused the failures?
UPDATE: I discovered that IIS crashes when there are multiple requests (img, css, js). PyISAPIe is called for each of them, passing them to static server once recognized.
No idea why this happens...
PyISAPIe is not a good choice to run Django on Windows 2008. In this article you can find better solution: Running Django on Windows (with performance tests)
Check the eventlog it should be in there.
You may also find some more detail in the httperror log (C:\Windows\System32\LogFiles\HTTPERR).
I discovered that IIS crashes when there are multiple requests (img,
css, js). PyISAPIe is called for each of them, passing them to static
server once recognized. No idea why this happens...
Do multiple request cause the error on both machines? When there are multiple requests in an ISAPI application, each request runs in its own thread. The Python multi-threading model is GLOBAL - all threads running under that Python process are co-mingled and sharing all global resources, so you must serialize all multi-threaded code running in all applications and processes using your Python engine. This is a serious downside in Python multi-threaded processing and may be the source of your problems. See http://docs.python.org/library/multiprocessing.html and other sources.
But even this only occurs on one machine and not the other, that may still be the cause - it could also depend on many other environmental variables - number of requests, resources of the machine, processors, etc.
Check memory usage on machine (total physical).
We are using Hudson to build mixed C++/Java projects with an Ant script. It is running in Tomcat 6, on a Win XP virtual machine.
I have noticed recently that when a user logs off the machine (from a remote desktop session), builds that are currently running tend to suddenly fail without an error message.
Has anyone encountered anything similar or have an idea what might be causing this effect? I can post additional information about our setup if needed, I'm just not sure what's relevant in this case.
EDIT: I have tried running the Tomcat service under various users, but this doesn't seem to help. Tried the standard Local System account, as well as the server Administrator and a domain administrator account.
Try adding -Xrs to the Tomcat JVM arguments.
For more information see this bug.