Discussion:
[Opensg-users] OpenSG2.0: Changelist problems
Michael Raab
2014-06-24 13:31:07 UTC
Permalink
Carsten Neumann
2014-06-24 14:54:23 UTC
Permalink
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
Michael Raab
2014-06-24 15:10:09 UTC
Permalink
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>
<div>Hi Carsten,</div>

<div><br/>
&gt;hmm, looking at the places where this member variable is assigned, it<br/>
&gt;gets reset when the ChangeList is cleared - do you ever clear yours?<br/>
&gt;Does _pContainerChanges point to something sensible or is it simply !=<br/>
&gt;NULL, but pointing at garbage?</div>

<div>&nbsp;</div>

<div>Seems to be reasonable; Is definitely not NULL;</div>

<div>What I saw was that uiEntryDesc was set to &#39;AddReference&#39;, which makes not much sense there or?</div>

<div>
<div>&nbsp;</div>

<div>I did not find any place where this member variable gets reset; Could you point me there?</div>

<div>&nbsp;</div>

<div>I call&nbsp; Thread::getCurrentChangeList()-&gt;clear(); after each frame..</div>

<div>&nbsp;</div>

<div>&gt; In editMFViews() after the call to editMField() does the above hold,<br/>
&gt; i.e. is _pContainerChanges-&gt;bvUncommittedChanges == &amp;this-&gt;_bvChanged?</div>

<div>&nbsp;</div>

<div>_pContainerChanges-&gt;bvUncommittedChanges is NULL while &amp;this-&gt;_bvChanged has some value...</div>

<div>&nbsp;</div>

<div>&gt; If you add a call to ChangeList::dump() (say before sending it across<br/>
&gt; the cluster) does your VDTRenderChannel show up in any of the lists<br/>
&gt; dumped and how does that change over time?</div>

<div>&nbsp;</div>

<div>I already did this. I can see some AddRef/SubRefs and exactly one &#39;Changed&#39; state, but this is directly after creation...</div>

<div>&nbsp;</div>

<div>Thanks,</div>

<div>Michael</div>

<div style="margin: 10.0px 5.0px 5.0px 10.0px;padding: 10.0px 0 10.0px 10.0px;border-left: 2.0px solid rgb(195,217,229);">
<div style="margin: 0 0 10.0px 0;"><b>Gesendet:</b>&nbsp;Dienstag, 24. Juni 2014 um 16:54 Uhr<br/>
<b>Von:</b>&nbsp;&quot;Carsten Neumann&quot; &lt;***@gmail.com&gt;<br/>
<b>An:</b>&nbsp;opensg-***@lists.sourceforge.net<br/>
<b>Betreff:</b>&nbsp;Re: [Opensg-users] OpenSG2.0: Changelist problems</div>

<div>Hello Michael,<br/>
<br/>
On 06/24/2014 03:31 PM, Michael Raab wrote:<br/>
&gt; Recently we ran into some cluster sync problems that I do not really<br/>
&gt; unterstand.<br/>
&gt; We have a self implemented fieldcontainer class VDTRenderChannel (full<br/>
&gt; fcd is attached). This field container has a MField of Viewports to render.<br/>
&gt; I use the method editMFViews() to get access to this MField and to mark<br/>
&gt; it as changed to get sync to the servers. Locally everything works fine,<br/>
&gt; but beside the initial sync after creation, changes to that class and<br/>
&gt; especially to that MField are not synced to our servers. I tried to<br/>
&gt; debug that issue and these are my investigations:<br/>
&gt; - VDTRenderChannel::changed is never called<br/>
&gt; - stepping throw editMFViews() to editMField() into<br/>
&gt; registerChangedContainer() it seems that variable _pContainerChanges is<br/>
&gt; always present<br/>
<br/>
hmm, looking at the places where this member variable is assigned, it<br/>
gets reset when the ChangeList is cleared - do you ever clear yours?<br/>
Does _pContainerChanges point to something sensible or is it simply !=<br/>
NULL, but pointing at garbage?<br/>
<br/>
&gt; consequences:<br/>
&gt; * no entry for our fieldcontainer is placed to the changedStore<br/>
&gt; (may be the reason why it gets not synced), only in the<br/>
&gt; _uncommitedChanges list<br/>
&gt; *_pContainerChanges-&gt;bvUncommittedChanges = &amp;_bvChanged is not called.<br/>
<br/>
In editMFViews() after the call to editMField() does the above hold,<br/>
i.e. is _pContainerChanges-&gt;bvUncommittedChanges == &amp;this-&gt;_bvChanged?<br/>
<br/>
&gt; * when running commitChanges changed function is not called as<br/>
&gt; bvUncommittedChanges is not correct<br/>
&gt; I have no clue what may be the reason for the behavior. Maybe someone<br/>
&gt; can explain the change handling priciples in detail.<br/>
<br/>
The ChangeList servers two purposes: tracking fields that changed so<br/>
that the affected container&#39;s ::changed() method can be called when the<br/>
user calls commitChanges(). Additionally it continues to track (and<br/>
accumulate) those fields until the ChangeList is explicitly cleared so<br/>
that changes can be transmitted across the cluster (or in general<br/>
applied to another Aspect).<br/>
<br/>
&gt; Hope to get some help in short-term as we have some presentations the<br/>
&gt; next days where these features should work.<br/>
<br/>
If you add a call to ChangeList::dump() (say before sending it across<br/>
the cluster) does your VDTRenderChannel show up in any of the lists<br/>
dumped and how does that change over time?<br/>
<br/>
Cheers,<br/>
Carsten<br/>
<br/>
------------------------------------------------------------------------------<br/>
Open source business process management suite built on Java and Eclipse<br/>
Turn processes into business applications with Bonita BPM Community Edition<br/>
Quickly connect people, data, and systems into organized workflows<br/>
Winner of BOSSIE, CODIE, OW2 and Gartner awards<br/>
<a href="http://p.sf.net/sfu/Bonitasoft" target="_blank">http://p.sf.net/sfu/Bonitasoft</a><br/>
_______________________________________________<br/>
Opensg-users mailing list<br/>
Opensg-***@lists.sourceforge.net<br/>
<a href="https://lists.sourceforge.net/lists/listinfo/opensg-users" target="_blank">https://lists.sourceforge.net/lists/listinfo/opensg-users</a></div>
</div>
</div>
</div></div></body></html>
Carsten Neumann
2014-06-24 15:35:25 UTC
Permalink
Hello Michael,

On 06/24/2014 05:10 PM, Michael Raab wrote:
> >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?

that is quite odd. The entries are recycled, but when _pContainerChanges
is set to point to one (in FC::registerChangedContainer()) it also sets
the uiEntryDesc.

> I did not find any place where this member variable gets reset; Could
> you point me there?

ReflexiveContainer::clearChangeEntry(), called from:
- ChangeList::doClear()
- ChangeList::doApply(true)

> I call Thread::getCurrentChangeList()->clear(); after each frame..

Ok. If you put a ChangeList::dumpListSizes() right before that, what
numbers do you get? In particular IIRC if 'UC_S' > 0 (i.e. there are
uncommitted changes) calls to the containers ::changed() function may be
lost.

> > In editMFViews() after the call to editMField() does the above hold,
> > 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?
> I already did this. I can see some AddRef/SubRefs and exactly one
> 'Changed' state, but this is directly after creation...

Hmm, that is sort of consistent with _pContainerChanges not being reset.
The next change after the reset should cause the it to be put back on
the CL changed dump.
I think it would be quite interesting to find out why
ReflexiveContainer::clearChangeEntry() is not called (or why it doesn't
do anything), to me that currently seems like the root of the problem.

Cheers,
Carsten
Michael Raab
2014-06-25 09:25:15 UTC
Permalink
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>
<div>Hi Carsten,</div>

<div>&nbsp;</div>

<div>I got it. The problem was that I used a set() function for a field in the RenderChannel constructor (That worked without problems in 1.8 :-)).That caused the _pContainerChanges entry to be created. But the initialization of it was corrupt as the RenderChannel instance was not yet aware of its containerID. As the cleanup of pContainerChanges is triggered by containerID it was never successful.</div>

<div>So this is actually no bug in OpenSG but maybe it would be good to have a warning message or some kind of special handling in registerChangedContainer() if the containerID is set to 0.</div>

<div>&nbsp;</div>

<div>Thanks for your help...</div>

<div>&nbsp;</div>

<div>Michael</div>

<div>&nbsp;
<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Gesendet:</b>&nbsp;Dienstag, 24. Juni 2014 um 17:35 Uhr<br/>
<b>Von:</b>&nbsp;&quot;Carsten Neumann&quot; &lt;***@gmail.com&gt;<br/>
<b>An:</b>&nbsp;opensg-***@lists.sourceforge.net<br/>
<b>Betreff:</b>&nbsp;Re: [Opensg-users] OpenSG2.0: Changelist problems</div>

<div name="quoted-content">Hello Michael,<br/>
<br/>
On 06/24/2014 05:10 PM, Michael Raab wrote:<br/>
&gt; &gt;hmm, looking at the places where this member variable is assigned, it<br/>
&gt; &gt;gets reset when the ChangeList is cleared - do you ever clear yours?<br/>
&gt; &gt;Does _pContainerChanges point to something sensible or is it simply !=<br/>
&gt; &gt;NULL, but pointing at garbage?<br/>
&gt; Seems to be reasonable; Is definitely not NULL;<br/>
&gt; What I saw was that uiEntryDesc was set to &#39;AddReference&#39;, which makes<br/>
&gt; not much sense there or?<br/>
<br/>
that is quite odd. The entries are recycled, but when _pContainerChanges<br/>
is set to point to one (in FC::registerChangedContainer()) it also sets<br/>
the uiEntryDesc.<br/>
<br/>
&gt; I did not find any place where this member variable gets reset; Could<br/>
&gt; you point me there?<br/>
<br/>
ReflexiveContainer::clearChangeEntry(), called from:<br/>
- ChangeList::doClear()<br/>
- ChangeList::doApply(true)<br/>
<br/>
&gt; I call Thread::getCurrentChangeList()-&gt;clear(); after each frame..<br/>
<br/>
Ok. If you put a ChangeList::dumpListSizes() right before that, what<br/>
numbers do you get? In particular IIRC if &#39;UC_S&#39; &gt; 0 (i.e. there are<br/>
uncommitted changes) calls to the containers ::changed() function may be<br/>
lost.<br/>
<br/>
&gt; &gt; In editMFViews() after the call to editMField() does the above hold,<br/>
&gt; &gt; i.e. is _pContainerChanges-&gt;bvUncommittedChanges == &amp;this-&gt;_bvChanged?<br/>
&gt; _pContainerChanges-&gt;bvUncommittedChanges is NULL while &amp;this-&gt;_bvChanged<br/>
&gt; has some value...<br/>
&gt; &gt; If you add a call to ChangeList::dump() (say before sending it across<br/>
&gt; &gt; the cluster) does your VDTRenderChannel show up in any of the lists<br/>
&gt; &gt; dumped and how does that change over time?<br/>
&gt; I already did this. I can see some AddRef/SubRefs and exactly one<br/>
&gt; &#39;Changed&#39; state, but this is directly after creation...<br/>
<br/>
Hmm, that is sort of consistent with _pContainerChanges not being reset.<br/>
The next change after the reset should cause the it to be put back on<br/>
the CL changed dump.<br/>
I think it would be quite interesting to find out why<br/>
ReflexiveContainer::clearChangeEntry() is not called (or why it doesn&#39;t<br/>
do anything), to me that currently seems like the root of the problem.<br/>
<br/>
Cheers,<br/>
Carsten<br/>
<br/>
------------------------------------------------------------------------------<br/>
Open source business process management suite built on Java and Eclipse<br/>
Turn processes into business applications with Bonita BPM Community Edition<br/>
Quickly connect people, data, and systems into organized workflows<br/>
Winner of BOSSIE, CODIE, OW2 and Gartner awards<br/>
<a href="http://p.sf.net/sfu/Bonitasoft" target="_blank">http://p.sf.net/sfu/Bonitasoft</a><br/>
_______________________________________________<br/>
Opensg-users mailing list<br/>
Opensg-***@lists.sourceforge.net<br/>
<a href="https://lists.sourceforge.net/lists/listinfo/opensg-users" target="_blank">https://lists.sourceforge.net/lists/listinfo/opensg-users</a></div>
</div>
</div>
</div></div></body></html>
Carsten Neumann
2014-06-25 10:51:37 UTC
Permalink
Hello Michael,

On 06/25/2014 11:25 AM, Michael Raab wrote:
> I got it. The problem was that I used a set() function for a field in
> the RenderChannel constructor (That worked without problems in 1.8
> :-)).

glad to hear you found the problem!
For this kind of initialization there is onCreateAspect() (must call the
base class' onCreateAspect), which is called after the container is
registered with the FieldContainerFactory (and thus has a valid id).

> That caused the _pContainerChanges entry to be created. But the
> initialization of it was corrupt as the RenderChannel instance was not
> yet aware of its containerID. As the cleanup of pContainerChanges is
> triggered by containerID it was never successful.
> So this is actually no bug in OpenSG but maybe it would be good to have
> a warning message or some kind of special handling in
> registerChangedContainer() if the containerID is set to 0.

I'm adding the attached, which hopefully catches these cases in debug
builds.

Cheers,
Carsten
Loading...