What factors do influence the Catalyst app restart mechanism? - perl

I have a Perl Catalyst application which is launched normally using the -r parameter.
I have noticed 2 types of behaviour:
1) the application restarts normally on every "dummy change" of the code (by "dummy change" I mean adding a space or deleting one, smth like this)
2) the application doesn't restart (the same "dummy change"), the "Attempting to restart the server" text is displayed and the app remains blocked in this state (I have to kill it manually)
The behaviour depends on the actual code. It seems there is something related to the code which influences which behaviour acts at one moment. The behaviour is constant, i.e. the same code have one constant behaviour of 2.
The application itself seems to work fine, without any errors or warnings.
How could the code influence this behaviour? (I mean generally)
What factors are related to restart mechanism?

That is because signal handling has changed in the newer version of the Oracle client. Use the "ora_connect_with_default_signals" option to restore default signal handler.
Here is how you can do it in the DBIx::Class model (MyApp::Model::DB):
connect_info => [
'dbi:Oracle:mydb',
'username',
'password',
{
ora_connect_with_default_signals => [ 'INT' ],
},
],
or in the config file:
<Model DBIC>
connect_info dbi:Oracle:mydb
connect_info username
connect_info password
<connect_info>
ora_connect_with_default_signals [ INT ]
</connect_info>
</Model>

I have seen similar behaviour when using a standalone server via PSGI (ie plackup -r), where the server restarts once, and subsequent code changes produce the message but no restart.
However, I have never seen the built-in server myapp_server.pl -r behave in this manner. Any change to a perl module, YAML file etc triggers the restart successfully.
In the brief research I did on it at the time I did turn up this discussion of Plack and restart.

Related

yii, i am getting sql error when using restful api

I am writing restful API with Yii, but I am getting an SQL error in create function. My purpose is to add new data to the news table, but it asks me for the author_id. How can I do it without crushing the default create method?
Solution 1. Run this below query on mysql/phpmyadmin and restart server
SET GLOBAL sql_mode = 'NO_ENGINE_SUBSTITUTION';
Solution 2.
Open the my.ini or my.cnf file for editing (the file you have depends on whether you are running Windows or Linux).
Find the following line:
sql_mode = "STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
Replace it with the line below:
If the line is not found, insert the line under the [mysqld] section (if there is no [mysqld] section, create it).
sql_mode= ""
Restart the MySQL service for the change to take effect.
If restarting is not a feasible option at the moment, you may log into the database server and execute the below command for the changes to take effect immediately. However, the change will be discarded the next time the MySQL service restarts unless the above process is performed.
set global sql_mode='';

Sapper and Service Workers

This is more of a service worker question, although it could be more specific to Sapper. I really don't know, as I am the first to admin I struggle with Service Workers, have barely used them, and feel like they are a pain the butt very often.
Basically, no matter what I do, I cannot get localhost:3000 to stop loading the old copy of the app. I've unregistered the service worker in various ways, including try to programmatically unregister. I've clear caches, and even cleared all browsing data from the browser. The server from my Sapper dev environment is NOT running.
This is happening with Brave, but behaves the same in Opera, and seems like a general Chromium scenario. I don't user Firefox or Safari, but may test in one soon to see what behavior happens there.
Here is a clip showing how I try to unregister the Service Worker.
https://youtu.be/Cb24I_fEklE
I used this little trick that works like a charm. In your rollup.config.js, there's a serviceWorker object in the outputs object.
serviceworker: {
input: config.serviceworker.input(),
output: config.serviceworker.output(),
plugins: [
resolve(),
replace({
"process.browser": true,
"process.env.NODE_ENV": JSON.stringify(mode),
}),
commonjs(),
!dev && terser(),
],
preserveEntrySignatures: false,
onwarn,
},
Define a variable dev on top if not already declared:
const dev = process.env.NODE_ENV === "development";
Now change your service worker config like this:
serviceworker: !dev && {
input: config.serviceworker.input(),
output: config.serviceworker.output(),
plugins: [
resolve(),
replace({
"process.browser": true,
"process.env.NODE_ENV": JSON.stringify(mode),
}),
commonjs(),
!dev && terser(),
],
preserveEntrySignatures: false,
onwarn,
},
Clear cache, the only thing that works for me to bypass it.
The issue is the service worker is service from the cache, serving from the cache again probably resets this item in the cache as even more valid to send and you get caught in something of a cycle.
--
I found this question because I was considering completely removing the service worker to try to get the performance of my site a little higher...
Is it critically necessary? What are the benefits of it?
Make sure to close any browser tabs that have the app running in it, you can't replace a service worker while it's servicing an existing version of the application. Also try reloading the page once the service worker is installed if there are any caching issues.

No error when stopping non existing service with chef

Im new to chef and trying to understand why this code does not return any error while if i do the same with 'start' i will get an error for such service does not exist.
service 'non-existing-service' do
action :stop
end
# chef-apply test.rb
Recipe: (chef-apply cookbook)::(chef-apply recipe)
* service[non-existing-service] action stop (up to date)
Don't know which plattform you are running on if you are running on Windows it should at least log
Chef::Log.debug "#{#new_resource} does not exist - nothing to do"
given that you have debug as log level.
You could argue this is the wrong behaviour, but if the service dose not exist it for sure isen't running.
Source code
https://github.com/chef/chef/blob/master/lib/chef/provider/service/windows.rb#L147
If you are getting one of the variants of the init.d provider, they default to getting the current status of a service by grepping the process table. Because Chef does its own idempotence checks internally before calling the provider's stop method, it would see there is no such process in the table and assume it was already stopped.

How to display "Application is down for upgrade" message when redeploying Glassfish application?

I tried to access a web application while it was in the process of redeploying or reloading, and I just got a 404 error. This is likely to result in time-wasting helpdesk calls if a user happens to see it. How can I replace the 404 message with something more helpful, like "This application is being upgraded - check back in a minute or two"?
You may want to consider looking at Application Versioning feature to "pre-deploy" an application to minimize the impact.
Deploy your app:
$ asadmin deploy myapp.war
Deploy version2 in "disabled" mode, meaning the old version is still active:
$ asadmin deploy --enabled=false --name myapp:version2 myapp.war (version2 is an arbitrary name)
When ready to activate version2:
$ asadmin enable myapp:version2
The nice thing about this approach is that if you run into issues with version2, you can always fall back to the original version:
$ asadmin enable myapp
I normally deploy my webapps behind an Apache proxy. When the appserver goes down Apache returns a 503 response.
This can be customised with an alternative "I'm sorry we're doing maintanence" message
You can also customize the standard response codes (403, 404, etc.) in the server configuration. The simple change is to change the message text, but it isn't as elegant as what you are looking for. However, there will always be a point where the environment will return 404, 503, etc., so you might consider adding this, in addition to, the "behind the proxy" answer provided by #Mark O'Connor.

Capistrano deploy how to use use_sudo and admin_runner

I'm trying to configure Capistrano so that it works for our server setup. We are deploying symfony projects so i'm also using capifony. I'm still experiencing some problems with permissions.
On our server every project runs as a project user, so every project has it's own user. So i configured use_sudo and set it to true and i configured the admin_runner to be the user of the project. But it still didn't work so i modified the capifony to start using try_sudo in stead of the regular run. Which made it work a little bit better. But i'm a bit confused about what to use in which case. You have try_sudo, sudo and run. But which is needed for which use-case?
When you use run i think it'll always be your local user
try_sudo i think will check if the use_sudo flag is true if so it will use the sudo command if not it will use the local user. If you have admin_runner configured it will sudo to the user configured as admin_runner
sudo will always try to sudo
Now my problem is the deploy:symlink method this is also just a regular run command so it executes as the local user, which gives permission problems when i try to view the website.
So can anyone tell me if my description of the 3 commands is correct? and also does anyone know how the admin_runner and use_sudo is suposed to be used, so that the symlink is also being done correctly (and also all other commands done by capistrano)?
kind regards,
Daan
Apologies for such a tardy answer Daan. Your understanding of Capistrano is correct. Note also that the :use_sudo flag defaults to true.
In Capistrano 2.11.2, you'll find lib/capistrano/configuration/variables.rb:
_cset(:run_method) { fetch(:use_sudo, true) ? :sudo : :run }
and lib/capistrano/recipes/deploy.rb:
def try_sudo(*args)
options = args.last.is_a?(Hash) ? args.pop : {}
command = args.shift
raise ArgumentError, "too many arguments" if args.any?
as = options.fetch(:as, fetch(:admin_runner, nil))
via = fetch(:run_method, :sudo)
if command
invoke_command(command, :via => via, :as => as)
elsif via == :sudo
sudo(:as => as)
else
""
end
end
Perhaps your permissions problem involves your server, running as a normal user, not being able to read the contents of the release directory that your current symlink is pointing to?