Nevermind. False alarm. Somehow, somebody (or something) was messing with the firewall. I haven't really looked at the firewall settings at all. And maybe the firewall was off the last time. Maybe it was because of a windows update or something that activated the firewall automatically. Anyway, thanks in advance. Sorry for the inconvenience. I've added the port to the exception and now it's working again.
ben...@cs.its.ac.id wrote: > Yeah, sorry. I know that link. And used to show them to other newbies. I > confess I haven't put the right word or enough information about this one. > I'm actually a SVN user, a mere programmer, who have just been appointed > to set up a SVN server (while also developing the app). Not exactly my > forte and comfort zone and although I've been taught about Computer > Network, I've forgotten about most of them. So, I do apologize. > > Now to elaborate more: > > 1. I can still connect locally (that is the 127.0.0.1). And the webserver > worked just fine locally (weird). > 2. I don't know a little about the XAMPP because it's already installed > there for another programmer's MySQL service, which he himself manage, > before I installed uberSVN. I don't know how he configured his XAMPP's > Apache. While for the SVN itself, I didn't do anything to the > configuration at all. > 3. About the telnet. Well, it hasn't crossed my mind at all. Thanks for > pointing it up. Will try that. > 4. At first, I STFG'ed about my current issue but can only find the ones > using Linux so I only have the faintest idea about where to look for the > windows version. However after reading the manual of uberSVN I finally > know where to look. There are a few of them. error_log, localhost.log, > catalina.log. > > The error_log one doesn't show any error except for this warning: > > [Wed Dec 14 10:40:56 2011] [notice] Parent: Created child process 3332 > httpd.exe: Could not reliably determine the server's fully qualified > domain name, using 192.168.1.116 for ServerName > [Wed Dec 14 10:40:56 2011] [warn] Init: Session Cache is not configured > [hint: SSLSessionCache] > httpd.exe: Could not reliably determine the server's fully qualified > domain name, using 192.168.1.116 for ServerName > > The localhost.log doesn't have anything except the Initializing / > Destroying / Closing the Spring service. > > While the catalina.log only have some errors about the web application so > I don't know whether it was actually the cause or not. > > Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader > clearReferencesJdbc > SEVERE: The web application [/ubersvn] registered the JDBC driver > [org.hsqldb.jdbcDriver] but failed to unregister it when the web > application was stopped. To prevent a memory leak, the JDBC Driver has > been forcibly unregistered. > Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader > clearReferencesThreads > SEVERE: The web application [/ubersvn] appears to have started a thread > named [HSQLDB Timer @111089b] but has failed to stop it. This is very > likely to create a memory leak. > Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader > clearReferencesThreads > SEVERE: The web application [/ubersvn] appears to have started a thread > named [net.sf.ehcache.CacheManager@120d6b7] but has failed to stop it. > This is very likely to create a memory leak. > Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader > clearReferencesThreads > SEVERE: The web application [/ubersvn] appears to have started a thread > named [com.wandisco.ubersvn.entities.LDAPConnectionEntity.data] but has > failed to stop it. This is very likely to create a memory leak. > Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader > clearReferencesThreads > SEVERE: The web application [/ubersvn] appears to have started a thread > named [com.wandisco.ubersvn.entities.ConfigurationEntity.data] but has > failed to stop it. This is very likely to create a memory leak. > Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader > clearReferencesThreads > SEVERE: The web application [/ubersvn] appears to have started a thread > named [com.wandisco.ubersvn.entities.ComponentInstallHistoryEntity.data] > but has failed to stop it. This is very likely to create a memory leak. > Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader > clearReferencesThreads > SEVERE: The web application [/ubersvn] appears to have started a thread > named [com.wandisco.ubersvn.entities.FeedEntity.data] but has failed to > stop it. This is very likely to create a memory leak. > Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader > clearReferencesThreads > SEVERE: The web application [/ubersvn] appears to have started a thread > named [com.wandisco.ubersvn.entities.PermissionEntity.data] but has failed > to stop it. This is very likely to create a memory leak. > Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader > clearReferencesThreads > SEVERE: The web application [/ubersvn] appears to have started a thread > named [com.wandisco.ubersvn.entities.RepositoryEntity.data] but has failed > to stop it. This is very likely to create a memory leak. > Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader > clearReferencesThreads > SEVERE: The web application [/ubersvn] appears to have started a thread > named [com.wandisco.ubersvn.entities.JenkinsEntity.data] but has failed to > stop it. This is very likely to create a memory leak. > Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader > clearReferencesThreads > SEVERE: The web application [/ubersvn] appears to have started a thread > named [com.wandisco.ubersvn.entities.FeedCommentEntity.data] but has > failed to stop it. This is very likely to create a memory leak. > Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader > clearReferencesThreads > SEVERE: The web application [/ubersvn] appears to have started a thread > named [com.wandisco.ubersvn.entities.FeedTagEntity.data] but has failed to > stop it. This is very likely to create a memory leak. > Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader > clearReferencesThreads > SEVERE: The web application [/ubersvn] appears to have started a thread > named [com.wandisco.ubersvn.entities.TeamEntity.data] but has failed to > stop it. This is very likely to create a memory leak. > Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader > clearReferencesThreads > SEVERE: The web application [/ubersvn] appears to have started a thread > named [com.wandisco.ubersvn.entities.RepositorySizeHistoryEntity.data] but > has failed to stop it. This is very likely to create a memory leak. > Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader > clearReferencesThreads > SEVERE: The web application [/ubersvn] appears to have started a thread > named [com.wandisco.ubersvn.entities.QuicklinkEntity.data] but has failed > to stop it. This is very likely to create a memory leak. > Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader > clearReferencesThreads > SEVERE: The web application [/ubersvn] appears to have started a thread > named [com.wandisco.ubersvn.entities.ExtensionEntity.data] but has failed > to stop it. This is very likely to create a memory leak. > Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader > clearReferencesThreads > SEVERE: The web application [/ubersvn] appears to have started a thread > named [com.wandisco.ubersvn.entities.PackageEntity.data] but has failed to > stop it. This is very likely to create a memory leak. > Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader > clearReferencesThreads > SEVERE: The web application [/ubersvn] appears to have started a thread > named [org.hibernate.cache.UpdateTimestampsCache.data] but has failed to > stop it. This is very likely to create a memory leak. > Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader > clearReferencesThreads > SEVERE: The web application [/ubersvn] appears to have started a thread > named [org.hibernate.cache.StandardQueryCache.data] but has failed to stop > it. This is very likely to create a memory leak. > Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader > clearReferencesThreads > SEVERE: The web application [/ubersvn] appears to have started a thread > named [change-binaries-processor] but has failed to stop it. This is very > likely to create a memory leak. > Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader > clearReferencesThreads > SEVERE: The web application [/ubersvn] appears to have started a thread > named [AWT-Windows] but has failed to stop it. This is very likely to > create a memory leak. > Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader > clearThreadLocalMap > SEVERE: The web application [/ubersvn] created a ThreadLocal with key of > type [com.sun.faces.util.Util$1] (value > [com.sun.faces.util.Util$1@1117854]) and a value of type > [java.util.HashMap] (value [{com.sun.faces.patternCache={ = }}]) but > failed to remove it when the web application was stopped. This is very > likely to create a memory leak. > Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader > clearThreadLocalMap > SEVERE: The web application [/ubersvn] created a ThreadLocal with key of > type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@1e84fc3]) and a > value of type [com.sun.faces.extensions.avatar.lifecycle.AsyncResponse] > (value [com.sun.faces.extensions.avatar.lifecycle.AsyncResponse@ccb016]) > but failed to remove it when the web application was stopped. This is very > likely to create a memory leak. > Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader > clearThreadLocalMap > SEVERE: The web application [/ubersvn] created a ThreadLocal with key of > type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@1e84fc3]) and a > value of type [com.sun.faces.extensions.avatar.lifecycle.AsyncResponse] > (value [com.sun.faces.extensions.avatar.lifecycle.AsyncResponse@3ca80d]) > but failed to remove it when the web application was stopped. This is very > likely to create a memory leak. > Dec 14, 2011 10:40:22 AM org.apache.catalina.loader.WebappClassLoader > clearThreadLocalMap > SEVERE: The web application [/ubersvn] created a ThreadLocal with key of > type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@1e84fc3]) and a > value of type [com.sun.faces.extensions.avatar.lifecycle.AsyncResponse] > (value [com.sun.faces.extensions.avatar.lifecycle.AsyncResponse@1b43378]) > but failed to remove it when the web application was stopped. This is very > likely to create a memory leak. > > I hope this can give you more information about the issue. > > Mertens, Bram wrote: >>> >> >> >> Mazda Motor Logistics Europe NV, Blaasveldstraat 162, B-2830 Willebroek >> VAT BE 0406.024.281, RPR Mechelen, ING 310-0092504-52, IBAN : BE64 3100 >> 0925 0452, SWIFT : BBRUBEBB >> >> -----Original Message----- >>> From: ben...@cs.its.ac.id [mailto:ben...@cs.its.ac.id] >>> Sent: woensdag 14 december 2011 9:35 >>> To: users@subversion.apache.org >>> Subject: Commit failed because I couldn't connect. >>> >>> Hi, I'm a new member in the maillist. Nice to meet all of you. Now, for >>> my >>> question. This is my current system: >>> >>> The SVN-client: windows xp pro + Tortoise SVN 1.6.16, Build 21511 >>> The SVN-server: windows xp pro + WANDisco uberSVN 11.10 beta + SVN >>> 1.6.17 >>> + XAMPP 1.7.4 >>> >>> The SVN worked for a few weeks, but today it doesn't. This is the >>> message >>> from tortoise: >>> >>> Commit failed (details follow): >>> OPTIONS of 'http://192.168.1.116:9880/NSsFS-2D-RBU/trunk': could not >>> connect to >>> server (http://192.168.1.116:9880) >>> >>> >>> I've tried to browse the link from a browser and it also didn't work. >>> So >>> I >>> guess the problem is at the apache server or so. My assumption is the >>> apache from uberSVN and XAMPP clashed. How do I solve this? Thanks a >>> lot >>> in advance. >> >> Welcome to the list. >> >> Don't take this wrong, it is meant to help you, but please read >> http://catb.org/~esr/faqs/smart-questions.html . >> >> Basically you are asking someone else to do your job by saying "it >> doesn't >> work" and expecting someone else to take your hand and walk you through >> it. >> >> A lot of people on this list are very helpful but you need to show you >> at >> least tried to solve it and ask specific questions. >> >> For example: how did you come to the assumption that uberSVN and XAMPP >> clash? If it worked for a few weeks, the config seems to at least work. >> What changed? >> >> What happened? What do the log files say? >> Have you tried to telnet to port 9880 on 192.168.1.116? >> Can you connect to the SVN repo on that server locally (that "sweet >> 127.0.0.1" in your signature)? >> >> In basic troubleshooting you start with as few components as possible: >> just SVN, no remote connection, no tortoise, no web server. >> Then you test by adding one component at a time. >> And check the log files. >> >> Regards >> >> Bram >> > > > Fare thee well, > Bawenang R. P. P. > > ---------------- > "127.0.0.1 sweet 127.0.0.1. There's no place like 127.0.0.1." > > > -- > > http://www.its.ac.id > > -- > > http://www.its.ac.id > Fare thee well, Bawenang R. P. P. ---------------- "127.0.0.1 sweet 127.0.0.1. There's no place like 127.0.0.1." -- http://www.its.ac.id