I want to use RequestBuilder to make HTTP requests in my PlayN project as described here:
http://code.google.com/webtoolkit/doc/latest/DevGuideServerCommunication.html#DevGuideHttpRequests
I added the tag in my module xml file:
but I still have the following compilation error:
The import com.google cannot be resolved
Is there something else I should do to make my project compile?
Here is the code:
import com.google.gwt.http.client.*;
...
String url = "http://www.myserver.com/getData?type=3";
RequestBuilder builder = new RequestBuilder(RequestBuilder.GET, URL.encode(url));
try {
Request request = builder.sendRequest(null, new RequestCallback() {
public void onError(Request request, Throwable exception) {
// Couldn't connect to server (could be timeout, SOP violation, etc.)
}
public void onResponseReceived(Request request, Response response) {
if (200 == response.getStatusCode()) {
// Process the response in response.getText()
} else {
// Handle the error. Can get the status text from response.getStatusText()
}
}
});
} catch (RequestException e) {
// Couldn't connect to server
}
If you're using Maven for your build (which I suspect you may be), make absolutely sure that the following dependency is in your html/pom.xml
<dependency>
<groupId>com.google.gwt</groupId>
<artifactId>gwt-user</artifactId>
<version>2.4.0</version>
<scope>provided</scope>
</dependency>
You might need to change the version if you're using a version of GWT other than 2.4.0
Edit: Now that I know you are running a Java application (based on the comments below) and not a GWT application, you're likely going to need to make HTTP requests with something other than GWT's HTTP client. You'll want to remove the aforementioned dependency and take a look at the answers to this question for some insight into how to do that...
If you're needing to make HTTP requests in both the GWT and Java PlayN targets, you're likely going to need to abstract the HTTP client interface needed in the core module and provide the appropriate concrete implementations in the java and GWT modules. I describe using Gin and Guice to inject java and GWT specific instances of AsyncService<> objects in this answer here, and a similar approach can be used in injecting the appropriate HTTP client instance required on a per platform basis if necessary...
Related
This article shows a well-known problem with HttpClient that can lead to socket exhaustion.
I have an ASP.NET Core 3.1 web application. In a .NET Standard 2.0 class library I've added a WCF web service reference in Visual Studio 2019 following this instructions.
In a service I'm using the WCF client the way it's described in the documentation. Creating an instance of the WCF client and then closing the client for every request.
public class TestService
{
public async Task<int> Add(int a, int b)
{
CalculatorSoapClient client = new CalculatorSoapClient();
var resultat = await client.AddAsync(a, b);
//this is a bad way to close the client I should also check
//if I need to call Abort()
await client.CloseAsync();
return resultat;
}
}
I know it's bad practice to close the client without any checks but for the purpose of this example it does not matter.
When I start the application and make five requests to an action method that uses the WCF client and then take a look at the result from netstat I discover open connections with status TIME_WAIT, much like the problems in the article above about HttpClient.
It looks to me like using the WCF client out-of-the-box like this can lead to socket exhaustion or am I missing something?
The WCF client inherits from ClientBase<TChannel>. Reading this article it looks to me like the WCF client uses HttpClient. If that is the case then I probably shouldn't create a new client for every request, right?
I've found several articles (this and this) talking about using a singleton or reusing the WCF client in some way. Is this the way to go?
###UPDATE
Debugging the appropriate parts of the WCF source code I discovered that a new HttpClient and HttpClientHandler were created each time I created a new WCF client which I do for every request.
You can inspect the code here
internal virtual HttpClientHandler GetHttpClientHandler(EndpointAddress to, SecurityTokenContainer clientCertificateToken)
{
return new HttpClientHandler();
}
This handler is used in to create a new HttpClient in the GetHttpClientAsync method:
httpClient = new HttpClient(handler);
This explains why the WCF client in my case behaves just like a HttpClient that is created and disposed for every request.
Matt Connew writes in an issue in the WCF repo that he has made it possible to inject your own HttpMessage factory into the WCF client.
He writes:
I implemented the ability to provide a Func<HttpClientHandler,
HttpMessageHandler> to enable modifying or replacing the
HttpMessageHandler. You provide a method which takes an
HttpClientHandler and returns an HttpMessageHandler.
Using this information I injected my own factory to be able to control the generation of HttpClientHandlers in HttpClient.
I created my own implementation of IEndpointBehavior that injects IHttpMessageHandlerFactory to get a pooled HttpMessageHandler.
public class MyEndpoint : IEndpointBehavior
{
private readonly IHttpMessageHandlerFactory messageHandlerFactory;
public MyEndpoint(IHttpMessageHandlerFactory messageHandlerFactory)
{
this.messageHandlerFactory = messageHandlerFactory;
}
public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters)
{
Func<HttpClientHandler, HttpMessageHandler> myHandlerFactory = (HttpClientHandler clientHandler) =>
{
return messageHandlerFactory.CreateHandler();
};
bindingParameters.Add(myHandlerFactory);
}
<other empty methods needed for implementation of IEndpointBehavior>
}
As you can see in AddBindingParameters I add a very simple factory that returns a pooled HttpMessageHandler.
I add this behavior to my WCF client like this.
public class TestService
{
private readonly MyEndpoint endpoint;
public TestService(MyEndpoint endpoint)
{
this.endpoint = endpoint;
}
public async Task<int> Add(int a, int b)
{
CalculatorSoapClient client = new CalculatorSoapClient();
client.Endpoint.EndpointBehaviors.Add(endpoint);
var resultat = await client.AddAsync(a, b);
//this is a bad way to close the client I should also check
//if I need to call Abort()
await client.CloseAsync();
return resultat;
}
}
Be sure to update any package references to System.ServiceModel.* to at least version 4.5.0 for this to work. If you're using Visual Studio's 'Add service reference' feature, VS will pull in the 4.4.4 versions of these packages (tested with Visual Studio 16.8.4).
When I run the applications with these changes I no longer have an open connection for every request I make.
You should consider disposing your CalculatorSoapClient. Be aware that a simple Dispose() is usually not enough, becaue of the implementation of the ClientBase.
Have a look at https://learn.microsoft.com/en-us/dotnet/framework/wcf/samples/use-close-abort-release-wcf-client-resources?redirectedfrom=MSDN, there the problem is explained.
Also consider that the underlying code is managing your connections, sometimes it will keep them alive for later use. Try calling the server a lot of times to see, if there is a new connection for each call, or if the connections are being reused.
The meaning TIME_WAIT is also discussed here:
https://superuser.com/questions/173535/what-are-close-wait-and-time-wait-states
https://serverfault.com/questions/450055/lot-of-fin-wait2-close-wait-last-ack-and-time-wait-in-haproxy
It looks like your client has done everything required to close the connection and is just waiting for the confirmation of the server.
You should not have to use a singleton since the framework is (usually) taking good care of the connections.
I created an issue in the WCF repository in Github and got some great answers.
According to Matt Connew and Stephen Bonikowsky who are authorities in this area the best solution is to reuse the client or the ChannelFactory.
Bonikowsky writes:
Create a single client and re-use it.
var client = new ImportSoapClient();
And Connew adds:
Another possibility is you could create a channel proxy instance from
the underlying channelfactory. You would do this with code similar to
this:
public void Init()
{
_client?.Close();
_factory?.Close();
_client = new ImportSoapClient();
_factory = client.ChannelFactory;
}
public void DoWork()
{
var proxy = _factory.CreateChannel();
proxy.MyOperation();
((IClientChannel)proxy).Close();
}
According to Connew there is no problem reusing the client in my ASP.NET Core web application with potentially concurrent requests.
Concurrent requests all using the same client is not a problem as long
as you explicitly open the channel before any requests are made. If
using a channel created from the channel factory, you can do this with
((IClientChannel)proxy).Open();. I believe the generated client also
adds an OpenAsync method that you can use.
UPDATE
Since reusing the WCF Client also means reusing the HttpClient instance and that could lead to the known DNS problem I decided to go with my original solution using my own implementation of IEndpointBehavior as described in the question.
I am trying to track the HTTP request and response time in Jetty. I have extended the jetty server and i am able to get the request timestamp using following snippet :
public void handle(HttpChannel connection) throws IOException,
ServletException {
super.handle(connection);
connection.getRequest().getTimeStamp();
}
I need to get the exact time of the response for the request.
How can i achieve it by extending jetty server ?
If any way of doing other than extending jetty. please let me know
Thank you
Since you seem to only be interested in the latency, do this.
The RequestLog mechanism is now to do this.
Instantiate a new RequestLogHandler and add it as the root of your server Handler tree (think nested, not collection).
Add a custom implementation of RequestLog to the RequestLogHandler
In your custom RequestLog.log(Request,Response) method, grab the Request.getTimeStamp() and work out the latency.
This approach is more durable to changes internally in Jetty, and does not require a fork Jetty + modify approach to work.
I'm just playing and testing a bit with the Restlet Client Api 2.2, but I don't get a non-blocking asynchronous request with a callback to work. I already have googled extensively
but really not found an answer to a (working) non-blocking solution.
I have the following two approaches:
Approach 1 ( Client - Request ):
Client c = new Client(Protocol.HTTP);
Request r = new Request(Method.GET, url);
System.out.println("START1");
c.handle(r, new Uniform() {
#Override
public void handle(Request request, Response response) {
int statusCode = response.getStatus().getCode();
System.out.println(statusCode);
}
});
System.out.println("START2");
Approach 2 ( ClientResource - setOnResponse() - get() ):
ClientResource cr = new ClientResource(url);
cr.setOnResponse(new Uniform() {
#Override
public void handle(Request request, Response response) {
int statusCode = response.getStatus().getCode();
System.out.println(statusCode);
}
});
System.out.println("START1");
cr.get();
System.out.println("START2");
The Console-Output for both approaches is always:
START1
Starting the internal HTTP client
SOME WAITING HERE
200
START2
Can anyone give me a hint to make one of these approaches non-blocking? Is that at all possible with the Restlet API? What am I missing, do I need another connector or must I define a seperate thread for the request myself?
I make a quick answer, an issue has been created: https://github.com/restlet/restlet-framework-java/issues/943
Initially the support of asynchronous was available using the internal nio connector.
As this connector is not fully stabilized, it has been decided to extract it from the core module and expose it inside a dedicated org.restlet.ext.nio module.
This explains why your code is blocking, as the current internal connector (in both 2.2 and 2.3 branches) does not support it.
At this time, the support is available using the nio extension, but this extension is not fully stabilized yet. So we are not inclined to encourage you to use it.
We are working on another scenario where we rely on the client connector provided by Jetty.
Stay tuned.
I'm using a Grizzly HttpServer which has two HttpHandler instances registered:
under /api/* there is an Jersey REST - style application offering the API of the product, and
under /* there is an StaticHttpHandler which serves static HTML / JavaScript content (which, among other things, talks to the API under /api/
For authentication I'm currently securing only the API using a Jersey ContainerRequestFilter implementing HTTP Basic Auth, which looks quite similar to what is presented in another SO question.
But as requirements changed, now I'd like to require authentication for all requests hitting the server. So I'd like to move the authentication one level up, from Jersey to Grizzly. Unfortunately, I'm completely lost figuring out where I can hook up a "request filter" (or whatever it is called) in Grizzly. Can someone point me to the relevant API to accomplish this?
The easiest solution would leverage the Grizzly embedded Servlet support.
This of course would mean you'd need to do a little work to migrate your current HttpHandler logic over to Servlets - but that really shouldn't be too difficult as the HttpHandler API is very similar.
I'll give some high level points on doing this.
HttpServer server = HttpServlet.createSimpleServer(<docroot>, <host>, <port>);
// use "" for <context path> if you want the context path to be /
WebappContext ctx = new WebappContext(<logical name>, <context path>);
// do some Jersey initialization here
// Register the Servlets that were converted from HttpHandlers
ServletRegistration s1 = ctx.addServlet(<servlet name>, <Servlet instance or class name>);
s1.addMapping(<url pattern for s1>);
// Repeat for other Servlets ...
// Now for the authentication Filter ...
FilterRegistration reg = ctx.addFilter(<filter name>, <filter instance or class name>);
// Apply this filter to all requests
reg.addMapping(null, "/*");
// do any other additional initialization work ...
// "Deploy" ctx to the server.
ctx.deploy(server);
// start the server and test ...
NOTE: The dynamic registration of Servlets and Filters is based off the Servlet 3.0 API, so if you want information on how to deal with Servlet listeners, init parameters, etc., I would recommend reviewing the Servlet 3.0 javadocs.
NOTE2: The Grizzly Servlet implementation is not 100% compatible with the Servlet specification. It doesn't support standard Servlet annotations, or deployment of traditional Servlet web application archive deployment.
Lastly, there are examples of using the embedded Servlet API here
The "hookup" part can be done using a HttpServerProbe (tested with Grizzly 2.3.5):
srv.getServerConfiguration().getMonitoringConfig().getWebServerConfig()
.addProbes(new HttpServerProbe.Adapter() {
#Override
public void onRequestReceiveEvent(HttpServerFilter filter,
Connection connection, Request request) {
...
}
#Override
public void onRequestCompleteEvent(HttpServerFilter filter,
Connection connection, Response response) {
}
});
For the "linking" to the ContainerRequestFilter you might want to have a look at my question:
UnsupportedOperationException getUserPrincipal
As an experiment in scala I want to set up a basic website with scala as a server side language. This would not carry out many interactive tasks - it would simply write and distribute HTML in response to HTTP requests.
I don't know much about how the piping of web servers works, but I've written lots of HTML, CSS, JS and PHP and I envisage this working much like the PHP back end in wordpress - the client sends an HTTP request for a page such as example.wordpress.com/2012/06/18/example_blog and the PHP on the server compiles an HTML web page and returns it to the user.
Although I'm open to suggestions, I'd rather not use a full blown framework such as Lift as I'm trying to build from the ground up. I'm only interested in the very basic task of taking an HTTP request as input and outputting an HTTP response.
Usually you'd take a Java EE server and implement a Servlet.
Here is one:
package myservlet
import javax.servlet.http._
class Servlet extends HttpServlet {
/** Servlet's main method. */
protected def welcome (request: HttpServletRequest, response: HttpServletResponse): Unit = {
response.getWriter.write ("hi")
}
override def doGet (request: HttpServletRequest, response: HttpServletResponse): Unit = welcome (request, response)
override def doPost (request: HttpServletRequest, response: HttpServletResponse): Unit = welcome (request, response)
}
Then you'd mention it in web.xml as usual:
<servlet><servlet-name>MyServlet</servlet-name>
<servlet-class>myservlet.Servlet</servlet-class></servlet>
<servlet-mapping><servlet-name>MyServlet</servlet-name>
<url-pattern>/</url-pattern></servlet-mapping>
Refer to any Java Servlet tutorial for details.
You may not want to deal with Java EE and the whole servlet thing, especially if you don't come from the "Java world".
There are some really lightweight HTTP toolkits in Scala like Blueeyes or Play mini but my favorite is definitely Unfiltered
EDIT: A more complete answer on this thread Scala framework for a Rest API Server?