So, to answer my own question, the message ends up going to Akka, hence the lack of seeing it in the traceback. I knew Akka was in the mix after looking at various diagrams and seeing it all over the logs, but I wasn’t totally sure where the handoff was.
On the flip side, when it comes to tracing out calls to the southbound plugin I’m working on, I found that Akka was not in the mix, and instead it went to an LMAX Disruptor against a thread pool (dispatched by the NotificationPopListener/DOMNotificationRouter until eventually the magical BindingDOMNotiificationListenerAdapter does some weird looking reflection call to call to call whatever your plugin is doing). Oh, and I was surprised to see disruptor in the mix, I haven’t seen anyone use that approach since my time in HFT. You guys are serious about performance.
I’m still looking for a hook in my southbound plugin to receive “PacketInMessage” callbacks when they are received by the TCPHandler on 6653. Today I’m going to randomly try assigning various elements to my yang configuration to see if the appropriate structure shows up in my auto-generated “Abstract${PROJECT}ImplModule.java” file. Again, if anyone can give me a hint or a clue I’d appreciate it.
-Ryan Dietrich
On Apr 19, 2016, at 1:47 PM, Ryan Dietrich < ryan@...> wrote:
Thanks for the notes. I’ll drop another line when I get it all figured out :) On Apr 19, 2016, at 12:06 PM, Moiz Raja (moraja) < moraja@...> wrote:
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
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
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
_______________________________________________ openflowjava-dev mailing list openflowjava-dev@...https://lists.opendaylight.org/mailman/listinfo/openflowjava-dev
|
