Is there any reason a postman post request would work but the very same restsharp code gateway times out? I can still get the token just fine through restsharp, but when I try one request, it times out.
For what it's worth, I just battled with this error myself making a request to the exact same endpoint.
I had Restsharp installed via the NuGet Package Manager and then installed the Elli.Api package. Once I installed this package the timeout errors started, but were not happening before (Note: I was making direct API calls and not using the EllieMae dotnet bindings, but installing the Elli.Api package still caused timeouts).
What seemed to work for me is installing the Elli.Api package, then uninstalling Restsharp and reinstalling it. Requests seemed to function normally after this.
One other note: the Restsharp package I used was 106.2.2 both when I uninstalled it and when I reinstalled it.
EDIT: Doing this seems to cause various errors when you try to use the dotnet bindings (such as a missing method error when trying to use GetAccessToken).
Related
Hy everbody,
I created a ASP.NET Core Web App which i run as a Windows Service.
That is working fine until i started to use Devart as DB-Provider for my Oracle-Database.
As soon as is include the Nuget-Package Devart.Data.Oracle.EFCore in my Project i get the following Error when i try to start my Windows Service:
[SC] StartService FAILED 1053:
The service did not respond to the start or control request in a timely fashion.
I can start the Service again when i remove the Package Devart.Data.Oracle.EFCore.
The Nuget-Package Devart.Data is also included but there is no Problem.
I can start the Service with the Package Devart.Data inculded without any Issue.
Unfortunately i need both Packages.
Maybe someone can give me a hint where i can find what the Problem with the Package Devart.Data.Oracle.EFCore is?
Thank you very much.
I tried a view suggestions from there: https://appuals.com/how-to-fix-error-1053-the-service-did-not-respond-to-the-start-or-control-request-in-a-timely-fashion/#:~:text=Users%20experience%20the%20error%20message,respond%20in%20the%20time%20window.
I want to update my server with the latest version of parse server, but I am running into the issue where are all the calls send back a 403 Forbidden.
The exact same calls work on 2.2.23 and below but not on 2.2.24 and above. I am using parse for an iOS app, where I am using SDK 1.14.
Notes on the setup:
added VERBOSE environment variable, logs correctly on 2.2.23 but nothing on 2.2.24
running the server in localhost with node v6.9.1 installed.
pointing to a DB in mLab with mongod version: 3.0.12.
using express "~4.14.x"
Reviewed issues:
https://github.com/ParsePlatform/parse-server/issues/508 Where the
user was able to fix it by starting from scratch with
parse-server-example. I have tested this, using my ParseServer
instantiation and copying over the cloud code, I am having the same
issue.
https://github.com/ParsePlatform/parse-server/issues/1017 Was about
passing the X-Parse-Application-Id, which I am doing since it is
working for 2.2.23 but not for 2.2.24 and higher
Has anybody experienced something similar? Any hint on what I could try?
Thanks!
I have an error importing a WSDL definition from an ASP.NET version 4 Visual Studio 2010 Express project, into SOAPUI 4.5.1
URL would be like
http://localhost:7929/ws/AX.asmx?WSDL
Error generated
Error loading [http://localhost:7929/ws/AX.asmx?WSDL]: org.apache.xmlbeans.XmlException:
org.apache.xmlbeans.XmlException: error: Unexpected element: TAG_END
Error trace:
com.eviware.soapui.impl.support.definition.support.InvalidDefinitionException
at com.eviware.soapui.impl.wsdl.support.wsdl.WsdlLoader.loadXmlObject(WsdlLoader.java:138)
at com.eviware.soapui.impl.wsdl.support.xsd.SchemaUtils.getDefinitionParts(SchemaUtils.java:535)
...
Any suggestions most welcome!
I had the same issue with Soap UI 5.2.0
The solution for me was to turn off the proxy (as suggested by #user518066)
The issue is that soapui doesn't know where to find the schema file.
If your wsdl is deployed to a server, it will return a url of the xsd file to include and soapui will be able to find it....
I had the same problem, after several hours I found that the problem was about IPv6.
When I go to service URL I can see and validate the wsdl file. There was no problem at all.
http://localhost/SoapServer.php?wsdl
But when I add this URL to SoapUI it gives error Unexpected element: TAG_END.
I found the reason by using cURL, curl http://localhost/SoapServer.php?wsdl returns 404!!
So realized that my Apache listens both IPv4 and IPv6, browser goes to IPv6 and gets the wsdl but cURL and SoapUI goes to IPv4 and get 404 error.
I disabled IPv6 on my Apache by removing the line Listen [::0]:80 in httpd.conf file, this solved the problem.
Are you sure that the service is running?
When debugging solutions with several WCF projects, there are times in which we could think that we are running the project we are working into and it turns not be that case.
If you face an Error 404 when enter the svc url into a browser, then this could be the cause of the problem.
In that scenario, SOAP UI will fail when trying to add or create a new WSDL endpoint.
So, make sure that your solution starts running from the project where the target svc is located.
This works locally. Set up: Grails 2.0.3. Debain Linux. I've deployed other applications successfully to Cloud Foundry.
Apparently this thing can happen as a consequence of the Spring Security Plugin not being happy with the resources plugin. Removing the resources plugin doesn't cure this.
This is the problem:
Class: java.lang.IllegalStateException
Message: No thread-bound request found: Are you referring to request attributes outside of
an actual web request, or processing a request outside of the originally receiving thread?
If you are actually operating within a web request and still receive this message, your
code is probably running outside of DispatcherServlet/DispatcherPortlet: In this case, use
RequestContextListener or RequestContextFilter to expose the current request.
Adding the org.springframework.web.context.request.RequestContextListener and its loader to web.xml and importing them into the page doesn't help either.
There is much about this on the web, but in my case it only happens on Cloud Foundry.
Cloud Foundry runs on Java 1.6, like my machine. The logs say the same as the quote above, with stack traces identical to what I've found on the web.
Any ideas? I'm stuck. I've spent the best of two days on this.
Thanks.
Adding compile ":webxml:1.4.1" to the plugins section of BuildConfig.groovy should fix that. Credit to http://support.cloudfoundry.com/entries/21371626-grails-mongodb-deployment-fails
I have installed the OpenID plugin (v0.4.3) for my Grails(v2.0.1) app but I am having trouble authenticating with Google as the OpenID provider.
I believe the problem is that OpenId4Java v0.9.4 doesn't handle Google's response properly. I read this somewhere the other day but can't find a reference at the moment (will edit when I find it).
So I want to upgrade the version of the OpenId4Java jar that the plugin has with a later version. But I am not sure where/how to do this.
In the <home dir>/.grails/2.0.1/projects/<my project>/plugins/openid-0.4.3/lib folder the jar is java-openid-sxip-0.9.4.jar. And the one I find in the recommended download from http://code.google.com/p/openid4java/ is openid4java-0.9.6.jar.
I've never had to replace a jar supplied by a plugin before so I'm just wondering where I should put the 0.9.6 jar, and how I get my app to recognise it?
It seems that installing version 0.4.4 (released late May 2012) of the OpenID plugin does the trick. It comes with openid4java-nodeps-0.9.6.jar instead of java-openid-sxip-0.9.4.jar meaning the newer version (v0.9.6) of OpenId4Java is used.