Hi Anil,
Why is it happening in Issue 1?
"and then you disconnect the device from second controller and reconnect it,
ownership goes to third controller"
I found that when disconnect the device from the second controller, the device
data in data store will be deleted. So the FRM will deregist
Hi Anil,
Why is it happening in Issue 1?
"and then you disconnect the device from second controller and reconnect it,
ownership goes to third controller"
I found that when disconnect the device from the second controller, the device
data in data store will be deleted. So the FRM will deregist
Hi Muthukrishnan,
there is no golden standard behind this value. Setting it to 100ms or even
lower value will result into low latency system but this also decreases
throughput of system.
If you have few switches and little no big requirement on flows per second
throughput then 100ms might sui
Hi,
I have a 3-node cluster which I connect 200 OVSs to.
Each OVS is configured with all the 3 ODLs as managers.
When checking which ODL took ownership on which OVS, I expected something
equally distributed but got:
ODL 1: 14 switches
ODL 2: 46 switches
ODL 3: 140 switches
Is this normal?
Than
Hi again Luis,
I managed to get single layer serialization to pretty stable state, but I have
1 quick question, and hopefully you will know the answer.
According to test result from flow-services CSIT here:
https://logs.opendaylight.org/releng/jenkins092/openflowplugin-csit-1node-flow-services-
Adding Anil since I asked him about this last week.
I think the default behavior for ownership is simply which ODL receives the
incoming connection first becomes the owner. I might have that confused
with the ovsdb side though.
On Thu, Feb 16, 2017 at 9:25 AM, Sela, Guy wrote:
> Hi,
>
>
>
> I h
Hi Tomas,
The reconciliation test does the following:
0) Enable stale-flow entry feature (otherwise step 5 will not work)
1) add 2000 groups + 1000 flows (+10 table-miss)
2) Disconnect network
3) Remove 20 groups + 10 flows
4) Reconnect network
5) Check groups and flows are deleted from switch (
OpenFlow Plugin
1. Please provide updates on any previously-incomplete items from prior
milestone readouts. N/A
2. Has your project achieved API freeze such that all externally accessible
Stable or Provisional APIs will not be modified after now? Yes
https://git.opendaylight.org/gerrit/gitweb?p
Hello openflowplugin developers ,
I have been using lithium release of opendaylight. We are seeing ODL
crashes with error mentioned in the subject line , when we test the
scenario of frequent connection flap .
If this issue has been already addressed as part of the latest release ,
could anyo
Hi Santosh,
Looks like your controller crashed while spawning a new native JVM thread,
because your JVM Is out of native heap space.
Can you increase your native heap space and see if you still hit the issue
(it might take longer to recreate the issue). Meanwhile if you have the
heapdump, please
Hi Anil ,
Thanks for your response ..
We are running with following memory option , I think which is sufficient
for ODL instance having 150 OF connection.
-Xms128M -Xmx31393m -XX:MaxPermSize=15696m
Any thoughts on this ??
We would be trying to recreate this issue in order to get heap dump ...
Hi Santosh,
Couple of questions -
a) Does crash happen instantaneously – I mean within shorter intervals or
degradation is progressive over time ?
b) since you emulate the flaps, is it possible to control the frequency of
flapping with your emulation ?
If (a) holds true or (b) is po
Thank you for explanation Luis. I missed step 3 when I was going through test
report. At least now I know where to search for issue and after this last one
will be fixed, single layer model implementation will be finally finished,
because other than this it is not causing any more regressions bo
13 matches
Mail list logo
