Subsonic Forum

Installation goes OK however when I try to access the main page, which I have set up on an alternate port, all I get is....

Directory: /

The same behavior locally on the server or from a remote workstation.

I believe I'm using Java 1.6.38

The service is started. Did I miss something in the setup somewhere. I had this working fine on WHS2011 with no issues.

Dave

Make sure Java is 1.7 if you are using SS 4.7+, unless you have a special build. Uninstall 1.6 and install 7.

Actually my initial try was with 1.7 and when this happened I thought reverting back to 1.6 was the answer. Any ideas?

SS 4.7 Standard works fine under java 1.6 - Its some of the mods eg Madsonic which require 1.7. (hence special builds)

Did you use the standard windows install?

Check the SS logs (Both the C:\Subsonic & the ones in Program Files) and see if there are any errors shown.

I've installed SS on a Win 8 test box which is the same code base. I plan on doing Essentials 2012 soon but don't see any reason why it would have problems.

If you are now setup in Win Essential 2012. aren't you now on a domain? Did you edit the Subsonic service with valid domain credentials?

Actually by default the local system account is in play but I did create an account for Subsonic use in the domain and made sure full control permissions were in play on the file system. After reviewing all of the logs, I did come across this in the Subsonic agent log...

15 [main] INFO org.springframework.context.support.ClassPathXmlApplicationContext - Refreshing org.springframework.context.support.ClassPathXmlApplicationContext@19c26f5: display name [org.springframework.context.support.ClassPathXmlApplicationContext@19c26f5]; startup date [Tue Jan 22 09:19:30 MST 2013]; root of context hierarchy
78 [main] INFO org.springframework.beans.factory.xml.XmlBeanDefinitionReader - Loading XML bean definitions from class path resource [applicationContext-agent.xml]
484 [main] INFO org.springframework.context.support.ClassPathXmlApplicationContext - Bean factory for application context [org.springframework.context.support.ClassPathXmlApplicationContext@19c26f5]: org.springframework.beans.factory.support.DefaultListableBeanFactory@2a5330
500 [main] INFO org.springframework.beans.factory.support.DefaultListableBeanFactory - Pre-instantiating singletons in org.springframework.beans.factory.support.DefaultListableBeanFactory@2a5330: defining beans [service,agent,frame,settingsPanel,statusPanel]; root of factory hierarchy
Executing: subsonic-service.exe -start
Executing: subsonic-service.exe -stop
38071 [pool-1-thread-2] WARN org.springframework.remoting.rmi.RmiProxyFactoryBean - Could not connect to RMI service [rmi://localhost:9412/SubsonicDeployerService] - retrying
Executing: subsonic-service.exe -start
Executing: subsonic-service.exe -stop
130385 [pool-1-thread-2] WARN org.springframework.remoting.rmi.RmiProxyFactoryBean - Could not connect to RMI service [rmi://localhost:9412/SubsonicDeployerService] - retrying
Executing: subsonic-service.exe -start
26005880 [pool-1-thread-2] WARN org.springframework.remoting.rmi.RmiProxyFactoryBean - Could not connect to RMI service [rmi://localhost:9412/SubsonicDeployerService] - retrying
26027963 [pool-1-thread-1] WARN org.springframework.remoting.rmi.RmiProxyFactoryBean - Could not connect to RMI service [rmi://localhost:9412/SubsonicDeployerService] - retrying

Looks like a Java issue. I'd try an uninstall/reinstall of Java.

OK...and which Java version is recommended with a 4.7 Subsonic release?

I've been using the latest current release on all my installations without any problems.

Ther were some issues with the first releases of Java 7, and to confuse things further users that were installing the war version on Tomcat have to remember to use Tomcat 6 rather than 7. I think that plus the current news hype regarding zero day thereats has created a lot of confusion.

I've just kept using the latest available Jave on my servers without any problems so far. I'd go that route unless there is clear evidence to do otherwise.

It's very common for programmers who have a piece of code that doesn't work to blame their OS, their compiler/JVM, their hardware etc. Guess what? That's normally not the source of the error. I'd place my bet on this not being a Java issue but a rare bug, race condition, network issue etc taking place in the Subsonic / Spring framework code. Blaming Java is very convenient but until you write a test case that reproduces it, I simply don't believe it. This specific error has been reported before but so far, I've unfortunately seen no real solution but only random "try reinstalling this or that". Which sometimes helps, and sometimes not.

Subsonic 4.7 runs equally well on Java 1.6 and 1.7, as far as I know.

hakko wrote:It's very common for programmers who have a piece of code that doesn't work to blame their OS, their compiler/JVM, their hardware etc. Guess what? That's normally not the source of the error. I'd place my bet on this not being a Java issue but a rare bug, race condition, network issue etc taking place in the Subsonic / Spring framework code. Blaming Java is very convenient but until you write a test case that reproduces it, I simply don't believe it. This specific error has been reported before but so far, I've unfortunately seen no real solution but only random "try reinstalling this or that". Which sometimes helps, and sometimes not.

Subsonic 4.7 runs equally well on Java 1.6 and 1.7, as far as I know.

That actually depends on your definition of "source". Let's take a great example with browsers and JS. It is very common to have JS which is perfectly valid and conforming to standards which breaks in one browser or another (typically in IE, but not always) which you can reproduce in a small JSFiddle test case. You can say that the error is "caused" by that specific code all you want, but the fact of the matter is there is not actually anything wrong with the code but with how certain browser's react to it. And of course regardless of what the root issue is, you as a programmer have to fix it anyways.

While it is entirely possible that in this case it is an actual code issue causing a race condition, it is also entirely possible that it is a rare compiler/JVM issue causing the race condition. It is also quite possibly a rare bug caused by the framework Subsonic is using and is triggered by perfectly good and valid code. Of course if there is a way to avoid it, it should be done. I just strongly disagree that it is necessarilly because of something wrong Subsonic is doing.

All that is above my paygrade and I'm glad you guys understand the esoterics involved. For myself and the OP, I think we just want to get what's available up and running.

I have found that most of these issues when I have seen them in my own environment have been due to a lack of patience during the install process, or a problem caused by an improper shutdown of the host, sometimes caused by MS automatic upgrades.

In any event, uninstalling and do a patient clean reinstall of Java and Subsonic will almost always result in getting it running unless there are serious underlying problems with either hardware or the OS on the host machine.

In any case, I'm sure the OP just wants to get his configuration working.

In my experience, just doing the clean reinstall is much easier than trying to decipher the underlying cause and doing all manner of research, googling, and editing to fix the problem. I acknowledge that others have far greater knowledge of all the undelying components than I have, but I've installed SS literally, hundreds of times and have gotten pretty good at getting it running properly in spite of my lack of knowledge with programming, Java, database tech, and whatever else Subsonic depends on. I try to merely present the easiest ways to get going for the typical user based on my experiences.

Many thanks to you guys for providing the more in depth discussions that have helped us gain more insight into the nuts and bolts underneath the surface.

G

You're absolutely right about the browser situation. I don't know if it's fair to compare that to mature technologies as a C compiler or a JVM though. How often have you or your friends and colleagues written code that breaks the JVM in a way that can be reproduced?

My only point here is: the common knowledge currently is that no-one knows what the issue is. It's helpful posting that, and it's kind of helpful suggesting reinstalling Subsonic/Java/your OS, as it might help. But stating that this is a Java issue (ruling out the possibility of other sources of errors) seems wrong to me.

A Google search for the error message indicates to me that there's something funny in the Spring framework, and I'll partly blame Subsonic for using a super old outdated version of said framework (2.5.6).

Dave,

The local system account should be fine as long as you are accessing a local drive using X:\Music.

I haven't tested Essentials yet, but if it sets up shares like WHS 2011, then you may have to us a valid user account that has access to the shares and then use the UNC format to access the media folders.

HTH

hakko wrote:You're absolutely right about the browser situation. I don't know if it's fair to compare that to mature technologies as a C compiler or a JVM though. How often have you or your friends and colleagues written code that breaks the JVM in a way that can be reproduced?

My only point here is: the common knowledge currently is that no-one knows what the issue is. It's helpful posting that, and it's kind of helpful suggesting reinstalling Subsonic/Java/your OS, as it might help. But stating that this is a Java issue (ruling out the possibility of other sources of errors) seems wrong to me.

A Google search for the error message indicates to me that there's something funny in the Spring framework, and I'll partly blame Subsonic for using a super old outdated version of said framework (2.5.6).

I'm sure that's all true, but for the average user if somethings broken and reinstalling Java fixes it, regardless if its Java, springwork, or the tooth fairy; in his/her mind it's a Java issue. I'm not arguing your position, I just think it's a discussion for a different audience (i.e. developers) rather than the typical user trying to get Subsonic running.

When I write that it's probably a Java issue, I'm not trying to pinpoint the underlying issues with browsers, frameworks, or any other related technologies that interact with Java or Subsonic. I'm only trying to point the user to a way to correct the problem. For the users purposes, I think characterizing the problem as a Java issue is valid - not perhaps from the standpoint of a developer - but certainly valid enough in a general way to assist the average user.

If in fact my characterization is so egregious, I shall endeavour to develop language that defines the issue more accurately.