You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@karaf.apache.org by "Ioannis Canellos (Created) (JIRA)" <ji...@apache.org> on 2011/12/24 13:06:30 UTC

[jira] [Created] (KARAF-1125) Cellar events should include all the information required for the processing of the event.

Cellar events should include all the information required for the processing of the event.
------------------------------------------------------------------------------------------

                 Key: KARAF-1125
                 URL: https://issues.apache.org/jira/browse/KARAF-1125
             Project: Karaf
          Issue Type: Improvement
            Reporter: Ioannis Canellos
            Assignee: Ioannis Canellos


When an event is processed in Cellar most of the time a lookup to the distributed registry is required.

I can see a couple of issues with this approach:
i) Unnecessary access to the distributed resources. 
ii) The state of the group is only in memory and is not persisted anywhere.
iii) Having the state in the distributed memory its not easy to view the state of a group.

I think that we should not use distributed memory as registry at all. Each event should contain all the information required for its processing and those information should be persisted locally on each node (configuration admin / fileinstall).

The only thing that maybe needs to be addressed, is what happens when a new node joins a group. I am thinking that it should not be really hard to send something like "request group config" command and then just process the result.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

[jira] [Commented] (KARAF-1125) Cellar events should include all the information required for the processing of the event.

Posted by "Jean-Baptiste Onofré (Commented JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/KARAF-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175713#comment-13175713 ] 

Jean-Baptiste Onofré commented on KARAF-1125:
---------------------------------------------

Yes, we can use the ConfigAdmin to store that, and use Cellar itself to replicate the state (using a config listener).
                
> Cellar events should include all the information required for the processing of the event.
> ------------------------------------------------------------------------------------------
>
>                 Key: KARAF-1125
>                 URL: https://issues.apache.org/jira/browse/KARAF-1125
>             Project: Karaf
>          Issue Type: Improvement
>          Components: cellar-core
>            Reporter: Ioannis Canellos
>            Assignee: Ioannis Canellos
>
> When an event is processed in Cellar most of the time a lookup to the distributed registry is required.
> I can see a couple of issues with this approach:
> i) Unnecessary access to the distributed resources. 
> ii) The state of the group is only in memory and is not persisted anywhere.
> iii) Having the state in the distributed memory its not easy to view the state of a group.
> I think that we should not use distributed memory as registry at all. Each event should contain all the information required for its processing and those information should be persisted locally on each node (configuration admin / fileinstall).
> The only thing that maybe needs to be addressed, is what happens when a new node joins a group. I am thinking that it should not be really hard to send something like "request group config" command and then just process the result.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

[jira] [Updated] (KARAF-1125) Cellar events should include all the information required for the processing of the event.

Posted by "Jean-Baptiste Onofré (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/KARAF-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Baptiste Onofré updated KARAF-1125:
----------------------------------------

    Fix Version/s: cellar-3.0.0
    
> Cellar events should include all the information required for the processing of the event.
> ------------------------------------------------------------------------------------------
>
>                 Key: KARAF-1125
>                 URL: https://issues.apache.org/jira/browse/KARAF-1125
>             Project: Karaf
>          Issue Type: Improvement
>          Components: cellar-core
>            Reporter: Ioannis Canellos
>            Assignee: Ioannis Canellos
>             Fix For: cellar-3.0.0
>
>
> When an event is processed in Cellar most of the time a lookup to the distributed registry is required.
> I can see a couple of issues with this approach:
> i) Unnecessary access to the distributed resources. 
> ii) The state of the group is only in memory and is not persisted anywhere.
> iii) Having the state in the distributed memory its not easy to view the state of a group.
> I think that we should not use distributed memory as registry at all. Each event should contain all the information required for its processing and those information should be persisted locally on each node (configuration admin / fileinstall).
> The only thing that maybe needs to be addressed, is what happens when a new node joins a group. I am thinking that it should not be really hard to send something like "request group config" command and then just process the result.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

[jira] [Updated] (KARAF-1125) Cellar events should include all the information required for the processing of the event.

Posted by "Ioannis Canellos (Updated) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/KARAF-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ioannis Canellos updated KARAF-1125:
------------------------------------

    Component/s: cellar-core
    
> Cellar events should include all the information required for the processing of the event.
> ------------------------------------------------------------------------------------------
>
>                 Key: KARAF-1125
>                 URL: https://issues.apache.org/jira/browse/KARAF-1125
>             Project: Karaf
>          Issue Type: Improvement
>          Components: cellar-core
>            Reporter: Ioannis Canellos
>            Assignee: Ioannis Canellos
>
> When an event is processed in Cellar most of the time a lookup to the distributed registry is required.
> I can see a couple of issues with this approach:
> i) Unnecessary access to the distributed resources. 
> ii) The state of the group is only in memory and is not persisted anywhere.
> iii) Having the state in the distributed memory its not easy to view the state of a group.
> I think that we should not use distributed memory as registry at all. Each event should contain all the information required for its processing and those information should be persisted locally on each node (configuration admin / fileinstall).
> The only thing that maybe needs to be addressed, is what happens when a new node joins a group. I am thinking that it should not be really hard to send something like "request group config" command and then just process the result.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira