SPURIOUS ABORT! O RLY?

[Paul Phillips]

https://github.com/scala/scala/issues/2267

"I just happen to cancel a job on https://scala-webapps.epfl.ch/jenkins/job/pr-checkin-per-commit/ although I am not a registered jenkins user ( I'm sorry I did that - I was just curious what would happen). I just wanted to let you know as it is probably a security issue (or should I rather file an issue to jenkins project?)"

Let's hope this isn't the explanation for all our "spurious" aborts.

[Lukas Rytz]

Yay. Was it this one?

https://scala-webapps.epfl.ch/jenkins/job/pr-checkin-per-commit/1130/console

--
You received this message because you are subscribed to the Google Groups "scala-internals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-interna...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Lukas Rytz]

It was "simply" a misconfiguration - anonymous had the "cancel job" permission. Config history

tells me that change was introduced 9 month ago - I cannot see by whom, but it was probably me.

It's very well possible that this was the reason for our spurious aborts - after all the search engine

bots are visiting our jenkins, and probably following links of the form

  https://scala-webapps.epfl.ch/jenkins/job/scala-checkin/1234/stop

I tried it out, when aborting as anonymous the jenkins log shows exactly the stack trace that we

have been seeing for our spurious aborts.

So... yay.

Mar 18, 2013 9:06:17 AM hudson.model.Run execute

INFO: test #282 aborted

java.lang.InterruptedException

at java.lang.Object.wait(Native Method)

at hudson.remoting.Request.call(Request.java:146)

at hudson.remoting.Channel.call(Channel.java:672)

at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:158)

at $Proxy73.join(Unknown Source)

at hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:915)

at hudson.Launcher$ProcStarter.join(Launcher.java:360)

at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:91)

at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:60)

at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)

at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:820)

at hudson.model.Build$BuildExecution.build(Build.java:199)

at hudson.model.Build$BuildExecution.doRun(Build.java:160)

at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:599)

at hudson.model.Run.execute(Run.java:1567)

at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)

at hudson.model.ResourceController.execute(ResourceController.java:88)

at hudson.model.Executor.run(Executor.java:237)

[Adriaan Moors]

Oh, jenkins! Thanks, Lukas :-)

yay indeed!

--

See you at Scala Days (June 10–12, NYC)!

[Paul Phillips]

On Mon, Mar 18, 2013 at 1:09 AM, Lukas Rytz <lukas...@epfl.ch> wrote:

I tried it out, when aborting as anonymous the jenkins log shows exactly the stack trace that we

have been seeing for our spurious aborts.

So... yay.

In the interests of post-morteming, why couldn't any of us figure this out? I also didn't manage the last connection even after starting this thread - that open access + GET cancel semantics meant that any robot traversal would cancel everything. No wonder they came in waves.

Is the http log recorded distinctly from the event log containing the cancellation, such that we never saw them together? One would think it would have been obvious seen as a series of GETs from some IP each immediately followed by a "spurious abort".

[Lukas Rytz]

On Mon, Mar 18, 2013 at 6:13 PM, Paul Phillips <pa...@improving.org> wrote:

On Mon, Mar 18, 2013 at 1:09 AM, Lukas Rytz <lukas...@epfl.ch> wrote:

I tried it out, when aborting as anonymous the jenkins log shows exactly the stack trace that we

have been seeing for our spurious aborts.

So... yay.

In the interests of post-morteming, why couldn't any of us figure this out?

The main reasons I see

 - Jenkins just tells us "Aborted" without any clue why. I would expect such a thing only if something

   really goes wrong, eg in slave communication, and there's not way to generate a sensible message.

   Also the fact that it logged an InterruptedException made us look for some kind of real problem.

 - Having GET requests trigger actions is bad design

 

I also didn't manage the last connection even after starting this thread - that open access + GET cancel semantics meant that any robot traversal would cancel everything. No wonder they came in waves.

Is the http log recorded distinctly from the event log containing the cancellation, such that we never saw them together?

The main log lists exceptions, started and finished jobs. You can enable all kind of additional

logging, but there's a huge amount of sources. I played a bit with that at some point, but it's

extremely difficult to get a sensible amount of detail without generating literally kilobytes

of data per second. So I gave up. But most of all I didn't expect that it would be related to an

HTTP request.

 

One would think it would have been obvious seen as a series of GETs from some IP each immediately followed by a "spurious abort".

[Paul Phillips]

On Mon, Mar 18, 2013 at 1:50 PM, Lukas Rytz <lukas...@epfl.ch> wrote:

 - Having GET requests trigger actions is bad design

I went looking for a pithy quote to reinforce this and learned a whole new "word" when something said that GET requests should be nullipotent.

"Describing an action which has no side effect. Queries are typically nullipotent: they return useful data, but do not change the data structure queried. Contrast with idempotent."

...on the other hand, I'm not sure how this is supposed to differ from "pure".

[Lukas Rytz]

maybe the difference is that the same GET request might return different results over time, while

pure functions are expected to be, well, functions of their arguments, referentially transparent.