This was approved in last weeks integration meeting [0] and the wiki [1] has been updated. Thanks, JamO [0]

After thinking about this for a bit, I think we have two real current problems: 1.) It's confusing for people to figure out what projects are related to OpenFlow and how. 2.) It's hard for people to

As indicated in their M2 Status Email [1], the OPENFLOWJAVA team would like to request a system test waiver for Boron [2]. The reason behind the request is that openflowjava's functionality is tested

Hi Michal, Thanks for your reply. Yes, I will do the changes as you have indicated. Regards, Chinmay

Hi Chinmay, in that case please go ahead with your changes. You can also remove the two positive counters mentioned before to further improve the performance (we will still have the send messages

Hi Michal, From our ongoing effort to debug some of the performance related issues we find that it greatly simplifies the debugging process if error cases (for example like message drop) are

Hi Chinmay, you can turn the counters on / off by providing the <statistics> element in 45-openflowjava-stats.xml file (inside openflowjava-config module). If this element is present, counters will be

Hi Michal and all, In that case I think best would be to introduce the functionality that would allow to enable/disable (via JMX or Config subsys) the counter module on demand. In this way we can have

Hi Chinmay, your point makes sense. However, we should thoroughly​ consider removing these counters. These were introduced in the past to check if / where there are messages being lost between

​+1​ ​+1​ -- Thanks Anil

Yes - as Alex mentioned during the last meeting the topic was phased release & semantic versioning - but we could do it on the coming Monday. About the last point - I think we should: 1. Not get rid

And the need to have a new groupID means that downstream projects would be affected and have to change their dependency information in their pom files. --Colin

I'll point out a couple of things with a restructure: 1) Build history might potentially be lost if the projects change their final component name (which is unlikely). Just changing the

The last question is basically, should we merge openflowjava and openflowplugin into one project? leave them apart? or pick a different splitting point? That was basically the focus of the 3-5 mails

Correct it didn’t, last TWS focused on phased release and semantic versioning. +1, absolutely. +1, those are openflow-related projects, and are tied to openflow. I believe it makes sense having them

So, did the TWS on this topic actually happen? I think it didn't, but it probably should in the near future. It sounds like there's two (or maybe three) orthogonal questions here: 1.) Should the

Hi Michal, Thanks for your reply. Indeed the formula indicated by you gives the expected value !! So it obviates the implementation of a new counter. However following new thoughts emerge. Do we

Hello Chinmay, is it really needed to add such counter ? One can get this number byDS_ENTERED_OFJAVA - (DS_ENCODE_SUCCESS + DS_ENCODE_FAIL) if only OutboundQueue is used. This counter looses its

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

Hi all, To supplement present testing and diagnosing scenarios using message counts, I am proposing following new count. Count name : DS_DROPPED_PACKET_QFULL Purpose : To count messages dropped