I had almost the same doubts and problems and the same scenario as yours and feel that the paid documentation is not covering all the aspects.But you seem to have crossed the stage where i am stuck.So if you can tell me how to launch the application that is what url should be given to launch the program. When the program is in /default/deploy I give
now when it is in /all/deploy what should be the url
If u can pls reply
You start JBoss like this:
run.sh -c all
And then you should be able to acess your application under http://localhost:8080/Myapplication. The thing is, if you start it without -c all it will go into /default/deploy, if you start it with -c all it will go into /all/deploy.
yes i am using
run -c all for windows
both the servers start and create partition , recognize each other
but when i give http://localhost:8080/myapplication
and also if u can tell me if what jndi.properties file has to be chaged in order for clustering to work.
I read in the documentation that
java.naming.provider.url has to be changed and given the server1 ip:port , server2 Ip:port
is it the /all/config/jndi.properties
if you run in cluster env, use HAJNDI. HAJNDI runs on 1100 port.
1)change connection to server1:1099 to 1100 in cluster env
2)add server1:1100, server2:1100 to url in your jndi.properties
3) Jboss will use first available HAJNDI.
4) In multicasting env, you don't need pass url. JBoss client porxy will locate for you.
5) If I were you, first will add server:1100, server2:1100 in my jndi.properties and check it works fine then take out url in JNDI properties.
Do not edit the jndi.properties file in /all/conf, that file is for JBoss only and JBoss does not need it to be changed to get clustering to work.
david, either change your jndi.properties file to have one of these:
nothing! (i.e. no "java.naming.factory.url.pkgs" entry.
Setting the URL specifically works correctly. No issue there.
My problem was that if I don't set it (to get multicast discovery), I get the wacky behaivour.
Problem is solved by setting url to ""(empty string) though, so everything works fine for me at the moment (64000 balanced reqests and climbing, from my test app)
I assume you meant "java.naming.provider.url" and not "java.naming.provider.url.pkgs"? I was under the impression that the 'pkgs' entry was for java packages that it will lookup the namingcontext class.
I believe you've been bitten by the same bug I've just logged. Apparently turning autodiscovery off (i.e. supplying a list of URLs) can cause serious problems.
Thanks, my radar didn't catch this BR, I will take a look at it.
pls can anyone be specific which jndi.properties file are we talking.it's not /all/conf/jndi.properties as is made clear so which one.
It depends on how you are providing the connection properties to your client application.
One possibility is to place a jndi.properties file on the clients classpath containing the connection properties, when you do new InitialContext(); (No parameters) the jndi.properties will be read.
When people are discussing changes to jndi.properties this is the file that they are refering to.