Does anymore same experience or solution for that ?
My app works fine only several days after deployment, after that it turns to blank screen with "Not Found" text on it.
App is with "WildFly Application Server 8.2.1.Final" Cartridge with status "Started" - note that I am aware of iddling of apps at Openshift, this is not the case.
Recieved reply from OpenShift as following :
It looks like you're hosting your app on a small gear. The WildFly cartridge could be quite memory consuming, depending on what app you are deploying. Please check whether the gear is not having memory issues, as described
https://developers.openshift.com/faq/troubleshooting.html#_why_is_my_application_restarting_automatically_or_having_memory_issues
If there seems to be no memory issues, please check your log files for further information about the problem. You can check your log files by using the 'rhc tail' command, or by sshing into your application and looking in the ~/app-root/logs directory.
You can learn more about checking your log files in our Developer Portal (https://developers.openshift.com/en/managing-log-files.html)
Related
Enviornment :
DCOS : 1.7 running on vagrant
There are many reasons this could fail, but you did not provide enough information to narrow it down. However, the most common problem observed when getting started is missing the bit about having a private vs public agent available and the role being specified in the app json. I can't tell from the single screen shot what environment you are running or the json for the apps you were trying to run. If you are really stuck, try visiting https://dcos.io/docs/1.7/administration/installing/custom/troubleshooting/ and check out their slack channel for assistance. https://dcos-community.slack.com/
I got the same problem when installing DCOS form the Azure template, when I logged in, it appeared that I had 0 nodes connected in my cluster (which is obviously not good). I reinstalled it from another template and it fixed my problem. Hope it helps.
I'm running XAMPP on my windows machine and experiencing a problem with Apache crashing a couple times a day. When it does, a dialog pops up and I have to manually tell windows to end the program. After I do that, XAMPP automatically starts it back up in a couple of seconds with no issues. When it crashes while I'm not home though, the server is down until I get back. So I have two questions:
Are periodic crashes something that should be expected, or is this indicative of another issue I should be trying to pinpoint?
If this is something I should just learn to deal with, is there a way to automatically restart httpd.exe when these issues occur, so I don't experience down time when I'm away from home?
You'd look into log files, especially the Apache access and error logs, to see what happened, when you are not at home. I've met some similar situation: I have a problematic PHP script hosted on my server, when someone visits the page, it leads to an Apache crash.
I'd suggest you do the investigation as follows:
Search the timestamp of recent Apache restart.
Check the Apache access log to see whether there are some scripts have been accessed.
Manually access these scripts in your browser (to see if Apache will crash again)
You'd better check the PHP error log as well.
If there is really nothing suspicious, you can try WAMP bundle alternatively, which is also a very popular PHP development environment and it is stable.
Although there aren't many cases in which one should "expect" periodic crashes, in this case you are better of reconsidering your setup. From the frontpage of the XAMPP site:
XAMPP is the most popular PHP development environment
Sure, you can use it as "production" server, but XAMPP isn't build for hosting websites, it is intended as development server, so you don't have to manually setup Apache, PHP and MySQL on you dev machine. If you actually want to run your website for the public, setup Apache/IIS, MySQL and PHP manually, those products on there own are made for running in production. Or you can consider getting some cheap shared hosting somewhere, so you don't need to setup anything.
I have problem printing reports to PDF through bullzip from Navision Application Server (1) if user is not in Local Admin group (2). Only under both conditions.
In Nav code I'm doing the following: init bullzip automation object (set all parameters to suppress GUI), run report to print document to virtual bullzip printer, catch output file. Thats it. Straight as a rail.
I have two environments: Windows Server 2008 and Windows 7 (different versions of Nav, but this is changing nothing). On Windows 7 it just do nothing (but works if user is admin). On server I can see error in Event Log (translated to English)
Faulting application gui.exe, version 9.8.0.1599, time stamp 0x517126dc, faulting module USER32.dll, version 6.0.6002.18541, time stamp 0x4ec3e39f, exception code 0xc0000142, fault offset 0x0006f52f, the process ID 0x3bc, application start time 0x01ce562238369fa9.
Gui.exe is a part of bullzip.
If I run the same code from Nav Classic Client, or from the same NAS launched in command line, or under local administrator account, or if i put the NAS user in local admin group - it works just fine.
To solve this problem i need to find out one of two and how to fix it:
What is the difference between local admin and regular user that could cause application to crash in non-interactive mode (service) under regular user account.
What is the difference in running NAS as service and as command line that could cause application to crash when run as service.
What I've tried so far: extend non-interactive desktop heap, give user all local privileges that admin have in gpedit. Not works. Don't know direction for further digging.
Any alternative free pdf printers advices are welcome.
This question is still actual. Though I've managed to setup PDF printing with PDFCreator. The tough part was to let several different NAS to print simultaneously. And now the setup have a bottleneck - PDFCreator's printing queue. With bullzip automations it could be avoided.
We've had some cases where third party DLL's have crashed within NAV due to permission restrictions.
The only effective way we could narrow down the files that it was trying to access was through using Process Monitor to try narrow down what was causing permission issues.
We found a folder within System32 to do with the System's Network Profile that some DLLs use. On that note, NAS's and such should be run under a domain account.
I think re-installing the application will do that,
Just make sure you are uninstalling each bullzip and ghost script,
Now Ghost script is tricky thing, if you are installing 32 bit over 64 then you are having problem,
refer this download link download appropriate version, install it,
and then install bullzip, after downloading new version from here
this will do..
then also if any problem(if you are using application for automation, you require new com object..) refer Forum, that explains most of application interface problems..
where you need to use public class PdfSettings with namespace bioPdf.
I hope this will help ..
Whew...ok, been wrestling with this for a while and I can't figure out what is going on.
I am new to Azure caching, but at this point I have read a good bit and I think I have it setup right, but something is obviously wrong so what do I know?
Ok, so first I setup a dedicated caching web worker role using this fine tutorial: http://berniecook.wordpress.com/2013/01/27/distributed-caching-in-azure-cache-worker-role/
I have an ASP.net MVC 4 website that is supposed to be using it.
I have my solution set to multiple starting projects with my cloud caching project set to start first, but no matter what I do, I get the "role discovery data is unavailable".
Sometimes in my output log I get that the Role Environment failed to initialize, but not very often. Most of the time the output log says that is succeeds. Regardless of that, I still get the error above.
I was thinking that maybe the issue was because I was running on local azure storage and compute emulators, so I reconfigured and published the Cloud Service to Azure to see if that helped.
It didn't...
The fun part is that there have been exactly 2 times when it suddenly worked (both when I was working locally). 2 times about of about 100. I didn't do anything different...just ran the debugger and poof, it all worked. This at least lends a bit of credit that it is actually setup correctly.
Needless to say, this is putting a huge damper on my productivity so any advice would be appreciated.
Update
Ok, I have figured out a workaround of sorts...I have learned that the reason that it consistently failed was because the development web server was holding onto a file which prevented the caching server to launch correctly.
The workaround is to stop the web server each and every time I want to recompile and run the code. This is obviously not ideal, so any ways to make this more reliable would be appreciated.
Thanks,
David
I don't know if this helps but I find that if I don't shut down the both the storage and compute emulator, I get weird errors, so after doing an F5 and closing the browser down, I manually shut down both emulators
I've attempted just about everything to get our ClickOnce VB.NET app to run under Terminal Services as a RemoteApp. I have a batch file that runs the .application file for the app.
This works fine via RDP desktop session on the terminal server. As a TS RemoteApp, however, well... not so much.
I get a quick flash of command prompt (the batch file) on the client system and then... nothing...
Same goes for having it point to the .application file directly (without using a batch file) or even copying the publication locally and having it point to that.
I found a technet.microsoft.com discussion about a similar issue, but there's no resolution to it listed.
For anyone who has run into this before and got it working, what did you have to do?
We currently use RemoteApp's for everything else on that server, so I'm hoping to stick with that if possible.
The current workaround is to build and run an MSI-based installer for the app on our terminal server whenever we publish via OneClick out to the network, but this can be quite a pain at times and is easy to forget to do.
Since the app works fine via Terminal Services when run in full desktop mode but not during RemoteApp, I don't think it's anything specific to Terminal Server permissions so much as ClickOnce requiring something that isn't available when running as a RemoteApp.
The Key to getting it to work is to use Windows Explorer "C:\windows\explorer.exe". This process is the base process when you login to a full session.
If you setup the RemoteApp to use Windows Explorer and the command line argument of the path to the .application file for the ClickOnce application then it will work when launched as a remote application. Windows Explorer will flash for a second when it starts, but it will disappear then the ClickOnce application will launch.
Why does it have to be a ClickOnce application? I would consider just deploying the exe file and assemblies.
I know it only half a solution, but if the application does not change much, it might be a good solution.
I believe your problem is related to the fact that ClickOnce needs to store it's data in a special user folder called the ClickOnce application cache. Apparently because of how Terminal Services sets up user folders ClickOnce can't access this in TerminalServices mode.
See this link for more information.
http://msdn.microsoft.com/en-us/library/267k390a(VS.80).aspx
There may not be a way to do it :(
Can you launch the .exe directly? It's buried under your profile in \AppData\Local\Apps\2.0[obfuscated folders], but you should be able to find it.
That will skip the built-in update process, but if it can be launched that way you could then write code to do a manual update after the application starts.
Faced the same problem this morning and got it resolved by copying the clickonce app's directory from the user settings folder to somewhere like c:\MyApp\ - I know its nasty and not very ideal.. but good enough for me!
We recently ran across this issue and decided to post a bug report on this issue to the Visual Studio development team. Feel free to comment on the bug report. It has to be a bug in ClickOnce caused by some changes in Server 2008.
https://connect.microsoft.com/VisualStudio/feedback/details/653362/net-clickonce-deployment-not-working-as-remoteapp-or-citrix-xenapp-on-server-2008-server-2008-r2
We also have a discussion on the MSDN forums covering this issue:
http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/7f41667d-287a-4157-be71-d408751358d9/#92a7e5d9-22b6-44ba-9346-ef87a3b85edc
Try using RegMon and FileMon when starting the app - You may be able to track it down to a file and/or registry permission issue.
Also maybe check the event logs to see if anything's getting logged when the process fails.