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