On Apr 19, 2016, at 12:06 PM, Moiz Raja (moraja) <moraja@...> wrote:

See this - https://wiki.opendaylight.org/images/2/2d/MD-SAL_Clustering_Internals.pptx and https://www.youtube.com/watch?v=A9wAAbvliR0

If there were more operations done on that read write transaction then you should see more TransactionProxy logging. The presentation should have an example of transaction logging.

-Moiz

From: <openflowjava-dev-bounces@...> on behalf of Ryan Dietrich <ryan@...>
Date: Tuesday, April 19, 2016 at 10:48 AM
To: "openflowjava-dev@..." <openflowjava-dev@...>
Subject: Re: [openflowjava-dev] Hi, question about "flow"

I know where the TransactionProxy “is” from a file location perspective.  It is in the controller repo, under md-sal.

I don’t understand from a processing perspective you get from TicketProcessor to the TransactionProxy. (I’m looking at the “translate” call in TicketProcessorFactoryImpl.  That looks like it is translating the response, back to a result set?)

Is there any documentation or videos that describe the path from the TCP packet in that steps you all the way through to MD-SAL making a query to the database?

I just want to know how a request is served by openflowplugin-java to MD-SAL / distributed-datastore.

Here are the logs I am referring to (I can find the logic pathway form TcpHandler all the way to TicketProcessorFactoryImpl, but after that the “trail” goes cold):

2016-04-18 14:40:31,403 | DEBUG | ntLoopGroup-11-1 | ConnectionAdapterImpl            | 177 - org.opendaylight.openflowjava.openflow-protocol-impl - 0.7.0.Beryllium | ConsumeIntern msg on [id: 0x67c3f8a9, /10.20.116.148:7801 => /10.10.1.200:6653]

2016-04-18 14:40:31,403 | DEBUG | ntLoopGroup-11-1 | QueueKeeperHarvester             | 180 - org.opendaylight.openflowplugin - 0.2.0.Beryllium | pinging message harvester in starve status

2016-04-18 14:40:31,403 | DEBUG | OFmsgProcessor-0 | TicketProcessorFactoryImpl       | 180 - org.opendaylight.openflowplugin - 0.2.0.Beryllium | message received, type: MultipartReplyMessage

2016-04-18 14:40:31,403 | DEBUG | OFmsgProcessor-0 | TicketProcessorFactoryImpl       | 180 - org.opendaylight.openflowplugin - 0.2.0.Beryllium | translatorKey: 4 + org.opendaylight.yang.gen.v1.urn.opendaylight.openflow.protocol.rev130731.MultipartReplyMessage

2016-04-18 14:40:31,403 | DEBUG | OFmsgProcessor-0 | MultipartReplyTranslator         | 180 - org.opendaylight.openflowplugin - 0.2.0.Beryllium | Received group statistics multipart reponse

2016-04-18 14:40:31,403 | DEBUG | OFmsgProcessor-0 | MultipartReplyTranslator         | 180 - org.opendaylight.openflowplugin - 0.2.0.Beryllium | Converted group statistics : org.opendaylight.yang.gen.v1.urn.opendaylight.group.statistics.rev131111.GroupStatisticsUpdatedBuilder@5cfbeda4

2016-04-18 14:40:31,403 | DEBUG | OFmsgProcessor-0 | TicketProcessorFactoryImpl       | 180 - org.opendaylight.openflowplugin - 0.2.0.Beryllium | message processing done (type: MultipartReplyMessage, ticket: 1371401748)

2016-04-18 14:40:31,407 | DEBUG | ds-oper-thread-0 | TransactionProxy                 | 164 - org.opendaylight.controller.sal-distributed-datastore - 1.3.0.Beryllium | New READ_WRITE Tx - member-1-chn-1-txn-2061-1461012031407

On Apr 19, 2016, at 11:15 AM, Moiz Raja (moraja) <moraja@...> wrote:

TransactionProxy is in the Distributed data store (aka Clustered data store). The code for that is in the controller project. Look for module sal-distritributed-datastore.

-Moiz

From: <openflowjava-dev-bounces@...> on behalf of Ryan Dietrich <ryan@...>
Date: Tuesday, April 19, 2016 at 10:04 AM
To: "openflowjava-dev@..." <openflowjava-dev@...>
Subject: [openflowjava-dev] Hi, question about "flow"

Hi, I am just starting out with OpenDaylight and I feel like this:

https://img.buzzfeed.com/buzzfeed-static/static/2014-10/26/6/enhanced/webdr08/enhanced-14836-1414320930-8.jpg

I have a firm grip on the netty library in Java, so I decided to start with the TcpHandler class and work my way backwards until I found the linkage to what is making calls to the database.

I got lost at the “Tickets” area in the code.   I cannot figure out how you get to TransactionProxy (which I see in the karaf logs as the next “step” of execution before a response is returned), following the chain of events from 

TcpHandler

TcpChannelInitializer

DelegatingInboundHandler

ConectionAdapterImpl

OutboundQueueManager

ConnectionConductorImpl

QueueKeeper

QueueProcessorLightImpl

TicketProcessorHandlerImpl

???

???

TransactionProxy

I am trying to learn how to create a plugin of sorts for the south bound interface of Open Daylight, allowing me to choose whether MD-SAL references its own data store, or make calls externally to my systems.  Basically, I want to try and create an “aspect programming” concept that intercepts all GET requests going to MD-SAL, and allows me to make a decision on where to get the information (such as a REST request to a third party system).  I assume this is not the “norm”, after looking at the Toaster provider plugin example.  Am I barking up the wrong tree?  Can anyone help me fill in the blanks on how a request on how southbound requests are serviced?  Any and all information to help me get a footing in this system is much appreciated!

Also, I’d like to pay a compliment to the developers of this project.  I’ve worked on a lot of Java applications in my career, and this is some really well written (and tested!) code.

-Ryan Dietrich