I'm using LogEntries as an add-on on AppHarbor. While everything works fine when logging via the controllers, I can't get any log from a worker running on a separate thread.
Is it LogEntries dependent on an HttpContext?
Related
I have an AngularJS application and I'm trying to use Cypress to stub some of the network requests that it makes. Currently, my problem is with a request with resource type Img. I know from Cypress documentation that Cypress cannot stub non-XHR resource types/requests, but I'm looking for a workaround.
My application requests the image from a backend server, which I want to stub or fake. I prefer not to modify the application code, and would rather create an external workaround.
I've looked into the following and found them not to be useful in this scenario:
Sinon.js - Similarly can only handle XHR requests.
nock - Replaces node's http.request, but that doesn't seem to work within Cypress. It might work if I added it straight into my application code, which I prefer not to do.
I've also tried the following but was unsuccessful:
mockserver - Ran the mockserver and added an expectation, but none of the requests made to the mockserver seemed to go through.
Service Worker API - Was unsure about how to register my service worker, since it requires a .js file as an input. What .js file would be served as input if I'm controlling the service worker via Cypress?
a mock server using express - The issue is the application is running on localhost:<some_port>, while the mock server is running on localhost:<some_other_port>. I'm having trouble specifying port numbers when constructing the request through the application. Basically, my application isn't really respecting different port numbers.
EDIT:
I've been successful with creating a mock server using express. According to Cypress documentation, servers shouldn't be started and stopped within before() and after()'s. Instead, they should be started prior to Cypress being started, and stopped after Cypress is stopped.
I have written a service to host NServiceBus and for some reason NServiceBus is shutting down almost immediately after starting the service. If I run the executable manually everything works exactly as it should but as a service it decides to shutdown without an error being logged. Below is an example of the log files:
Selected active license from C:\ProgramData\ParticularSoftware\license.xml
Security warnings are reported due to opening up some of the security for testing purposes
Initiating shutdown.
Shutdown complete.
All of this takes place in 0.48 seconds.
This is a .net 4.6.1 application as my organization doesn't allow .net core at this point.
I have finally figured out the answer, I had 2 separate ways of closing the connection with NServiceBus, one was supposed to be used in the case that it was being ran as a console app, while the other was for when a service was running. The problem was that the one for the console app was also being hit by the service before it was supposed to, I have now resolved that issue.
I use Workbox to pre-cache assets required to render the app shell, including a basic version of index.html. Workbox assumes that index.html is available in cache, otherwise, page navigation fails because I have this registered in my Service Worker:
workbox.routing.registerNavigationRoute('/index.html');
I also have the self.skipWaiting() instruction in the install listener:
self.addEventListener('install', e => {
self.skipWaiting();
});
As I understand it, there are 2 install listeners now:
One that's registered by Workbox for pre-caching assets (including index.html)
One that I registered manually in my Service Worker
Is it possible for self.skipWaiting() to succeed while Workbox's install listener fails? This would lead to a problematic state where assets don't get pre-cached but the Service Worker is activated. Is such a scenario possible and should I protect against it?
I highly recommend "The Service Worker Lifecycle" as an authoritative source of information about the different stages of a service worker's installation and updating.
To summarize some info from that article, as it applies to your question:
The service worker first enters the installing phase, and however many install listeners you've registered, they will all get a chance to execute. As you suggest, Workbox creates its own install listener to handle precaching.
Only if every install listener completes without error will the service worker move on to the next stage, which might either be waiting (if there is already an open client using the previous version of the service worker) or activating (if there are no clients using the previous version of the service worker).
skipWaiting(), if you choose to use it, it will bypass the waiting stage regardless of whether or not there are any open clients using the previous version of the service worker.
Calling skipWaiting() will not accomplish anything if any of the install listeners failed, because the service worker will never leave the installing phase. It's basically a no-op.
The one thing that you should be careful about is using skipWaiting() when you are also using lazy-loading of versioned, precached assets. As the article warns:
Caution: skipWaiting() means that your new service worker is likely
controlling pages that were loaded with an older version. This means
some of your page's fetches will have been handled by your old service
worker, but your new service worker will be handling subsequent
fetches. If this might break things, don't use skipWaiting().
Because lazy-loading precached, versioned assets is a much more common thing to do in 2018, Workbox does not call skipWaiting() for you by default. It's up to you to opt-in to using it.
I have a webapp deployed successfully in Jetty webserver.
The webserver responds to requests fine.
When I access the app it renders the home page.
Recently I noticed that when I don't use the app for certain period of time it breaks somehow. The period is somewhere around 2/3 weeks.
When I access the webapp after 2/3 weeks of idle I receive this output.
If I try to access any other link, i.e. the login page (/login.faces) I receive:
Problem accessing /error/not-found.faces. Reason:
/error/not-found.xhtml Not Found in ExternalContext as a Resource
which normally used to work before idling.
If I restart the webserver everything returns to normal and works fine. There are scheduled tasks set which make the app interact every day with database. (There is a scheduled task for fetching currency rates via webservice).
Therefore, my question is what would be the cause which breaks the site and makes it unavailable after idling? Is this a webserver (jetty) issue? Am I missing any setting which is crucial?
FYI, the project structure is: Java with Spring, Hibernate, JSF (PrimeFaces) and Jetty
This occurred due to permissions in CentOS.
If anyone faces the same issue make sure to check the logs have appropriate permissions to read and write
When a machine reboots, do all the services which are run under the accounts (system/service/network service) get run before a user logs on?
JD.
Services have a "start type" defined per-service, those types are boot, system, auto, demand, disabled. Services also have dependencies on each other, defined in the registry.
Services with boot and system start type are started during the time period when only NT Native binaries can run (the Win32 API is not yet ready). For example, these services include such as csrss.exe which provides some of the Win32 API.
Once Win32 has been initialized, the services with start type automatic are started. During this time, the service which allows the user to log in runs -- this displays the login prompt and does allow the user to log in.
In every case, if the service being start depends on other services, then the other services will be started in advance.
So, yes, it is possible for users to log in prior to the execution of a service. However, if the login service were to depend on your service... Better, though, if you detect that your service has started. Considering using a named global event with CreateEvent() api. Your service creates the event, your application awaits the event before calling the service. Also, your app can use the ServiceControl API to start the service only when in use.
The windows "Services.msc" management plug-in hides the boot and system services. To learn more about these startup types, refer to this API documentation: MSDN: ChangeServiceConfig Function .
Yes, using (by default) a built-in Windows account. In Services (run services.msc) there is a "Log On As" column that tells you the user that the service logs in as.
I do not think so. This should be asynchronous. If you are fast enough to log on, some of the services will still be coming up. This does not include "system" services