× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Are you running this on a multiprocessor machine? Just because this works 99.99% of the time, it sounds like the kind of multi-threading error I heard so much about at JavaOne last week.

Try marking the variable that holds the reference to your IFSFile object "volatile". Marking it so changes the JVM memory model contract. Most of the as400.access package does it's work on worker threads. Your thread blocks while the worker thread does its thing. When the worker thread returns, it releases your thread from the block. If the worker thread is setting the value of the reference, it might not actually be in the memory your thread is using at the time your thread accesses it. This is due to memory caching at each of the processors involved in the two threads.


-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of David Gibbs
Sent: Tuesday, October 11, 2011 10:16 AM
To: Java Programming on and around the IBM i
Subject: Re: Null pointer on IFSFile delete?

On 10/11/2011 9:48 AM, Joe Pluta wrote:
David, I have no idea. I think this is the line that's failing:

ds = (ClientAccessDataStream) fd_.server_.sendAndReceive(req);

This would imply that either fd_ or fd_.server_ is null. fd_ cannot
be null or it would have failed earlier in the delete() method. In
fact, the delete() method calls fd_.connect(), which is supposed to
set the server_ value.

So the only way I can see this happening is if you somehow lost the
connection for your file and were unable to re-establish it. Are you
doing this delete immediately upon creating the IFS File object?

yeah, that's pretty much what was identified last time.

John E, the jt400 development lead, suggested updating the most current version of jt400.jar ... which I did. But the error manifested again. Unfortunately it's completely sporadic. The code in question will work fine for weeks and then fail for no apparent reason.

Against my better judgment, I've added a catch for npe when the delete is performed. I'd rather leave a file behind in the ifs than abort the process.

david


--
IBM i on Power - For when you can't afford to be out of business
--
This is the Java Programming on and around the IBM i (JAVA400-L) mailing list To post a message email: JAVA400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/java400-l.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.