809364 - sutagent zeroconf is causing jmdns thread to spike cpu on panda boards

Status: RESOLVED FIXED

(Testing Graveyard :: SUTAgent, defect)

Description

[Joel Maher ( :jmaher ) (UTC -8)]

we need to remove our on by default Zeroconf for SUTAgent as this is causing a massive CPU spike in the SUTAgent while running on the panda boards in production.

I would really like to find the root cause of this as I suspect there is something fishy going on with the general network.  Maybe a flood of dns packets, or invalid packets that it cannot handle well.

Comment 1

[Joel Maher ( :jmaher ) (UTC -8)]

Attachment: use sutagent.ini to control zeroconf, off by default (1.0)

Comment 2

[William Lachance (:wlach)]

Comment on attachment 679281 [details] [diff] [review]
use sutagent.ini to control zeroconf, off by default (1.0)

LGTM

># HG changeset patch
># Parent e069342dc6658bdd2d806a70a3b832e4868b927b
>Bug 809364 - sutagent zeroconf is causing jmdns thread to spike cpu on panda boards. r=wlach

> import com.mozilla.SUTAgentAndroid.SUTAgentAndroid;
> import com.mozilla.SUTAgentAndroid.R;
>@@ -39,6 +40,7 @@
>     RunDataThread runDataThrd = null;
>     Thread monitor = null;
>     Timer timer = null;
>+    boolean doZeroConfig = false;
> 
>     @SuppressWarnings("unchecked")
>     private static final Class<?>[] mSetForegroundSignature = new Class[] {
>@@ -178,14 +180,24 @@
>             runDataThrd.start();
>             doToast(String.format("Data channel port %d ...", DATA_PORT));
> 
>-            startZeroConf();
>+            DoCommand tmpdc = new DoCommand(getApplication());
>+            File dir = getFilesDir();
>+            File iniFile = new File(dir, "SUTAgent.ini");
>+            String sIniFile = iniFile.getAbsolutePath();

I didn't notice this before, but it seems pretty silly to create a DoCommand instance just to get some ini data. Could we not make GetIniData into a static method and call it directly? Or put this function in some more appropriate class, like say SUTAgentAndroid? (where it is always called from anyway)

Seems like this is a longstanding issue so not worth blocking the patch on, but I thought I'd point it out.

Comment 3

[Joel Maher ( :jmaher ) (UTC -8)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/84b0991ccd97

Comment 4

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/84b0991ccd97