First I made a socket implementation and then I decided that in order to choose between the two I must implement a RMI solution. I have now done that. And now to my question:
when I try to simulate multiple clients (by creating threads in a loop) and try to book a room it seems to work fine when I try it with 500 threads. Ant then I tried it with 700 I got alot of
java.rmi.ConnectException: Connection refused to host: xx.xxx.xxx.x; nested exception is:
java.net.ConnectException: Connection refused: connect
This is ofcourse from the client threads. The server does not throw any exceptions. Is this something that I need to worry about? With my socket solution I could run it with 10.000 threads.....
I never tested my RMI solution with that amount of threads, so I don't have any idea (but it seems a bit odd to me). Maybe you could try to simulate the issue with a very easy RMI example (like this one)
I have now tested the simple RMI example and here are the results.
500 threads - no problem.
700 threads - no problem
1000 threads - multiple exceptions like above.
Since this worked with 700 I run the URLyBird test again and it worked with both 700 and 900 and it worked fine but not with 1000..... hmmm I dont know what to think about this. Otherwise I like the RMI solution a little better than the socket.....
Well champ, you can stay with the RMI solution. A super powerful server is not a must requirement, so I'd say that what you have is certainly enough. You can even mention what they can expect from your solution, and since it wasn't mentioned how many requests the server has to handle concurrently, then you concluded that what you built was enough.
I experience exactly the same behavior: when you start 750 threads accessing the RMI server (with the simple example) you get a lot of "connection refused" exceptions. No need to say I didn't test my RMI server with that many concurrent requests. I tested it with maximum 35 threads.