Hi Robert,
Slightly orthogonal question delving more into overheads
Would the overhead not be higher than just trivially marginal on the backend
for a transaction ?
In other words, the moment newXYZTransaction is created, proxy, context,
snapshot, txn-actors and other related objects get
Hi Michael,
Quarantine is the state when akka system level messages could not be exchanged
across the nodes – these include but not limited to heartbeats, remote
deathwatch, node state updates etc.
This article https://livingston.io/understanding-akkas-quarantine-state/ gives
a fair idea
s again the domain of applications and is
orthogonal to the choice of standalone txn or chained txn as well as the type
of failures
Regards
Muthu
-Original Message-
From: Robert Varga [mailto:n...@hq.sk]
Sent: Saturday, June 09, 2018 5:37 PM
To: Muthukumaran K ; Faseela K
; Anil Vishn
Transaction Chains is also useful in context of ensuring that last txn is
completed before next is executed so that subsequent txn can see the changes
made by previous one (of course within single subtree) more efficiently. And
also enables single-writer discipline
@Robert,
In context of Txn
I can think of one case which can fall-flat with the colocation of EOS owner of
registered entity with a specific shard is that :
When the entity owner starts running txns against another shard which may not
be collocated, then we do not get the fullest benefit of colocation.
For example, we
meeting about this sometime tomorrow morning - say at 10 am. Chris will be able
to arrange a room for us. We can ask Casey to have a Zoom session. It will be
great if you guys can attend - at least Robert, Tom, Michael, Stephen, Muthu,
etc.
Thanks,
Abhijit
On Sun, Jan 1, 2017 at 11:22 PM
Hi Martinez,
In order to stress the OpenflowPlugin, we typically use an app called
bulk-o-matic -
https://github.com/opendaylight/openflowplugin/blob/master/applications/bulk-o-matic/src/site/asciidoc/bulk-o-matic.adoc
Please note that this app was meant for stressing openflowplugin without any
Thank a lot :-)
Regards
Muthu
-Original Message-
From: controller-dev-boun...@lists.opendaylight.org
[mailto:controller-dev-boun...@lists.opendaylight.org] On Behalf Of Robert Varga
Sent: Thursday, February 15, 2018 3:34 AM
To: Casey Cain; dev; controller-dev@lists.opendaylight.org
+Jaya
-Original Message-
From: Robert Varga [mailto:n...@hq.sk]
Sent: Thursday, January 18, 2018 7:43 PM
To: Jamo Luhrsen; Muthukumaran K; Sam Hague
Cc: controller-dev; genius-...@lists.opendaylight.org; Kency Kurian
Subject: Re: [controller-dev] Should application code persist do
on second set of runs soon
Regards
Muthu
From: Ajay Lele [mailto:ajaysl...@gmail.com]
Sent: Friday, January 12, 2018 12:19 PM
To: Muthukumaran K
Cc: Robert Varga; Sam Hague; controller-dev;
genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org>;
Kency Kurian; Bgpc
[mailto:n...@hq.sk]
Sent: Friday, January 12, 2018 2:11 AM
To: Sam Hague
Cc: Michael Vorburger; Muthukumaran K; Tom Pantelis; controller-dev;
genius-...@lists.opendaylight.org; Kency Kurian
Subject: Re: [controller-dev] Should application code persist do retries on
TransactionCommitFailedExcept
From: Ajay L [mailto:ajayl@gmail.com]
Sent: Wednesday, November 15, 2017 1:46 AM
To: controller-dev@lists.opendaylight.org
Cc: Muthukumaran K; Srini Seetharaman; Robert Varga; ajaysl...@gmail.com; Sai
MarapaReddy
Subject: Re: [controller-dev] Circuit Breaker timed out
Hi All,
We are also
Hi Robert,
>>> Could we use the make-leader-local RPC for this, and how?
When this API invoked when there are inflight transactions (transactions being
in various stages from submit phase till DTCN submission phase to respective
DTCL actors) with erstwhile leader, what happens to those
13, 2017 6:19 AM
To: Jamo Luhrsen; Muthukumaran K; controller-dev@lists.opendaylight.org;
integration-...@lists.opendaylight.org
Subject: Re: [controller-dev] Best way to gracefully shutdown Karaf in ODL
context
Hey Muthu,
Yes, I think you should take a look at the systemd configuration we ship
[mailto:tompante...@gmail.com]
Sent: Thursday, October 12, 2017 1:05 PM
To: Muthukumaran K
Cc: Faseela K; infrautils-...@lists.opendaylight.org;
controller-dev@lists.opendaylight.org; R Srinivasan E; Dayavanti Gopal Kamath
Subject: Re: [controller-dev] Expose Datastore health to applications via
BZ 9034 :
(1) a lot of those "ERROR ShardDataTree
org.opendaylight.controller.sal-distributed-datastore - 1.5.2.Carbon |
member-0-shard-default-operational: Failed to commit transaction ...
java.lang.IllegalStateException: Store tree
...@gmail.com [mailto:srini...@gmail.com] On Behalf Of Srini
Seetharaman
Sent: Saturday, August 12, 2017 1:55 AM
To: Muthukumaran K
Cc: Tom Pantelis; controller-dev@lists.opendaylight.org
Subject: Re: [controller-dev] Circuit Breaker timed out
Or was there a real disk issue in that machine you were
Hi Tom, Srini,
We have also noticed this with Boron very sporadically even without any
explicit action taken on shard like Srini did
Srini,
Are you referring “journal-plugin-fallback” from
http://doc.akka.io/docs/akka/current/scala/general/configuration.html#config-akka-persistence
?
to use module-based
sharding. Am I correct ?
The reason why I ask is we wanted to run Netvirt CSIT with tell-based protocol
enabled to have a basic sanity cleared with this change and then do more
focused testing with HA and scale scenarios.
Regards
Muthu
-Original Message-
From:
: Wednesday, August 02, 2017 11:29 PM
To: Muthukumaran K; controller-dev
Cc: odl netvirt dev
Subject: Re: [controller-dev] Testing the FE BE separation of Datastore
(Bug-5280)
On 24/07/17 17:28, Muthukumaran K wrote:
> Hi Robert,
Hello Muthu,
sorry for the late response, this email got left behind in
Hi Robert,
This is in context of the changes for BZ-5280. We would like to test the
changes on master branch. Have some clarifications on the same
a) Since this change had been major, as I recollect, there was a
discussion earlier on isolating the changed code-path and old code path. Is
I agree with Tom.
Had experienced this earlier due to a laggard listener back before stable
carbon cut. Eventually , listener had got fixed (not in connection with this
observation but I had just picked up the build spaced well after the original
build) and I had not been able to repro the
: Wednesday, March 29, 2017 7:31 AM
To: Tom Pantelis
Cc: Muthukumaran K; controller-dev@lists.opendaylight.org
Subject: Re: [controller-dev] Backward compatibility of akka-persistence journal
When using module level sharding, it will be good if we can mention the
revision-date for the module in module
Data import / export is a new feature in master branch which can export
datastore contents in JSON format and also import the same. Since this feature
is not there in earlier releases and would not be usable for moving data from
Be to Bo.
Regards
Muthu
From:
Hi Tom,
I assume using backup and restore for below scenario would still have the same
issue right ? As I understand, Backup and Restore may make the content agnostic
to the node-members but the data backed-up will still have the shard-level
metadata as part of backed-up data which can impact
Thanks for the update Siva
Regards
Muthu
From: Sivasamy Kaliappan [mailto:sivasa...@gmail.com]
Sent: Wednesday, March 22, 2017 6:03 PM
To: Tom Pantelis
Cc: Muthukumaran K; controller-dev
Subject: Re: [controller-dev] EOS entity without an owner after data store
exception
We are not seeing
@Guy,
URL should be
http://:8181/jolokia/read/org.opendaylight.controller:Category=Shards,name=member--shard-topology-operational,type=DistributedOperationalDatastore
Regards
Muthu
From: controller-dev-boun...@lists.opendaylight.org
[mailto:controller-dev-boun...@lists.opendaylight.org] On
Hi Tom,
From the stacktrace it appears as Beryllium SR3 - 1.3.3.Beryllium-SR3
As I recollect, this appears as symptom which called for pre-leader fix. So,
would it be better to try out Boron ?
Regards
Muthu
From: controller-dev-boun...@lists.opendaylight.org
...@hpe.com]
Sent: Thursday, January 12, 2017 4:21 PM
To: Vishal Thapar <vishal.tha...@ericsson.com>; Muthukumaran K
<muthukumara...@ericsson.com>; Tom Pantelis <tompante...@gmail.com>
Cc: odl netvirt dev <netvirt-...@lists.opendaylight.org>;
controller-dev@lists.opend
tore%20>
Regards
Muthu
From: Vishal Thapar
Sent: Thursday, January 12, 2017 3:48 PM
To: Muthukumaran K <muthukumara...@ericsson.com>; Sela, Guy <guy.s...@hpe.com>;
Tom Pantelis <tompante...@gmail.com>
Cc: odl netvirt dev <netvirt-...@lists.opendaylight.org>;
contr
) and
also some tunnel config (which could be part of default-config shard) in same
transaction, then we cross the shard boundaries and what Robert says hold true
for that case.
Regards
Muthu
From: Sela, Guy [mailto:guy.s...@hpe.com]
Sent: Thursday, January 12, 2017 2:53 PM
To: Muthukumaran K
to manage the uniformity of broker contracts?
Regards
Muthu
-Original Message-
From: Robert Varga [mailto:n...@hq.sk]
Sent: Tuesday, December 27, 2016 9:10 PM
To: Muthukumaran K <muthukumara...@ericsson.com>; Colin Dixon
<co...@colindixon.com>; Shrenik Jain <shrenik.j..
Thanks Robert.
>>> Oracle's 'STARTUP UPGRADE' does a similar thing
This analogy improves my understanding :-)
Regards
Muthu
-Original Message-
From: Robert Varga [mailto:n...@hq.sk]
Sent: Saturday, December 10, 2016 4:28 PM
To: Muthukumaran K <muthukumara...@ericsson
Hi,
If we follow the procedure explained under section "Through REST Endpoints" at
the link - https://wiki.opendaylight.org/view/AAA:Changing_Account_Passwords in
a 3 node cluster, should the step be executed on all 3 cluster nodes. Asking
because the file - idmlight.db.mv.db, is local to each
Hi Pragati,
Are you looking for clustering of ODL ? If so, you may want to have a look at a
good introduction here - https://www.youtube.com/watch?v=A9wAAbvliR0
Also, there are presentations on ODL wiki on clustering.
ODL clustering internally uses inter-node (controller instances)
Hi Guy,
To your previous mail, yes, the routing is currently at the local-node level.
Wrt to your second mail on routed-rpc, that's roughly how it works in context
of OFPlugin. As to which node acts as current active RPC provider for a given
route-key (switch-id in this case) is determined
Hi Srini,
We have tried the approach what Moiz had mentioned – using CDTCN and caching
data, and it was quite performant in one of our reference application. You may
want to look - https://git.opendaylight.org/gerrit/#/c/45131/
Regards
Muthu
From:
: Thursday, September 01, 2016 4:27 AM
To: Sela, Guy; Muthukumaran K; controller-dev@lists.opendaylight.org;
mdsal-...@lists.opendaylight.org; yangtools-...@lists.opendaylight.org
Subject: Re: [mdsal-dev] Serialize/Deserialize DTOs to JSON
On 08/24/2016 01:21 PM, Sela, Guy wrote:
> The only
at this enhancement -
https://bugs.opendaylight.org/show_bug.cgi?id=5421
Regards
Muthu
From: Muthukumaran K
Sent: Thursday, August 25, 2016 1:11 PM
To: 'Sela, Guy'; mdsal-...@lists.opendaylight.org;
controller-dev@lists.opendaylight.org
Cc: Alfasi, Shlomi; Cohen, Elad
Subject: RE: Invoking MD
JVMs. Of course, that was just a personal experiment nothing official :-)
Regards
Muthu
-Original Message-
From: Sela, Guy [mailto:guy.s...@hpe.com]
Sent: Thursday, August 11, 2016 1:32 PM
To: Muthukumaran K; Robert Varga; controller-dev@lists.opendaylight.org;
mdsal
]
Sent: Thursday, August 04, 2016 11:30 PM
To: Muthukumaran K
Cc: controller-dev@lists.opendaylight.org
Subject: Re: [controller-dev] What is the condition under which
IllegalStateException - "store tree and candidate base differ" is thrown
It means preCommit/commit occurred out-of
41 matches
Mail list logo
