MessagePack template lookup causing stuck threads in WebLogic?

Question

We're using MessagePack 0.6.6 for Java in Grails 2.0 on WebLogic 11g (10.3) to serialize string data...

public void serialize(Object object, OutputStream outputStream) 
   throws IOException {
   byte[] bytes = MessagePack.pack(object);
   outputStream.write(bytes);
   outputStream.flush();
}

The problem we're seeing in WebLogic is lots of STUCK threads, so we dumped the thread stack and found some threads getting stuck at org.msgpack.template.TemplateRegistry.lookup(TemplateRegistry:198), see dump below. We're confident our code did not introduce this issue since, in the example above, it's clear we're using MessagePack.pack() in a thread-safe manner. Looking at TemplateRegistry.java, line 198, lookup() is synchronized, but we're not sure why it's causing stuck threads.

        "[STUCK] ExecuteThread: 
    '1' for queue: 'weblogic.kernel.Default (self-tuning)'" id=43 idx=0xec tid=60 prio=1 alive, in native, blocked, daemon

-- Blocked trying to get lock: org/msgpack/template/TemplateRegistry@0xfffffffe8c2fb8e8[fat lock]
    at jrockit/vm/Threads.waitForUnblockSignal()V(Native Method)
    at jrockit/vm/Locks.fatLockBlockOrSpin(Locks.java:1679)[optimized]
    at jrockit/vm/Locks.lockFat(Locks.java:1780)[optimized]
    at jrockit/vm/Locks.monitorEnterSecondStageHard(Locks.java:1312)[optimized]
    at jrockit/vm/Locks.monitorEnterSecondStage(Locks.java:1259)[optimized]
    at jrockit/vm/Locks.monitorEnter(Locks.java:2466)[inlined]
    at jrockit/vm/Locks.monitorEnterForced(Locks.java:859)[optimized]
    at jrockit/vm/RNI.c2java(JJJJJ)V(Native Method)   
    at jrockit/vm/Locks.monitorEnterUnmatched(Ljava/lang/Object;)V(Native Method)
    at org/msgpack/template/TemplateRegistry.lookup(TemplateRegistry.java:198)[optimized]         
    at org/msgpack/MessagePack.write(MessagePack.java:195)[inlined]
    at org/msgpack/MessagePack.pack(MessagePack.java:639)[inlined]

score 1 · Answer 1 · answered Aug 31 '12 at 08:49

According the current MessagePack JavaDoc the static pack(Object v) method is deprecated and the not static method write(Object) is recommended to be used.

Usage Example:

MessagePack msgpack = new MessagePack();
byte[] bytes = msgpack.write(object);

Could you check whether the usage of the write method solves the problem?

19 Lee · Accepted Answer · 2014-02-09T13:23:15.647

You should use packer and unpacker as this blog says.

MessagePack msgpack = new MessagePack(); // singleton
Packer packer = msgpack.createPacker(outputStream); // createPacker every time
packer.write(object);

Following code may yield a perm gen memory error if you do too many since new MessagePack() loads classes every time.

MessagePack msgpack = new MessagePack();
byte[] bytes = msgpack.write(object);

score 0 · Answer 3 · answered Mar 13 '15 at 16:59

0

I believe it's not make sense to create packer manually, as long MessagePack.write() does that for you

public byte[] write(T v) throws IOException { BufferPacker pk = createBufferPacker();

I do have perm gen error you are talking about, so what I'm thinking about is to just use one MessagePack instance across all my app, is it make sense how do you think?

answered Mar 13 '15 at 16:59

Andriy Kopachevskyy

7,276
10
47
56

@raffian I partly agree with Lee, I just claim that in latest message pack version when you call new MessagePack().write(someObject) method, new message packer created by default, so you don't have to create it explicitly it sufficient to just call write method on MessagePack instance . Check source codes please and show me where I'm wrong if you not agree with this statement. – Andriy Kopachevskyy Mar 14 '15 at 00:52
I believe you, and I did not say you're wrong, just said Lee's answer was sufficient for my original question. – raffian Mar 14 '15 at 01:12

MessagePack template lookup causing stuck threads in WebLogic?

3 Answers3