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.
benang_at_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_at_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_at_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_at_1e84fc3]) and a
> value of type [com.sun.faces.extensions.avatar.lifecycle.AsyncResponse]
> (value [com.sun.faces.extensions.avatar.lifecycle.AsyncResponse_at_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_at_1e84fc3]) and a
> value of type [com.sun.faces.extensions.avatar.lifecycle.AsyncResponse]
> (value [com.sun.faces.extensions.avatar.lifecycle.AsyncResponse_at_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_at_1e84fc3]) and a
> value of type [com.sun.faces.extensions.avatar.lifecycle.AsyncResponse]
> (value [com.sun.faces.extensions.avatar.lifecycle.AsyncResponse_at_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: benang_at_cs.its.ac.id [mailto:benang_at_cs.its.ac.id]
>>> Sent: woensdag 14 december 2011 9:35
>>> To: users_at_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
Received on 2011-12-14 12:26:12 CET