GoogleCloudPlatform / google-cloud-java / 3081 / 2
72%
master: 72%

DEFAULT BRANCH: master
Ran
Files 458
Run time 24s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 81.124% (-0.5%) from 81.612%
3081.2

push

travis-ci

garrettjonesgoogle 
pubsub: start with polling by default (#1625)

* pubsub: start with polling by default

Previously, Subscribers start with streaming pull and fall back
to polling pull if streaming is unavailable.
To prevent fallback or streaming from causing any problem in production,
this commit starts Subscribers with polling pull directly.
Streaming pull will be re-enabled once the endpoint is working.

Since the ultimate fate of fallback is up in the air,
I chose to comment out the start-with-streaming code instead of
deleting.

This change also smoked out a logic bug that causes a race condition.
A message can be "nacked" either by calling AckReplyConsumer::accept
with an explicit NACK or a throwable signally an error.
The explicit NACK case works properly.

In case of a throwable, MessageDispatcher did not set the "acked" flag.
(Acks and nacks share most of the same code path;
they might as well use the same flag.)
This causes two things to happen concurrently.

1. Since the message is being nacked, it is added to the nack list
to be reported to the pubsub service.

2. Pubsub client automatically extends deadlines of the messages
the client's user is processing. Since acked flag is not set,
the client also tries to extend the message's deadline.

If (1) happens first, the test code sees that the message is being
nacked and the test passes even though the client will later
incorrectly extend the message's deadline.

If (2) happens first, the test code sees the incorrect deadline
extension and fails.

The fix is simple: set the acked flag.

* pubsub: fix testModifyAckDeadline flaking, maybe

Previously MessageDispatcher starts off with deadline duration of 0.
Since we need to extend deadline before the time is up,
the client extends deadline a little before the deadline.
This translates to scheduling deadling extension "in the past".

In turn, this causes tasks to be run -- and new tasks scheduled --
without explicit ... (continued)

20036 of 24698 relevant lines covered (81.12%)

119.13 hits per line

Source Files on job 3081.2