Mike Finger

Greenhorn
+ Follow
since Sep 30, 2003
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Mike Finger

You can only check stuff out with the pvcs task. You're going to have to
drive the PVCS Command Line Interpreter (pcli.exe) and put (put.exe) thru ant...
18 years ago
According to the java api it's supposed to be a no-op --
The bug seems to be that it isn't a no-op..
The stack trace I'm getting when I try to close the connection is:
java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for JDBC]Object has been closed.
at com.microsoft.jdbc.base.BaseExceptions.createException(Unknown Source)
at com.microsoft.jdbc.base.BaseExceptions.getException(Unknown Source)
at com.microsoft.jdbc.base.BaseConnection.validateClosedState(Unknown Source)
at com.microsoft.jdbc.base.BaseStatement.validateClosedState(Unknown Source)
at com.microsoft.jdbc.base.BasePreparedStatement.clearParameters(Unknown Source)
at com.microsoft.jdbc.base.BasePreparedStatement.close(Unknown Source)
at com.svtechnology.database.DBConnectionBitMechanic.destroy(DBConnectionBitMechanic.java:297)
Hello,
I was wondering if anyone out there in Java land could confirm/deny the following:
from http://dbforums.com/arch/30/2003/7/529049

Apperently with the MSSQL jdbc driver (and also the Data Direct Driver) you cannot close a connection twice. If you do so, something will get screwed in the driver. It wont show up all the time, just when you push the driver. So check your code and make sure you don't close a connection twice.

I spent alot of time going thru the microsoft and data direct web sites and couldn't find anything...
It appears that I'm experiancing this, but am trying to confirm the bug.
Eugene,
Thanks for the info. Our client is also using a quad proc box with hyper-threading , which I suspect might increase the chances for a threading conflict on non-thread safe code?
Thanks
Mike
[ October 01, 2003: Message edited by: Mike Finger ]
Hello all,
I'm having what I believe is a synchronization issue at a client site (we're trying to reproduce it in house) under heavy load.
We're using win2k/jdk1.4.1_02/jrun 4 server with sp2. What is happening is the server is not responding, but no java thread dump (we've scoured the hd several times to be sure).
Anyways, when I scour the server logs i'm finding tons of:
09/29 10:06:52 error
java.util.NoSuchElementException
at java.util.LinkedList.remove(LinkedList.java:575)
at java.util.LinkedList.remove(LinkedList.java:347)
at com.sctechnology.util.cache.ArrayCache.add(ArrayCache.java:95)
at com.sctechnology.util.cache.CacheManager.setItem(CacheManager.java:342)
at com.sctechnology.delegate.actor.User.addToCache(User.java:332)
at com.sctechnology.delegate.actor.User.addToCache(User.java:321)
at com.sctechnology.delegate.actor.User.getInstance(User.java:285)
at com.sctechnology.action.UtilitiesAction.getUser(UtilitiesAction.java:154)
at com.sctechnology.action.view.ShowViewAction.perform(ShowViewAction.java:68)
at org.apache.struts.action.ActionServlet.processActionPerform(ActionServlet.java:1787)
at com.svtechnology.util.ActionServlet.processActionPerform(ActionServlet.java:146)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1586)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:492)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at jrun.servlet.FilterChain.doFilter(FilterChain.java:86)
at jrun.servlet.security.StandardSecurityFilter.doFilter(StandardSecurityFilter.java:103)
at jrun.servlet.FilterChain.doFilter(FilterChain.java:94)
at jrun.servlet.security.JSecurityCheckFilter.doFilter(JSecurityCheckFilter.java:70)
at jrun.servlet.FilterChain.doFilter(FilterChain.java:94)
at jrun.servlet.FilterChain.service(FilterChain.java:101)

The cache object basically uses a linkedlist to impliment LRU cache. The methods that access the linkedlist object are syncronized, but
I'm not convinced they're 100% thread safe (i.e. the get method removes the item someone is getting and moves it to the back, it's one syn. method, while the add method adds an object and checks to make sure the maxsize hasn't been reached, if so it removes some elements, etc).
So the question: Can is get java.util.NoSuchElementException from a linkedlist due to it not being thread safe?
And perhaps more importantly - how would I reproduce it? I made a thread test harness to hammer on the cache object, but no luck...\
Even a simple proof of concept using linked list in a multi threaded enviroment would sufice. I've been able to un syncronize ind. methods have interesting meltdowns, but I haven't been able to force the cache into a nosuchelement exception.
I'm reluctant to ship a fix off the client without knowing what's wrong (The hardest part!!!), because I'm not 100% convinced
it's unsafe threading and not bad code logic.
Thanks
Mike