I've seen that Jetty now supports HTTP/2. Spent some time researching and can't see a way of implementing this in Apache Camel-Jetty. Any idea whether this is something that Camel will need to implement? Or is it configurable using their RestConfigurationDefinition?
Thanks in advance.
I'm afraid you need to do some extra work to enable the HTTP/2 feature. Camel-Jetty Components has two parts, one is Consumer (Jetty Server) and the other is Producer (Jetty Client). If you want to enable the HTTP/2 feature, you need to make sure the Http module is loaded by modifying some code. I don't think you can do it by doing some configuration with the RestConfigurationDefinition.
Please send a feature request by creating a JIRA for it.
I've got client server application, with JBossAS7 and client which uses remote EJB provided by the server. I have to pass file from client to server, where it will be further processed via InputStream. Also have to pass file from server to client, where on server i get OutputStream. File size is not limited, it might be even 5GB. What can I do to implement solution to this case? Passing byte[] array seems not to be a good solution, RMI limits size what I've read. RMIIO is GPL (i need solution free for commercial use). Is http transfer the only reasonable way to do this?
edit: it seems that RMIIO was always LGPL!
You might consider setting up a Netty Server running on JBoss AS as showed in this Netty Tutorial and pass data using bare sockets.
Another option is HTTP by means of a simple HTTP Transfer using a Servlet for example.
I'd exclude EJB since they are transactional component, and admitted you managed to pass this data through RMI-IIOP, you still have to set up a huge Transactional timeout.
Hope it helps.
RMIIO is LGPL (different from just GPL), which is free for commercial use and is not viral (assuming you have not modified the rmiio library).
I have some C simulations running on my university servers and I am bored of having to sit and wait for them to end, considering they take quite a while. So I want to develop some kind of mechanism to know when they have ended. I was thinking of implementing an SMTP client with gmail, but considering I can't install anything on the system I wasn't able to add the SSL libraries to do so. I also can't remote access my desktop from outside campus. So once I leave I can't VNC y desktop.
So I was thinking if there is some way where I can rent some online space for free and be able to talk with the server through ftp or http and set add some text that the simulation has ended. That way I can check the space from home and know it ended.
I know the question is quite messy, and hope someone can help point me out to someideas.
Thanks
I'd recommend, 100webspace.com, it allows PHP and MySQL, all for free! Then just send data to it with HTTP PUT and/or GET and view the results over the interweb.
My trawling of the web consistently turns up libcurl as the library of choice for interfacing C with HTTP commands. This is a sample using it with the PUT method.
A possibility would be using a simple blog and updating it via HTTP. Just as an example, blogger supports simple messages in XML. (REST would be my first choice but XML is not that bad)
Edit:
Tumblr does support using an HTTP POST without XML.
I'd like to build a multiplayer web game application in which it supports chat. I presume the application will have to handle hundreds of simultaneous connections.
I'm planning to host my application in a shared web hosting, which has these limitations (most likely similar to PHP + Comet (long-polling) scaling / hosts):
It does not seem I can change the web server. Most likely it's using Apache.
Supports MySQL 5, PHP 5.3.x, Perl, Python, Ruby on Rails, CGI
(To be more precise, I'll be using HawkHost's shared web hosting.)
And here are my result of research, followed by my questions:
Some resources (like Python Comet Server) say that PHP is not good for handling concurrent connections, while Python is better choice. Is this true?
I've tried the long polling technique in PHP (although I don't know whether it's correctly implemented or not, like Comet issue with abandoned open connections) using "Loop endlessly until the data changes." method. This almost works. The remaining problem is that the server process never dies when the browser is closed (the server does not know that the connection has been terminated, and the data never changes). Is there any way the PHP can detect whether the browser has been terminated so that it stops the loop?
I've been looking everywhere to look for answers but still I can't conclude anything. This topic has also been asked on StackOverflow so many times, I'm sorry if I may sound repeating >.<.
Currently I am able to code using PHP, MySQL, and JQuery for JS. I'm still new to the term Comet and Server Push. If necessary, I'm also willing to learn new scripting language like Python.
I appreciate any insights of what scripting language, framework, and techniques to use to start my project.
When you have a shared hosting environment and there are a number of restrictions enforced then it's a good idea to outsource the realtime functionality. I would say this since I work for one such company, Pusher. But I hope others will back me up on this.
When using a hosted solution you can push a notification by making a HTTP request to a RESTful API. The service will then deliver the message to the connected Web Client (browser). The browser does need to include a script tag or use a library that also connects to the hosted service.
The main benefits are:
No installation or maintenance
No need to handle persistent connections - no resource usage
Really simple usage: Script tag in app and call REST API
The hosted solution handles scaling
Also, here's a list of hosted realtime solutions.
So you can use Python. Then you can use Tornado. (psst... facebook uses it)
And I had same problem with open connections. Just don't spend time for search solution in PHP - later you will be sorry. I was. Just use what is made for Comet. If you more prefere JAVA, then there is: CometD.
And for game get a normal hosting. They cheap this days.
I am creating a Silverlight 2 user interface to a remote instrument. There are two concurrent users at different sites interacting with the instrument (operator at the instrument and remote scientist) and any number of observer users not interacting with it, just watching. However, whenever one of the two active users changes something these changes must be immediately reflected in the UIs of all users, e.g. panning or zooming an image or annotating or selecting part of an image, adding items to a collection displayed in a listbox. Within the client I use observable collections which easily reflect changes made by that user, but it is harder seeing changes made by another user. I can poll for changes from each client but something like push notifications would be better. I have extensively Googled for examples but not found anything which is quite what I need. There are all sorts of security issues with Silverlight interacting with WCF services which mean many potential examples just don't work. I have essentially run out of time on this project and need help fast. Does anyone have any suggestion of a suitable simple example which illustrates how to do this? I am an experienced developer but have had to teach myself Silverlight and WCF services and there is noone in my area who knows anything about these. Even tho' I have done a fair amount of ASP.NET work I am not a web/Javascript guru. Thanks.
Push notification is supported in Silverlight 2 using the new WCF PollingDuplexHttpBinding support. There are two assemblies installed with the Silverlight SDK (one for Silverlight app one for WCF server).
I have a few blog posts and a full sample application that demonstrate how to 'push' Stock updates from a Console Application server that self-hosts a WCF service to connected clients. It also shows how each client can add notes against a Stock and have those notes synchronized (pushed from server) to all other connected clients.
The latest version of the sample (Part 4) shows how to synchronize pushed updates between both Silverlight and WPF clients using two server endpoints as follows:
using System;
using System.ServiceModel;
using System.ServiceModel.Description;
namespace StockServer
{
public class StockServiceHost : ServiceHost
{
public StockServiceHost(object singletonInstance, params Uri[] baseAddresses)
: base(singletonInstance, baseAddresses)
{
}
public StockServiceHost(Type serviceType, params Uri[] baseAddresses)
: base(serviceType, baseAddresses)
{
}
protected override void InitializeRuntime()
{
this.AddServiceEndpoint(
typeof(IPolicyProvider),
new WebHttpBinding(),
new Uri("http://localhost:10201/")).Behaviors.Add(new WebHttpBehavior());
this.AddServiceEndpoint(
typeof(IStockService),
new PollingDuplexHttpBinding(),
new Uri("http://localhost:10201/SilverlightStockService"));
this.AddServiceEndpoint(
typeof(IStockService),
new WSDualHttpBinding(WSDualHttpSecurityMode.None),
new Uri("http://localhost:10201/WpfStockService"));
base.InitializeRuntime();
}
}
}
WPF clients connect to the WSDualHttpBinding endpoint and Silverlight clients connect to the PollingDuplexHttpBinding endpoint of the same WCF service. The app also shows how to handle the Silverlight client access policy requirements.
Clients (Silverlight or WPF) can add notes against a Stock in their UI and these notes propagate back to the server to be pushed to all other clients. This demonstrates communication in either direction and hopefully performs all of the necessary communication required for your app.
You can see a screenshot of the demo application running here.
Not that am pushing Flex in fan boy fashion, but matter of factly this is the kind of architecture we build into all our Flex-based applications routinely. Here is what we do on Flex - no doubt it could be suitably translated to Silverlight:
We take three ingredients and integrate them together to accomplish this capability:
Comet pattern (an HTTP compatible way to do server push notifications - look on Wikipedia for more info)
JMS messaging topics (publish/subscriber queues)
The Adobe BlazeDS servlet
The latter item implements the Comet pattern, supports AMF object marshaling (Adobe's binary serialization format for ActionScript3 objects), and bridges to a JMS queue or topic. When bridging to a topic, then multiple Flex clients running in a browser can be proxied in as subscribers to a JMS topic. So if any client publishes a message (or the server-side code publishes into the topic), all client subscribers will have the message pushed to them via BlazeDS and the Comet Pattern implementation.
Effectively you need to locate or write a component that accomplishes what BlazeDS does. You might also need to implement some client code that interacts with the Comet pattern of this server-side component.
Does WCF support the Comet Pattern and bi-directional messaging? Especially where complies to HTTP and port 80 or port 443 for SSL. Looks like you've already looked into that and not found anything for bi-directional messaging. So you may need to roll your sleeves up and do some coding.
Some things to note about doing server push to a web app:
BlazeDS supports two primary modes of implementing the Comet pattern (there's actually a 3rd polling option but am ignoring it):
long-polling
HTTP streaming
The long-polling one you should find to be more universally supportable to most web browsers. So you might streamline to just supporting that initially. Or you could spend the time to make your client code try HTTP streaming first and switch to long-polling if necessary.
As to a message broker that can provide publish/suscribe capatibility, you might consider using ActiveMQ JMS. It is open source and free with active community support (you can buy support too). Plus you can use NMS to integrate as a .NET client.
Having a message broker sitting in the middle-tier is actually important because it will be a place for messages to be placed safely. If your clients are doing long-polling, you wouldn't want them to miss any new message during an interval when they're not actually connected.
Another thing to consider in high traffic volume scenarios (hundreds or thousands of clients, such as a web site on the Internet), you need to have an approach to the Comet Pattern that is scalable.
In the Flex/Java world, the BlazeDS servlet (which is open source) has been modified to work with asynchronous model. In Java a socket listener can be built to use NIO channels and Java Concurrency Executor thread pools. The Tomcat web server has a NIO listener and support for asynchronous Servlet 3.0 events. BlazeDS in particular has been modified, though, to work with the Jetty web server. The bottom line is that the scalability of this asynchronous approach means a single physical web server can be enhanced to support up to around 20,000 concurrent Comet-style client connections.
It's been a while since I've done serious .NET programming but used to the io capabilities were much like Java 1.1 except with an asynchronous result handler capability. This, though, is not the same thing as creating asynchronous socket listeners via Java NIO channels. A NIO channel implementation can support hundreds to thousands of socket connections with a relatively small thread pool. But C# and .NET has gone through two or three significant revs - perhaps there have been new io capabilities added that are comparable to NIO channels.
I just wanted to clarify that the PollingDuplexHttpBinding doesn't implement 'true' push notifications, as reveals its name (polling). From the msdn documentation:
When configured with this binding, the Silverlight client periodically polls the service on the network layer, and checks for any new messages that the service wants to send on the callback channel. The service queues all messages sent on the client callback channel and delivers them to the client when the client polls the service.
However it is more efficient than the traditional way of polling a web service, since after each poll, the server will keep the channel open for a certain time (say 1 minute), and if a message arrives in that time it will directly 'push' the message to the client. The client has to repeatedly renew its connection, it so to say polls the service.
If you want to implement real push notifications with silverlight I believe you need to work with sockets, and I recommend reading some of Dan Wahlin's blog posts on the subject.
Alternatively,
if you want a native silverlight API with no proxies, bridges or webservers involved you could use Nirvana from my-Channels as your messaging middleware. Check out Nirvana from my-Channels and their showcase site. (sorry i am a new user and cant submit links):
Alex
EDIT: it's actually working fine. I got badly bitten by the "hidden variable" in a closure :(
I used the PollingDuplex for SL2 and I think that it's not ready for production yet.
My main issue is the fact that it doesn't discriminate on the clients on the same machine. If I run 2 clients then one of them won't be able to poll the server anymore and will die of timeout. There is a SessionId that is different for the 2 clients but it's just ignored on the client side.
Likewise, if I kill a client and then create a new one afterwards then the new client will get the push updates from the previous client for a while.
Did anyone encounter the same issues or are they fixed in SL3?
Actually I ran some more demo codes and realised that for some reason you have to specify the InstanceContextMode and InstanceMode so that the service is session based and not a singleton (as far as I can tell). There are clear performance issues in the simple demo code that I pulled.
It is quite unfortunate that this behaviour wasn't documented.
My organization found the Silverlight 2.0/WCF push implementation to be a little "not ready for prime time", at least for what we were planning to use it for.
We ended up going with XMPP/Jabber, because it is a more well formed beast, and you can implement it fairly easily in Silverlight, by just getting some resources off the internet.
I do believe that Silverlight 3.0 will implement a newer/more well formed push implementation, from what I can tell from publicly available information.
The PollingDuplexHttpBinding is probably the most elegant way to do it.
One possilby less involved alternative is to use a TCP socket from your Silverlight client. Whenever one of the Silverlight clients needs to have an update pushed you can send it a TCP message which contains the name of the WCF service it needs to call or some other light weight piece of information.
I use this approach for an application and it works well.
One much simpler and more powerful solution at the site http://www.udaparts.com/document/Tutorial/slpush.htm