SGS ate my exception stacktrace... :(

[chumDS]

Blargh!

I’m certain that I’ll eventually be able to track this down, but it’d sure be handy if I could get those last 14 lines of the stack trace…

May 5, 2007 12:37:36 PM com.sun.sgs.impl.kernel.schedule.MasterTaskConsumer run
WARNING: dropping a task that failed with a non-retryable exception: com.sun.sgs.service.TransactionRunner[owner:[ id=“user” context=Aethyria ]]
com.sun.sgs.app.ObjectIOException: ManagedObject was not referenced through a ManagedReference:
-object (class “Aethyria.AePlayerConnection”, Player.USER@f4705fee2e30b39a)
[remainder of class-fields snipped]
at com.sun.sgs.impl.service.data.SerialUtil.check(SerialUtil.java:236)
at com.sun.sgs.impl.service.data.SerialUtil.serialize(SerialUtil.java:89)
at com.sun.sgs.impl.service.data.ManagedReferenceImpl.flush(ManagedReferenceImpl.java:481)
at com.sun.sgs.impl.service.data.ReferenceTable.flushChanges(ReferenceTable.java:102)
at com.sun.sgs.impl.service.data.ManagedReferenceImpl.flushAll(ManagedReferenceImpl.java:460)
at com.sun.sgs.impl.service.data.Context.prepareAndCommit(Context.java:224)
at com.sun.sgs.impl.service.data.DataServiceImpl.prepareAndCommit(DataServiceImpl.java:407)
at com.sun.sgs.impl.service.transaction.TransactionImpl.commit(TransactionImpl.java:236)
at com.sun.sgs.impl.service.transaction.TransactionCoordinatorImpl$TransactionHandleImpl.commit(TransactionCoordinatorImpl.java:66)
at com.sun.sgs.impl.kernel.TaskHandler.runTransactionalTask(TaskHandler.java:144)
at com.sun.sgs.service.TransactionRunner.run(TransactionRunner.java:46)
at com.sun.sgs.impl.kernel.TaskHandler.runTaskAsOwner(TaskHandler.java:101)
at com.sun.sgs.impl.kernel.schedule.MasterTaskConsumer.run(MasterTaskConsumer.java:91)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:613)
Caused by: com.sun.sgs.app.ObjectIOException: ManagedObject was not referenced through a ManagedReference: Player.USER@f4705fee2e30b39a
at com.sun.sgs.impl.service.data.SerialUtil$CheckReferencesObjectOutputStream.replaceObject(SerialUtil.java:139)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1045)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
at java.util.HashMap.writeObject(HashMap.java:985)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:917)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1339)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1375)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1347)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
at java.util.HashMap.writeObject(HashMap.java:985)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:917)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1339)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1375)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1347)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
at java.util.HashMap.writeObject(HashMap.java:985)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:917)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1339)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1375)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1347)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1290)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1079)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:302)
at com.sun.sgs.impl.service.data.SerialUtil.serialize(SerialUtil.java:85)
… 14 more

I was really hoping to see a reference to some of MY code in here!

Any hints as to how I can get at it, aside from half-splitting and shotgun approaches?

Thanks!

[Hoyle]

@chumDS

May 5, 2007 12:37:36 PM com.sun.sgs.impl.kernel.schedule.MasterTaskConsumer run
WARNING: dropping a task that failed with a non-retryable exception: com.sun.sgs.service.TransactionRunner[owner:[ id=“user” context=Aethyria ]]
com.sun.sgs.app.ObjectIOException: ManagedObject was not referenced through a ManagedReference:
-object (class “Aethyria.AePlayerConnection”, Player.USER@f4705fee2e30b39a)
[remainder of class-fields snipped]
at com.sun.sgs.impl.service.data.SerialUtil.check(SerialUtil.java:236)
at com.sun.sgs.impl.service.data.SerialUtil.serialize(SerialUtil.java:89)

Not sure if the last lines of the stack trace will help you. This may be occuring in a seperate thread and thus outside of your code.

What’s happening is your object “Aethyria.AePlayerConnection” is being referenced in some object that is being serialized. ManagedObjects can not be serialized within other objects, instead you have to use a ManagedReference.

You should look for any case where you have a Serialized object that is referencing your AePlayerConnection. I often do this by accident quite regularly.

Hope that helps.

p.s. on a side note, it would be nice if the class that was trying to be serialized was also displayed along with the name of the ManagedObject.

[Jeff]

@Hoyle

p.s. on a side note, it would be nice if the class that was trying to be serialized was also displayed along with the name of the ManagedObject.

Good thought, I’ll suggest it to the team 8)

We’re working on the Darkstar ortal now, One thing we should definitely have is an RFE section to catch these great ideas in a more organized fashion.

[chumDS]

@Hoyle

Not sure if the last lines of the stack trace will help you. This may be occuring in a seperate thread and thus outside of your code.

What’s happening is your object “Aethyria.AePlayerConnection” is being referenced in some object that is being serialized. ManagedObjects can not be serialized within other objects, instead you have to use a ManagedReference.

Right. And, of course, that WAS the problem, which I eventually traced back to me accidentally putting the ManagedObject on my list rather than its reference.

The thing I was hoping to get out of SGS was the debugging aid of a full stack trace which, at the very least, would’ve come back to a line in one of my tasks, right? (Well, in this case, it would’ve.)

Anyway – of course it’s possible to debug this stuff without system-help; I was just suggesting that it’d sure be nice to GET the system-help. “It’s 2007”, and all that

Btw, I’m rather excited that I’m currently serving-up frame data that includes moving objects and displaying them in a SGS/J3D client. Probably no big deal to all of you who have gone further, but a major milestone in this project.

“It’s all downhill <cough, cough> from here!”

[Jeff]

@chumDS

Right. And, of course, that WAS the problem, which I eventually traced back to me accidentally putting the ManagedObject on my list rather than its reference.

The thing I was hoping to get out of SGS was the debugging aid of a full stack trace which, at the very least, would’ve come back to a line in one of my tasks, right? (Well, in this case, it would’ve.)

Nope.

Cause that exception isn’t thrown when you put it in the field. We have no way of catchign that.\

The exception happens in the SGS commit code.
The suggestion that it report the object whose serialization triggered the exception though is a good idea.

Btw, I’m rather excited that I’m currently serving-up frame data that includes moving objects and displaying them in a SGS/J3D client. Probably no big deal to all of you who have gone further, but a major milestone in this project

Cool. Im sure everyone would love to see a screan shot or two when your ready!
.

[chumDS]

@Jeff

Cause that exception isn’t thrown when you put it in the field. We have no way of catchign that.\

Right, I get that – but it happened during execution of a TASK, right? That is, one of my tasks was attempting to make use of a ManagedObject that it didn’t “own” (i.e., didn’t get from a reference) – right?

(If I’m TOTALLY mis-reading the error, well… shame on me! But I got the impression that this all happened on my task.)

So what I was asking for was the stack-trace back to my task code.

The exception happens in the SGS commit code.
The suggestion that it report the object whose serialization triggered the exception though is a good idea.

Sure, that’d help, too.

Cool. Im sure everyone would love to see a screan shot or two when your ready!

Oh, you’ll be seeing 'em, don’t worry about that! 8)

[galthaus]

@chumDS

Right, I get that – but it happened during execution of a TASK, right? That is, one of my tasks was attempting to make use of a ManagedObject that it didn’t “own” (i.e., didn’t get from a reference) – right?

(If I’m TOTALLY mis-reading the error, well… shame on me! But I got the impression that this all happened on my task.)

So what I was asking for was the stack-trace back to my task code.

I think this is a semantic problem. As a user of the API, the task isn’t “ours”. The code “using” the API is a small part of the system. The SGS kernel has tasks for handling incoming messages, timers, and data persistence. I’m sure I’m grossly over-simplifying this. The incoming-message handler does some processing to determine the appropriate API callback on an appropriate object. That is where our code comes in. When that code completes, the task does the other system things needed to continue operations. I assume (and from playing with it some) that the persists and reply messages and other things happen then.

In my thinking about it, I’ve been trying to always remind myself that the API is pretty much completely set up to be an event drvien/callback model. Even initialization seems to operate that way. (I have a jME/SGS system that I’ve been playing with.)

I guess the comments are a little off topic, but oh well.

[Jeff]

Your basically correct.

Your task code is called by the system. Commit happens after your code returns control to the system.

Thus although serialization happens in the same thread as your code, it happens outside of your code itself.

A full trace would just show the call stack disappearing into the bowels of our tasking kernel.