I am trying to upgrade prebid v0.34.10 to v1.11.0 and I noticed getBidResponses() behaves differently between the two versions.
For v0.34.10, if nobody participates in the auction, then in the statusMessage it would say Bid returned empty or error response
For v1.11.0, if nobody participates in the auction, then the same method will just return with a smaller list of adUnits with a smaller list of bidders.
I took a look at the upgrade notes but I didn't see any mentions for the problem above.
Does anyone know if there is a config or alternative method I can use to check the status of an bid? I was using the getBidResponses() method to create e2e tests for our implementation
Prebid version 1+ doesn't record bids coming after the timeout while v0.34 does.
For more info check out this issue:
https://github.com/prebid/Prebid.js/issues/2640
Related
We have a concurrency issue in our system. This one occurs mainly during burst load through our API from an external system and is not reproducible manually.
So I would like to create a Gatling test to 1) reproduce it whenever I want and 2) check that we have solved the issue.
1) I am done for the first point. I have created two requests checking for the status 201 and I run them with many users.
2) This issue allow the creation of two resources with the same unique value. The expected behaviour is to have one that is created and the others should fail with the status 409. But I have no idea on how we can check that any of the request, but at least once, complete with 201 while all the others are failing with 409.
Can we do a kind of post-check on all requests with Gatling ?
Thanks
Store results already seen in a global ConcurrentHashMap and compute expected value in the is check in a function, based on presence in the CHM (201 for missing or 409 for existing).
I don't think you can achieve what you're after with a check on the call itself as gatling users have no visibility of results returned to other users, so you have no way of knowing whether the successful (201) request has already been made (short of some very messy hacking using a check transformer)
But you could use simulation level assertions to do this.
So you have your request where you assert that you expect a 201 response
http("my request")
.get("myUrl")
.check(status.is(201))
this should result in all but one of these requests failing in a simulation, which you can specify using the assertion...
setUp(
myScenario.inject(
...
)
)
.assertions(
details("my request").successfulRequests.count.is(1))
I am busy with configuring our new TFS 2015 server (on premises) and trying to get the new vnext builds to work properly.
What I now have are some extra powershell scripts that increase the version number of my assemblies.
It also changes the buildnumber in TFS by calling the API method (see tfs rest api). My json body only sends the new build number (eg. {"buildNumber": "1.0.1.1234"}) and this works fine.
Now I have added some major, minor and patch version variables in the build definition for the version. Once the build is done this should be updated and so I thought to do the same kind of thing and just send an update API call to the corresponding builddefinition endpoint. The documentation says the revision number is mandatory so I have added that. For the rest I only added the changed variables.
The api call works, but the nasty thing is that it will update the whole definition and clear out all the other settings which I did not provide in the json body. I also tried first getting the defintion through the API, changing the json values for the variables and send that back but that didnt work correct also.
So does anybody know a good solution for this?
As a workaround what I did for now is adding a dummy build definition (eg. "_ProjectVersion") totally empty except for the variables and my build task now uses that build definition to get the latest version numbers and update them. So the api call still empties that whole build definition but since it only contains my variables I dont mind.
I am also doing this in powershell since all scripting should be automated and done in powershell.
The problem I have is that the API call to get the json of an existing BuildDefinition returns invalid json when managed in powershell.
For example the "#{multipliers=[]; will fail with 'must have at least one value' even though a 'json validator' may report as Valid. The correct json is {"multipliers": "[]",
Worklight 6.1 on both Windows (colleague) and Mac (me), building an a Hybrid app destined for Android device but to speed up development we do initial testing as Mobile Web App in Chrome browser on desktop.
We get a weird symptom that I'm trying to fine-down to a reproducible test case. I think I see different behaviours when stepping in debugger and just letting it run. Want to check whether a certain coding pattern could be the cause of the symptom before I go any further.
Fundamental question: should we wait for the resolution of a promise returned by a JSONSTore request for an action on a collection before issuing another request? more explanation below.
The overall intent is to load some data into the JSONStore, with some intelligent replace/merge action if a record is already present. Pseudo code:
for each record retrieved from back-end
if ( record already present in Store )
do some data merging
replace record
else
add record
The application code actually works like this, just considering the add() case, the problem manifests when the store is empty, all records need to be added
for each record to add
addPromise = store.get().add(record);
listOfPromises.insert(addPromise);
examine the list of promises recording any errors
That is there is no "wait" for add to finish before issuing the next add request. Hence in effect we've initiated a set of adds "in parallel" whatever that might mean in JavaScript in Chrome.
The code appears to run just fine, no errors reported. On android device it works reliably. In Chrome under normal running (no stepping in debugger) we end up with no reported errors but only one record inserted - indeed as though a snapshot of the initial "empty" store had been taken and each add is working on that "empty" copy.
After writing this I'm now pretty convinced that the coding pattern described above is vulnerable to a kind of race and that the better approach is build a list of documents to be added and insert them in a single operation.
A more detailed answer will be coming later, but I now know that this
the coding pattern described above is vulnerable to a kind of race and
that the better approach is build a list of documents to be added and
insert them in a single operation.
is true. In the browser the JSONStore does require that we wait for the result of one request before issuing another one. The recommended approach is
var dataToAdd = buildArrayOfDataToAdd(responseFromServer);
var dataToReplace = buildArrayOfDataToReplace(responseFromServer);
jsonstore.add( dataToAdd ).then( function() { jsonstore.replace( dataToReplace); })
This is a strange bug that we started seeing about a year ago. At first, I only occasionally noticed it on my dev machine, but now it's been starting to appear in production, which is problematic.
We use Ubuntu (11.04), and Mono 2.6.7 in production (I can also repro with Mono 2.10.x), inside apache, using mod_mono.
Basically, sometimes (very hard to reproduce), when apache starts the application, SolrNet decides to lower case the entire URL it transmits to the solr server. If the application is in this state, it stays this way until it is restarted (and occasionally requires a couple of restarts to clear up.) We might go for 20 - 50 or more restarts without seeing this problem come up. or sometimes it will happen every 2 or 3.
A good url looks like this:
INFO: [] webapp=/solr path=/select params={sort=Creative.PromotionalScore+desc&start=0&q=*:*&?=&qt=standard&fq={!tag%3DCreative.GalleryReviewStatus}Creative.GalleryReviewStatus:Approved&fq={!tag%3DCreative.SectionIncludedTarget}Creative.SectionIncludedTarget:220358+OR+(NOT+Creative.SectionIncludedTarget:[*+TO+*]+*:*)&fq={!tag%3DActive}Active:true&fq={!tag%3DCreative.ShowInGallery}Creative.ShowInGallery:true&fq={!tag%3DCreative.Size}Creative.Size:"Rectangle"&fq={!tag%3DRecordType}RecordType:FiveToOne.Gallery.Rmx.Creative&rows=12}
A bad url looks like this:
http://solrServer:8080/solr/select?qt=standard&fq=%7b!tag%3dcreative.galleryreviewstatus%7dcreative.galleryreviewstatus%3aapproved&fq=%7b!tag%3dcreative.sectionincludedtarget%7dcreative.sectionincludedtarget%3a306433+or+(not+creative.sectionincludedtarget%3a%5b*+to+*%5d+*%3a*)&fq=%7b!tag%3dactive%7dactive%3atrue&fq=%7b!tag%3dcreative.showingallery%7dcreative.showingallery%3atrue&fq=%7b!tag%3dcreative.size%7dcreative.size%3a%22rectangle%22&fq=%7b!tag%3drecordtype%7drecordtype%3afivetoone.gallery.rmx.creative&sort=creative.promotionalscore+desc&rows=18&start=0&q=*%3a*&?
(first, I apologize, these two URLs are extracted from different stages of the pipe, all I have access to at the moment.)
When the bad url is submitted, Solr throws a fatal exception, complaining of an unknown field:
HTTP Status 400 - can not sort on undefined field: creative.promotionalscore
type Status report
message can not sort on undefined field: creative.promotionalscore
description The request sent by the client was syntactically incorrect (can not sort on undefined field: creative.promotionalscore).
Having used Solr and SolrNet in production for four years now, all I can say is that I've never seen this on .NET, so I'm guessing it's a bug in Mono.
In order to pinpoint where exactly the URL is becoming lowercase, I'd put several logging points, for example here, here, and here.
After this logging is in place, once the bug occurs, the log should be analyzed, logging should be probably refined, etc, until the exact source of the bug is located.
Hopefully then the bug can be reproduced, reported, fixed, etc.
I checked out the latest SVN trunk of qooxdoo and now i have the following problems:
Some events seems that they are not comming through
Virtual Lists are not filled anymore (the _createWidget() method of the extension from qx.ui.virtual.cell.AbstractWidget is not called)
My original version was QX 1.0.1-pre and the problems appeared also when i tried to migrate to 1.2
Just to get the obvious stuff out of the way, did you follow the steps of the migration guide and make any necessary changes outlined in migration.log?
Aside from that, the virtual widgets are still experimental and no migration path is provided, meaning you'll have to go over your code and check if the parts of the ui.virtual API you're using have changed since 1.0.1.
For the missing events, please provide some more information: What events are you listening for?
The problem with the event seems to be a bug in Qooxdoo