Jon Trussler

+ Follow
since Jul 05, 2001
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
(keep public parts private until JForum day)
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt
Moderation Tools

Recent posts by Jon Trussler

I have successfully redirected from IIS 5 to Tomcat 5.5 the /serlvet-examples webapp that comes with the Tomcat 5.5 distribution. I also have been able to successfully test my own servlets by calling them directly on port 8080. I have been unable, however, to redirect to these servlets in the same fashion as the sample servlets. When I view the uri runtime info via /jkstatus everything looks consistent so I suspect the file listed below.


#Look at
#for parameter description

info=Shared memory file. Required for multiprocess servers
file=D:\Apache Software Foundation\Tomcat 5.5\temp\jk2.shm

info=Ajp13 worker, connects to tomcat instance using AJP 1.3 protocol

# Map webapps to the Web server uri space

info=Servlet examples, map requests for all servlets to Tomcat.

info=Sample Servlets

# define the worker

# Uri mapping


Let me reiterate that everything works fine by calling port 8080. All servlets located in /servlets-examples work. A servlet in /sample works but a jsp file in that webapp throws a HTTP 500 - Internal server error as well as all of the servlets in the /contracts webapp.

Any ideas would be appreciated.
11 years ago
And as for your question, I actually spent a decent amount of time on my design document, but not because I felt it would show on my score. I have rarely seen results where participants did not receive full marks on documentation. I went into detail because I figured that it would make the essay portion of the certification even more trivial than I expected. Turns out I was correct. Hope this helps.
Here's the breakdown:
This report shows the total points that could have been awarded in each section and the actual number of points you were awarded. This is provided to give you per-section feedback on your strengths. The maximum possible # of points is 155; the minimum to pass is 124. General Considerations(maximum = 58): 50 Documentation(maximum = 20): 20 GUI(maximum = 24): 24 Server(maximum = 53): 50
Design Decisions:
- Modified Data Class
- Didn't modify lock/unlock signature
- Tracked remote clients for record locking
- local/remote database switching
- used Unreferenced to clean up rogue locks
- Kept it Simple
I took the exam on October 9 and got the results October 14.
Although I didn't post many messages, this forum has been very helpful. A special thanks goes out to Peter den Haan with regards to identifying remote clients.
Thanks again.
I basically do the same thing.
1) check to see if there are any locks held by this connection; if so continue.
2) get a key set from my locking structure
3) get the iterator from this set
4) loop through the keys and if the value associated with the key is the dead connection, call the iterator's remove method and notify all
i haven't found anything more efficient than this but since the code is not completely executed unless step 1) is true, i don't think it will be a performance hit. basically, step 1 should never evaluate to true unless the client quits abnormally or the client is not well-behaved.
What do you think?
hi morph,
yes i do keep track of the client that places each lock without modifying any method signatures. i also use RMI. the Remote Database is actually the server connection object. each client gets its own copy. if you take a look at the the "Contradictory requirements" thread you will get a better insight into how to accomplish this. however, by searching through the forum, it seems that a minority of the people actually take this trail.
uncommenting the locking code above will only be useful for clients that are not well-behaved but will put a little burden upon well-behaved clients. obviously we cannot delegate all the methods to the data class (lock/unlock). but do you think that if a networked client wants to write to a record but hasn't got a lock, you should acquire a temporary lock behind the scenes? I haven't made up my mind on situations such as this. I don't know that the server should assume that clients aways act as we expect them to.
This is a little off the topic but I think it raises some important issues with record locking. I implemented a record locking system that keeps track of clientid by giving each remote user their own server side connection object. Now, in a well behaved system, each client will always perform, say a modify operation, by the sequence lock, read, modify, write, unlock. How well-behaved should we trust our data clients to be? If we track our clients, we can always make sure the record is locked by a certain connection before we make our database calls. In our remote implementation, we can obviously delegate much of the work to our methods in the Data class. So should we have additional checks around our delegation of the modify or other database functions to handle record locking if the client is not well behaved? This will definitely cause some overhead but will create a more stable and secure implementation. How does everyone weigh this trade-off.
Any thoughts or suggestions?
Peter, Matthew, etc....
Now I have a system where each client gets its own server side object to talk to. Now it is very easy to maintain record locks without changing my method signatures. Thanks for the guidance. I just have one question.
1. If a client aborts without unlocking his records, what is the best way to automate that unlocking process? I have implemented the Unreferenced interface and that works but not in a timely manner. Sometimes it takes 10 minutes to detect this. Granted, aborting without unlocking is a rare exception assuming a properly behaved client. Others have used a timing mechanism. Any suggestions?
Nevermind. If you clean up after yourself there is no delay in calling unreferenced as long as the program is exited normally. For abnormal exits, you will have to wait. I have experimented with decreasing the java.rmi.dgc.leaseValue but that seems to create a lot of overhead with renewing leases. Any comments are appreciated.
[This message has been edited by Jon Trussler (edited August 22, 2001).]
Matthew, Peter, etc,
I am missing something big here. Please help me out but without cheapening the test as Matthew expressed.
My RMI object is a RemoteDatabase that, naturally, extends UnicastRemoteObject and implements my RemoteDatabaseInterface which extends a generic DatabaseInterface and Remote
If we were to have as you mentioned above:
public void lock(int recnum) throws...
Wouldn't "this" be the "Connection" object that you refer to, which is RemoteDatabase in my case? And in that case, isn't the connection object the same for all clients connecting remotely? Obviously it cannot be since you identify the client holding the locks by connection object.
Basically I am having difficulty with the notion that everyone has to share the same locking structure while at the same time has a different connection object when only 1 object is bound to the registry.
I basically have a solution that I am confident will get me a passing score, as many people have passed without tracking client locks. However, I would like to be as thorough as possible. And as we all should know, a certification isn't the only reason for completing the assignment.
I would appreciate any further advice on connection tracking without modifying method signatures.
Peter, etc...,
if :
interface RemoteDataInterface extends DataInterface, Remote { // that's all folks}
class RemoteDatabase extends UnicastRemoteObject
implements RemoteDatabaseInterface
is that to say that the implementation of the public methods of DatabaseInterface in RemoteDatabase can be of the form :
public publicMethodOfData() { return dta.publicMethodOfData(); }
where dta is a local private instance variable of type Data
Please let me know if I am way off line.
Thanks in advance.