[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Commit failed because I couldn't connect.

From: <benang_at_cs.its.ac.id>
Date: Wed, 14 Dec 2011 16:58:16 +0700 (WIT)

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 
Received on 2011-12-14 11:03:33 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.