Trying to resolve a manager from within the system context
Project Darkstar Community Forums  
Jul 02, 09, 04:49 pm *

Login with username, password and session length
News:
 
   Home   Help Search Login Register  
Pages: [1]   Go Down
  Print  
Author Topic: Trying to resolve a manager from within the system context  (Read 1763 times)
oak
Hero Member
*****
Offline Offline

Posts: 516



View Profile WWW
« on: Mar 17, 08, 03:04 pm »

I am using a manager/service pair to submit fatal errors in our server by using the logging-system. This is quite a hack but it works very well. Except in the case where a SEVERE-level log message occurs in the system context (here is an example):

Code:
SEVERE: acceptor error on port: 6,655
java.io.IOException: accept failed
        at com.sun.sgs.impl.nio.AsyncServerSocketChannelImpl$1.call(AsyncServerSocketChannelImpl.java:245)
        at com.sun.sgs.impl.nio.AsyncServerSocketChannelImpl$1.call(AsyncServerSocketChannelImpl.java:240)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at com.sun.sgs.impl.nio.Reactor$PendingOperation.selected(Reactor.java:534)
        at com.sun.sgs.impl.nio.Reactor$ReactiveAsyncKey.selected(Reactor.java:764)
        at com.sun.sgs.impl.nio.Reactor.performWork(Reactor.java:308)
        at com.sun.sgs.impl.nio.ReactiveChannelGroup$Worker.run(ReactiveChannelGroup.java:267)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
        at java.lang.Thread.run(Thread.java:619)

Then the logging-system will try to get hold of a manager from the system context, this is not allowed (that makes sense). But trying to get hold of a manager from the system context results in yet an other SEVERE logging message.... and guess what happens then  Grin

Now, I am aware that what I am doing with the logging-system might not be very wise - but it works very well for our test-setup. So here is the real question: Is it possible to test if some code is running in a context suitable for accessing managers, or is the only way trying and catching?
Logged
stp
Moderator
Sr. Member
*****
Offline Offline

Posts: 438


View Profile
« Reply #1 on: Mar 18, 08, 05:43 am »

In the 0.9.5 stack there's really no way to check for this. One thing you could do is ask who the current task owner is, and then look at the identity or context to see if you're running as part of the system (i.e., not an application). FYI, you shouldn't ever be running in this context anyway. It sounds to me like you might be using the context from your Service constructor, and not the one provided when ready() is called.

In the current codebase we're working with, this confusion goes away. There is no exposed notion of "context" except the context of a transaction. The Managers are always available within a transaction, so you don't have to worry about how or when you started a transaction. I think this will make things much simpler, but I don't know when this code will get pushed.

Out of curiosity, why does your logger need access to a Manager? Are you persisting the log messages?


seth
Logged
oak
Hero Member
*****
Offline Offline

Posts: 516



View Profile WWW
« Reply #2 on: Mar 18, 08, 07:53 am »

Out of curiosity, why does your logger need access to a Manager? Are you persisting the log messages?

Sort of, if a message is SEVERE then it is sent to a Service that saves it in the data-store for later posting it to our bug-tracking system.

Our client does the same thing - just without the use of services. This makes it easy for us to track bugs/glitches in the system. It is not pretty but it works very well and gives a good idea about the state of the system.
Logged
stp
Moderator
Sr. Member
*****
Offline Offline

Posts: 438


View Profile
« Reply #3 on: Mar 20, 08, 05:50 am »

That's a cool idea. We've talked about (and experimented with) different transactional logging utilities, but it could also be nice to have the general purpose ability to tag messages for different purposes like this..


seth
Logged
Pages: [1]   Go Up
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.5 | SMF © 2006-2008, Simple Machines LLC Valid XHTML 1.0! Valid CSS!