I am trying to enable the Browser monitoring provided by New Relic in my Rails app. I followed the steps listed in the docs - which is basically turning on the feature within the New Relic settings for the app. But not all errors are being logged within the JS Errors tab. My questions is do I need to do some changes within Rails app to include new relic agent on the page? I currently have browser_monitoring.auto_instrument: false in my newrelic.yml because I use the manual way of doing this for some specific pages. Is this property also responsible for doing the error monitoring?
Thanks!
Yes, the auto instrumentation is what injects NewRelic's JavaScript into your page to analyze performance and report errors. The default is true. If you've turned it off, you'll only catch errors from pages where you're manually including it.
If you turn it back on, you can disable it on certain pages where you're doing things manually using newrelic_ignore.
Related
The description of "Vite" was tempting and I was stupid enough to enable this new feature. Since then I am stuck with endless UI recompile loops! I.e. each time after I logged into my application the frontend gets recompiled AGAIN and the application restarts. ||-(
Disabling Vite in the lower right control-dialog is not accepted, it remains activated. How do I get rid of this unbaked feature again?
This is using Vaadin 23.1.7 and Java 17.
In Vaadin 23.1 you can remove the feature flag by deleting it from src/main/resources/vaadin-featureflags.properties.
Note that Vaadin 23.2 uses Vite by default. If you want to continue using Webpack going forward, you need to instead add this feature flag to the properties file:
com.vaadin.experimental.webpackForFrontendBuild=true
I had been happily using Java live reload while debugging my Vaadin application over the past few months.
Today, after I started my browser and directed it to my locally running Vaadin application I got a popup in the lower right corner stating:
Java live reload unavailable. Live reload for Java changes is currently not set up. Find out how to make use of this functionality to boost your workflow. Read more
Clicking onto the read more link (pointing to 'https://vaadin.com/docs/v14/flow/workflow/workflow-overview') just brings me to a "404 Page Not Found" error page.
So - two or actually three questions:
what could cause my live-reload functionality go missing? I am using MS Edge and the Live-reload plugin is enabled (and it used to work until yesterday).
where has the page gone explaining how to set that up?
and finally: Any idea, what to check or fix to get this working again? I consider that pretty essential functionality for efficient UI development!
For question 2, you can find the documentation here: https://vaadin.com/docs/v14/guide/live-reload
Quite not sure why I see this error.
I navigate to my Login View like so http://test.staging.com/mywebsite/Login
My Login view was just redone using MVC but I have seen this same error message going to an aspx page as well...
If I use http I get the error message The specified request cannot be executed from current Application Pool.
If I use https://test.staging.com/mywebsite/Login, I'm good.
If I don't specify a protocol, test.staging.com/mywebsite/Login, I get the error as well
Is there an error happening under the covers and my custom error page can't be shown like discussed here?
What are some other causes of this error?
That usually means your custom errors are configured to run as a different AppPool.
You can read more at MSDN. (See section "Using Custom Errors from Another Application Pool").
There are two ways to correct this behavior. The first is possibly not one that you are interested in because it would require you to change your current architecture and run both sites in the same application pool (such as share the same worker process memory space). To do this, simply move the /errors virtual directory to run in the same application pool as the site for which it serves the custom error.
The second way is to make use of a registry key provided by IIS 6.0. This registry key makes sure IIS 6.0 does not check the metadata during the execution of the custom error and therefore allowing this to work.
See the article for information on the registry key fix.
It may also mean that you are using something along the lines of Server.Transfer to a page that is in a different AppPool.
It could be because you're using different versions of ASP.NET for one or many apps in the pool.
Make sure all apps in the pool use the same version of ASP (e.g. ASP 2.0.50727)
If you just added a new app, try changing the app momentarily to a different version of ASP, then back to same version. I experienced an issue where the displayed version was correct, but under the hood, a different version was used!
Check your event log, under Application, to get more details about the error.
The message would be caused by your page server-side redirecting to a page served by another application pool. Such as for example, in your link, the error page.
I know this is an old thread, but I stumbled upon it and found a different solution. Here's what worked for me: Make sure your application handles .asmx files correctly
From IIS:
Right Click on your project > Properties > Configuration
If necessary, add the .asmx file extension that maps to the aspnet_isapi.dll
Limit to: "GET,HEAD,POST,DEBUG" and restart.
Because I can't comment on vcsjones's answer, I'll add it down here. The DWORD value IgnoreAppPoolForCustomErrors needs to be set under HKLM\SYSTEM\CurrentControlSet\Services\W3SVC\ Parameters vs HKLM\SYSTEM\CurrentControlSet\Services\W3SVC referenced in that technet article. Set it to 1 and do an iisreset and you're good to go.
Source Blog Post
In my particular case, I received this error while trying to serve a content (non ASP.NET) website while it was an Application. Right-Clicking the virtual folder and removing the application fixed it for me.
In my case the application used the application pool that didn't exist. I have no idea how it's happened.
In the struts documentation they are saying that by setting
<constant name="struts.devMode" value="true" />
This will cause the site to load fastly.
So my question is is it possible to put this constant in live site so that it will load the live site fastly. Is there any problem with that?
Thanks
You took it all wrong,struts.devMode when enabled, acts much friendlier, which can significantly speed up development.
When you have made the devMode=true in your config file this will help you in following steps
Struts 2 will reload your resource bundles on every request (meaning you can change your .properties files, save them, and see the changes reflected on the next request).
It will also reload your xml configuration files (struts.xml), your validation files, etc, on every request. This is useful for testing or finetuning your configuration, without having to redeploy your application every time.
it will raise the level of debug or normally ignorable problems to errors.
In Short it is a weapon for the developer for enhance his development process by figuring out any error, as when enabled it will show yo much friendly and detailed error underlying the cause and any suggestion.
Here are more details for devMode
Struts2 Development mode
It is never recommended to enabled this in your production as enabling this means you are reloading your configuration file /any other property files on each request which will definitely slow down the overall portal.
By default, the development mode is disabled, because it has a significant impact on performance, since the entire configuration will be reloaded on every request.
The development mode is only suitable in a development or debugging environment. In a production environment, you have to disable it. It will cause significant impact on performance, because the entire application configuration and properties files will be reloaded on every request and extra logging and debugging information will also be provided.
There is this one action that is requested using javascript during the loading of a page, it takes over 25 seconds to resolve. Looking at the code makes me think there is a scaling issue, but I am wondering if there is any way I can step through the code during the request so I can see what is happening. I try clicking 'debug/start debugging' but it won't launch the proper URL (access to the site is subdomain based), and it will also not find certain dependencies. I am able to browse the site directly via URL locally after mapping a URL via my hosts file to localhost (127...) but the default url that pops up (localhost...) from debug does not work because it is not formatted properly.
Any ideas?
You can attach the debugger to your browser by selecting "Attach to process" under "Debug" menu.
In the past, at least with ASP.NET we have used tracing to debug issues. You will just need to enable it in the webconfig. If you use warn, the messages will show in red and be easier to spot.