Win a copy of Bad Programming Practices 101 (e-book) this week in the Beginning Java forum!

Henry Wong

+ Follow
since Sep 28, 2004
Henry likes ...
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
New York City
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 Rancher Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Henry Wong

Suhaas Mohandos wrote:Here using the variable i which is a local variable inside run() method I am able to acheive the same thing which is independent copy for every thread. Then what is the need for a ThreadLocal variable concept?

The scope of a local variable is for the method call only. What if you want the variable at a larger scope than a single method?


Chaitanya Vaishampayan wrote:
Can someone please explain why is this happening ? And how to prevent this from happening and making it work as expected.

Synchronization is cooperative. Owning a lock prevents another thread from owning the same lock. There is no magic to automatically prevent any other thread to access any component of the object, that happens to be used as a lock.


Norm Radder wrote:
Very hard to say what the problem is without seeing code that executes and shows the problem.

I can take a guess.... There is an optimization with serialization. When you send the same object again, the system will detect it, and mark it as a resend. This means that you can't send a mutable object, make some changes, and send the same object again. The other side will detect it as the same object, and return the same reference.

If you want the Object stream to disregard previous sends, then use the reset() method.



Kathir jeyap wrote:
What are the differences between websocket vs TCP vs Push Notification ???

TCP is a type of transport on the socket. The other being UDP. There are actually others, but never mind those...

HTTP is a protocol that is on top of TCP. This is the protocol that is used by web servers. When browsers connects to the web servers, this is the most common protocol that is used.

For security reasons, when a web application (that comes from the internet using HTTP) tries to connect to hosts, it is only allowed to connect to the same host and port. There is another feature that can cross domain to another web server. Regardless, this means that it must connect to a web server -- and unfortunately, this means that it must also use HTTP.

Anyway, enter web sockets.... A web socket starts off as a HTTP connection. During the connection, the protocol will request an upgrade. This upgrade is for a fully connected long term raw connection to the web server. In other words, the upgrade is for the HTTP protocol to get out of the way, and treat the connection as simply a TCP connection.

Push notifications, is a mobile phone feature. Not really a mobile phone developer, so I will let others elaborate.

Hope this helps,
3 days ago

fred rosenberger wrote:
And a good actor often can't do much with a bad script.  My family found "Mama Mia" to be unwatchable.  I mean...Meryl Streep, Colin Firth, Christine Baranksi...These are not exactly "hacks".  Yet the script was so horrible, we turned it off.

Mama Mia is basically following the broadway show, so, it can't really deviate much from that...

And as for the broadway show, that is basically a lightly threaded story for ABBA music. When it first came out, I don't think many people thought it was more than that.... but... I can see your point. By the time it got to the movie stage, much of that is lost -- and the movie is for the masses at that point.

3 days ago

Vyacheslav Belenky wrote:
(2) The output of the program might be 0 instead of 42 because of a reordering phenomenon, that is, first the ready variable will be set to true and after that the number variable will be set to 42

I ran with parameter 500 (500 attempts) on a Linux, Mac, and Windows but couldn't replicate.

To replicate the issue, I think...

First, you will need to find a Java compiler that will re-order for that exact example. Keep in mind that the Java compiler can do code motion for optimization purposes. It is not reordering randomly. If your example doesn't have any benefit from having code motion, there is no reason for the compiler to do it.

Second, assuming you can achieve the code motion, then it is still a race condition. You need to try it with different OSes, with different hardware, with different loads (other programs running), and even then, it may only occurs after years of trying. Heck, it may only occur for a future machine that hasn't been built yet.

Again, the author is basically saying that there is nothing (as stated in the Java specifications) that can guaranteed the correct output for that example.


Vyacheslav Belenky wrote:
(1) ReaderThread will never see the change the main thread made to the ready variable (setting it to true) and thus will be a forever loop

Interestingly, you may never see this issue trigger in that example code.  The reason is... most OSes will flush all caches during a context switch. And even on high end boxes, with plenty of cores, most, if not all, OSes have timer interrupts that run to service it -- which of course, will flush the caches. This means, eventually, the ready variable will change.

Regardless, the author is basically saying that there is nothing (as stated in the Java specifications) that can guaranteed the memory flush. And the author is correct.


Vyacheslav Belenky wrote:To be honest, I was not aware that concurrency in Java is so scary, in a sense that it's possible that a thread will not see a change in a shared variable that another thread makes.

BTW, what you are describing is not specific to Java.... Using threading without any synchronization may have memory inconsistency issues. The reasoning is, there are caches and registers, that are used to load/store variables -- in order to operate on them. And there are optimizations that will keep those values in those caches/registers longer.

Basically, do *not* share variables between threads without correct synchronization.


The JMS API is a way to interface to messaging environments. Many of the questions that you are asking are specific to the implementation that you are using. Perhaps, it would be a good idea to research the messaging environment that you are using.

4 days ago

Vaibhav Gargs wrote:
Which acknowledgement mode we should be using for this case? And, suppose our application consumed the message successfully, and in the meanwhile, the broker gets restarted without having any acknowledgement, then, i believe it will redeliver the message, right? And, what will happen for non-persistent messages?

It is the responsibility of the receiver to detect duplicates (with some help from the sender). Depending on the configuration, the message may be redelivered, and you have to do dup detection.

Non persisted messages do not survive restarts...

5 days ago

Ron McLeod wrote:
Could the the JMSCorrelationID header be used for this if it wasn't already being used for other purposes?

Using a header if fine too.... but regardless, to guarantee it, it is the responsibility of both the sending application and receiving application. It can't be done one sided.

5 days ago

... but ... to answer your question...

Vaibhav Gargs wrote:how can we identify the duplicates JMS messages?

If you want it guaranteed, you can only do it by payload. It is your message, sent by your publishers/producers, and for your subscribers/consumers; so, only your application knows that the message has been processed. Now, you can argue that it can be done via sequence numbers, yadda yadda  yadda, but, keep in mind, that that means that your publisher can't double publish (and also, have restart mechanisms that guarantees never to republish).

6 days ago

This is a side discussion... but... simply, if you are not using transactions, you are always responsible for duplicate detection.

In the case of queuing (if you don't use transactions), you get a message, you have to process the message, you have to tell the broker that you processed it, and finally, the broker confirming that it has been consumed. etc.... and ... somewhere between processing the message and the broker confirming that it has been processed, is the point where you want the message to be no longer delivered. Unfortunately, the actually point is where the broker confirms it (that it can survive a restart).

So, if you processed it to the point where you are okay with it, and the environment dies before it is confirmed, it will be redelivered on restart.... so... in other words, without transactions, you are responsible for duplicate detection.

6 days ago

Vyacheslav Belenky wrote:
Question: should I change the way I think about protected members of a superclass?

Not exactly sure what you mean ... except... it doesn't compile because of rule 6.6.2 of the JLS...

... or basically, the TestClass is not responsible for the protected members of the PublicClass (and in different package), and hence, can't access it. This is regardless of whether the protected member is part of the PublicClass, or inherited from a superclass.


Mary Rani wrote:
What do we mean by "4-6 clock cycles"?

A CPU uses a clock signal to drive it. For example, a 3 Gigahertz CPU, has about 3 billion cycles per second. Each cycle is one up to 5 volts and back down of that clock. Considering that most processors can do at least one instruction per cycle these days, that works out to 3 billion instructions per core per second.

Anyway, to answer your question, 6 cycles on a 3 Gigahertz CPU works out to about (1 / 500,000,000) of a second...

2 weeks ago