FW: How to see SF errors
"Guijarro, Julio" <[email protected]> Mon, 20 Nov 2006 13:07:21 -0000
| Newsgroups | gmane.comp.java.smartfrog.user |
|---|---|
| Message-ID | <[email protected]> |
-----Original Message----- From: Andreas Unterkircher Sent: 20 November 2006 11:08 To: Guijarro, Julio Subject: Re: [Smartfrog-support] How to see SF errors Hello Julio, >> -----Original Message----- >> From: Andreas Unterkircher >> Sent: 17 November 2006 07:51 >> To: Guijarro, Julio >> Subject: Re: [Smartfrog-support] How to see SF errors >> >> Hello Julio, >> >> thanks for your mail. Concerning this topic I'm actually also > interested >> in two applications: >> >> Communication with a running component: >> We use the management console to change attributes in a running >> component. Now if you change the attribute to a bad value you should >> immediately get a warning by the component (otherwise you could have a >> bad surprise when the component terminates because its then when the >> attribute is relevant). > > The only way to check this is to use runtime predicates that could > evaluate the attributes once changed. Now the predicates propagate to > runtime when they are LAZY but we don't have a way from the console to > trigger any method call or similar. The way to do it automatically would > be to overwrite sfAdd/sfModifyAttribute and then run the runtime check. > These methods can throw SmartFrog exception that the exception would be > detected by the console. > >> Distributed tail: >> I'd like to have components that can do a distributed tail. I.e. they >> get the newlines added to files on different machines and merge these >> into a display on my machine. >> Note that if we'd have a distributed tail I could already solve the >> above problem and also the logging thing as you could always do a tail >> on the log files SF creates on the different machines. > > Good idea. We don't have anything like this but it would not be > difficult to implement. The log can be distributed but it is not > documented because I want to change a couple of things that I am not > happy with before people start depending on it. > >> BTW could one use the ManagementConsole output window to do this? > > The console can do that. This is similar to what the TraceConsole does. > The trace component collects the data and this data is sent to a > component implementing Display, in this case the trace console. In > addition to printing the text in the output tab, the trace console > parses that text and creates a tree in another tab. > >> Best regards, >> Andreas >> > Do you mind if I copy this message to the distribution list? > > Thanks, > > Julio > >> Guijarro, Julio wrote: >>> Andreas, >>> >>> I think the problem that you have is due to the way you deploy your >>> description. >>> >>> When deploying a description, the command sfStart will not return > until >>> the sfStart lifecycle method of the root component of your > description >>> has completed. If this component is deploying Parallel components, > then >>> it will almost return immediately, and the shell script won't > receive >>> more notifications about the lifecycle of that application, because >>> parallel has its own thread to drive the sfStart lifecycle of its >>> children. >>> >>> If you want to continue receiving notifications you can do several >>> things: >>> a) build a root component for your application that is capable of >>> sending notifications when something happens, you can even use the >>> lifecycle hooks (see trace component for an example) and this > component >>> could use, for example, the jabber component to send notifications > to a >>> central server, email, or multicast. >>> >>> b) add components to your description to send notifications about > the >>> progress of the system. For an example check how the dynamic web > server >>> example sends notifications about the installation steps. >>> >>> C) you can register your new application as a child of a component > which >>> mission is to receive notifications and liveness events of its > children >>> and then react to it (raise alarms, send events, emails, ...) >>> If you use the command line to deploy your description, then you can >>> register your new application with your special compound using the >>> following syntax: >>> >>> smartfrog -a "HOST >>> > localhost:sfDefault:Andreas":DEPLOY:org/smartfrog/examples/counter/examp >>> le.sf::localhost: >>> -e >>> >>> This will deploy counter component called "Andreas" as a child of >>> localhost:sfDefault. Note that sfDefault has to be capable of having >>> children. >>> >>> >>> Julio >>> >>> >>> >>>> -----Original Message----- >>>> From: smartfrog-support-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org >>> [mailto:smartfrog- >>>> support-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of Andreas >>> Unterkircher >>>> Sent: 15 November 2006 08:04 >>>> To: smartfrog-support >>>> Subject: [Smartfrog-support] How to see SF errors >>>> >>>> >>>> Hello, >>>> >>>> We're running the SF deamon (as a service, no gui) on several >>> machines. >>>> There logging is configured like >>>> >>>> > org.smartfrog.sfcore.logging.LogImpl.loggerClass=org.smartfrog.sfcore.lo >>> gg >>>> ing.LogToFileImpl >>>> >>>> We always deploy on one host hostA a description that has >>> subcomponents >>>> that get deployed to other hosts (with sfProcessHost hostB etc.). > The >>>> problem is that if I deploy such a description from my machine with >>>> >>>> sfStart hostA ... >>>> >>>> if there is any error in deployment I don't see it on my machine, > but >>> I >>>> have to look into the log file on hostA or even into log file of > the >>>> host the subcomponent got deployed to with sfProcessHost (it seems > to >>> me >>>> that the errors encountered get also logged on hostA, but I'm not > sure >>>> if this is always the case). Now the question: >>>> Is it possible to propagate these errors back to my machine so that > I >>>> see it in my local terminal where I typed "sfStart..." ? >>>> >>>> Thanks, >>>> Andreas >>>> >>>> >>>> > ------------------------------------------------------------------------ >>> - >>>> Take Surveys. Earn Cash. Influence the Future of IT >>>> Join SourceForge.net's Techsay panel and you'll get the chance to >>> share >>>> your >>>> opinions on IT & business topics through brief surveys - and earn > cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE >>> V >>>> _______________________________________________ >>>> Smartfrog-support mailing list >>>> Smartfrog-support-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org >>>> https://lists.sourceforge.net/lists/listinfo/smartfrog-support >> >> -- >> Andreas Unterkircher >> IT Department >> Grid Deployment Group >> CERN >> CH-1211 Geneva 23 -- Andreas Unterkircher IT Department Grid Deployment Group CERN CH-1211 Geneva 23 ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV