I'm a newbie in RAD ide and currently I always restarts the server everytime I make a change.
I'm wondering what is usually the most efficient way when deploying an ear file to WAS upon code changes.
1) If the WAS is auto synchronize, does it mean that on every ctrl+s I make, it will redeploy immediately?
2) If auto synchronize is off, does changing a resources like jsp or xhtml pages would reflect without restart? How about changing java codes?
As much as I would like to try these right now, I do not have a license of RAD at home.
Thanks in advance for all the help.
In general you should try to avoid restarting server as much as possible, as it takes time. It is better to Republish, or remove and then add application to server.
1) If the WAS is auto synchronize, does it mean that on every ctrl+s I make, it will redeploy immediately?
Not immediately, it depends on the Publishing interval setting in the Server settings > Publishing (I don't remember the default, it is about 10-15 sec).
2) If auto synchronize is off, does changing a resources like jsp or xhtml pages would reflect without restart? How about changing java codes?
Restart has nothing to do with that, only republishing.
Behavior depends on other publishing options - In the Publishing settings for WAS in server settings you have the following options:
Run server with resources within the workspace
Run server with resources on Server
If you run from workspace, changes will be detected and application will reflect changes (if change in the java code application will be restarted).
If you run with on Server setting, then changes will not be reflected until republish not restart.
Restart is only required, if you change some settings on the server, e.g. changing datasource settings, security settings, etc..
For synchronizing - if you have large project, and making lots of changes it is usually better to temporary remove application from the server to avid constant republishing or disable automatic publishing.
Related
I use hot deploy ./mvnw compile quarkus:dev. According to the documentation, I do only need to change the files without saving it and refresh the browser. However, in my case hot deploy does only work if I save the file before requesting the page. I used the getting-started-project from quarkus quickstarts. My question is: Is this the right behaviour (change file->save file->request page) and the following statement wrong (change file->request page):
https://www.baeldung.com/quarkus-io (section 4: hot reload)
In other words, changes made to Java files or to configuration files
will automatically be compiled once the browser is refreshed. The most
impressive feature here is that we don't need to save our files. This
could be good or bad, depending on our preference.
You absolutely need to save your files for hot reload to be triggered.
The update is based on the file timestamps to have changed.
What you don't need is recompiling your application or restarting anything.
My Continuous Integration is running ver very slow.
After launch with -r "ContinuousIntegration.exe -r" it hangs after "Restoring objects…" and before "Optimizing file repository…". It can last within that state even for an hour. After all everything is imported well...
With a profiler I've found that most time is consumed by CMS.DataEngine.TranslationHelper
Anyone has some ideas what is wrong ? Click here to see the screenshot of profiler
If you have a lot of custom objects or data within those out of the box or custom objects with relationships when you are doing a -r it can take a long time to update your local instance. Simply put, it's rebuilding the whole database with the structure in the CI files. Also, the documentation states:
To ensure that the restore process works correctly, you need to stop your Kentico application before running the restore process. Otherwise you may encounter the following problems:
Deadlocks or data inconsistencies if the system attempts to write to the CIRepository folder while data is being restored from the files
Outdated content in the application's cache if you restore without restarting (can cause inconsistencies in the Kentico administration interface or the website's content)
So be sure to stop your instance when restoring to help with the performance.
We've recently launched a new website in Azure (i.e. Azure Websites) and as is typical with new launches we've had to deploy a few tweaks to fix minor issues shortly after launch.
We want to use Slots in the long run but this is not possible at the moment. Hence we are deploying to the live site. It's a fairly busy site with a good amount of traffic and obviously want to keep downtime to am minimum.
We are using Visual Studio to publish file changes to Azure but have noticed that even if we publish a relatively insignificant single file the whole site goes down and struggles to come back up. I was assuming that publishing a single file would literally just replace that file on the file system but it's behaving more like it recycles the application pool (or Azure equivalent) for the site. The type of files I've been publishing have been Razor views, hence would not typically cause a recycle.
Does anyone know what actually happens under the hood of VS Publish and if there is a way to avoid this happening?
Thanks.
I just tried this using a basically clean new MVC app (https://github.com/KuduApps/Dev14_Net46_Mvc5), and I did not see this behavior. The Index.html view has a hit count based on a static, which would tell us if the app or the page got restarted (or if that specific page got recompiled).
Then the test is to publish it, make a change to some other view (about.cshtml), and publish again. WHen doing this and hitting Index.cshtml, the count keeps going up, and there is minimal slowdown.
If you see it getting restarted after a view change, I suggest using Kudu Console to look at the files in site\wwwroot before/after the publish, and check what has a newer timestamp (e.g. check web.config, bin folder, ...).
Our production Liferay instance absolutely refuses to deploy my latest theme. Something is preventing it from displaying my latest CSS changes. Unfortunately, there are NO log errors and no Firebug Console errors, so it's been a real headache to diagnose. I just get a really ugly plain page with links and no styles applied.
I have tried everything I can think of to fix this.
Undeploy/redeploy theme
restart the Glassfish container
use Liferay Server Administration page to "Clear content cached across this JVM", "Clear database cache", "Verify Database plugins", etc.
undeploy, restart, redeploy
undeploy, delete leftover files/folders pertaining to the theme in 'applications' folder, restart container, redeploy
clear my browser cache
try a different browser
many more combinations of the above. You get the idea.
Last night I reached the boiling point because my theme deployed and displayed in our test environments without issue, but didn't work in production. The only thing that was different is that I wasn't using
include-and-override=portal-developer.properties
in my portal-ext.properties file.
I took a gamble and added this line to my production portal-ext.properties and restarted the production server. My theme now displays without a problem.
The file portal-developer.properties only appears to contain the following properties:
theme.css.fast.load=false
theme.images.fast.load=false
javascript.fast.load=true
javascript.log.enabled=false
layout.template.cache.enabled=false
browser.launcher.url=
combo.check.timestamp=true
freemarker.engine.cache.storage=soft:1
freemarker.engine.modification.check.interval=0
openoffice.cache.enabled=false
velocity.engine.resource.manager.cache.enabled=false
com.liferay.portal.servlet.filters.cache.CacheFilter=false
com.liferay.portal.servlet.filters.etag.ETagFilter=false
com.liferay.portal.servlet.filters.header.HeaderFilter=false
com.liferay.portal.servlet.filters.themepreview.ThemePreviewFilter=true
So, finally, my question is, am I merely trading a slight performance boost for a massively easier deployment experience?
Or are there more serious concerns to loading this file in a production environment?
Thanks in advance for the input!
Ben
You'll get a really bad performance with that portal-ext.properties. That configuration is only intended to be used in development environments.
If you delete the css/.sass_cache directory on your deployed theme you'll see your css changes and you'll be able to use a different portal-ext.properties on production environment.
http://issues.liferay.com/browse/LPS-26939
Regards
My application is a combination of Spring/Hibernate/JPA. Recently my development environment was migrated to RAD 7 with WAS7. Previous I was using v.6 for RAD & WAS.
The problem is,
when I make a Java change, the server publishes for a long time, sometimes it takes upto 10 mins for a single line of change to take effect. Also even JSP changes alone takes much time during publishing!!
This was not the case in WAS6. Publishing java changes was not even a concern in WAS6. The changes takes effect immediately as the publish process is done within a few seconds.
This publishing process keeps on running several times as I make changes in my code, and I have to wait (for long intervals during work hours) till it completes, to verify/test my changes during runtime. This is horrible!!
Is there a way to make WAS7 publish JSP/Java changes faster in few seconds as like WAS6? Is there any fix/refresh pack for this?
Can someone help me with this?
Thanks in adavance.
This problem can be overcome if you have the control to publish rather than automatically publishing it. You can wait to make all your changes and then publish it.
To do that
In the server view double click on the server that you are working on and under publishing check the option "Never publish automatically".
Also if you can give the option "Run server with resources within the workspace" that would do reduce the time of copying the files from your workspace to server space while publishing.