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 are
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 is
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 not
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,
the
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 and
ding
j.u.l APIs...
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/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
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
that
Logger is not "so much" multi-thread safe.
Any suggestion or better fix?
--
Regards,
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 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
On 7/1/2013 11:49 PM, Chris Hegarty wrote:
On 1 Jul 2013, at 17:22, Remi Forax 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:02 AM, Shi Jun
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
s.
Do you think 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
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 is
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 th
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
On 3/8/2012 7:59 PM, David Holmes wrote:
On 8/03/2012 6:09 PM, Shi Jun Zhang wrote:
On 3/2/2012 5:05 PM, Alan Bateman wrote:
On 02/03/2012 07:53, David Holmes wrote:
Yes we need to move to a more capability based inclusion &
conditional compilation mechanism. I'm not sure if the bu
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
thi
thinking we
can use #ifndef __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 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
to include 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
23 matches
Mail list logo