Is it possible to let the server send messages to all connected clients without waiting for any action from them? Let me explain it :-) I've been reading the docs/examples and I have found nothing that satifies my needs: the flow is always the same; a client connects (e.g: a GET call to a Rest API), the connection is suspendend and until a new API call is received (e.g.: a POST call) the server simply waits (or at least this is what I have understood). My use case is pretty different: I want the server to send some "notifications" once new data become available. This would be my use case (pretty simplifed):
Client A connects to server
Connection is suspended since no new data is available at the moment
The server gets notified new data is available from an external
source and broadcasts it to client A
Go to step 2
What I have achieved so far is getting the connection successfully established. The next step is to solve this server issue. I must say this technology is completely new to me so it is possible I misunderstood how something works. If that's the case, let me know!
This is my stack:
Spring 3.2.0 RELEASE
Jersey 1.8
Atmosphere Jersey 1.0.13
Tomcat 7.0.40
Thank you all in advance!
UPDATE: After following this I get this warning, which I have no idea how to get rid of:
2013-06-04 09:40:36,284 WARN [org.atmosphere.cpr.AtmosphereFramework] - Failed using comet support: org.atmosphere.container.Tomcat7AsyncSupportWithWebSocket, error: Tomcat failed to detect this is a Comet application because context.xml is missing or the Http11NioProtocol Connector is not enabled.
If that's not the case, you can also remove META-INF/context.xml and WEB-INF/lib/atmosphere-compat-tomcat.jar Is the Nio or Apr Connector enabled?
2013-06-04 09:40:36,285 WARN [org.atmosphere.cpr.AtmosphereFramework] - Using org.atmosphere.container.Tomcat7BIOSupportWithWebSocket
I followed the app structure commented here, so this should not be a problem. I have noticed that by changing the transport to "websocket" instead of "long-polling" shows no errors. The server finally sends data tough :)
I followed your link and modified the code a little.
When you are in the step 3 "The server gets notified new data is available from an external source and broadcasts it to client A", you have to write a line like this:
BroadcasterFactory.getDefault().lookup("/*").broadcast(response);
At first I used the TextMessage received from my ActiveMQ Queue but I get this error, so I used a Jackson class as an object response and everything worked fine.
SEVERE: A message body writer for Java class org.apache.activemq.command.ActiveMQTextMessage, and Java type class org.apache.activemq.command.ActiveMQTextMessage, and MIME media type application/json was not found
jun 03, 2014 11:32:21 AM com.sun.jersey.spi.container.ContainerResponse write
SEVERE: The registered message body writers compatible with the MIME media type are:
application/json (JSONJAXBElementProvider, JSONArrayProvider, JSONObjectProvider, JSONRootElementProvider, JSONListElementProvider, ...)
Related
I am trying to authenticate user using FormLoginHandler and Postgresql Database with SqlAuthentication.
But I get the following error:
Jun 15, 2022 1:14:34 PM io.vertx.ext.web.RoutingContext
SEVERE: Unhandled exception in router
io.vertx.ext.web.handler.HttpException: Unauthorized
Caused by: io.vertx.core.impl.NoStackTraceThrowable: Invalid username/password
I am providing the right credentials.
The code snippet is:
SqlAuthenticationOptions sauthopts = new SqlAuthenticationOptions();
sauthopts.setAuthenticationQuery(AUTHENTICATE_QUERY);
SqlAuthentication authenticationProvider = SqlAuthentication.create(sqlClient, sauthopts);
router.route("/secure/*").handler(RedirectAuthHandler.create(authenticationProvider, "/login.html"));
FormLoginHandler formLoginHandler = FormLoginHandler.create(authenticationProvider);
router.route("/loginhandler").handler(formLoginHandler);
Please let me know if I am missing something here; or point me to a sample example.
Thanks in Advance.
Your setup doesn't show anything abnormal at first sight. For security reasons, we cannot "just" log the authentication data, as it would be a critical OWASP bug and security vulnerability.
My best guess is that probably is something not totally correct with the query, so this means you have now 2 options:
debug the application and see the query that is being sent + the arguments
prepare a small complete example that shows the bug and open an issue in vert.x so we can debug it further.
If you're upgrading from an older version, be aware that in vert.x 4.2.0 some changes were made to the base64 encoding to keep it consistent across modules. This could be a reason why authentication could fail as the encoded hashes may be slightly different. If you're just doing 4.3.0 from the start, then this would not be a problem.
I am writing an apache-camel RabbitMQ consumer. I would like to react somehow to connection problems (i.e. try to reconnect). Is it possible to configure apache-camel to automatically reconnect?
If not, how can I find out that a connection to the queue was interrupted? I've done the following test:
start the queue (and some producer)
start my consumer (it was getting messages as expected)
stop the queue (the messages stopped arriving, as expected, but no exception was thrown)
start the queue (no new messages were received)
I am using camel in Scala (via akka-camel), but a Java solution would be probably also OK
You can pass in the flag automaticRecoveryEnabled=true to the URI, Camel will reconnect if the connection is lost.
For automatic RabbitMQ resource recovery (Connections/Channels/Consumers/Queues/Exchanages/Bindings) when failures occur, check out Lyra (which I authored). Example usage:
Config config = new Config()
.withRecoveryPolicy(new RecoveryPolicy()
.withMaxAttempts(20)
.withInterval(Duration.seconds(1))
.withMaxDuration(Duration.minutes(5)));
ConnectionOptions options = new ConnectionOptions().withHost("localhost");
Connection connection = Connections.create(options, config);
The rest of the API is just the amqp-client API, except your resources are automatically recovered when failures occur.
I'm not sure about camel-rabbitmq specifically, but hopefully there's a way you can swap in your own resource creation via Lyra.
Current camel-rabbitmq just create a connection and the channel when the consumer or producer is started. So it don't have a chance to catch the connection exception :(.
I'm using RESTlet as Server and Client. Server is running over Tomcat and I can access it from browser.
For Client, I'm using org.restlet.resource.ClientResource. It works fine if I send a few requests to that server, but if I send a few hundred calls it breaks:
Fev 20, 2013 12:59:43 PM org.restlet.engine.connector.ClientConnectionHelper start
INFO: Starting the internal [HTTP/1.1] client
(some calls work)
Fev 20, 2013 1:00:49 PM org.restlet.util.SelectionRegistration block
WARNING: The thread blocked at the cyclic barrier has timed out
java.util.concurrent.TimeoutException
at java.util.concurrent.CyclicBarrier.dowait(CyclicBarrier.java:250)
at java.util.concurrent.CyclicBarrier.await(CyclicBarrier.java:427)
at org.restlet.util.SelectionRegistration.block(SelectionRegistration.java:191)
at org.restlet.engine.io.NbChannelInputStream.onFill(NbChannelInputStream.java:230)
at org.restlet.engine.io.Buffer.process(Buffer.java:601)
at org.restlet.engine.io.NbChannelInputStream.read(NbChannelInputStream.java:307)
at java.io.InputStream.read(InputStream.java:101)
at org.restlet.engine.io.BioUtils.copy(BioUtils.java:80)
at org.restlet.engine.io.NioUtils.copy(NioUtils.java:147)
at org.restlet.representation.ReadableRepresentation.write(ReadableRepresentation.java:104)
at org.restlet.representation.ChannelRepresentation.write(ChannelRepresentation.java:76)
at org.restlet.representation.ChannelRepresentation.write(ChannelRepresentation.java:82)
Exception in thread "main" java.io.IOException: The thread blocked at the cyclic barrier has timed out.
at org.restlet.util.SelectionRegistration.block(SelectionRegistration.java:197)
at org.restlet.engine.io.NbChannelInputStream.onFill(NbChannelInputStream.java:230)
at org.restlet.engine.io.Buffer.process(Buffer.java:601)
at org.restlet.engine.io.NbChannelInputStream.read(NbChannelInputStream.java:307)
at java.io.InputStream.read(InputStream.java:101)
at org.restlet.engine.io.BioUtils.copy(BioUtils.java:80)
at org.restlet.engine.io.NioUtils.copy(NioUtils.java:147)
at org.restlet.representation.ReadableRepresentation.write(ReadableRepresentation.java:104)
at org.restlet.representation.ChannelRepresentation.write(ChannelRepresentation.java:76)
at org.restlet.representation.ChannelRepresentation.write(ChannelRepresentation.java:82)
Caused by: java.util.concurrent.TimeoutException
at java.util.concurrent.CyclicBarrier.dowait(CyclicBarrier.java:250)
at java.util.concurrent.CyclicBarrier.await(CyclicBarrier.java:427)
at org.restlet.util.SelectionRegistration.block(SelectionRegistration.java:191)
... 11 more
I wanna use Apache HTTP Client to be able to do more calls, but I can't find documentation on how to attach it.
I had the same problem but on a live production machine which caused my server to eat up 100% of CPU. I was able to solve it by going back to using restlet 2.1.0 instead of 2.1.2. Not really an answer to the underlying problem, but definitely a solution.
Every evidence points this error to be internal in RESTlet client. Instead of using it, I used URL.getInputStream(), and with that I was able to easily do 10K sequential calls to my RESTlet server. Of course URL is way simple, it's unable to handle errors and shouldn't be used in production, but it proved RESTlet isn't worth it.
I also managed to make Benchmark comparing Axis2 and RESTlet as server, and they had same performance taking 3-5 milisecs to answer a request, I expected REST to be faster... I implemented REST server directly from Servlet and it too 0-1 milisecs to respond. Because of that I decided to drop REST and stick with SOAP Axis2, it's not slower than RESTlet and just a few milisecs slower than Servlet, but it way more flexible and powerful.
From time to time I get the following warning in the logfile of my Wicket application:
04.10.2012 14:52:08,525 WARN [org.apache.wicket.core.request.mapper.AbstractBookmarkableMapper]
Unknown listener interface 'd allow_url_include=On '
What does that mean and how do I fix it? I tried Google, but I could only find results for the PHP configuration allow_url_include.
I'm using Wicket 6.0.0
Most likely an automated tool tries to exploit some PHP application. Wicket can't handle this request and prints the warning. Look in the access log what HTTP requests hit your server at this timestamp to see which request caused this warning.
It's safe to ignore this warning in this case.
I'm working on an EJB3 MDB that listen to a MQ queue in a distant server.
All is working fine (MDB triggered when a message is put into the listenned queue) except the treatment done by the MDB. For information, i use WMQ resource adapter to map the queue.
Into the method 'onMessage' of the MDB, i try to cast the given message into the class 'com.ibm.jms.JMSBytesMessage', but i get a strange error message.
The code is the following one (simple for the example):
public void onMessage(Message theMessage) {
((JMSBytesMessage) theMessage).readBytes(myBytes);
}
And the exception message:
Exception while reading input request: com.ibm.jms.JMSBytesMessage incompatible with com.ibm.jms.JMSBytesMessage
Ok, the message received should be (and is) type 'com.ibm.jms.JMSBytesMessage', so why the application doesn't work ? Should it be possible that my JBoss server already use another version of the library 'com.ibm.mqjms.jar' (including the JMSBytesMessage class) and cause this kind of error ?
ps: i've deployed the application on a JBoss server version 4.2.3 under linux system.
I've already make the application work on my local machine with same version of JBoss server but under window system (same configuration, same libraries, etc.)
Does someone have an idea about the reason of such error ?
Thanks in advance for any help.
Regards,
EDIT: SOLUTION: cast with javax.jms.BytesMessage instead of com.ibm.jms.JMSBytesMessage
Might as well reproduce my comment as answer:
Don't cast to the MQ-specific com.ibm.jms.JMSBytesMessage, cast to the JMS-standard javax.jms.BytesMessage. Coupling your code to the implementation-specific types is counter to what JMS tries to achieve.