Since go-live with Spartacus 2.0 in December last year, we are experiencing node server restart issue. After carefully analysing the code, we made some fixes which decreased the count of the restarts but not the full issue.
In September 2021, we upgraded the Spartacus framework from 2.0 to 3.4 version, but still this issue was there and could see 3 server restarts per day in one node. Within a week of going live with the 3.4 version, we encountered one serious issue where content was getting switched between our multi-sites. Here is the link to the ticket raised for the same: SSR issue in 3.x version
After carefully reading the Spartacus documentation, we gave a workaround in the rendering strategy to use ALWAYS_SSR and never fallback to CSR in case of timeout. This workaround surprisingly fixed the server restart issue as well. But now, with our recent release in November 2021, we did put the SAP suggested workaround to solve the issue being raised in SSR issue in 3.x version, which got resolved, however, opens the server restart issue again in production.
I highly suspect that when cache reaches some threshold, node server is getting restarted automatically, which was not happening when we were using the ALWAYS_SSR rendering strategy.
Can we please hear something on this problem?
Thanks in advance.
Related
I have few queries related to the EOL of VueJS 2:
From Wiki link here:Vue.js - Wikipedia , I learn that Vue2 is having EOL in Sep 2023. Is this correct?
Where can we find the Last minor version of Vue2 i.e 2.7 as mentioned here ? If we will start using 2.7, how long it would help us to buy some time for migration to vue 3?
We have VueJS2 application and if we fail to migrate to Vue3 due to some reasons before EOL(using migration guide here: Introduction | Vue.js), What will be the impact?
Will we stop getting any security updates? OR Can we still expect critical security updates?
I hope we would still continue development using VueJs2 and npm install would continue to work for dev environment setup? Are there any chances of one or more dependency stop getting downloaded? (for example node sass etc?)
Are there chances that as the browsers will continue to update to the latest versions and cause some functionality in VueJS 2 stop working and we wouldn't be able to complaint since it’s already EOL?
I believe since no upgrade will happen to VueJS 2, we wouldn’t be able to expect any support for new features in browsers. Is it correct?
Your response will help us to understand and plan the things much in advance.
Will we stop getting any security updates? OR Can we still expect critical security updates?
EOL usually means the same thing on any ecosystem. It stops getting updates to allow moving on to the next thing. It'll still work but it's going to be just like that unless someone continues maintaining it in some way.
if we fail to migrate to Vue3 due to some reasons before EOL, What will be the impact?
You stop getting updates.
Vue component/libraries/plugin developers might write less Vue 2 code and more Vue 3.
If they wrote a Vue 2 code then use that. If there's none, you write one.
I hope we would still continue development using VueJs2 and npm install would continue to work for dev environment setup? Are there any chances of one or more dependency stop getting downloaded? (for example node sass etc?)
You can still continue working on it. It will install as long as it is still hosted on npm.
Are there chances that as the browsers will continue to update to the latest versions and cause some functionality in VueJS 2 stop working and we wouldn't be able to complaint since it’s already EOL?
I believe since no upgrade will happen to VueJS 2, we wouldn’t be able to expect any support for new features in browsers. Is it correct?
Vue is a library for rendering elements and I don't think it uses or ever will use any browser-specific code.
We are facing memory leak issue with ConfigurationProviders ConfigurationRoot.
Looks like this issue may have been fixed
https://github.com/aspnet/Extensions/issues/861
However, Microsoft.Extensions.Configuration 3.0.0 requires NETCORE 3.0. Can someone please confirm how this fix can be applied with .NETCore 2.2.7? We do not want to upgrade to NETCORE 3 yet, as we have time constraints for project delivery.
This is specifically related to the reload change token, so I would assume disabling reload on the JSON files would negate the issue. That means you'd have to restart your app if you made any changes to the JSON files, but that really shouldn't be much of an issue, as you should really only be making configuration changes as part of a new build and deployment anyways (via your CI/CD pipeline).
Otherwise, no, you'd have to upgrade to Core 3.0, unless this fix gets back-ported into the 2.1 LTS release. That's actually a possibility, so it might be worth calling it out on the issue, since a memory leak is a pretty serious issue to leave unchecked in an LTS release. It might have just flown under the team's radar.
The other possibility is that is is back-ported into 2.1, but since you're on 2.2, it's not there. I'm not sure if they'd necessarily back port it into 2.2, since that's not an LTS. As such, your choice may boil down to down-grading to 2.1 or upgrading to 3.0. That's the breaks of the game when you're not not on the LTS release - upgrading may be required.
This issue has been sorted, see details here
https://github.com/aspnet/Extensions/issues/2576
I am trying to update my app for the first time and ran into this issue. I searched a lot but none of the solutions worked for me.
App Store Connect Operation Error
ERROR ITMS-90062: "This bundle is invalid. The value for key CFBundleShortVersionString [2020.0] in the Info.plist file must contain a higher version than that of the previously approved version [2020.0]. Please find more information about CFBundleShortVersionString at https://developer.apple.com/documentation/bundleresources/information_property_list/cfbundleshortversionstring"
And my info.plist file is :
General Window:
TL;DR: If you have an app version that was approved for the official app store, you cannot upload a build with the same version to TestFlight. You have to remove the app from official app store submission, or increase your TestFlight version #.
I figured out why this happened to me.
I have an app in the app store with version 2010.
I have been running an external beta test with version 2020, and build numbers in the range of 400-410
In order to discover if my app would get rejected in the app store once I'm ready to actually release it in a few weeks, I submitted version 2020, build 407 for official app store review. I expected it to be rejected for various reasons. It was approved! However, i'm not ready to release it since I still have more fixes I want to implement. So, I let it sit there, waiting for me to do something with it.
Then, I wanted to upload a newer build for my External beta, still version 2020, build 410, and I received this error.
Thanks to user462990's answer, I realized that the error could be due to the fact that I have version 2020 currently approved and waiting to be launched into the official app store, so iTC didn't allow me to submit the same build # for a TestFlight external beta.
So, I selected "cancel this release" of the official approved version, and Viola! I can now upload a build with the same build #.
I think it was some issue on Apple's side. It resolved itself automatically after few hours.
What worked for me is to change it from 1.0 (.6) to 1.1 (.0) It's not really a new "Version" but incremental improvements and corrections. One thought is that when an app is accepted into the iTunes store then next upload must be to a higher VERSION.
You must always increase the version number when uploading updates, so change it from 1.0 to 1.1.
I'm having a similar issue today. I uploaded a new build a couple days ago with no issues. I found someone who posted a similar issue here: https://discussions.apple.com/thread/7297092. They were able to resolve it by changing the Info.plist values in their sub-projects, however, I tried doing that, and I still ran into the same issue.
I cannot find any information on why this is occurring or when this started, but I know that I uploaded a prerelease build to TestFlight with all of the same projects 5 days ago.
I currently increment my prerelease builds this:
1.10 (1) -> CFBundleVersionShortString (CFBundleVersion)
1.10 (2)
...
I was up to 1.10 (7), which I deployed 5 days ago. Now, I can't get anything to work 1.10 (8), 1.10 (9), 1.10 (1.10), etc. They all say "CFBundleShortVersionString [1.0] must be greater than previously approved version [1.3]"
1.3 is correct as the previous version available in the store, but clearly, 1.0 as the Bundle version is not.
I ran into this issue when going from version 1.141 to version 1.15. Apple does not treat the version as a decimal number - they treat it as multiple integers separated by periods. Thus in my case Apple considered 1.141 to be Major version 1, Minor version 141 and then my new version was Major version 1, Minor version 15. Since 141 > 15 it fails.
Two options to deal with this:
Use Apple's interpretation of version numbers, so you always increment the minor version by 1: 1.1, 1.2, ... 1.9, 1.10, 1.11.
If you wish to use "hundreds" or "thousands" places (I do, as I try to encode the scope of the build in the precision - I use the thousands place for minor bug fix releases), then always pad them out with zeros: 1.10, 1.11, 1.20, 1.30
So in my case I went from 1.141 to 1.150 and I was able to upload.
I have been given a weblogic assignment for my internship, but i have never worked with weblogic before. I have been told that the config.xml needs to be updated. are there any samples or suggestions as to how to go about updating an 8.1 config to a 10.3?
i have been reading through a few oracle pages, but i am still confused. can a config.xml be upgraded using workshop?
thank you for your time.
I have installed a fresh install of XWiki on a Windows platform.
The XWiki instance was installed using hsql for data storage.
The XWiki instance is hosted on Apache Tomcat.
Some of my users entered an apostrophe into the title of a page as well as the page content.
I received the following error:
http://jira.xwiki.org/jira/browse/XE-767
What is my next step to fix my broken XWiki instance?
Is there a way to upgrade a XWiki instance to a version that works? How do I save my existing content?
From reviewing the developers comments, it appears that issue has been corrected.
I, however, do not have enough background in Java or XWiki to know how I can move forward.
Thank you in advance for your help.
Indeed, the best solution is to upgrade to a newer version. Don't worry, upgrades are not that difficult.
http://platform.xwiki.org/xwiki/bin/AdminGuide/Installation#HUpgradinganXWikiInstallation
There are two parts in an upgrade: the platform, meaning all the files on the filesystem, and the wiki content, since quite often things change in the default wiki documents. Your specific bug can be fixed by upgrading the platform part, so if you're not too confident about upgrading the wiki content, you can just leave the old content in place.
In order not to lose your current database, be sure to leave the old "database" folder in place, and just replace the "webapps\xwiki" part.
From the error report the versions that fix the issue are
2.7 - http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterprise27
2.6.1 - http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterprise261
You can upgrade to one of them or to any following version, like XE
3.0 - http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWikiEnterprise30
All versions can be downloaded from http://forge.ow2.org/project/showfiles.php?group_id=170
In a project that has such a rapid development cycle is very good to upgrade often in order to benefit from the latest features and bug fixes.