Win a copy of Svelte and Sapper in Action this week in the JavaScript forum!

R van Vliet

Ranch Hand
+ Follow
since Nov 10, 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 R van Vliet

Ivan Krizsan wrote:Hi!
I recall having seen some setting in GlassFish that allowed me to configure the size of a threadpool from which threads serving requests are taken.
See this article:
Thus I feel that increasing the size of this threadpool may solve your problem.
With reservation for having misunderstood the question...
Best wishes!

Hi Ivan,

Although this would reduce the problem since it's less likely that all threads are waiting for a nested request to finish the problem will still occur during heavy loads. Basically we should either do the nested (or sub) request asynchronously or to a different http-listener. We were able to reproduce the issue with 40 threads in the pool so it's not a fix.
10 years ago

Perfectly valid question, it was causing the http-worker threads of GF to block. I've now figured out why. We were running both web services (so, the SOAP and the RESTful one) on the same virtual server/http listener within GF. Since the JAX-RS one was requesting the WSDL of the SOAP one on a per request basis it was a matter of time before it grinded to a halt.

To simplify the explanation, assume GF reserves a single http worker thread for port 8080 where both of these are running. It will grab that worker thread for my JAX-RS request, which in turn wants to request a WSDL. Since the only worker thread is then blocked it cannot return the WSDL.

In hindsight a perfectly obvious problem ;)
10 years ago
Hi guys,

I have an odd problem. I want to access a JAX-WS webservice deployed on a GF2 app server from a JAX-RS based webservice running on Jersey within GF2. Now, the second the JAX-RS service is accessed concurrently (so, more than a few requests come in at roughly the same time) the SOAP web service client freezes on this part of the code :

Naming changed but assume namespace and such are correct. Now if I do this in a seperate java app I can do this all day long with as many threads as I'd like. If I load test the JAX-RS call without this bit of code it always works just fine. However this bit of code inside a JAX-RS method hangs the server. It looks like the HTTP listener no longer responds.

Anyone any ideas?

10 years ago
To answer your questions :

1) Not expensive at all. Lightweight object allocation and deallocation happens at very, very low cost in modern VMs.
2) Yes, as mentioned it is completely useless to use any kind of object pooling for lightweight objects. Objects that are expensive to create (because they access remote resources for example or initiate connections of some sort) are candidates for pooling but that's really about it.
3) Iterating over an array is faster than using in iterator in all cases (although in the case of an iterator backed by ArrayList for example the performance would be similar). That said your array approach would have to be aware of thread concurrency which introduces locking and synchronization to your solution which doesn't help performance at all.

All that said, you're talking about performance differences that can probably only be measured in microseconds so it sounds like premature optimization to me. Prioritize clean, maintainable code. Iterators in most cases are easier to read in code than array iteration code surrounded by locking.
10 years ago

ajse ruku wrote:Requirement is such that i need to have 30-35 static final strings (generally one line 90-100 words) having some variables.
At run time based on data available,i need to pick a string , replace the variables with values and then pass that to some other method which is not my concern.


Couldn't you just make a final static string array and select the appropriate one at runtime? An enum with a string field would do as well and is probably even more elegant. Certainly beats hardcoded references to static strings. All that said hardcoding such strings into a class sounds like a suboptimal design choice to me.

And for future reference please include as much relevant information about the problem you're trying to solve in your original post. It's a little inefficient for everyone to have to ask about specific details just so they can help you with your problem.
10 years ago

Jim Hoglund wrote:Henry : A question. How is the reality of multiprocessors reflected in Java 1.6,
and what do I need to know for about this for SCJP-6? Is it true that physically,
with multiple processors, there may be multiple threads running (with OS magic),
but logically, based on the language spec, thread behavior is as described above?

Jim ... ...

The language spec is not in the way of true thread concurrency, you just have to keep in mind that there are some things you have to take into account with problems such as the above. Due to writes potentially happening out of order on the CPU level double check locking can still fail unless you force the VM not to keep track of references/variables in a thread local way. The volatile keyword does just that in this case.

Peter Taucher wrote:

Still broken i think, should be :

or ofcourse as was mentioned :

Here you go, about 2,500 times faster on my computer and should be relatively generic :
10 years ago

Istvan Kovacs wrote:

Andraz Poje wrote:

How do I get more precise result?

Besides running many times and making sure you get the JIT compiler to actually compile your code before benchmarking, you may want to check out System.nanoTime().

Are there any VM implementations where System.nanoTime() isn't System.currentMillis() * 1000? I have yet to run into any. Also, the granularity of System.currentMillis() is so ridiculously unpredictable and high that you need a LOT of iterations of naturally quick operations to get accurate timing information. You can avoid JIT based inaccuracies by running your complete test a couple of times within a single execution cycle of your program so you're basically doing :

equals test
regex test
compare test
equals test
regex test
compare test
equals test
regex test
compare test

Dismiss the first X as potential runs that were influenced by a lack of JIT compilation and off you go. Now...

All that said, this seems a rather theoretical excersize because I sincerely doubt there are real world programs where switching from compareTo() to equals() provides a significant performance improvement. Add to that that equals() is the most obvious option anyway it should rarely be a problem.

By the way, the performance differences can be explained quite easily :

1) match uses regex which need to be compiled and pattern matched, as explained above
2) equals generally performs better than compare because it has an early-out before it enters its inner loop that's almost always used, namely s1.length() != s2.length(). A compare needs to do the s1.charAt(i) - s2.charAt(i) for the first different character regardless of string length. You will find different results if you always compare equal length strings. Or more specifically, you will see that compareTo and equals performance will be similar.
10 years ago
At the risk of derailing the topic slightly. How did you end up requiring data from 5 unrelated tables yet requiring said data for a single DAO? What is the relationship and why does it not have a similar relationship in your data model. The reason I'm asking is because if you can add said relationship in your data model you can probably create a single query to retrieve all required data for your DAO and let the database worry about optimizations such as parallelism, fetch buffers, caching, etc.
10 years ago
Can you give us some details on the size and properties of a record and on what kind of hardware this is supposed to be running on? 50k records is practically nothing. Short of every CSV record taking 5-10k and the uniqueness check being complicated for some reason there is no reason this can't all be done within a single digit amount of seconds, and in memory, by the way.
10 years ago
Hey guys,

We have the following problem that I'm hoping you guys have a solution for :

We have a table "Item" with a column "name". We want to be able to determine in a consistent, concurrency safe way that we can add a new record of type "Item" with a value for "name" that is unique. As most readers will know JPA only supports optimistic locking but we have no issues with using vendor specific pessimistic locking. That said I still cannot figure out a good way to do something like this without using database level uniqueness constraints which is something we really want to avoid (we do not always have access to client databases and whether or not this field has to be unique is an application setting that varies across different deploys for us, so doing it on an app level is a lot easier for us). Is there a way to do this without table locks?

I hope someone has a good suggestions for us, thanks!
Have you tried the very first google hit that "linked list in java" gives?
10 years ago
Can I add that storing currency in floating point formats is usually not a good idea. Have a google on the topic.

EDIT : Ernesto's solution would be the one I'd use
10 years ago

ramprasad madathil wrote:I understand the benefits of the concurrent package.

>I personally think it is preferred to seperate the work itself from the component that needs to decide if work needs to be done in the first place. This'll allow you to, for example, define different kinds of work in different classes while using the same controller class to trigger the work (that's another reason to use Runnable, you can pass different units of work to the same thread instance over and over if desired).

I was looking for some thing on those lines - Thank you for that


You're very welcome, ThreadPoolExecutor + Runnable will give you exactly what you need