Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Long Running Async Operations fail to be serialized by AzureJacksonAdapter #612

Open
crachmanin opened this issue May 22, 2019 · 2 comments
Assignees
Labels

Comments

@crachmanin
Copy link
Contributor

It appears that some long running Async Operations cannot be serialized by the AzureJacksonAdapter.

When attempting to create a live event using the Java SDK generated for Azure Media Services (see https://github.com/Azure/azure-sdk-for-java/tree/master/mediaservices/resource-manager/v2018_07_01 beta 3 version) the following error is encountered:

com.microsoft.azure.CloudException: polling response does not contain a valid body: {
"name":"1431219a-acad-4d70-9a17-f8b7a5a143cb","status":"InProgress","error":{
"code":"None","message":null,"target":"e1a19fd1-8110-470a-a82f-9f789c2b2917"
}
}
at com.microsoft.azure.AzureAsyncOperation.fromResponse(AzureAsyncOperation.java:148)

You can reproduce the issue with the following media services code:

MediaManager mediaManager = MediaManager.authenticate(restClient, config.getSubscriptionId());
AzureMediaServicesImpl client = mediaManager.inner()
MediaServiceInner mediaService = client.mediaservices().getByResourceGroup(config.getResourceGroup(), config.getAccountName());

IPRange allAllowIpRange = new IPRange().withName("AllowAll").withAddress("0.0.0.0").withSubnetPrefixLength(0);

IPAccessControl ipAccessControl = new IPAccessControl().withAllow(ImmutableList.of(allAllowIpRange));
LiveEventInputAccessControl liveEventInputAccess = new LiveEventInputAccessControl().withIp(ipAccessControl);

LiveEventInner parameters = new LiveEventInner()
.withDescription("Sample LiveEvent for testing")
.withVanityUrl(false)
.withEncoding(new LiveEventEncoding().withEncodingType(LiveEventEncodingType.NONE).withPresetName(null))
            .withInput(new LiveEventInput().withStreamingProtocol(LiveEventInputProtocol.RTMP).withAccessControl(liveEventInputAccess));
 liveEvent.withLocation(mediaService.location());

 LiveEventInner liveEvent = client.liveEvents().create(config.getResourceGroup(), config.getAccountName(), liveEventName, parameters)
@v-jizhang
Copy link

I'll use the following Json string as example. The deserialization of "name" and "status " are Ok. The problem is "error" property.

"{
 "name":"e35e6e97-f675-4332-935d-0e9dc5cc2010",
 "status":"Succeeded",
 "error":{
 	"code":"None",
	"message":null,
	"target":"7eadf3ee-e262-4ae4-8484-65cf797ba99f"
 	}
 }"

The "error" property is a sub-tree and needs a codec to be read, as seen in method "deserialize" in CloudErrorDeserialization.java (line 3), which tries to read the tree. But the passed in argument p does not have a codec and it's where the exception is thrown.
```
1 @OverRide
2 public CloudError deserialize(JsonParser p, DeserializationContext ctxt) throws IOException {
3 JsonNode errorNode = p.readValueAsTree();
4 if (errorNode == null) {
5 return null;
6 }
7 if (errorNode.get("error") != null) {
8 errorNode = errorNode.get("error");
9 }
10
11 JsonParser parser = new JsonFactory().createParser(errorNode.toString());
12 parser.setCodec(mapper);
13 return parser.readValueAs(CloudError.class);
14 }

I think the fix is simple, we have a reference (line 12 sets the codec) to the codec and we can use that to read the tree directly. Just replace line 3 with:
JsonNode errorNode = mapper.readTree(p);  // Or something similar to this line.

praries880 added a commit that referenced this issue May 24, 2019
@praries880
Copy link
Contributor

@v-jizhang Thanks for adding the information.

We have a fix for the issue : #614

praries880 added a commit that referenced this issue May 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants