Hi Carsten,
>hmm, looking at the places where this member variable is assigned, it
>gets reset when the ChangeList is cleared - do you ever clear yours?
>Does _pContainerChanges point to something sensible or is it simply !=
>NULL, but pointing at garbage?
Seems to be reasonable; Is definitely not NULL;
What I saw was that uiEntryDesc was set to 'AddReference', which makes not much sense there or?
I did not find any place where this member variable gets reset; Could you point me there?
I call Thread::getCurrentChangeList()->clear(); after each frame..
> In editMFViews() after the call to editMField() does the above hold,
> i.e. is _pContainerChanges->bvUncommittedChanges == &this->_bvChanged?
> i.e. is _pContainerChanges->bvUncommittedChanges == &this->_bvChanged?
_pContainerChanges->bvUncommittedChanges is NULL while &this->_bvChanged has some value...
> If you add a call to ChangeList::dump() (say before sending it across
> the cluster) does your VDTRenderChannel show up in any of the lists
> dumped and how does that change over time?
> the cluster) does your VDTRenderChannel show up in any of the lists
> dumped and how does that change over time?
I already did this. I can see some AddRef/SubRefs and exactly one 'Changed' state, but this is directly after creation...
Thanks,
Michael
Gesendet: Dienstag, 24. Juni 2014 um 16:54 Uhr
Von: "Carsten Neumann" <carsten.p.neum...@gmail.com>
An: opensg-users@lists.sourceforge.net
Betreff: Re: [Opensg-users] OpenSG2.0: Changelist problems
Von: "Carsten Neumann" <carsten.p.neum...@gmail.com>
An: opensg-users@lists.sourceforge.net
Betreff: Re: [Opensg-users] OpenSG2.0: Changelist problems
Hello Michael,
On 06/24/2014 03:31 PM, Michael Raab wrote:
> Recently we ran into some cluster sync problems that I do not really
> unterstand.
> We have a self implemented fieldcontainer class VDTRenderChannel (full
> fcd is attached). This field container has a MField of Viewports to render.
> I use the method editMFViews() to get access to this MField and to mark
> it as changed to get sync to the servers. Locally everything works fine,
> but beside the initial sync after creation, changes to that class and
> especially to that MField are not synced to our servers. I tried to
> debug that issue and these are my investigations:
> - VDTRenderChannel::changed is never called
> - stepping throw editMFViews() to editMField() into
> registerChangedContainer() it seems that variable _pContainerChanges is
> always present
hmm, looking at the places where this member variable is assigned, it
gets reset when the ChangeList is cleared - do you ever clear yours?
Does _pContainerChanges point to something sensible or is it simply !=
NULL, but pointing at garbage?
> consequences:
> * no entry for our fieldcontainer is placed to the changedStore
> (may be the reason why it gets not synced), only in the
> _uncommitedChanges list
> *_pContainerChanges->bvUncommittedChanges = &_bvChanged is not called.
In editMFViews() after the call to editMField() does the above hold,
i.e. is _pContainerChanges->bvUncommittedChanges == &this->_bvChanged?
> * when running commitChanges changed function is not called as
> bvUncommittedChanges is not correct
> I have no clue what may be the reason for the behavior. Maybe someone
> can explain the change handling priciples in detail.
The ChangeList servers two purposes: tracking fields that changed so
that the affected container's ::changed() method can be called when the
user calls commitChanges(). Additionally it continues to track (and
accumulate) those fields until the ChangeList is explicitly cleared so
that changes can be transmitted across the cluster (or in general
applied to another Aspect).
> Hope to get some help in short-term as we have some presentations the
> next days where these features should work.
If you add a call to ChangeList::dump() (say before sending it across
the cluster) does your VDTRenderChannel show up in any of the lists
dumped and how does that change over time?
Cheers,
Carsten
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
On 06/24/2014 03:31 PM, Michael Raab wrote:
> Recently we ran into some cluster sync problems that I do not really
> unterstand.
> We have a self implemented fieldcontainer class VDTRenderChannel (full
> fcd is attached). This field container has a MField of Viewports to render.
> I use the method editMFViews() to get access to this MField and to mark
> it as changed to get sync to the servers. Locally everything works fine,
> but beside the initial sync after creation, changes to that class and
> especially to that MField are not synced to our servers. I tried to
> debug that issue and these are my investigations:
> - VDTRenderChannel::changed is never called
> - stepping throw editMFViews() to editMField() into
> registerChangedContainer() it seems that variable _pContainerChanges is
> always present
hmm, looking at the places where this member variable is assigned, it
gets reset when the ChangeList is cleared - do you ever clear yours?
Does _pContainerChanges point to something sensible or is it simply !=
NULL, but pointing at garbage?
> consequences:
> * no entry for our fieldcontainer is placed to the changedStore
> (may be the reason why it gets not synced), only in the
> _uncommitedChanges list
> *_pContainerChanges->bvUncommittedChanges = &_bvChanged is not called.
In editMFViews() after the call to editMField() does the above hold,
i.e. is _pContainerChanges->bvUncommittedChanges == &this->_bvChanged?
> * when running commitChanges changed function is not called as
> bvUncommittedChanges is not correct
> I have no clue what may be the reason for the behavior. Maybe someone
> can explain the change handling priciples in detail.
The ChangeList servers two purposes: tracking fields that changed so
that the affected container's ::changed() method can be called when the
user calls commitChanges(). Additionally it continues to track (and
accumulate) those fields until the ChangeList is explicitly cleared so
that changes can be transmitted across the cluster (or in general
applied to another Aspect).
> Hope to get some help in short-term as we have some presentations the
> next days where these features should work.
If you add a call to ChangeList::dump() (say before sending it across
the cluster) does your VDTRenderChannel show up in any of the lists
dumped and how does that change over time?
Cheers,
Carsten
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
------------------------------------------------------------------------------ Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft
_______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
