Activating master view as in MasterView I created:
var advOutputPayload = new JobSvf2OutputPayloadAdvanced();
advOutputPayload.GenerateMasterViews = true;
// prepare the payload
List<JobPayloadItem> outputs = new List<JobPayloadItem>()
{
new JobPayloadItem(
JobPayloadItem.TypeEnum.Svf,
new List<JobPayloadItem.ViewsEnum>()
{
JobPayloadItem.ViewsEnum._2d,
JobPayloadItem.ViewsEnum._3d
},
advOutputPayload
)
};
JobPayload obJob = new JobPayload(new JobPayloadInput(b64(info.revitFileUrn)), new JobPayloadOutput(outputs));
then I call with 'x-ads-force: true' using the SDK:
dynamic jobPosted = await derivative.TranslateAsync(jobPayload, force);
Where force is set to true.
And sometimes it works perfectly fine but sometimes I get this two errors:
Case 1
Error calling Translate: {"fault":{"faultstring":"Gateway Timeout","detail":{"errorcode":"messaging.adaptors.http.flow.GatewayTimeout"}}}
Case 2 (when I try to rerun.):
{"Result":"Conflict","Diagnostic":"The request is rejected as it conflicts with a previous request that is in-progress."...
What I am doing wrong or what I should do?
The network jitter might cause the 504 Gateway Timeout error since it could not reproduce on your side now. If it occurs again, feel free to report to us via forge[DOT]help[AT]autodesk[DOT]com.
Regarding the 409 Conflict error, it means that Forge service has accepted your previous request translation job and it's processing the job, but you request another translation job with x-ads-force=true, then it returns 409 Conflict. if you retry without x-ads-force=true, then it will return 201 Created, according to our engineering team.
Hope it's clear enough to you.
Related
I want to send streaming data (as sequences of ArrayBuffer) from a Chrome extension to a Chrome App, since Chrome message API (includes chrome.runtime.sendMessage, postMessage...) does not support ArrayBuffer and JS arrays have poor performance, I have to try other methods. Eventually, I found WebRTC over RTCDataChannel might a good solution in my case.
I have succeeded to send string over a RTCDataChannel, but when I tried to send ArrayBuffer I got:
code: 19
message: "Failed to execute 'send' on 'RTCDataChannel': Could not send data"
name: "NetworkError"
It seems that it's not a bandwidths limits problem since it failed even though I sent one byte of data. Here is my code:
pc = new RTCPeerConnection(configuration, { optional: [ { RtpDataChannels: true } ]});
//...
var dataChannel = m.pc.createDataChannel("mydata", {reliable: true});
//...
var ab = new ArrayBuffer(8);
dataChannel.send(ab);
Tested on OSX 10.10.1, Chrome M40 (Stnble), M42(Canary); and on Chromebook M40.
I have filed a bug for WebRTC here.
I modified my code, now everything worked amazing:
removed RtpDataChannels option when creating RTCPeerConnection.(YES, remove RtpDataChannels option if you want data channel, what a magic world!)
on receiver side: no need createDataChannel, instead, handle onmessage, onxxx by using event.channle from pc.ondatachannel callback:
pc.ondatachannel function(event)
var receiveChannel = event.channel;
receiveChannel.onmessage = function(event){
console.log("Got Data Channel Message:", event.data);
};
};
This issue has been bugging me since the inception of the new Google Drive Android Api (GDAA).
First discussed here, I hoped it would go away in later releases, but it is still there (as of 2014/03/19). The user-trashed (referring to the 'Remove' action in 'drive.google.com') files/folders keep appearing in both the
Drive.DriveApi.query(_gac, query), and
DriveFolder.queryChildren(_gac, query)
as well as
DriveFolder.listChildren(_gac)
methods, even if used with
Filters.eq(SearchableField.TRASHED, false)
query qualifier, or if I use a filtering construct on the results
for (Metadata md : result.getMetadataBuffer()) {
if ((md == null) || (!md.isDataValid()) || md.isTrashed()) continue;
dMDs.add(new DrvMD(md));
}
Using
Drive.DriveApi.requestSync(_gac);
has no impact. And the time elapsed since the removal varies wildly, my last case was over 12 HOURS. And it is completely random.
What's worse, I can't even rely on EMPTY TRASH in 'drive.google.com', it does not yield any predictable results. Sometime the file status changes to 'isTrashed()' sometimes it disappears from the result list.
As I kept fiddling with this issue, I ended up with the following superawfulhack:
find file with TRASH status equal FALSE
if (file found and is not trashed) {
try to write content
if ( write content fails)
create a new file
}
Not even this helps. The file shows up as healthy even if the file is in the trash (and it's status was double-filtered by query and by metadata test). It can even be happily written into and when inspected in the trash, it is modified.
The conclusion here is that a fix should get higher priority, since it renders multi-platform use of Drive unreliable. It will be discovered by developers right away in the development / debugging process, steering them away.
While waiting for any acknowledgement from the support team, I devised a HACK that allows a workaround for this problem. Using the same principle as in SO 22295903, the logic involves falling back to RESTful API. Basically, dropping the LIST / QUERY functionality of GDAA.
The high level logic is:
query the RESTful API to retrieve the ID/IDs of file(s) in question
use retrieved ID to get GDAA's DriveId via 'fetchDriveId()'
here are the code snippets to document the process:
1/ initialize both GDAA's 'GoogleApiClient' and RESTful's 'services.drive.Drive'
GoogleApiClient _gac;
com.google.api.services.drive.Drive _drvSvc;
void init(Context ctx, String email){
// build GDAA GoogleApiClient
_gac = new GoogleApiClient.Builder(ctx).addApi(com.google.android.gms.drive.Drive.API)
.addScope(com.google.android.gms.drive.Drive.SCOPE_FILE).setAccountName(email)
.addConnectionCallbacks(ctx).addOnConnectionFailedListener(ctx).build();
// build RESTFul (DriveSDKv2) service to fall back to
GoogleAccountCredential crd = GoogleAccountCredential
.usingOAuth2(ctx, Arrays.asList(com.google.api.services.drive.DriveScopes.DRIVE_FILE));
crd.setSelectedAccountName(email);
_drvSvc = new com.google.api.services.drive.Drive.Builder(
AndroidHttp.newCompatibleTransport(), new GsonFactory(), crd).build();
}
2/ method that queries the Drive RESTful API, returning GDAA's DriveId to be used by the app.
String qry = "title = 'MYFILE' and mimeType = 'text/plain' and trashed = false";
DriveId findObject(String qry) throws Exception {
DriveId dId = null;
try {
final FileList gLst = _drvSvc.files().list().setQ(query).setFields("items(id)").execute();
if (gLst.getItems().size() == 1) {
String sId = gLst.getItems().get(0).getId();
dId = Drive.DriveApi.fetchDriveId(_gac, sId).await().getDriveId();
} else if (gLst.getItems().size() > 1)
throw new Exception("more then one folder/file found");
} catch (Exception e) {}
return dId;
}
The findObject() method above (again I'm using the 'await()' flavor for simplicity) returns the the Drive objects correctly, reflecting the trashed status with no noticeable delay (implement in non-UI thread).
Again, I would strongly advice AGAINST leaving this in code longer than necassary since it is a HACK with unpredictable effect on the rest of the system.
While I´ve been trying to make the basic notification hub tutorial work on my Windows Phone solution with the following code
var channel = HttpNotificationChannel.Find("MyPushChannel3");
if (channel == null)
{
channel = new HttpNotificationChannel("MyPushChannel3");
channel.Open();
channel.BindToShellToast();
}
channel.ChannelUriUpdated += new EventHandler<NotificationChannelUriEventArgs>(async (o, args) =>
{
var hub = new NotificationHub("http://messaging-ns.servicebus.windows.net/messagingt", "---MY CONECTION STRING---");
await hub.RegisterNativeAsync(args.ChannelUri.ToString());
});
I get a NotificationHubNotFoundException in the await line with the following message
HTTP request failed.
HTTP Details:
Status: 404
Reason: Not Found
Full content: 404No service is hosted at the specified address..TrackingId:2e4b1100-18de-4b24-bbec-68516ddc3b60_G4,TimeStamp:2/2/2014 1:30:23 AM
I tried a number of options for the first parameter of the NotificationHub constructor called "notificationHubPath" with no luck to get my app registered. Anyone has faced this error in the past. Unfortunately there are not enough documentation in how does this constructor works in MDSN.
Thanks
When creating the NotificationHub type object, try by passing just the hub name with the connection string, not the whole address:
var hub = new NotificationHub("messagingt", "---CONECTION STRING---");
I had the same issue, and after close/open VS2013, restart PC and change Wifi/3g connection it worked again like before... strange, i suppose that was a internet connection issue.
you can use fiddler to show more information, i forgot in my case...
First of all, I'm using the most recent of Rx, that is 2.1. As far as I understand, lots of things have changed when Rx turned 2, so I'm really looking forward to receive an up-to-date answer. Thanks in advance.
I'm implementing a classic task for Rx: observing text of TextBox (AutoCompleteBox from WPToolkit to be exact), in order to provide a list of suggestions to user. Suggestions are fetched from the network, and I want to use these ordinary Rx goodies, like Throttle, DistinctUntilChanged, etc.
I'm also using recently released portable HttpClient for Windows Phone 8, since it provides task-based asynchronous API, which is nice.
The problem I'm having is the cross-thread access while reading the Text value of 'AutoCompleteBox`. Here is the code:
var http = new HttpClient();
var searchFunc = Observable.FromAsync<HttpResponseMessage>(() =>
http.GetAsync(FormatUrl(SEARCH_URL, "DE", new GeoCoordinate(51, 13), searchBox.Text /* <-- causes exception */, 10, "")));
var uithread = new SynchronizationContextScheduler(SynchronizationContext.Current);
var textChange = Observable.FromEventPattern<RoutedEventArgs>(searchBox, "TextChanged")
.Throttle(TimeSpan.FromMilliseconds(800))
.DistinctUntilChanged()
.SubscribeOn(uithread)
.SelectMany(searchFunc)
.Select(async (resp) => SearchResultsParser.ParseSearchResults(await resp.Content.ReadAsStreamAsync(), new GeoCoordinate(51, 13)))
.Select(async (results) => searchBox.ItemsSource = await results)
.ObserveOn(uithread)
.Subscribe();
Exception happens when searchFunc is executed. I see from VS that it executes on a Worker Thread, despite I use SubscribeOn.
Here's the example using SynchronizationContextScheduler, but I've also tried just SubscribeOnDispatcher, with the same result. Looks like I'm missing something important with this ObserveOn stuff, or maybe regarding Observable.FromAsync. Could you kindly point me to my mistake?
SubscribeOn is almost never what you want - you might think it means "Where my Subscribe method runs", but it actually means "Where the actual wiring to the IDisposable (and disposal) runs" - ObserveOn is the equivalent for "This is where I want my actual Subscribe code to execute"
Ref: Observable.SubscribeOn and Observable.ObserveOn
Please consider the following code and the explanation from this Mozilla tutorial "Using web workers":
var myWorker = new Worker('my_worker.js');
myWorker.onmessage = function(event) {
print("Called back by the worker!\n");
};
Line 1 in this example creates and
starts running the worker thread.
Line 2 sets the onmessage handler for
the worker to a function that is
called when the worker calls its own
postMessage() function.
The thread is started in the moment the Worker constructor is called. I wonder if there might be a race-condition on setting the onmessage handler. For example if the web worker posts a message before onmessage is set.
Does someone know more about this?
Update:
Andrey pointed out that the web worker should start its work, when it receives a message, like in the Fibonacci example in the Mozilla tutorial. But doesn't that create a new race-condition on setting the onmessage handler in the web worker?
For example:
The main script:
var myWorker = new Worker('worker.js');
myWorker.onmessage = function(evt) {..};
myWorker.postMessage('start');
The web worker script ('worker.js')
var result = [];
onmessage = function(evt) {..};
And then consider the following execution path:
main thread web worker
var worker = new Worker("worker.js");
var result = [];
myWorker.onmessage = ..
myWorker.postMessage('start');
onmessage = ..
The "var result = []" line can be left out, it will still be the same effect.
And this is a valid execution path, I tried it out by setting a timeout in the web worker! At the moment I can not see, how to use web workers without running into race-conditions?!
The answer is that both the main script and the web worker have a MessagePort queue which collects the messages before the initial worker script returns.
For details, see this thread on the WHATWG help mailing list:
http://lists.whatwg.org/pipermail/help-whatwg.org/2010-August/000606.html