On 12/9/2013 4:28 PM, Peter Levart wrote:
On 12/09/2013 08:02 AM, Shi Jun Zhang wrote:
Peter,
I think you are misunderstanding this problem. This deadlock is not
related to the formatter synchronization, we can make
CustomerFormatter.format not synchronized and not call super.format
On 12/9/2013 4:40 PM, Peter Levart wrote:
On 12/09/2013 09:28 AM, Peter Levart wrote:
On 12/09/2013 08:02 AM, Shi Jun Zhang wrote:
Peter,
I think you are misunderstanding this problem. This deadlock is not
related to the formatter synchronization, we can make
CustomerFormatter.format
On 12/9/2013 8:04 PM, Peter Levart wrote:
On 12/09/2013 10:50 AM, Shi Jun Zhang wrote:
On 12/9/2013 4:40 PM, Peter Levart wrote:
On 12/09/2013 09:28 AM, Peter Levart wrote:
On 12/09/2013 08:02 AM, Shi Jun Zhang wrote:
Peter,
I think you are misunderstanding this problem. This deadlock
On 12/9/2013 10:01 PM, Peter Levart wrote:
On 12/09/2013 11:12 AM, Daniel Fuchs wrote:
On 12/9/13 9:58 AM, Peter Levart wrote:
On 12/09/2013 09:51 AM, Shi Jun Zhang wrote:
On 12/9/2013 4:28 PM, Peter Levart wrote:
On 12/09/2013 08:02 AM, Shi Jun Zhang wrote:
Peter,
I think you
On 12/6/2013 12:53 AM, Jason Mehrens wrote:
Shi Jun Zhang,
This problem is like hooking up your sink drain to your sink faucet.
Even if it you can get it to work you still would not want to use
it. In your code example you could just pre-pend the thread name to
the formatter string
...
Anyway, if usage of the 'synchronized' keyword never appears in
the Javadoc I guess that's for good reasons...
Thanks Alan,
-- daniel
-Alan
Hi Daniel,
This thread is silent for several days, do you have any finding in
Handler.publish?
--
Regards,
Shi Jun Zhang
On 11/29/2013 5:25 PM, Daniel Fuchs wrote:
On 11/29/13 7:19 AM, Shi Jun Zhang wrote:
On 11/29/2013 1:21 AM, Daniel Fuchs wrote:
Hi Shi Jun Zhang,
I agree with Peter.
It is strange that CustomFormatter calls Logger.log. This looks like
the source of the deadlock.
Hi Daniel,
I explained why
On 11/28/2013 8:13 PM, Peter Levart wrote:
On 11/28/2013 08:53 AM, Shi Jun Zhang wrote:
The problem is that we use a logger in CustomerFormatter and this
causes Logger.log call Logger.log itself. As FileHandler.publish and
StreamHandler.publish is synchronized, but the iteration to call
On 11/29/2013 1:21 AM, Daniel Fuchs wrote:
Hi Shi Jun Zhang,
I agree with Peter.
It is strange that CustomFormatter calls Logger.log. This looks like
the source of the deadlock.
Hi Daniel,
I explained why we call Logger.log in CustomerFormatter in another mail
replied to Peter
,
Shi Jun Zhang
On 7/5/2013 10:58 AM, Jonathan Lu wrote:
On 07/03/2013 11:04 AM, Shi Jun Zhang wrote:
On 7/1/2013 11:49 PM, Chris Hegarty wrote:
On 1 Jul 2013, at 17:22, Remi Forax fo...@univ-mlv.fr wrote:
On 07/01/2013 09:43 AM, Shi Jun Zhang wrote:
On 6/29/2013 12:05 AM, Shi Jun Zhang wrote:
On 6/28
On 7/1/2013 11:49 PM, Chris Hegarty wrote:
On 1 Jul 2013, at 17:22, Remi Forax fo...@univ-mlv.fr wrote:
On 07/01/2013 09:43 AM, Shi Jun Zhang wrote:
On 6/29/2013 12:05 AM, Shi Jun Zhang wrote:
On 6/28/2013 9:02 PM, Alan Bateman wrote:
On 27/06/2013 22:13, Remi Forax wrote:
On 06/27/2013 10
On 6/29/2013 12:05 AM, Shi Jun Zhang wrote:
On 6/28/2013 9:02 PM, Alan Bateman wrote:
On 27/06/2013 22:13, Remi Forax wrote:
On 06/27/2013 10:02 AM, Shi Jun Zhang wrote:
Hi,
There are some isEmpty() check added into get/remove methods since
8011200 to return directly if HashMap is empty
On 6/28/2013 9:02 PM, Alan Bateman wrote:
On 27/06/2013 22:13, Remi Forax wrote:
On 06/27/2013 10:02 AM, Shi Jun Zhang wrote:
Hi,
There are some isEmpty() check added into get/remove methods since
8011200 to return directly if HashMap is empty. However isEmpty is a
non-final public method
this is a bug or a wrong usage of extending HashMap? I find
there is a similar usage in javax.swing.MultiUIDefaults which extends
Hashtable.
--
Regards,
Shi Jun Zhang
/rev/e988de7465d4
Best regards!
- Jonathan
Thanks, Alan and Jonathan.
--
Regards,
Shi Jun Zhang
On 11/29/2012 6:40 PM, Alan Bateman wrote:
On 29/11/2012 07:17, Shi Jun wrote:
Hi all,
Previously 7099119 is fixed in the following changeset:
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dd55467dd1f2, but this
change is lost during the Mac port merging changes 7113349 and 7146424.
Hereby I
On 3/22/2012 12:36 PM, Charles Lee wrote:
On 03/21/2012 10:47 AM, Shi Jun Zhang wrote:
On 3/12/2012 11:28 AM, Shi Jun Zhang wrote:
On 3/9/2012 6:05 PM, David Holmes wrote:
On 9/03/2012 7:04 PM, Alan Bateman wrote:
On 09/03/2012 08:01, Shi Jun Zhang wrote:
The situation in NativeThread.c
On 3/12/2012 11:28 AM, Shi Jun Zhang wrote:
On 3/9/2012 6:05 PM, David Holmes wrote:
On 9/03/2012 7:04 PM, Alan Bateman wrote:
On 09/03/2012 08:01, Shi Jun Zhang wrote:
The situation in NativeThread.c is more complicated than other 2
files. I'm not familiar with BSD or Mac. It seems that we
On 3/9/2012 6:05 PM, David Holmes wrote:
On 9/03/2012 7:04 PM, Alan Bateman wrote:
On 09/03/2012 08:01, Shi Jun Zhang wrote:
The situation in NativeThread.c is more complicated than other 2
files. I'm not familiar with BSD or Mac. It seems that we don't need
to signal threads on BSD or Mac
On 3/8/2012 7:25 PM, Alan Bateman wrote:
On 08/03/2012 08:09, Shi Jun Zhang wrote:
There is still no reply from build infra project and even if it is in
build infra, it will take a long time to merge back to trunk. But
this including pthread problem really affects AIX platform. I'm
thinking
__solaris__ form because all other POSIX-conformant
platforms (BSD, Mac, AIX, ...) except Solaris need to include pthread.h.
Here is the webrev:
http://cr.openjdk.java.net/~zhangshj/pthread/webrev.00/
--
Regards,
Shi Jun Zhang
On 3/2/2012 3:53 PM, David Holmes wrote:
On 2/03/2012 5:05 PM, Shi Jun Zhang wrote:
Currently jdk/src/solaris/bin/java_md.c includes pthread.h with
#ifdef __linux__, but BSD, MAC OS, AIX all needs to include pthread.h.
To avoid the situation that the ifdef clause becomes longer and longer
like
pthread.h only needs to use
#ifdef USE_PTHREADS. The files include pthread.h are
jdk/src/solaris/bin/java_md.c
jdk/src/solaris/native/sun/nio/ch/NativeThread.c
jdk/src/solaris/transport/socket/socket_md.c
Any comments?
--
Regards,
Shi Jun Zhang
24 matches
Mail list logo
