I disabled some plugins to upgrade Jira. The upgrade was not carried out as new version of Jira needs 64 bit hardware. Upon stopping and restarting the instance to resume with original application, I get this message:
The following plugins are required by JIRA, but have not been started:
FishEye Plugin (com.atlassian.jirafisheyeplugin)
catalina.out:
***********************************************************************************************************************
The following plugins are required by JIRA, but have not been started: FishEye Plugin (com.atlassian.jirafisheyeplugin)
***********************************************************************************************************************
2011-08-04 16:08:51,896 main FATAL [atlassian.jira.upgrade.UpgradeLauncher] Skipping, JIRA is locked.
2011-08-04 16:08:51,896 main INFO [atlassian.jira.scheduler.JiraSchedulerLauncher] JIRA Scheduler not started: JIR startup checklist failed.
2011-08-04 16:08:52,219 main FATAL [jira.web.dispatcher.JiraWebworkActionDispatcher]
******************************************
JIRA startup failed, JIRA has been locked.
******************************************
Aug 4, 2011 4:08:52 PM org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8080
Aug 4, 2011 4:08:52 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 62989 ms
Does anyone have a clue as to how to re-enable fisheye plugin manually?
Any help greatly appreciated, thanks to all SO`ers.
This also happens when the update is succesfull and you've deactivates FishEye before. Sad.
There's an article in Atlassian's documentation at http://confluence.atlassian.com/display/JIRA/How+to+Enable+the+FishEye+Plugin+from+the+Plugin+Administration+Screen, but this doesn't work for me (note that the plugin name is written wrong there, too).
Any other hints?
Related
I created a build system on windows 2019 server where I installed Jenkins version 2.375.1 and which is running Java 17. I am completely new in this and doing it for first time.
Here is the issue: Whenever I run any job, sometime s(4-6 out of 10) it fails by throwing an exception. See below :
java.nio.channels.ClosedChannelException
at jenkins.agents.WebSocketAgents$Session.closed(WebSocketAgents.java:153)
at jenkins.websocket.WebSockets$1.onWebSocketClose(WebSockets.java:80)
at jenkins.websocket.Jetty10Provider$2.onWebSocketClose(Jetty10Provider.java:149)
at org.eclipse.jetty.websocket.common.JettyWebSocketFrameHandler.notifyOnClose(JettyWebSocketFrameHandler.java:308)
at org.eclipse.jetty.websocket.common.JettyWebSocketFrameHandler.onClosed(JettyWebSocketFrameHandler.java:292)
at org.eclipse.jetty.websocket.core.internal.WebSocketCoreSession.lambda$closeConnection$0(WebSocketCoreSession.java:272)
at org.eclipse.jetty.server.handler.ContextHandler.handle(ContextHandler.java:1450)
at org.eclipse.jetty.server.handler.ContextHandler.handle(ContextHandler.java:1487)
at org.eclipse.jetty.websocket.core.server.internal.AbstractHandshaker$1.handle(AbstractHandshaker.java:212)
at org.eclipse.jetty.websocket.core.internal.WebSocketCoreSession.lambda$closeConnection$1(WebSocketCoreSession.java:272)
at org.eclipse.jetty.util.Callback$4.completed(Callback.java:184)
at org.eclipse.jetty.util.Callback$Completing.succeeded(Callback.java:344)
at org.eclipse.jetty.websocket.common.JettyWebSocketFrameHandler.onError(JettyWebSocketFrameHandler.java:268)
at org.eclipse.jetty.websocket.core.internal.WebSocketCoreSession.lambda$closeConnection$2(WebSocketCoreSession.java:284)
at org.eclipse.jetty.server.handler.ContextHandler.handle(ContextHandler.java:1468)
at org.eclipse.jetty.server.handler.ContextHandler.handle(ContextHandler.java:1487)
............
............
............
And the log I got in node machine on console is :
INFO: Connected
Jan 15, 2023 8:05:02 AM hudson.remoting.UserRequest perform
WARNING: LinkageError while performing
UserRequest:hudson.node_monitors.SwapSpaceMonitor$MonitorTask#4c55cc1c
java.lang.UnsatisfiedLinkError: C:\Users\test*****\AppData\Local\Temp\jna--202642030\jna2121667260400486382.dll: A dynamic link library (DLL) initialization routine failed
at java.base/jdk.internal.loader.NativeLibraries.load(Native Method)
at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:388)
at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:232)
at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:174)
at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2389)
at java.base/java.lang.Runtime.load0(Runtime.java:755)
at java.base/java.lang.System.load(System.java:1953)
at com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:1045)
at com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:1015)
at com.sun.jna.Native.<clinit>(Native.java:221)
at com.sun.jna.Structure.setAlignType(Structure.java:291)
at com.sun.jna.Structure.<init>(Structure.java:208)
at com.sun.jna.Structure.<init>(Structure.java:204)
at com.sun.jna.Structure.<init>(Structure.java:191)
at com.sun.jna.Structure.<init>(Structure.java:183)
at org.jvnet.hudson.Windows$MEMORYSTATUSEX.<init>(Windows.java:67)
Some more info about configuration :
Both controller and node machine is windows server 2019
Since in latest Jenkins the java web connect(Run Jenkins as service on node) is not available so directly running the agent command in node's CLI.
Both controller and node is running Java v17
I went through couple of links and tried all the possible suggestion provided like power management settings on salve machine, increasing Jenkins build timeout settings etc... but no luck.
Any help on this is highly appreciated.
Thanks.
Not sure if there is a bug in Jenkins itself or something. I could not find the answer of the exact issue but after making some changes in jenkins configuration, now i am able to run all the jobs without getting above exception.
Here it is : Earlier i checked jenkins to use websocket in slave configuration. If i just disable it and run then not getting any issue.
Just disbaling this worked for me.. Thanks.
I have restored config in Jenkins using ThinBackup plugin (https://wiki.jenkins-ci.org/display/JENKINS/thinBackup)
Intermittently proxy stops working after restarts and I get this warning in logs:
Jul 23, 2014 11:02:04 AM hudson.diagnosis.ReverseProxySetupMonitor getTestForReverseProxySetup
WARNING: http://hostBB.com:8080/manage vs. http://hostAA.com:8080/manage
hostBB is where I imported the full backup made on hostAA.
How do I fix this?
I run an app using embedded container using grails run-app -Dgrails.env=myenv and it works fine. I then do grails war -Dgrails.env=myenv deploy it on a Tomcat 6 server and it doesn't work. I get a bunch of log4J errors that go away once I add log4j jars to Tomcat lib's directory. The lo4j errors now go away. I am left with:
INFO: Deploying web application archive qkr2.war
Sep 7, 2013 11:09:54 PM org.apache.catalina.core.StandardContext start
SEVERE: Error listenerStart
Sep 7, 2013 11:09:54 PM org.apache.catalina.core.StandardContext start
SEVERE: Context [/mk2] startup failed due to previous errors
But there are no previous errors. So I haven't a clue what could be wrong.
Or what to do next. Any tips?
Thanks
According to http://grails.org/doc/latest/ref/Command%20Line/war.html, the environment comes BEFORE the "war" part of the command, so that could be it. i.e. the command should read:
grails -Dgrails.env=myenv war
Check the logging to see what environment grails thinks it's starting under. Otherwise, I'd try adding the environment variable at Tomcat startup, rather than building different wars for different environments.
This all presumes that the logging config is correct in this myenv environment. If not, then I can't tell you why it's not starting without more of the logging available.
When you see "SEVERE: Error listenerStart" deploying to Tomcat, look at the log files. In general you'll find that the error is in stacktrace.log or localhost.2013-09-07.log (the date part of the file name may be different of course).
I work on a 4 person development team using IntelliJ, but for some reason only one the team members can successfully build a WAR file and deploy. All other members will receive the following error:
Aug 17, 2012 2:14:31 PM org.apache.catalina.core.StandardContext start
SEVERE: Error listenerStart
Aug 17, 2012 2:14:31 PM org.apache.catalina.core.StandardContext start
SEVERE: Context [/xxx] startup failed due to previous errors
2012-08-17 14:14:40,171 [http-8080-1] ERROR context.ContextLoader - Context initialization failed
java.lang.NoSuchMethodError: org.springframework.web.context.support.XmlWebApplicationContext.getEnvironment()Lorg/springframework/core/env/ConfigurableEnvironm
ent;
From everything I've researched, this is caused by a version conflict in the Spring Framework, but for the life of me I can't seem to resolve the issue.
Has anyone ever run into this issue? And how can I resolve it?
Modify your catalina.sh/catalina.bat such that you launch java using the -verbose:class flag. It will produce a lot of output, but you should be able to see which JAR file you're loading org.springframework.web.context.support.XmlWebApplicationContext from and chances are it's not the same version that your version of Grails is using. Remove the bad version from your classpath and hopefully you'll be good to go.
When saving a CMS block in Magento 1.4.1, I am getting an error, connection reinitalized by my web browser. I only get this this error, when adding the tags <script></script>. Any other changes I can save and I can add new blocks as long as I don't use <script></script>
The only error I'm seeing is in /var/www/website/var/log/exception is this and only if I hit F5 after getting the connection reinitalized error. Apache and other system logs are not reporting any additional errors.
2012-07-06T08:47:22+00:00 DEBUG (7): HEADERS ALREADY SENT: <pre>[0]
/var/www/vhosts/site/app/code/core/Mage/Core/Controller/Response/Http.php:44
[1] /var/www/vhosts/site/lib/Zend/Controller/Response/Abstract.php:727
[2] /var/www/vhosts/site/app/code/core/Mage/Core/Controller/Response/Http.php:75
[3] /var/www/vhosts/site/app/code/core/Mage/Core/Controller/Varien/Front.php:188
[4] /var/www/vhosts/site/app/code/core/Mage/Core/Model/App.php:304
[5] /var/www/vhosts/site/app/Mage.php:596
[6] /var/www/vhosts/site/index.php:78
This website was working fine on a Centos 5.4 with PHP 5.2.13. All the same Apache and PHP modules were installed on the new Debian server. Any help would be sincerely appreciated.
Version Information
Magento 1.4.1
Debian 6.0 i386
PHP 5.3.3-7+squeeze13 with Suhosin-Patch (cli) (built: Jun 10 2012 09:35:18)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
with the ionCube PHP Loader v4.0.7, Copyright (c) 2002-2011, by ionCube Ltd.
Server version: Apache/2.2.16 (Debian)
Server built: Apr 1 2012 06:40:08
A rule in our Netasq firewall was blocking the <SCRIPT> tag. Once we disabled the rule, the client was able to use the tag again. We did warn him, however, that netasq probably put that rule their for a very good reason.