Alan Mehio

Ranch Hand
+ Follow
since Apr 04, 2005
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 Alan Mehio

Tom,
If you do advance search on google by selecting the *.edu, and do a refine through the link you may find what you are looking for;
type this into google search

java 2D tutorial site:edu


Some time the best tutorials are found at university
6 years ago
Dan,
you said:

and it's a custom font I made

. Try to pick up another font file from your computer by search for *.ttf or post the ButtonFont.ttf so we can look into it and make some test.
It may be the file is corrupt or does not comply with the standard tff file.
How did you creat the "ButtonFont.ttf" ?

If you use a well known font file from you computer do you encount the same issue.

6 years ago
Paul,
Not clear what do you mean by ?

problemwhen i open in second time jfilechooser when i want close...don't close.



Can you post a working compiled code showing the issue so that you can get a better help.

6 years ago
Hi,
If you can post a working code; then we can help.

9 years ago
It is clear. You are trying to cast to String Type even the object you have is a DefaultMutableTreeNode

Can you post the full stack trace as well as the working code so that we can fix it for you
9 years ago
Chris,
I did not get the time to look at it; however, I am posting this response in order to make it on top.


Cheers
Alan
10 years ago
Hi,

try to look at this http://www.pbjar.org/blogs/jxlayer/jxlayer40/

actually I have used the older version 3.0 for proving a concept in a GUI application.


I hope this get you started.
10 years ago

nmohan kumar wrote:will the thread be availabe even if the server gets stopped?

actullay i am running my application on websphere server 6.0.i am using three thread classes.The problem is the server is getting stopped after two threads got finished.

In my servet ,i have coded like,

t1.start();
t2.start();
t3.start();

t2.join();
t2.notify();

i want the third thread to be run after t1,t2 finished running.

t2.join();
t2.notify();

and made the t3 waiting..but the application server gets stopped..

1.is it possible to restart the server,is there any code?
2.will the thread t3 be alive even after the server gets stoped?.


can anyone give me an idea on how to solve this issue?..










to start t3 after t1 and t2

t1.join();
t2.join();

t3.start();

How did you implement your wait for the t3 thread? can you post a working code which shows the case only?

I am not sure what is the implementation of the server stop in your case ( web sphere server 6.0)


rmi tcp connection

CPU resource is being consumed over time in App 4.3 even when program test is idle.



It is difficult to guess what the thread is doing unless we can see the code. My guess is the rmi thread is doing some thing in a periodic way. Do you see the CPU resource goes up and down or what pattern do you see??

Ulf,
Thanks for your valuable comments. Actually my post was based on explaining the idea of the periodic thread running in a very simple view to allow for understanding the concept without using a thread part. The second point I want to stress on is the usage of java.util.Timer; the Timer has a draw back which is there is only one thread that execute the TimerTask hence if the timer task takes too long to run, the timing accuracy of other Timer Tasks can suffer; for example, if the recurring TimerTask is scheduled to execute every 20 ms and another TimerTask takes 40 ms to run, hence, the recurring tasks get called twice which will will have different consequences.

As a result, it is better to use ScheduledThreadPoolExecutor for periodic task execution.


Is there a way to acquire a permit from any semaphore in a collection? Similar to select() in Unix I/O programming: you have collection of stream handles and wait for data in any of them.



I am not sure if this answer the question; the semaphore are useful for implementing kind of resource pooling in your case a pool of limited stream handler so you want to put a bound or limit on of the size of stream handlers ( ELEMENTS IN THE COLLECTION) so that if this bound is being exceeded the caller thread to pull more will block until an available resource ( stream handler) is returned into the collection. In your case, you have a bounded collection and at the same time
your element (stream handler ) will block i.e will be in a wait state until an event happens


Collection of ServerSocket of size n which listen to different ports is an ideal sample of example which I will try to simulate if you would like me to continue


Hope this could help.

Hi,
Usually periodic execution of a task can be done by using sleep in your run or you can use ScheduledExecutorService which is more preferred things to do.

The first one is better for you to understand the concept.




Please let me know if you want the other approach or if you have any further question. Always it is better not to extend a thread and implement Runnable which is done above for many reasons.


Hope this could help
Sebastian,
Thanks for getting back and explaining the JDBCSupport tool.

That is why I decided to mark each connection instance with the id of the thread that is allowed to work with it.



Yes this is a good idea.

I got confused since your sample code does show thread created in a method which make the object thread safe




Cheers
Alan
Sebastian,
Just looking at your code I am still not getting to undrstand how the two thread will wait? the threads has to acquire a lock on an object in your case do you want
the connection pooling to be the one.

First of all your thread get created in a method any idea why? second you mentioned



# /*
# * This is what happens:
# * Thread 1 obtains a connection and closes it again (connection gets released into the pool)
# * Thread 1 then notifies Thread 2 which was waiting.
# * Thread 2 obtains a connection and runs a query (no exception expected).
# * Thread 2 then notifies Thread 1 which was waiting.
# * Thread 1 uses the connection instance it previously closed which should now be locked (Exception expected).
# */



Thread 2 notifies thread1 on what waiting object?

If Thread1 uses the connection instance it previously closed ( returned to the pool). So how do you know that this is the connection which was used when you ask the pool for another connection from thread1


The idea is not clear for me. CAN YOU PLEASE ExPLAIN what do you want to prevent such as:
" I want a connection pool which will block any thread asking for connection if there is another thread working with the connection and once the another thread
get the connection back to the pool the thread get notified and start to use the connection again." So you want to prevent the same connection to be used
at the same time from many thread; you want the connection to be used by one thread at a time and allowing other threads to obtain the this connection but not to use it i.e wait ( block) until the first thread finishes from it.

Do you mean it is a kind of blocking queue where other thread has to wait for the resource until the resource will be available i.e returned back to the pool ??



Rob Prime wrote:What you want is a read-many-write-one lock: reading threads can have access unless another thread is writing; other reading threads are not a problem. Writing threads must wait until all other reading and writing threads have finished. don't know if this has been implemented in Java yet but it's not that hard to implement yourself if it isn't.



Further to Rob comments( thanks Rob). There is in java 5 ( concurrency util) something called ReadWriteLock.
If we look at the JAVA DOC; it says:

"A ReadWriteLock maintains a pair of associated Lock locks, one for read-only operations and one for writing. The read lock may be held simultaneously by multiple reader threads, so long as there are no writers. The write lock is exclusive.

All ReadWriteLock implementations must guarantee that the memory synchronization effects of writeLock operations (as specified in the Lock interface) also hold with respect to the associated readLock. That is, a thread successfully acquiring the read lock will see all updates made upon previous release of the write lock. "

Now the last statement is very interesting which means there will be no stale data so any read thread will capture the latest write thread so this is a guranttee of visibility across all reader threads.

Now if we compare the performance of ReadWriteLock implementation ( ReentrantReadWriteLock) w.r.t. ReentrantLock; we can see on the average for more then 4 threads we will get almost double throughput ( measure of taks compleleted per unit of time)

Now if we give an example here to clarify the concept more; please notice, I am assuming you are using java 5 and above.



I hope this could help