I'm building a Netbeans platform maven application but it seams that the repository that hosts Netbeans modules is down or something.
<repository>
<id>netbeans</id>
<name>NetBeans</name>
<url>http://bits.netbeans.org/nexus/content/groups/netbeans/</url>
</repository>
I'm getting this error when I try to build the project.
Apr 04, 2016 10:22:37 AM org.apache.maven.wagon.providers.http.httpclient.impl.client.DefaultHttpClient tryExecute
INFO: I/O exception (java.net.SocketException) caught when processing request: Connection reset
Apr 04, 2016 10:22:37 AM org.apache.maven.wagon.providers.http.httpclient.impl.client.DefaultHttpClient tryExecute
INFO: Retrying request
as for today 20/04/2016 it shows this error
An error occurred.
Sorry, the page you are looking for is currently unavailable. Please
try again later.
If you are the system administrator of this resource then you should
check the error log for details.
Faithfully yours, nginx.
I can confirm it has been down for the past few days as well. However, I've been using http://repo.spring.io/libs-release-remote/ as it has the netbeans-platform artifacts that I need.
I confirm it's not working for me either (2016-04-20). It was working yesterday (2016-04-19).
Nginx replies with an error:
An error occurred.
Sorry, the page you are looking for is currently unavailable. Please
try again later.
If you are the system administrator of this resource then you should
check the error log for details.
Faithfully yours, nginx.
Related
I'm kind of stuck troubleshooting an issue.
During a Jenkins build I see the following error:
Exception in thread "main" java.io.IOException: Server returned HTTP response code: 403 for URL: http://services.gradle.org/distributions/gradle-1.7-bin.zip
This also happens when I run ./gradlew clena build in my project in localhost (no VPN, etc)
It does NOT happen when I paste the binary URL into my browser (so that old gradle version does exist)
Binary referenced in gradel-wrapper.properties:
distributionUrl=http\://services.gradle.org/distributions/gradle-1.7-bin.zip
Any ideas?
Comments have pointed you to answer, but to clarify with more information and references.
Gradle announced on October 17, 2019, that starting on Janurary 2020, all Gradle services will no longer serve requests made with HTTP.
The URL you have specified for in gradle-wrapper.properties is for HTTP, switch to the HTTPS URL and it should work.
Reference: https://blog.gradle.org/decommissioning-http
I'm working on a fresh installation of stock DSpace 5.3 (Windows Server 2012, Tomcat 8.0, Maven 3.2.5, Ant 1.9.6). This particular instance will be a dark archive without Google Analytics enabled; we don't currently have a GA account or analytics key, although we plan to register one eventually for a separate public-facing instance.
As per the problem described in JIRA ticket DS-2718, DSpace hangs with the following message in dspace.log when I attempt to download a bitstream:
2015-10-20 09:52:02,324 INFO org.apache.http.impl.execchain.RetryExec
# I/O exception (java.net.SocketException) caught when processing
request to {s}->https://www.google-analytics.com:443: Network is
unreachable: connect
2015-10-20 09:52:02,324 INFO org.apache.http.impl.execchain.RetryExec
# Retrying request to {s}->https://www.google-analytics.com:443
Since we won't be using GA on this instance, disabling it in Spring is a good workaround until the issue is resolved. As per the instructions, I commented out the Google Analytics entry in dspace-5.3-src-release\dspace-xmlui\src\main\webapp\WEB-INF\spring\applicationContext.xml, disabled Tomcat and rebuilt DSpace. An initial attempt running mvn package -Dmirage2.on=true still produced the problem, so I tried a "ground up" rebuild:
cd d:\dspace-5.3-src-release\dspace
mvn clean package -U -Dmirage2.on=true
[successful build]
cd d:\dspace-5.3-src-release\dspace\target\dspace-installer
ant update
[successful update]
[copy webapps to Tomcat 8.0\webapps and start Tomcat]
Even after the rebuild, however, I'm still getting the same error, with the same java.net.SocketException in dspace.log.
Not sure why this isn't working. Have I missed a step or setting in the rebuild process so that the change to applicationContext.xml isn't being applied?
FWIW, I tried grepping for "google" in dspace-5.3-src-release\dspace-xmlui-mirage2 to see if this could be a Mirage 2 problem, but I don't see anything that looks relevant.
This isn't an answer to why you're still seeing the SocketException, but the real fix for the problem you're describing is to remove the default GA key from dspace-services/src/main/resources/config/dspace-defaults.cfg, see https://github.com/DSpace/DSpace/commit/5b84fef1ad789443d06c338558a92f854b20c8ef. Have you tried doing that?
The issue resolved itself after I ran mvn clean -Dmirage2.on=true in both [dspace-src] and [dspace-src]\dspace. I'm guessing that the issue originated on our end due to someone running a maven build from the wrong directory.
I've also removed the default key from dspace-defaults.cfg as suggested. Everything's now working.
The server suddenly stopped to work and on restarting it gave the following error. Couldn't find anything related to this online. Any idea what is wrong and how to resolve this?
org.neo4j.server.logging.Logger log SEVERE:
org.neo4j.server.ServerStartupException: Starting Neo4j Server failed:
Active marked as 1 but no data/graph.db/nioneo_logical.log.1 exist at
org.neo4j.server.AbstractNeoServer.start(AbstractNeoServer.java:218)
at org.neo4j.server.Bootstrapper.start(Bootstrapper.java:87) at
org.neo4j.server.Bootstrapper.main(Bootstrapper.java:50) Caused by:
java.lang.IllegalStateException: Active marked as 1 but no
data/graph.db/nioneo_logical.log.1 exist at
org.neo4j.kernel.impl.transaction.xaframework.XaLogicalLogFiles.determineState(XaLogicalLogFiles.java:138)
at
org.neo4j.kernel.impl.recovery.StoreRecoverer.recoveryNeededAt(StoreRecoverer.java:65)
at
org.neo4j.server.preflight.PerformRecoveryIfNecessary.run(PerformRecoveryIfNecessary.java:56)
at
org.neo4j.server.preflight.PreFlightTasks.run(PreFlightTasks.java:70)
at
org.neo4j.server.AbstractNeoServer.runPreflightTasks(AbstractNeoServer.java:333)
at
org.neo4j.server.AbstractNeoServer.start(AbstractNeoServer.java:152)
... 2 more
Apr 25, 2014 9:13:07 PM org.neo4j.server.logging.Logger log SEVERE:
Failed to start Neo Server on port [7474]
It looks like you've messed up your datastore e.g. by a unclean shutdown. To recover try the following procedure:
IMPORTANT: before doing any manual changes to your graph.db folder, make sure that you have a valid backup copy e.g. by tar -zcf <path>/graph.db.tar.gz data/graph.db.
Check that the backup from 1. is fine.
rm data/graph.db/nioneo_logical.log.active. NB: this operation might be harmful.
try to restart the server
if it comes up, check if the latest changes you did before the DB reached its current state.
Im trying to use jenkins to build and deploy the war file to a tomcat present in different server and im getting the following error -
Deploying /var/lib/jenkins/jobs/ura_Web/workspace/ura-1.0.war to container Tomcat 6.x Remote
ERROR: Publisher hudson.plugins.deploy.DeployPublisher aborted due to exception
org.codehaus.cargo.container.ContainerException: Failed to redeploy [/var/lib/jenkins/jobs/ura_Web/workspace/ura-1.0.war]
at org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.redeploy(AbstractTomcatManagerDeployer.java:195)
at hudson.plugins.deploy.CargoContainerAdapter.deploy(CargoContainerAdapter.java:64)
at hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:90)
at hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:77)
at hudson.FilePath.act(FilePath.java:905)
at hudson.FilePath.act(FilePath.java:878)
at hudson.plugins.deploy.CargoContainerAdapter.redeploy(CargoContainerAdapter.java:77)
at hudson.plugins.deploy.DeployPublisher.perform(DeployPublisher.java:47)
at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:804)
at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:776)
at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.post2(MavenModuleSetBuild.java:969)
at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:726)
at hudson.model.Run.execute(Run.java:1618)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:491)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:247)
Caused by: java.io.FileNotFoundException: http://192.168.2.X/manager/list
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1401)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.invoke(TomcatManager.java:504)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.list(TomcatManager.java:622)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.getStatus(TomcatManager.java:635)
at org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.redeploy(AbstractTomcatManagerDeployer.java:176)
... 16 more </code>
Can anyone tell me what is wrong?
I had exactly this problem just now and still have not solved it. However, I suspect it is happening because of proxy issues.
Is it possible to try setting the manager URL to http://localhost
rather than http://192.168.2.X? This worked for me, showing that the credentials were at least correct and the module functions. When I switch the manager URL back to a remote machine or the FQDN of the local server, it again failed. This indicates to me something proxy related.
The only trouble then is configuring the proxy settings for Jenkins, especially http.nonProxyHosts. If you can do that maybe you'll have more luck than me. I cannot get the Jenkins System Information proxy values to change no matter what I do!
Also manually test from a browser on both the build server and elsewhere your access to the manager URL: http://192.168.2.X/manager/list
I am trying to deploy my spring application in a server machine which having the tomcat 6.0.29 server. But tomcat server getting stop automatically while extracting the war.
In Catalina Log I have the following:
Jan 27, 2012 3:02:44 AM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive application.war
In localhost.log
Jan 27, 2012 3:03:21 AM org.apache.catalina.core.ApplicationContext log
INFO: Initializing Spring root WebApplicationContext
There is no any stacktrace.
I tried to restart the tomcat but server getting stop while extracting the war file. I tried by increasing the JVM memory to 1024MB. Still same problem.
I have deployed the same war in my another testing server and it is working fine.
Any help...
Are you seeing something like this "SEVERE: Error listenerStart"? or none in the logs.
If Tomcat fails there should be a thread dump and/or a heap dump in the startup directory.
Also check the ports available from OS/firewall to bind with.
Enabling debug logging might help. (Change the log levels to DEBUG instead of INFO in the log files below)
Enabling Tomcat debug log:
Refer to : How to set level logging to DEBUG in Tomcat 6?
Enabling Spring debug log:
You can enable spring debug logging mode (why its failing to deploy the webapp) by adding the logging.properties(name should match exactly) in your WEB-INF/classes directory
Refer to : SEVERE: Error listenerStart
How are you launching Tomcat? What OS is this? I have encountered this problem myself in the past when launching Tomcat on CentOS using a startup script. Usually had something to do with security settings of the files and/or of selinux preventing the writing/reading of certain filespaces on the disk.
Try running from the console using ./catalina.sh run and see if that works on the server (assuming it is a *nix server). If so, check ownership of all files and read/write permissions. Disable selinux (if currently enabled) momentarily to see if that makes any difference.
It's a bunch of trial and error when you don't have any further debug information available.
Last time I faced this problem it was due to the fact I was thinking that I am using h2database while the configurations were such that it was using mysql and of course there was no mysql server to connect to.
I was using a maven project in eclipse and none of my changes were taking effect until I did
Project Properties-> Maven-> Update Project and then in
Servers Tab right click on the server name and Publish.
Check the jdbc.properties file in the webapp (in my case it was somewhere inside /.metadata/.plugins/org.eclipse.wst.server.core/tmp1/wtpwebapps/ folder) not in source code to see what are the final parameters for database connection.