I'm working on URLyBird 1.3.1 using NetBeans and I'm trying to test whether locking/unlocking is working. I'm comfortable that the code is doing what I think I want it to do. However, I don't really know whether it will work in practice.
I have followed these steps:
--- Start up network server
--- Place a break point in the method implementing lock(recNo) just at the lockedRecords.notifyAll(); statement, that is, just after placing the entry (key is instance of RoomFileAccess file that implements all of the methods in the Data class and its value is the record number being locked)for the locked record into the container (a WeakHashMap).
--- Start network client 1 in the debug mode in NetBeans
--- Start network client 2 in the debug mode in Netbeans
--- Book a room with network client 1 so thread stops at breakpoint
--- Try to book the same room with network client 2
I'm expecting that network client 2 will stop in the block in the lock method shown below:
However, cbased on the stack trace I don't think it gets that far.
Below is the partial stack trace of what the network client 2 hits:
java.rmi.ConnectIOException: error during JRMP connection establishment; nested exception is: java.net.SocketTimeoutException: Read timed out at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:274) at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:171) at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:94) at suncertify.remote.RoomDatabaseImpl_Stub.isBooked(Unknown Source) at suncertify.gui.GuiController.bookRoom(GuiController.java:126) at suncertify.gui.ClientWindow$BookRoom.actionPerformed(ClientWindow.java:262)
I'm not sure what the results mean or even if I'm trying to test the lock/unlock functionality correctly.
Any suggestions about how to test end-to-end locking/unlocking that you have would be helpful!
I used MTJUnit, a multithreaded JUnit extension to test the threadsafety of my solution (URLyBird 1.3.3). I also put in extensive logging (finer and finest level) in combination with a custom log formatter that shows also the thread name and a more detailed timestamp than with the regular formatters, see example log output below.
I found this approach allowed me to more fully test (hundreds of simultaneous "users") than any "multi-debug" session could possibly do
Sun Certified Developer for the Java 2 Platform
Sun Certified Enterprise Architect for the Java Platform, Enterprise Edition 5
Doody calls. I would really rather that it didn't. Comfort me wise and sterile tiny ad:
Create Edit Print & Convert PDF Using Free API with Java