Unable to run setup:upgrade command- Scandipwa - reactjs

Installing scandipwa after cache changes to varinsh cache.
I'm Facing an error while running setup:upgrade command.
Error flushing Varnish server. Host: "scandi.pwa". PURGE response code: 500 message: Internal Server Error
using apache. Can we fix this on apache without using nginx?
Thanks

Related

Issue getting rsDriver to work using RSelenium

I am having an issue with getting a server connection using the rsDriver function using this code:
driver <- rsDriver(browser = "chrome", chromever = "111.0.5563.19", port=free_port(),check=F, verbose=T)
I get this error:
Warning: Could not determine server status.[1] "Connecting to remote server" Could not open chrome browser. Client error message: Undefined error in httr call. httr output: Failed to connect to localhost port 14415 after 2229 ms: Connection refused Check server log for further details.
As suggested by other posts, I have tried deleting the LICENSE.chromedriver files which has not worked, as well as updating all dependencies of wdman. I have also attempted to revert wdman back to 0.2.5 from the current version but the old version will not install. While attempting to roll wdman back to v0.2.5 using
remotes::install_version("wdman",version="0.2.5",repos="http://cran.us.r-project.org")
I get this error:
Downloading package from url: http://cran.us.r-project.org/src/contrib/Archive/wdman/wdman_0.2.5.tar.gz Installing package into ‘C:/Users/abc/AppData/Local/R/win-library/4.2’ (as ‘lib’ is unspecified) Warning message: In i.p(...) : installation of package ‘C:/Users/abc/AppData/Local/Temp/RtmpuCeY3j/remotes1aec32a03b15/wdman’ had non-zero exit status
I have also tried using firefox instead of chrome without success. This is on windows 10, with R 4.2.2, RSelenium 1.7.9.

Deploy error An unexpected error occurred: "ESOCKETTIMEDOUT". App Service Azure

I have a big problem trying to deploy a react app to a azure app service with visual studio azure app service extension, im getting this error
info There appears to be trouble with your network connection. Retrying...
error An unexpected error occurred: "https://registry.yarnpkg.com/date-fns/-/date-fns-2.0.0-alpha.27.tgz: ESOCKETTIMEDOUT".
Im using yarn and i read that increase the network timeout maybe solve this. But how i can do it?
I am using yarn and i read that increase the network timeout maybe
solve this. But how i can do it?
You can try running it in your terminal :
$ yarn install --network-timeout 1000000
And also try to clear the cache by running the below cmd
$ yarn cache clean
$ yarn // to install dependencies, no need for "yarn install"
Please refer the below links for more information:
.yarn is having troubles with the network connection | SO THREAD .
. React deployment keeps failing with ESOCKETTIMEDOUT | MS Q&A
Try to NOT run build on Azure. Do this by answering NO when you publish.
Have you already made the settings to build on Azure (answered yes) .. undo by deleting the following files
.vscode\settings.json
.deployment
Create the file .yarnrc, and write into file:
network-timeout 1000000
Save file & deploy your app with the file

Starting jetty fail in ubuntu 14

I install the solr-jetty package in a Ubuntu 14 container running in a cloud9 workspace.
To install the package I run the following command:
sudo apt-get install solr-jetty
The installation doesn't return any error.
Then I try to start solr with the following command:
sudo service jetty start
But I receive the following error:
* Starting Jetty servlet engine. jetty
* Jetty servlet engine started, reachable on http://host-solr-3694477:8983/. jetty
...fail!
In the log file of jetty I get the following message:
failed setting default capabilities.
set_caps(CAPS) failed for user 'jetty'
Service exit with a return value of 4
How can I resolve this issue?
To resolve the problem I had to change the user that run jetty from jetty to root.
This can be configured by editing the /etc/default/jetty file.
I think it is not the more correct solution because it can add security problems. If anyone have a better solution ...
Docker user here, same problem, but - this worked for me (and this is as unadvised as changing the user to 'root', suggested above):
https://docs.docker.com/engine/reference/run/#/runtime-privilege-and-linux-capabilities
Set the following on your 'docker run' command when creating a container:
--privileged=true
I'm just using docker for development, so not overly concerned yet with the security implications of this.

Solr: 404 error with getting admin page

I've installed Solr on my Ubuntu to this path
/opt/solr/solr-4.10.2
After installing I started Solr:
sudo bin/solr start from /opt/solr/solr-4.10.2 directory
As I can understand it started successfully
Waiting to see Solr listening on port 8983 [/]
Started Solr server on port 8983 (pid=8385). Happy searching!
But when I try to get to admin page
http://localhost:8983/solr
I got 404 error:
HTTP ERROR: 404
Problem accessing /solr. Reason:
Not Found
Powered by Jetty://
Do you have any suggestion what's going wrong and where to look in order to fix this problem?
Since this error can be caused by a lot of things, you need to access the log file and debug the execution.
First of all, open your Node log file, located in /opt/solr/solr-4.10.2/node1/log and look for something weird (Shift+F for Errors).
Generally, this error occurs when you have a mismatch between the Solr required Java JDK and your current Java JDK.
When I had this problem, I found in the log file the following error message java.lang.UnsupportedClassVersionError: org/apache/solr/servlet/SolrDispatchFilter : Unsupported major.minor version 51.0 and realized the problem was the java version.
To solve this, try to change the current JDK, using the command sudo update-alternatives --config javac.
If the error still occurs, try to uninstall all unused JDK's, because Solr is getting the wrong path.
The final solution to this issue is to open the file /opt/solr/solr-4.10.2/solar.in.sh and edit the SOLR_JAVA_HOME, writing the right JDK path (e.g /usr/lib/jvm/java-1.7.0)
Disclosure: the secret is look in the log file and figure out what is causing the issue.
Cheers.
try:
http://localhost:8983/solr/index.html
[solr's web.xml]
<servlet>
<servlet-name>LoadAdminUI</servlet-name>
<servlet-class>org.apache.solr.servlet.LoadAdminUiServlet</servlet-class>

Jenkins - Git client plugin throwing Http-503 error when it is connecting through HTTP proxy

some thing weird thing happened to my Jenkins setup and killing me for whole day to solve the issue.
I have Jenkins job setup which connects to git repository on remote server through Http proxy. Below are the details
Jenkins Version: 1.527
Git client plugin : 1.9.1
Git plugin : 2.2.2
It was working fine for more than a month without any issue. But started giving Http 503 error when it try to pull the latest changes from that repository recently.
Below is the error:
Fetching changes from the remote Git repository
git.exe config remote.origin.url https://<userName>:<Passwd>#<giturl>
Fetching upstream changes from https://<userName>#<giturl>
git.exe --version FATAL: Failed to fetch from https://<userName>#<giturl>
hudson.plugins.git.GitException: Failed to fetch from
https://<userName>#<giturl> at
hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:623) at
hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:855) at
hudson.plugins.git.GitSCM.checkout(GitSCM.java:880) at
hudson.model.AbstractProject.checkout(AbstractProject.java:1408) at
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:676)
at
jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
at
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:581)
at hudson.model.Run.execute(Run.java:1597) at
hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at
hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:247) Caused by:
hudson.plugins.git.GitException: Failed to connect to
https://<userName>#<giturl> (status = 503)
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.checkCredentials(CliGitAPIImpl.java:1978)
After working with my network team, it is a issue with Http Proxy. I was asked to use git:// instead of https:// in the github URL. It works great now.

Resources