Chad Schultz

+ Follow
since Mar 25, 2007
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
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Chad Schultz

Well, I've done more reading, more experimenting, and a great deal of banging my head against the wall. I've made progress, but have another problem.

On my Windows machine, I found that neglecting to read output will cause a process to hang around indefinitely- however, this does NOT prevent the process from being destroyed. Interrupting a thread does not appear to automatically kill the child process; it musy be explicitly destroyed. If I'm incorrect about any of this, please let m know, as that means I made a mistake.

The original problem I had was in the code I showed originally. The code looped until all output from the process was exhausted, and THEN exercised the waitFor() method. So my program only checked to see if it was interrupted on the waitFor() catch block- after the process had completed.

The revised code is as follows:

As suggested, the new ProcessOutputThread class runs as a separate thread, reading output from the process. Here's the class (minus comments, imports, etc)

The method of checking readLine() != null to tell when a process is complete seems odd to me, but that's from the legacy code- and I can't think of a better way.

It works beautifully- on MY machine. But on the Linux server, not so much. When the timer is set to a small amount (100-1000ms, just for testing purposes) and interrupts the main thread (the first chunk of code here), then this throws an IOException from the line containing "processOut.readLine()"

Why would it do this- and only on some machines? What's the best way to get around it?

13 years ago
Question: what can prevent destroy() from destroying a Process object?

I'm modifying a legacy program that runs a child process, which it gets from a call to Runtime.getRuntime().exec(). One requested feature was to stop the process if it hangs. So, I have implemented code to run a timing thread and interrupt this thread if the time expires before this (main) thread is complete. If interrupted, the thread destroys the process. Here's the code:

I've noticed that destroy() does not function instantly; that's why there is a second waitFor() call.

When I run the program with a ridiculously short time limit, the thread will be interrupted and log the messages saying that it is going to destroy the process. But the process completes normally- it even returns an exit code of 0! I should note that this child process is NOT fast. It may take up to a full minute to run, even when destroy() is called after 1 ms or 1 second or 10 seconds after it begins.

My tests (not using this specific child process) work beautifully. I have no problem using destroy() on simple test processes on the Linux box this runs on.

The only hint I can find is from another post on this forum, suggesting that all input needs to be read from the process before it ends. You can see above the odd code where it reads output from the child process, then calls waitFor()- that was in the original legacy code. I added the code that checks for an InterruptedException and destroys it. Could this possibly have anything to do with it? And if so, how can I get around it so I can destroy it?

I tried just interrupting the thread, thinking that would automatically kill the process said thread was running, but that didn't work either.
13 years ago
I�m having an odd problem with thread pooling.

I have a class (let�s call it Sender) that runs through a variety of data objects, spawning threads to process each one.

I created a class that implements Runnable and, of course, implements the run() method. When it is instantiated, a reference to Sender is passed to it. At the end of run(), it calls a callback method in Sender, giving it identifying information so Sender knows that data object has been processed and can delete it from the database table listing the data objects to process.

Sender creates an ExecutorService using Executors.newFixedThreadPool(). The number is set in a properties file, useful for debugging purposes and for fine-tuning performance and memory issues.

My Runnable objects are instantiated and given to the ExecutorService using the execute() method. After all data objects have been sent, Sender calls the shutdown() method.

All nice and, as far as I can tell, it should work beautifully. But there�s only one problem. The threads (which involve time-consuming tasks and actually spawn child processes- see the thread at for more background) never finish processing! However, when I have Sender sleep after executing all the threads, some complete. With enough time- or if I have sender loop, sleeping until threadExecutor.isTerminated()- then all the threads successfully complete processing.

I do not set the threads to be daemon threads. I do not believe the ExecutorService creates them at daemon threads. The main process should continue running until all threads are complete, correct? Any ideas why it�s stopping, and taking the threads with it?

Of course, if I don�t call shutdown() the process NEVER stops, as the ExecutorService waits indefinitely for more tasks to execute.
Thanks for all the suggestions! This is what I ended up trying:

I�m calling Executors.newFixedThreadPool to create a pool with the number of threads specified in a property file, and then instead of starting individual threads, I call the execute() method of the pool, passing the thread.

At the end of the thread�s run() method, it calls a method in the class that actually started the thread. This method runs code meant to wait upon successful completion of the thread. If there is an error, the thread will throw an exception, so if it reached the end of the run() method I�m assuming everything is ok. Since I have four separate programs needing to run these same threads for the same class, I have them all implement an interface with that callback method, although each one has different code in the body of the method.

I don�t know if that�s the best way, but it SEEMS to work. I hope. I need to do more testing.

I�m still running into that issue, however: stopping threads once they�ve exceeded a time limit. I�ve been reading more on threads, and I haven�t found anything that seems like it will work. I can�t have the thread continually check for interrupts; you see, its main function is to call third-party software (FOP, for those of you who have had the misfortune to deal with it), and that�s where it would hang if anywhere.

I thought I may just have a second thread class that creates the real thread, joins it with a time limit, and then once it wakes up, checks to see if the thread is alive and kills it if it is. The only problem with that is� apparently there�s no good way to kill the thread? The appropriate methods are deprecated, interrupt() is useless in this case (as I explained in the last paragraph), and I think I�m correct in stating that e ven if this �outer� thread terminates, the �inner� thread will continue merrily along to process, even if it is stuck in an infinite loop? Is there any way to make the thread stop?
Thanks for your prompt reply, Ugender! I think I understand what you'r egetting at... it makes sense to me, but I think I'd make some modifications. I could write code that would manually track the number of threads running, only allow the main program's loop to continue when a thread was open, track the time of each running thread to terminate it if it went on too long, and make a database call when the thread was finished to remove that record from the list of data to process.

Still, it seems that there should be an easier way. I did some more research; it seems like I should be able to use a ThreadPoolExecutor to limit the number of threads, queuing extra requests until they can be run, setting a keep-alive time, and having the threads call a callback method in the main class at the end of their code.

There's a problem with this approach, however. I'm reading the Java 1.5 API for ThreadPoolExecutor ( Keep-alive times only work when a) the pool has more than corePoolSize threads and b) the threads have been idle too long. Why is that a problem? a) Using an unbounded queue will queue all threads above and beyond corePoolSize. b) Using a bounded queue will, I think, discard extra thread requests beyond the boundary.
IF I understand all of this correctly (it's all new to me) this means that if the corePoolSize was, say, 5, then there would NEVER be more than 5 threads running... but idle threads would only be terminated if there were more than 5... meaning that, potentially, 5 threads could become idle one by one (a lot can happen in 20,000 threads) and the program would be stuck waiting forever.

But I'm likely misunderstanding this completely. It just seems like it should be easy to say "yo- I'm going to fling a hundred thousand items at you, but I only want you to process them five at a time. Shut threads down if they take too long to complete, and let me know when they're done, okay?" Any thoughts?


I'm having some difficulty with a project at work. Where the old program ran processes one at a time, I was charged with making it threadable.The downside is, it currently tries to run every thread at the same time. There are typically thousands, or tens of thousands, of threads to run, with each one taking several seconds to complete. (Yes, this is a batch process, in case you were wondering.) The threads are all nearly identical.

The details of what they do or why it is set up this way are not important; I have several questions, however. Looking at the Java API, I think ThreadGroups or ThreadPools may be the solution, but I'm not sure.

1. How I can put a limit on the number of threads that run at a single time- while making sure that every thread is run (that is, no threads may be discarded)?

2. The data to be processed is read from a table in the database; each record, once processed, needs to be removed from that table IF processing completed successfully. How can a thread tell the calling program that it has successfully completed execution?

3. How can I ensure that hung threads are terminated? Note, each thread launches a child process (again, don't bother asking why- it's too painful to explain). I want to make sure the thread, and its associated child process, no longer take up memory. As long as the record was not removed from the database (see question #2) this record will simply be processed the next time the program is run.

My task is simple. I want my JUnit tests to test the main() method. The tricky part is that when there is an error that prevents the problem from continuing, it exits- naturally.

Luckily, the program is already designed to call a method that then exits- so for testing purposes, I thought I would create a subclass in the test case file that overrides that method with one that throws a RuntimeException instead of calling System.exit(). However, I'm having trouble.

This is a basic representation of the program:

The test file goes something like this:

BTW, yes, I have read the JavaRanch page on overriding vs hiding. Unfortunately, that doesn't seem to have helped. Every time I run the test, it never completes; when I debug, I find that it reaches the original class's System.exit() instead of the new method. I've tried passing in a stub class in ABC's application context file (both casting it as ABC or as ABCStub). I've tried putting ABCStub in a separate file. I've tried making ABCStub not a static class. I've been banging my head against the wall for hours and still haven't found a solution to this simple problem: hiding that static exit() method.
13 years ago
I've been working on a project for a while, but now my ANT build has stopped working. I'm using my company's custom scripts that extend ANT and make use of a Maven POM file. This has worked fine for weeks. It's been a while since I last did an Ant build, so I have no idea what I could have changed to result in this.

I should note that a normal build works just fine; Eclipse itself shows no errors. But when I run the ANT build, I get a number of errors. All of them state the name of the source file and "cannot find symbol." They then state the symbol is a specific class. Every error refers to the same class.

I deleted the JAR from both the project directory and the local repository so it would be forced to pull the most up-to-date company version of the JAR. I've looked at the JAR in Eclipse and opened it to make sure that, yes, it DOES include the right file, and that file DOES include the right class. I've checked to make sure it was on the build path. Does anyone have any ideas?
13 years ago
Thanks, Kaydell, you reminded me of the fact that I'm using a FileWriter as well. I think that's where the problem is. I had a try block with a sequence of method calls, each relying on the last, each throwing a different exception. I created the FileWriter partway through and closed it at the end- but of course, if it hit an exception, it wouldn't reach that.

After quite a bit of frustrated experimentation, I discovered the only way to make this work and avoid "variable may not have been initialized" compiler errors (yes, Eclipse treats it as an error and so will not compile the file, even if @SupressWarnings is used), I initialized the FileWriter to null before the try block, then added a "finally" block with an IOException try/block inside that (never mind that the big try block already had one!) and THERE I was able to close the FileWriter. It doesn't look pretty, but it works.
13 years ago
How do I delete a file after I've passed it to a method that ends abnormally?

I'm trying to write an integration test for a simple program by extending Spring's AbstractDependencyInjectionSpringContextTests and using JUnit.

In one test, I create a tempfile, then call a method which is supposed to contact a remote service (via Spring and HTTPInvoker), retrieve data, and write it to the file. Then the method must delete the file.

However, this test specifically is to ensure the program properly handles the error when the service cannot be contacted (I'm using a bad URL to simulate this). So:
1. the file is created
2. the method is called
3. the method attempts to contact the remote service
4. the remote service call fails
5. the method throws a RuntimeException
6. the test catches the exception
7. the test tries to delete the file

However, delete() returns false, and the file is still there. deleteOnExit() doesn't work, either. If I comment out the method call, the file is deleted. My theory is that the machine believes the file to be open and in use by the method, and so won't allow it to be deleted. How do I have the code clean up its own mess and remove the files it creates each time I run the test? Thanks!
13 years ago
Okay, I know this is a stupid question...

It's easy enough to access an inner class in general. From a different class, you can refer to OuterClass.InnerClass. Easy as that.

However, I'm using an enum inner class. OuterClass.InnerEnumClass.InnerEnumMember doesn't work. Neither does Outerclass.InnerEnumMember. What's the syntax, then?

Let's use this as an extremely oversimplified example;

In this example, references FROM the outer class (dir = Direction.LEFT) work just fine. However, when I need to access it from another class, I cannot seem to use the enum (new OuterClass(Direction.RIGHT)). What's the proper syntax?

13 years ago
Wow. I didn't expect quite that many responses! I'm especially surprised to see people slamming Java in a Java forum.

Thanks everyone for your ideas. It looks like people mainly suggested calling the method to run the actual code from inside the try block. I thought that didn't look right when I had four successive try/catch blocks (one for each command line argument) with the method call hidden away in the last one, but that's just me.

I ended up putting all the initializing try/catch blocks into a separate method. They each set a class variable. In case something does go wrong, the catch blocks call a method that logs the error and exits the program. Then I have the main method call that method (no gripes about uninitialized variables!), and then the other methods of the class that perform the actual functionality. I feel that leads to clean code, the separate methods are easier to test, and then my main method gives a "bird's eye view" of the flow.
13 years ago
Thanks, Keith. I figured out how to handle it, though. I used the object in the wildcarded form: so I took a DeliveryCalendarDay<?> object from the List<DeliveryCalendarDay<?>>. Then I was able to use all the features of the base class, which is fortunately all I needed anyway. I had to change every reference in my code from the specific subclass to this wildcard generic class, but it works, whee!
13 years ago
I'm initializing different variables in try/catch blocks, and then when I use the variables the compiler tells me that they may not have been initialized. IT thinks that if an exception is caught, the variable won't be initialized- it doesn't realize that my catch blocks call a method which spits out an error and calls System.exit(1);

How do I make the "variable may not have been initialized" error go away?

This question has been sort of answered elsewhere; declare your variables outside the try/catch block, initialize them to default or null values outside the try/catch block so the compiler will shut up, and so on.

However, what about objects that MUST be initialized in a try/catch block, such as FileWriters?

I also could pile the execution code in the try block, which is very poor design, as that code won't produce the exception.

Or I could call a method from inside the try block and pass the variable there- oh, but what about the other objects/variables? This only works for one...
...unless I cram all the different objects into a single try block, and catch a slew of different exceptions. I could be mistaken, but that doesn't seem like good style either.

Or I could throw a RuntimeException in the catch block... right after the call to my special exiting method, so it would never be reached anyway.

Is there any good way to handle this kind of situation?
13 years ago
Hi all. My program accesses a service that returns a List<DeliveryCalendarDay<?>>, where DeliveryCalendarDay is a generic object to be parameterized with a specific calendar. My problem is that I have trouble using the actual objects from the list- I can't seem to find a way to tell the compiler that yes, I know what type of objects they are, so it's okay to let me access the methods. I've tried to read about wildcard parameterizations (it's very confusing to me!) and the only information I've found on this question (as far as I could understand what I read, anyway) is that it's a bad idea for methods to return such things. That doesn't help me, though- is there a way around this? Thanks!
13 years ago