I'm trying to do Server Performance Testing in Jmeter - 5.4.2 via PerfMon - 2.3. But when I try to run the bat file of startAgent - 2.2.3 it just opens for one moment and them closes (Note that I've JRE version 1.8 installed). When I tried to open the file via cmd directory command it's giving me the following error:
`ERROR: java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
I've tried to install the 2.2 version of startAgent.
I've tried to put the startAgent in the same directory as JMeter.
I've tried start it by disabling Firewall and Anti-Virus.
But nothing is working. I tried to do some related research regarding this error but there isn't many solution that I have found to be useful.
I was facing same issue when I tried unzipping the server-agent folder elsewhere so I unzipped it in a folder in C drive (C:\Jmeter) and it worked for me.
I have XAMPP installed on Windows 7 virtual machine. My old PHP version was 7.0.9 with Apache 2.4
I needed to upgrade the PHP version to 7.1.x and I set out reading about how to best to this. In end, I settled with the simple plan:
Stop Apache service
Downloaded new PHP version from official php website. For PHP 7 the 7.1.17 version was listed. I downloaded the thread safe version, as my Apache has thread safety enabled.
I extracted the contents of the downloaded archive to a folder.
I copied and replaced all files in the appropriate folders from C:/Server/php with the new php version files from the extracted archive.
I attempted to start Apache from the XAMPP control panel and the server will not start.
The message "Attempting to start Apache service..." just hangs and nothing happens.
The last entry in the error.log file in C:\Server\apache\logs shows the event when the server was stopped and that's it.
When I check the php version from CLI with the command php -v, the console returns installed php version 7.1.17
I tried different suggestions I read from similar questions, like changing ServerName localhost:80 to ServerName localhost:8080 and copying php7apache2.dll to apache/bin ( as suggested here: Upgrading PHP in XAMPP for Windows? ), alas the issue is not fixed and Apache does not start.
Of course, I also restarted the virtual machine, all the same.
At this point, I'm dumbfounded. Don't know what to do.
I need to get Apache running with php 7.1, as it is required by Magento 2.2.4. I do not want to reinstall XAMPP, as this will be a lenghty process with a lot of risk for more things to go wrong.
Any help is much appreciated!
Alright, so after checking Windows Logs > Application in Event Viewer I saw the error ".. the Apache service named is not a valid win32 application". I downloaded the x86 version of PHP from official website PHP for Windows
Then copied and replaced files as described above, and Apache started successfully.
To see if your Apache version is x64 or x86 open command prompt and cd to your Apache bin directory, in my case C:/Server/apache/bin , then run:
file httpd
A penetration test has recently identified that one of our RHEL(6.7) servers running Apache 2.2.15 is vulnerable on a number of points and needs to be updated to the latest version 2.4. I have run yum update and it says that there are no packages marked for update. I understand that I will need to download the updates manually. There are a few questions I have around the requirement to upgrade Apache.
I am up to date on the 2.2 version tree. Does this mean that any security patches made to version 2.4 will be back patched to version 2.2.X as well?
I am running PHP (version 5.3.3) and MySQL (version 5.1.73) - will these be affected by upgrading the Apache version (Google tells me that there is no problem on both fronts - but I thought I'd ask before I started down this route).
If you experts tell me that I have no other choice but to upgrade, then I'm planning on using the instruction set here: https://unix.stackexchange.com/questions/138899/centos-install-using-yum-apache-2-4
Thank you in advance for your advice.
You could download the 2.4 source code from the Apache site and compile it. There's a setting which will configure for RedHat:
--enable-layout=RedHat
This setting will configure the paths for executables, configuration files, libraries etc in one go.
The following should be a reasonable starting point for a configuration line:
sh ./configure --enable-layout=RedHat --enable-mods-shared=all
then perform a make and make install
Do the same with a newer version of PHP (5.3.29 is available in the "old downloads" section, but try a newer version. Check the changes first though) and your problems should be lessened. Finally, MySQL or MariaDB is available for download and compilation too
Obviously, try all of this on a test machine first and back everything up. Your test machine should be as close as possible to your production machine. If you use something like VirtualBox to try it, you can take a snapshot at each point of the process and rollback if something goes wrong
I've created an SVN repo on my Debian Wheezy build server following this tutorial.
svn --version gives 1.6.17.
Sadly, I can't commit anymore to the repo from my Windows 7 machine; it fails with the following error message:
Transmitting file data .svn: E730054: Commit failed (details follow):
svn: E730054: Error running context: An existing connection was forcibly closed
by the remote host.
I have had this error both with TortoiseSVN and the command line client.
These are the contents of /var/log/apache2/access.log on the server for the time of the failed commit: access.log.
There is no entry for the same time in the error log.
I'm still able to check out the contents of the repo and svn info http://myurl/svn/myrepo works also fine.
The Debian server with the repo is running inside a VM on a Windows Server 2008 R2 (Hyper-V-Manager 6.1). The connection from my Windows machine to the Windows Server is established using FortiClient 4.2.8.0307.
After I ran into this error yesterday, I purged svn from the server and setup the repo again. This made the repo accept commits for a couple of hours until it failed again with the same error.
Currently commits work again with TortoiseSVN but fail with the command line client.
What does E730054 mean and how can I fix it for good?
I have upgraded to Jessie in the meantime, but the situation did not improve. Commits with Tortoise stopped working again, meaning that it hangs at the "Sending Content" action for about five minutes and then prints the error that's in the title.
Checkouts still work without a hitch, though.
apache2 -v:
Server version: Apache/2.4.9 (Debian)
Server build: Mar 29 2014 21:52:01
svn --version:
svn, version 1.8.8 (r1568071)
compiled Apr 1 2014, 03:41:42 on i486-pc-Linux-GNU
Here's a thread that discusses the error, but I could not conclude a solution for my problem from it.
I noticed that the problem occurs when I want to commit the second modification of a file.
My fix
The issue went away permanently after using svnserve instead of apache2. This tutorial helped me set it up.
I had this problem with a single file while attempting to check in multiple files using Tortoise SVN on Windows 7 x64. Several attempts to commit the file using a variety of different versions of Tortoise SVN and the command-line version of SVN failed.
At the time, my laptop was using my home ISP internet connection. When I later went to work and attempted to commit the failing file from my employer's network, the file was committed without a problem.
I don't know why that was the case, but if you encounter this problem and find your way to this answer through a search engine query, you may want to try again – using a different internet connection. While not a solution to the problem, it may provide a temporary work-around.
As I was reading over the thread, it seems like some problems in the WEBDAV implementation on client site crashing the apache-thread. I had other issues with pre 1.8 repositories and I solved most of them by dump/reload the whole repository into a new one (using "svnadmin upgrade" is not sufficient!). Pre 1.8 repos have sometimes "corrupt/obsolete" data in revision files which is ignored by clients. It seems that this could cause the segfault.
You can dump/reload your repository like this:
svnadmin create newrepos
svnadmin dump oldrepos | svnadmin load newrepos
Note that it could take a tremendous amount of time to perform an update/reload cycle (approx. 1GB/h +- 50% depending mostly on disk speed).
If you have a different time, please post your time, I am doing a private research of dump/reload cycle performances.
I was getting this error.
Error running context: An existing connection was forcibly closed by the remote
I solved this issue by switching the proxy to Cntlm and it works perfectly fine.
I am using TortoiseSVN 1.9.3 version.
I was getting this error.
Error: An existing connection was forcibly closed by the remote
I am using the TortoiseSVN 1.11 version.
I am using checkpoint VPN, I simply restart my VPN connection
I too faced the similar issue.
SVN details: TortoiseSVN 1.12.0, Build 28568 - 64 Bit
Solution: Go to task manager and search for Tortoise SVN cache service, end this task and retry to update/commit the changes.
Hade same error.
My problem was with Avast antivirus, when i put the url of the svn server in the exclutions the problem was solved.
I met this problem after our svn server migrated from lan to internet. At last, I solve this problem by changing my IP Address.
For Example: from 192.168.0.60 to 192.168.0.71.
SVN Version: TortoiseSVN 1.9.7, Build 27907 - 64 Bit
OS Version: Windows 10, 1703
I too had this issue in SVN client. I cleared the temp folders in windows. Then cleared all data including auth details from "saved data" in SVN settings. Then retried in SVN, it asked for authentication and it opened fine without any error.
I had the same issue when using VPN with CollabNet's SubversionEdge.
I simply enabled Subversion Server should serve via https in Configuration -> Server Settings and this solved the issue for me.
I solved this for myself by using Eclipse to commit (I guess that's Subclipse then) instead of Tortoise 1.8.11
I didn't try too many of the other answers first but I did reboot, try diff internet connections, and I tried end tasking the TSVN Cache service. None of those worked and didn't get around to trying others. I also tried deleting the entire folder locally, did SVN checkout and applied the exact same changes (merged in a few commits from trunk) and tried committing... still wouldn't work with Tortoise SVN but then I tried Eclipse and it worked immediately.
My next commit worked perfectly fine with Tortoise SVN. Not sure what the cause was.
Is there a guide on how to do this easily? I want to upgrade it without losing all the configuration settings etc. Is there a particular method to achieve this (or config files that I can just copy to the new installation). I'm running it as a windows service at the moment so the new version will need to run in the same way too.
Thanks.
There isn't an upgrade script that will do it for you, at least not that I've ever used/found. Which, is actually a good thing, IMO. You can simply download the newer Tomcat version to a different directory than your current install (c:/tomcat55 and c:/tomcat6) and copy the configuration from you 5.5 installation. Nearly all of the basic settings are the same from 5.5 to 6.0.x, not as sure about 7.0. If you install the new service with a different service name, you don't have to worry about any conflicts (except the ports in your server.xml)
If this is a production box, I would recommend changing the ports on your new installation so you can run it alongside your current install, and test your applications before you switch over. If all is OK, you can shutdown your new Tomcat, update the ports to be what your current install is, shutdown Tomcat5.5, and start your new install and you should be good. Of course you can always run the new install on the different port, but if you're using Apache in front, you'll have to update the Apache config as well.
Hope this helps.