I am trying to upload a large json data from android retrofit client to django rest api view.
For example(Json Data):
{'post_data': [{'x':'asdkdadlf fdsfsd','y':'This is a paragraph........ Ending paragraph', 'created_on':'2018-22-08'},
{'x':'asdkdadlf fdsfsd','y':'This is a paragraph........ Ending paragraph', 'created_on':'2018-22-08'},
{'x':'asdkdadlf fdsfsd','y':'This is a paragraph........ Ending paragraph', 'created_on':'2018-22-08'},
....
{'x':'asdkdadlf fdsfsd','y':'This is a paragraph........ Ending paragraph', 'created_on':'2018-22-08'},
{'x':'asdkdadlf fdsfsd','y':'This is a paragraph........ Ending paragraph', 'created_on':'2018-22-08'},
]}`
API Response output:
08-22 13:21:12.964 15628-16104/com.mml.wapp D/Abhay: Group type: 1 group name: REAL ESTATE PROPERTYfrom:+234 818 230 9054
08-22 13:21:12.995 15628-16104/com.mml.wapp D/Abhay: Total messages in db before adding current message: 100
08-22 13:21:13.062 15628-16104/com.mml.wapp D/deleteMessage: Deleted all messages
08-22 13:21:13.200 15628-16109/com.mml.wapp D/OkHttp: --> POST https://api.multiplymyleads.com/api/upload_whatsapp_msgs/ http/1.1
Content-Type: application/x-www-form-urlencoded
08-22 13:21:13.204 15628-16109/com.mml.wapp D/OkHttp: Content-Length: 73304
08-22 13:21:13.211 15628-16109/com.mml.wapp D/OkHttp: postdata=%7B%22%E2%80%AA%2B234%20818%20230%209054%E2%80%AC%22%3A%5B%7B%22group_type%22%3A%221%22%2C%22time%22%3A%222018-08-
... followed by a lot more of that
As far as I understand, data in above response seems huge, may be that's why its getting timeout error? As its not able to upload all data in one API call in given timeout time in server side.
What can we do to resolve above issue ?
I have checked API returning success response if reduce the json post_data size.
I am using retrofit 2.0 client in android side for API call.
After lot of research I solved it from android side using below spinet of code.
OkHttpClient client = new OkHttpClient();
client.newBuilder()
.connectTimeout(60, TimeUnit.SECONDS)
.readTimeout(60L, TimeUnit.SECONDS)
.writeTimeout(60L, TimeUnit.SECONDS);;
Which increases timeout for response.
I am using the Zuora soap API. I am attempting to perform a query. I don't get any errors but the results are always null when I output the payload to log. What am I doing wrong? (the query I provide below should return 320 records, which is what I get if I execute the same query in a local non-mule test script)
This is the section of the flow.
I set the zoql query to flowVars (flowVars.query). For example : select id from Account WHERE updatedDate > '2016-06-24T23:00:00-06:00'
I use dataweave to create the xml payload (dw provided below)
I execute the query (web service consumer app xml details provided below)
DataWeave to set payload:
%dw 1.0
%output application/xml
%namespace ns0 http://api.zuora.com/
---
{
ns0#query: {
ns0#queryString: flowVars.query
}
}
Web Service Consumer app xml
<ws:consumer config-ref="ZuoraWebServiceConsumer" operation="query" doc:name="query_zuora"/>
ZuoraWebServiceConsumer config details:
<ws:consumer-config name="ZuoraWebServiceConsumer" wsdlLocation="zuora.a.49.0-sandbox.wsdl" service="ZuoraService" port="Soap" serviceAddress="https://apisandbox-api.zuora.com" doc:name="Web Service Consumer">
<ws:security>
<ws:wss-username-token username="myusername.here" password="mypassword.here" passwordType="TEXT" />
</ws:security>
</ws:consumer-config>
And the WSDL:
https://www.dropbox.com/s/fkrppvv7i5s1a4w/zuora.a.49.0-sandbox.wsdl?dl=0
After working with MuleSoft Support, it was discovered there is a bug with the Zuora connector. When Zuora returns an invalid session error, the Zuora connector is not catching it, destroying the connection from the pool, and initiating a new connection. MuleSoft has confirmed the bug.
I am trying to do some SOAP web service testing from Jmeter for POST methods. But I am not getting proper response. Please find some of the conditions and their exceptions below.
1) Implementation = HttpClinet4
Request: POST http://example.com/getInfo
With Post body request
Response: <HEAD><TITLE>Authentication Required</TITLE></HEAD>
<!-- default "Authentication Required" response (307) -->
</BODY>
Status : Pass
2) Implementation = HttpClinet3
Request: POST http://example.com/getInfo
With Post body request
Response: <HEAD><TITLE>internal error - server connection terminated</TITLE></HEAD>
Description: internal error - server connection terminated</B></FONT>
<HR>
<!-- default "internal error - server connection terminated" response (502) -->
</BODY>
Status : Fail
3) Implementation = Java
Request: POST http://example.com/getInfo/With some garbage value
With Post body request
Response:
Description: internal error - server connection terminated</B></FONT>
<HR>
<!-- default "internal error - server connection terminated" response (502) -->
</BODY>
Status : Fail
Why I am getting three different request and responses for different implementations? Which one should I use?
Note: I am running my Jmeter behind proxy with proper details from command prompt.Thanks in advance.
I'm using Apache JMeter 2.11 to test a web service with authentication. For the sample request I'm using View Results Tree as a listener and a SOAP/XML-RPC Request with the following syntax to my parameters:
URL: http://www.domain.com:####/dir/dir/webservice.asmx
SOAPAction: http://www.domain.com/action
What I have tried
1) Adding an HTTP Header Manager using
Name: Authorization:
Value: Basic [Base64 code encoded in ASCII, UTF-8, with or without domain in the user name] as explained here
With result: Response headers: HTTP/1.1 401 Unauthorized
2) Adding an HTTP Authorization Manager using
Base URL: http://www.domain.com:####
Username: [USERNAME]
Password: [PASSWORD]
Domain: [DOMAIN]
Realm: [NULL]
Mechanism: [BASIC_DIGEST/KERBEROS] as explained here
With result: Response headers: HTTP/1.1 401 Unauthorized
I also tried enabling Keep Alive in the request as suggested here
What am I doing wrong?
First you need to know the auth type, is it basic ? Digest ? Kerberos or other ?
Second, don't use SOAP/XML-RPC Request, use Http Request,
See Templates > Webservice in jmeter menu, it creates a sample test plan for Soap testing.
Add then your authentication with the correct Auth Manager using HttpClient 4 as sampler implementation and check.
After I got my single-page web app working (web pages served with ServiceStack's RazorFormat() MVC, not .ASP MVC), I ran a (previously passing) test for the service. The test failed. Tested the web app again (debug run, navigate to //localhost:1337/ResourceList in the browser): still working. Is something wrong with my test?
Here's the error:
Test Name: TestResourceList
Test FullName: [0-1015]ServiceWrapper.Test.TestSWrapperServices.TestResourceList
Test Source: c:\Users\uname\Documents\Visual Studio 2012\Projects\ServiceWrapper\UnitTestProject1\ServiceTests.cs : line 96
Test Outcome: Failed
Test Duration: 0:00:02.188
Result Message:
System.Net.WebException : Unable to connect to the remote server
----> System.Net.Sockets.SocketException : No connection could be made because the target machine actively refused it 127.0.0.1:1337
Result StackTrace:
at System.Net.HttpWebRequest.GetResponse()
at ServiceStack.ServiceClient.Web.ServiceClientBase.Send[TResponse](String httpMethod, String relativeOrAbsoluteUrl, Object request)
at ServiceStack.ServiceClient.Web.ServiceClientBase.Get[TResponse](IReturn`1 request)
at ServiceWrapper.Test.TestSWrapperServices.TestResourceList() in c:\Users\uname\Documents\Visual Studio 2012\Projects\ServiceWrapper\UnitTestProject1\ServiceTests.cs:line 98
--SocketException
at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Exception& exception)
Here's the test:
namespace ServiceWrapper.Test
{
[TestFixture]
public class TestSWrapperServices
{
AppHost appHost;
private const string ListeningOn = "http://*:1337/";
public const string Host = "http://localhost:1337";
private const string BaseUri = Host + "/";
[TestFixtureSetUp]
public void OnTestFixtureSetUp()
{
var appSettings = new AppSettings();
var username = Environment.GetEnvironmentVariable("USERNAME");
var userdomain = Environment.GetEnvironmentVariable("USERDOMAIN");
AppHost.AppConfig = new AppConfig(new AppSettings());
appHost = new AppHost();
// initialize Service Server
ServiceServer.SetUser(AppHost.AppConfig.UserName, AppHost.AppConfig.Password);
ServiceServer.SetLog(String.Empty);
try
{
appHost.Init();
appHost.Start(ListeningOn);
}
catch (HttpListenerException ex)
{
if (ex.ErrorCode == 5)
{
System.Diagnostics.Debug.WriteLine("You need to run the following command (as admin):");
System.Diagnostics.Debug.WriteLine(" netsh http add urlacl url={0} user={1}\\{2} listen=yes",
ListeningOn, userdomain, username);
}
else
{
System.Diagnostics.Debug.WriteLine("ERROR: {0}: {1}", ex.GetType().Name, ex.Message);
}
}
catch (Exception ex)
{
System.Diagnostics.Debug.WriteLine("ERROR: {0}: {1}", ex.GetType().Name, ex.Message);
}
}
[TestFixtureTearDown]
public void OnTestFixtureTearDown()
{
appHost.Dispose();
}
[Test]
public void TestResourceList()
{
JsonServiceClient client = new JsonServiceClient(BaseUri);
ResourceList response = client.Get(new ResourceList());
Assert.Contains("Some Value", response.property);
}
[Test]
}
}
I upgraded to the latest ServiceStack - 3.9.55, and it still didn't work. So, I started over again, sanity checking from the beginning. It turns out that the program.cs ListeningOn has http://*:1337/ while the nunit TestFixture ListeningOn was http://localhost:1337/
Checking urlacl (as admin) for http://localhost:1337/:
C:\Windows\system32>netsh http show urlacl url=http://localhost:1337/
URL Reservations:
-----------------
Checking urlacl (as admin) for http://*:1337/:
C:\Windows\system32>netsh http show urlacl url=http://*:1337/
URL Reservations:
-----------------
Reserved URL : http://*:1337/
User: DOMAIN\user
Listen: Yes
Delegate: No
SDDL: D:(A;;GX;;;S-1-5-21-2595267603-2801715271-1705165942-1002)
My earlier troubleshooting left the two projects with inconsistent ListeningOn values. Interestingly, using http://*:1337/ doesn't work as a wildcard url, as perhaps I had expected.
Here's a handy code snippet to help you build the add urlacl command. It also provides a useful (!) sanity check on the exact url you're listening on.
Console.WriteLine("You need to run the following command:");
Console.WriteLine(" netsh http add urlacl url={0} user={1}\\{2} listen=yes",
ListeningOn, userdomain, username);
--- Update ---
Upgrading ServiceStack eliminated the 'connection actively refused' error message. Once ListeningOn values were unified, the real
error message was exposed:
Result Message: ServiceStack.ServiceClient.Web.WebServiceException : Service Unavailable
Result StackTrace:
at ServiceStack.ServiceClient.Web.ServiceClientBase.ThrowWebServiceException[TResponse](Exception ex, String requestUri)
at ServiceStack.ServiceClient.Web.ServiceClientBase.ThrowResponseTypeException[TResponse](Object request, Exception ex, String requestUri)
at ServiceStack.ServiceClient.Web.ServiceClientBase.HandleResponseException[TResponse](Exception ex, Object request, String requestUri, Func`1 createWebRequest, Func`2 getResponse, TResponse& response)
at ServiceStack.ServiceClient.Web.ServiceClientBase.Send[TResponse](String httpMethod, String relativeOrAbsoluteUrl, Object request)
at ServiceStack.ServiceClient.Web.ServiceClientBase.Get[TResponse](IReturn`1 request)
at RemoteServerWrapper.Test.TestRSWrapperServices.TestDataList() in c:\Users\user\Documents\Visual Studio 2012\Projects\RemoteServerWrapper\UnitTestProject1\ServiceTests.cs:line 183
It's still obscure -- but at least it's not reporting something that's completely different from the real issue. So then I implemented trace in my app.config, like this:
<configuration>
<!-- ... other config settings ... -->
<system.diagnostics>
<sources>
<source name="System.Net" tracemode="includehex" maxdatasize="1024">
<listeners>
<add name="System.Net"/>
<add name="console"/>
</listeners>
</source>
<source name="System.Net.HttpListener">
<listeners>
<add name="System.Net"/>
<add name="console"/>
</listeners>
</source>
</sources>
<switches>
<add name="System.Net" value="Verbose"/>
<add name="System.Net.HttpListener" value="Verbose"/>
</switches>
<sharedListeners>
<add name="console"
type="System.Diagnostics.ConsoleTraceListener"
initializeData="false"/>
<add name="System.Net"
type="System.Diagnostics.TextWriterTraceListener"
initializeData="network.log"
/>
</sharedListeners>
<trace autoflush="true"/>
</system.diagnostics>
</configuration>
Which exposed a better error message:
ERROR: [::1]:1337 Request not found: /datarequest?DataKey=some_key&startDate=20130701&endDate=20130708
OK - now I have to pull in the servicestack sources so I can step through the code and figure out why I'm getting 'Not Found' in the test, when it works when I 'debug/run' and test via the browser. Turns out that RestHandler.FindMatchingRestPath(httpMethod, pathInfo, contentType) wasn't returning a match. Humm. Why is that? The AppHost is declared identically. So, what's different?
The rest services live in my project's main assembly. When run from 'debug/run' the default assembly has the services, and everything works. But when run from the test project, with the services assembly added as a reference, servicestack can't find them. They're not in the default location, relative to the test project. So I added an AppHost class at the top of my test file, rather than relying on the one from my program.cs, and declared it as follows:
public class RSWrapperServicesAppHostHttpListener
: AppHostHttpListenerBase
{
public RSWrapperServicesAppHostHttpListener()
: base("RSWrapper Services Tests", typeof(DataRequestService).Assembly) { }
// 'DataRequestService' is a random rest service class,
// defined in the referenced services assembly
}
Now ServiceStack is happy, and my tests work again.
How did they ever work? Originally everything was jumbled together all in one project. Once I separated things into separate assemblies, i.e. DTO, Services, Business Logic and Tests, I broke it. But since I was temporarily holding off on unit tests while getting the UI working, I didn't notice right away.