I need to implement a TCP server with a web interface included for management.
Basically, the tcp server will be listening to new connections and keeping current ones active while the web interface allow me to see information regarding these connections and to interact with them (e.g. send messages and seeing received ones)...
My concerns resides in the "TCP Server" integration with the web application.
For received messages I could simple use a shared DB, but I need to send messages to the peers connected into the TCP server.
My best bet is currently on JCA. Some research pointed me to a nice sample: http://code.google.com/p/jca-sockets.
The sample uses an Message Driven Bean to deal with messages received over port 9000, acting as an echo server.
I am new in the Java EE 6 world. I trying to figure out why things were done in one way or another in the sample (e.g. why MDB?).
JCA has a fairly complicated spec. So I am trying at first to adapt the sample above to keep the connections active to exchange data. My next step will be adapt it to accept a string over a servlet to forward it to a given peer.
Can someone help me out on this?
Well, first of all, using Java EE with TCP is not the best approach you may use. If you just need a simple TCP service with Web UI you'd better consider using Java SE with some web container attached (undertow works well).
In other hand, if you need your application to integrate into existing Java EE infrastructure your company has, JCA would be the best approach. While it's not designed for such kind of things, JCA is the only EE subsystem liberal enough for that kind of thread management you would need for TCP networking to work.
JCA-Socket you're referring above is not the best example of a JCA app. It uses plain Java's blocking sockets by blocking WorkManager thread, this is not very effective. Things got much better now and we have Java NIO and Netty for highly effective raw networking to work upon. I have a JCA connector for TCP interactions which may provide you a skeleton to build your own. Feel free to extend and contribute.
P.S. About MDB: message-driven bean is the only "legal" JCA approach of asynchronous incoming messages handling. Since TCP is asynchronous, you'll definitely need one in your application for all the things to start working. Outcoming data transfers happen through various ConnectionFactory interfaces you'll inject into your bean. The link above will provide you with a reference ConnectionFactory implementation as well as a simple tester app utilizing both ConnectionFactory and MDB messaging approaches.
Related
I have read up on web sockets providing full duplex connections over TCP which can be used in scenarios where long polling was used to get live updates to client from server. Now I have a Tomcat based application which serves multiple REST based web service response, and I want couple of API's to be implemented using web sockets say to render dashboard with latest data where multiple users are working on them concurrently, is that possible ? My concern here was even if the connection was upgraded to TCP from HTTP wouldn't web socket require a separate port to run than the default Tomcat port 8080. In that case should I house the Web Socket based endpoints separate to the Tomcat based application already running. Please do correct me if any of the above is wrong.
A couple of month ago, I wrote a small Spring Boot webapp with embedded Tomcat that provides both, REST endpoints and websocket support, and both via the same port. So, yes that works... if you wanna sneak a peek: https://github.com/tommybrettschneider/pinterest-boot
Besides that, this post should also clarify things:
Shall I use WebSocket on ports other than 80?
We have an enterprise solution deployed on Wildfly 8.0.0 server, we intend to support CoAP and MQTT also as communication protocol. We explored extensively but we couldn't find even any oblique reference to our problem case. Is it possible to add CoAP and MQTT support without destabilizing Wildfly setup ??
I think theoretically it is possible to use a https://www.eclipse.org/californium/ within an EE server for CoAP.
The main issue here is that Californium listens to an UDP port (and sends datagrams too).
So if you want to stay within a EE specification, you'll have to implement a JCA adapter for that.
If you want things to just work, you can run/manage it from a JMX bean.
WildFly being a Web Server doesn't necessarily need to support CoAP or MQTT because those are not standard HTTP based Communication protocols but protocols designed to enable M2M (Machine to Machine) Communication.
As of WildFly 8.0.0.Final it only allows HTTP (Servlet, JAX-RS, JAX-WS), Web Sockets, HTTP Upgraded Remoting (EJB Invocation, Remote JNDI).
All
I am making REST client calls from an EJB container (IBM Websphere v6.1) and cannot find any way to get a HTTP connection factory from WAS.
Is this possible in WAS 6.1?
Would expect be able to access this with JNDI so connection pool configuration, socket timeout, connection timeout, connections per URL etc could be centrally managed.
If not the alternative is to use a Client API such as HttpClient 4.3. But this has its own kettle of fish:
They recommend 'BasicHttpClientConnectionManager': "This connection manager implementation should be used inside an EJB container". However this implies one connection per thread which in an application with many threads will exhaust the resources of the O/S.
The other alternative 'PoolingHttpClientConnectionManager' seems to be a much better fit with much of the required controls, but in the the comments on the the Basic manager it says explicitly that the Pooling manager shouldn't be used in a EJB container managed context. Scanning the code for this it looks like the Pooling manager uses Future from the concurrent library but doesn't appear to directly use Threads.
Any suggestions about the best way forward would be appreciated - some options seem to be:
Test with PoolingHttpClientConnectionManager - with risk of subtle problems
Play safe with 'BasicHttpClientConnectionManager' but set short response and socket timeouts to constrain the number of concurrent sockets at the cost of lots of factory overhead. Yuk.
Some other way of getting access to the pool of HTTP connections in WAS 6.1.
Something else
Any suggestions for this rather ikky problem would be ideal.
Please don't suggest upgrading WAS - although future versions ie the WAS commerce version do seem to have a JCA HTTP Adaptor and 8.5 has a built in REST client.
Please don't publish responses relating to MQ/JMS, JDBC connection pooling or setting up resource adaptors for EIS other than HTTP.
I have to implement software that listens for UDP packets and persists their contents to a database.
It would be handy if this could run in JBoss, as this is the infrastructure we are using now.
I have seen that Netty is ideally suited to program the listener part.
Is there a way to use Netty "embedded" in JBoss? I have searched up and down the Net and the examples I have found are all for standalone listener programs.
Of course, but you have to clarify what you mean by ""embedded" in JBoss". If you are writing a standard EJB application, just put Netty bootstrap code in #PostConstruct of singleton session bean and destroy it in #PreDestroy.
If it's a web application, use any servlet's init() method (servlet must be created eagerly on startup).
Note that EJB spec does not allow creating custom threads and listening on arbitrary ports - Netty violates both of these requirements. But JBoss won't enforce this.
Sounds like JCA might be the appropriate path.
What is the best way to make a standalone java server built using J2SE Socket API high available? Using an HTTP server would have been a good choice specially for the built-in features e.g. security, clustering, transactions, etc. but the server should be capable of accepting TCP/IP socket connection from java & non-java clients (mainly legacy). Tomcat does not accept non-http TCP/IP requests? Moreover this post points out servlet for implementing socket connection it's not a good practice. What would be good approach?
After exploring online, this is what I have compe up with. A standalone java application can be made high available by using a combination of the following:
2 VM deployed with HAproxy and keepalived to form the highly available load balancing layer.
Keepalived will keep the load balancers in active-passive mode and the HAproxy will forward the requests to a cluster of backend socket based java server apps
At least 2 VM deployed with the custom socket based java server apps. The HAproxy servers will distribute the requests over these 2 VMs
Use at least 2 terracotta server to share the java server apps. Terracotta will provide the sharing of the memory and help the custom java servers to scale.
Use MySQL NDB Cluster for the database.
Any suggestions?