Our apache tomcat server is printing random nullpointer exceptions. Normally you would see a stacktrace..
INFO | jvm 1 | srvmain | 2012/03/30 13:44:43.733 | SEVERE: Servlet.service() for servlet frontend threw exception
INFO | jvm 1 | srvmain | 2012/03/30 13:44:43.733 | java.lang.NullPointerException
INFO | jvm 1 | srvmain | 2012/03/30 13:44:46.139 | Mar 30, 2012 1:44:46 PM org.apache.catalina.core.StandardWrapperValve invoke
INFO | jvm 1 | srvmain | 2012/03/30 13:44:46.139 | SEVERE: Servlet.service() for servlet frontend threw exception
INFO | jvm 1 | srvmain | 2012/03/30 13:44:46.139 | java.lang.NullPointerException
INFO | jvm 1 | srvmain | 2012/03/30 13:44:47.998 | Mar 30, 2012 1:44:47 PM org.apache.catalina.core.StandardWrapperValve invoke
INFO | jvm 1 | srvmain | 2012/03/30 13:44:47.998 | SEVERE: Servlet.service() for servlet frontend threw exception
INFO | jvm 1 | srvmain | 2012/03/30 13:44:47.998 | java.lang.NullPointerException
INFO | jvm 1 | srvmain | 2012/03/30 13:44:50.623 | Mar 30, 2012 1:44:50 PM org.apache.catalina.core.StandardWrapperValve invoke
You are going to have to restart the server if you want complete stack traces. You need to set the following JVM option:
XX:-OmitStackTraceInFastThrow
Related
I have the following code which handles some websocket messages:
Flux.create(sink -> {
handler//.log("handler")
.doOnNext(s -> log.info("propagating: {}", s))
.doOnNext(sink::next)
.doOnError(sink::error)
.onErrorComplete() // this allows you to silence the error and let the upstream subscriber handle it.
.publishOn(Schedulers.boundedElastic())
.subscribeOn(Schedulers.boundedElastic(), false)
.subscribe();
})
.take(10)
.onErrorResume(e -> Exceptions.unwrap(e)
.getClass()
.isAssignableFrom(Errors.NativeIoException.class),
t -> {
log.error("Websocket connection error: {}", t.getMessage());
log.debug("{}", t.fillInStackTrace().toString());
// the error is handled and hidden by retryWhen.
return Mono.error(t);
})
.retryWhen(RetryBackoffSpec.backoff(10000, Duration.ofSeconds(3))
.maxBackoff(Duration.ofSeconds(3))
.transientErrors(true)
.doBeforeRetry((s) -> log.error("Retrying connection to {}", "abc"))
.doAfterRetry(s -> log.error("Attempt {}/{} to restore connection to {} failed with {}", s.totalRetriesInARow(), 10000, "abc", s.failure().getMessage()))
);
Every now and then the connection drops and that's why there's a retryWhen operator in the pipe. As you can see above, I am printing messages to the console which inform about the connection drop and how many times it retries.
I, however, am not able to figure out how to print a "recover" message (i.e. Connection to X restored). Am I missing something from the docs or am I expected to write a custom RetryBackoffSpec that does it?
Example log output:
03:11:34.205 10-02-2023 | INFO | boundedElastic-6 | org.example.chaos.simulation.NetworkDisruptionTest | propagating: {"timestamp":1675991494202,"hello":"world!"}
03:11:34.703 10-02-2023 | INFO | boundedElastic-6 | org.example.chaos.simulation.NetworkDisruptionTest | propagating: {"timestamp":1675991494702,"hello":"world!"}
03:11:35.205 10-02-2023 | INFO | boundedElastic-6 | org.example.chaos.simulation.NetworkDisruptionTest | propagating: {"timestamp":1675991495203,"hello":"world!"}
03:11:35.704 10-02-2023 | INFO | boundedElastic-6 | org.example.chaos.simulation.NetworkDisruptionTest | propagating: {"timestamp":1675991495703,"hello":"world!"}
03:11:46.746 10-02-2023 | ERROR | boundedElastic-6 | org.example.chaos.simulation.NetworkDisruptionTest | Websocket connection error: recvAddress(..) failed: Connection timed out
03:11:46.749 10-02-2023 | ERROR | boundedElastic-6 | org.example.chaos.simulation.NetworkDisruptionTest | Retrying connection to abc
03:11:49.752 10-02-2023 | ERROR | parallel-3 | org.example.chaos.simulation.NetworkDisruptionTest | Attempt 0/10000 to restore connection to abc failed with recvAddress(..) failed: Connection timed out
03:11:52.763 10-02-2023 | ERROR | boundedElastic-5 | org.example.chaos.simulation.NetworkDisruptionTest | Retrying connection to abc
03:11:55.764 10-02-2023 | ERROR | parallel-4 | org.example.chaos.simulation.NetworkDisruptionTest | Attempt 1/10000 to restore connection to abc failed with connection timed out: /172.25.0.2:8090
03:11:58.772 10-02-2023 | ERROR | boundedElastic-3 | org.example.chaos.simulation.NetworkDisruptionTest | Retrying connection to abc
03:12:01.773 10-02-2023 | ERROR | parallel-5 | org.example.chaos.simulation.NetworkDisruptionTest | Attempt 2/10000 to restore connection to abc failed with connection timed out: /172.25.0.2:8090
--- A message such as "Connection to abc has been restored." is expected to appear here.
Why does the following error occur when I start a remote agent ?
Agent doesn't start and it keeps displaying this error
INFO | jvm 21 | 2015/10/20 12:12:27 | [Fatal Error] :-1:-1: Premature end of file.
INFO | jvm 21 | 2015/10/20 12:12:27 | Exiting due to fatal exception.
INFO | jvm 21 | 2015/10/20 12:12:27 | java.lang.reflect.InvocationTargetException
INFO | jvm 21 | 2015/10/20 12:12:27 | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
INFO | jvm 21 | 2015/10/20 12:12:27 | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
INFO | jvm 21 | 2015/10/20 12:12:27 | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
INFO | jvm 21 | 2015/10/20 12:12:27 | at java.lang.reflect.Method.invoke(Method.java:606)
INFO | jvm 21 | 2015/10/20 12:12:27 | at com.atlassian.bamboo.agent.bootstrap.AgentRunner.run(AgentRunner.java:28)
INFO | jvm 21 | 2015/10/20 12:12:27 | at java.lang.Thread.run(Thread.java:745)
INFO | jvm 21 | 2015/10/20 12:12:27 | Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'agentConfiguration' defined in class path resource [applicationContextRemoteAgent.xml]: Invocation of init method failed; nested exception is com.atlassian.bamboo.configuration.ConfigurationException: Could not load configuration file bamboo-agent.cfg.xml from /home/bamboo_path/bamboo-agent-home
INFO | jvm 21 | 2015/10/20 12:12:27 | at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1553)
INFO | jvm 21 | 2015/10/20 12:12:27 | at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:539)
INFO | jvm 21 | 2015/10/20 12:12:27 | at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:475)
INFO | jvm 21 | 2015/10/20 12:12:27 | at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:302)
INFO | jvm 21 | 2015/10/20 12:12:27 | at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:228)
...
INFO | jvm 21 | 2015/10/20 12:12:27 | at com.atlassian.bamboo.v2.build.agent.remote.RemoteAgent.start(RemoteAgent.java:68)
INFO | jvm 21 | 2015/10/20 12:12:27 | ... 6 more
INFO | jvm 21 | 2015/10/20 12:12:27 | Caused by: com.atlassian.bamboo.configuration.ConfigurationException: Could not load configuration file bamboo-agent.cfg.xml from /home/bamboo_path/bamboo-agent-home
INFO | jvm 21 | 2015/10/20 12:12:27 | at com.atlassian.bamboo.v2.build.agent.remote.AgentConfiguration.initConfiguration(AgentConfiguration.java:101)
INFO | jvm 21 | 2015/10/20 12:12:27 | at com.atlassian.bamboo.v2.build.agent.remote.AgentConfiguration.init(AgentConfiguration.java:62)
INFO | jvm 21 | 2015/10/20 12:12:27 | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
...
INFO | jvm 21 | 2015/10/20 12:12:27 | ... 19 more
INFO | jvm 21 | 2015/10/20 12:12:27 | Caused by: org.apache.commons.configuration.ConfigurationException: Premature end of file.
INFO | jvm 21 | 2015/10/20 12:12:27 | at org.apache.commons.configuration.XMLConfiguration.load(XMLConfiguration.java:673)
I'm using Bamboo Server instance, 5.8.1
Agent is running on JDK 1.7
As you can see from:
INFO | jvm 21 | 2015/10/20 12:12:27 | Caused by: com.atlassian.bamboo.configuration.ConfigurationException: Could not load configuration file bamboo-agent.cfg.xml from /home/bamboo_path/bamboo-agent-home
INFO | jvm 21 | 2015/10/20 12:12:27 | at com.atlassian.bamboo.v2.build.agent.remote.AgentConfiguration.initConfiguration(AgentConfiguration.java:101)
File bamboo-agent.cfg.xml cannot be loaded. In this scenario I've discovered that the file was corrupted, making the agent hang on startup.
This file should be in the following format:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<configuration>
<buildWorkingDirectory>/home/bamboo_path/bamboo-agent-home/xml-data/build-dir</buildWorkingDirectory>
<agentUuid>aaaaaaaa-bbbb-aaaa-aaaa-aaaaaaaaaaaa</agentUuid>
<agentDefinition>
<id>14221333</id>
<name>Java Compiler</name>
</agentDefinition>
</configuration>
What I've discovered is that when I delete the corrupted file, and start the agent again, It will start. However it will register as a new agent. Making all agent dedication or custom capability settings missing.
You can find the old agent's definition in bamboo administration panel
https_//bamboo.myurl.com/admin/agent/viewAgent.action?agentId=1234567
Copy paste the name and agent ID to bamboo-agent.cfg.xml and start the agent.
I am encountering the error when trying out my app. It works fine on my local instance as well as on a stand-alone Mule Server, but not on CloudHub. Any reason why this problem occurs?
Update
The app doesn't have any issues running from Studio on my local machine. The problem only occurred after I deployed it to CloudHub. I am not able to access the app from CloudHub and encounter a 405 Not Allowed (nginx) error page.
CloudHub logs shows the app has started successfully as far as I understand it. See the CloudHub deployment logs below:
19:29:02.272 | 07/10/2015 | SYSTEM | Deploying application to 1 workers.
19:29:05.450 | 07/10/2015 | SYSTEM | Provisioning CloudHub worker...
19:29:07.277 | 07/10/2015 | SYSTEM | Deploying application to 1 workers.
19:29:08.325 | 07/10/2015 | SYSTEM | Provisioning CloudHub worker...
19:29:25.696 | 07/10/2015 | SYSTEM | Starting CloudHub worker at 52.74.74.41 ...
19:29:32.862 | 07/10/2015 | SYSTEM | Starting CloudHub worker at 54.169.12.90 ...
19:30:49.027 | 07/10/2015 | SYSTEM | Worker(54.169.12.90): Starting your application...
19:30:50.715 | 07/10/2015 | INFO |
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Initializing app 'myapp' +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
19:30:50.958 | 07/10/2015 | INFO | Monitoring enabled: true
19:30:50.958 | 07/10/2015 | INFO | Registering ping flow injector...
19:30:50.975 | 07/10/2015 | INFO | Creating the PersistentQueueManager. Asynchronous VM queues will be persistent.
19:30:50.984 | 07/10/2015 | INFO | About to create the PersistentQueueManager with environment: scope: 55824160e4b0f5ecab93e207_559f73dfe4b02b744ec0f626 bucket: ch-persistent-queues-us-east-prod accessKey: AKIAIYBZZZI7M2PAT4WQ region: ap-southeast-1 privateKey: no
19:30:53.393 | 07/10/2015 | INFO | Apply ap-southeast-1 to the client com.amazonaws.services.sqs.AmazonSQSClient#5c6c69b6
19:30:53.393 | 07/10/2015 | INFO | New sqsClient is created com.amazonaws.services.sqs.AmazonSQSClient#5c6c69b6
19:30:53.412 | 07/10/2015 | INFO | Apply ap-southeast-1 to the client com.amazonaws.services.s3.AmazonS3Client#4a1e0237
19:30:53.469 | 07/10/2015 | INFO | New s3Client is created com.mulesoft.ch.queue.sqs.clients.S3Client#20d271f6
19:30:53.470 | 07/10/2015 | INFO | Done with SQSQueueManagementService() instance
19:30:53.505 | 07/10/2015 | INFO | Initialising RegistryBroker
19:30:53.760 | 07/10/2015 | INFO | Refreshing org.mule.config.spring.MuleArtifactContext#44b5763: startup date [Fri Jul 10 11:30:53 UTC 2015]; root of context hierarchy
19:30:57.438 | 07/10/2015 | WARN | Schema warning: Use of element <response-builder> is deprecated. HTTP transport is deprecated and will be removed in Mule 4.0. Use HTTP module instead..
19:30:57.630 | 07/10/2015 | WARN | Schema warning: Use of element <header> is deprecated. HTTP transport is deprecated and will be removed in Mule 4.0. Use HTTP module instead..
19:30:58.537 | 07/10/2015 | INFO | Using files for tx logs /opt/mule/mule-3.6.2-R43/./.mule/myapp/queue-tx-log/tx1.log and /opt/mule/mule-3.6.2-R43/./.mule/myapp/queue-tx-log/tx2.log
19:30:58.538 | 07/10/2015 | INFO | Using files for tx logs /opt/mule/mule-3.6.2-R43/./.mule/myapp/queue-xa-tx-log/tx1.log and /opt/mule/mule-3.6.2-R43/./.mule/myapp/queue-xa-tx-log/tx2.log
19:30:58.632 | 07/10/2015 | INFO | Initialising model: _muleSystemModel
19:30:59.749 | 07/10/2015 | INFO | Initialising flow: myappFlow
19:30:59.749 | 07/10/2015 | INFO | Initialising exception listener: org.mule.exception.DefaultMessagingExceptionStrategy#4fe27195
19:30:59.856 | 07/10/2015 | INFO | Initialising service: myappFlow.stage1
19:31:00.389 | 07/10/2015 | INFO | Registering the queue=55824160e4b0f5ecab93e207_559f73dfe4b02b744ec0f626_2D1531125C052F65252D3BF0500990 with display name=seda.queue(myappFlow.stage1)
19:31:00.402 | 07/10/2015 | INFO | Configured Mule using "org.mule.config.spring.SpringXmlConfigurationBuilder" with configuration resource(s): "[ConfigResource{resourceName='/opt/mule/mule-3.6.2-R43/apps/myapp/myapp.xml'}]"
19:31:00.403 | 07/10/2015 | INFO | Configured Mule using "org.mule.config.builders.AutoConfigurationBuilder" with configuration resource(s): "[ConfigResource{resourceName='/opt/mule/mule-3.6.2-R43/apps/myapp/myapp.xml'}]"
19:31:00.430 | 07/10/2015 | INFO | Apply ap-southeast-1 to the client com.amazonaws.services.sqs.AmazonSQSClient#1c5e47e5
19:31:00.430 | 07/10/2015 | INFO | New sqsClient is created com.amazonaws.services.sqs.AmazonSQSClient#1c5e47e5
19:31:00.448 | 07/10/2015 | INFO | Apply ap-southeast-1 to the client com.amazonaws.services.s3.AmazonS3Client#7b8419b2
19:31:00.468 | 07/10/2015 | INFO | New s3Client is created com.mulesoft.ch.queue.sqs.clients.S3Client#2c611f62
19:31:00.473 | 07/10/2015 | INFO | Done with SQSQueueManagementService() instance
19:31:00.504 | 07/10/2015 | INFO |
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Starting app 'myapp' +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
19:31:00.561 | 07/10/2015 | INFO | Starting ResourceManager
19:31:00.561 | 07/10/2015 | INFO | Starting persistent queue manager
19:31:00.562 | 07/10/2015 | INFO | Started ResourceManager
19:31:00.574 | 07/10/2015 | INFO | Successfully opened CloudHub ObjectStore
19:31:00.590 | 07/10/2015 | INFO |
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ DevKit Extensions (0) used in this application +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
19:31:00.591 | 07/10/2015 | INFO | Starting model: _muleSystemModel
19:31:00.594 | 07/10/2015 | INFO | Starting flow: myappFlow
19:31:00.595 | 07/10/2015 | INFO | Starting service: myappFlow.stage1
19:31:00.881 | 07/10/2015 | WARN | HTTP transport is deprecated and will be removed in Mule 4.0. Use HTTP module instead.
19:31:00.947 | 07/10/2015 | INFO | Initialising connector: connector.http.mule.default
19:31:01.156 | 07/10/2015 | INFO | No suitable connector in application, new one is created and used.
19:31:01.158 | 07/10/2015 | INFO | Connected: HttpConnector
{
name=connector.http.mule.default
lifecycle=initialise
this=5f68f6a9
numberOfConcurrentTransactedReceivers=4
createMultipleTransactedReceivers=true
connected=true
supportedProtocols=[http]
serviceOverrides=<none>
}
19:31:01.158 | 07/10/2015 | INFO | Starting: HttpConnector
{
name=connector.http.mule.default
lifecycle=initialise
this=5f68f6a9
numberOfConcurrentTransactedReceivers=4
createMultipleTransactedReceivers=true
connected=true
supportedProtocols=[http]
serviceOverrides=<none>
}
19:31:01.159 | 07/10/2015 | INFO | Starting connector: connector.http.mule.default
19:31:01.169 | 07/10/2015 | INFO | Initialising flow: ____ping____flow_____76326334
19:31:01.169 | 07/10/2015 | INFO | Initialising exception listener: org.mule.exception.DefaultMessagingExceptionStrategy#66551924
19:31:01.186 | 07/10/2015 | INFO | Initialising service: ____ping____flow_____76326334.stage1
19:31:01.380 | 07/10/2015 | INFO | Starting flow: ____ping____flow_____76326334
19:31:01.381 | 07/10/2015 | INFO | Starting service: ____ping____flow_____76326334.stage1
19:31:01.387 | 07/10/2015 | INFO | Registering listener: ____ping____flow_____76326334 on endpointUri: http://localhost:7557/____ping____
19:31:01.459 | 07/10/2015 | INFO | Loading default response transformer: org.mule.transport.http.transformers.MuleMessageToHttpResponse
19:31:01.542 | 07/10/2015 | INFO | Initialising: 'null'. Object is: HttpMessageReceiver
19:31:01.559 | 07/10/2015 | INFO | Connecting clusterizable message receiver
19:31:01.563 | 07/10/2015 | WARN | Localhost is being bound to all local interfaces as specified by the "mule.tcp.bindlocalhosttoalllocalinterfaces" system property. This property may be removed in a future version of Mule.
19:31:01.575 | 07/10/2015 | INFO | Starting clusterizable message receiver
19:31:01.575 | 07/10/2015 | INFO | Starting: 'null'. Object is: HttpMessageReceiver
19:31:01.644 | 07/10/2015 | INFO | Listening for requests on http://localhost:8085
19:31:01.645 | 07/10/2015 | INFO | Mule is embedded in a container already launched by a wrapper.Duplicates will not be registered. Use the org.tanukisoftware.wrapper:type=WrapperManager MBean instead for control.
19:31:01.675 | 07/10/2015 | INFO | Attempting to register service with name: Mule.myapp:type=Endpoint,service="____ping____flow_____76326334",connector=connector.http.mule.default,name="endpoint.http.localhost.7557.ping"
19:31:01.676 | 07/10/2015 | INFO | Registered Endpoint Service with name: Mule.myapp:type=Endpoint,service="____ping____flow_____76326334",connector=connector.http.mule.default,name="endpoint.http.localhost.7557.ping"
19:31:01.686 | 07/10/2015 | INFO | Registered Connector Service with name Mule.myapp:type=Connector,name="connector.http.mule.default.1"
19:31:01.689 | 07/10/2015 | INFO |
**********************************************************************
* Application: myapp *
* OS encoding: /, Mule encoding: UTF-8 *
* *
* Agents Running: *
* DevKit Extension Information *
* Batch module default engine *
* Clustering Agent *
* JMX Agent *
**********************************************************************
19:31:01.754 | 07/10/2015 | INFO | Registering the queue=55824160e4b0f5ecab93e207_559f73dfe4b02b744ec0f626_515E160FC244EB5157E8E7C8B162E0 with display name=seda.queue(____ping____flow_____76326334.stage1)
19:31:02.561 | 07/10/2015 | SYSTEM | Worker(54.169.12.90): Your application has started successfully.
19:31:09.295 | 07/10/2015 | INFO | Mule system health monitoring started for your application.
19:31:59.537 | 07/10/2015 | SYSTEM | Worker(52.74.74.41): Starting your application...
19:32:01.200 | 07/10/2015 | INFO |
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Initializing app 'myapp' +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
19:32:01.525 | 07/10/2015 | INFO | Creating the PersistentQueueManager. Asynchronous VM queues will be persistent.
19:32:01.526 | 07/10/2015 | INFO | About to create the PersistentQueueManager with environment: scope: 55824160e4b0f5ecab93e207_559f73dfe4b02b744ec0f626 bucket: ch-persistent-queues-us-east-prod accessKey: AKIAIYBZZZI7M2PAT4WQ region: ap-southeast-1 privateKey: no
19:32:07.054 | 07/10/2015 | INFO |
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Stopping app 'myapp' +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
19:32:07.056 | 07/10/2015 | INFO | Stopping flow: ____ping____flow_____807729792
19:32:07.056 | 07/10/2015 | INFO | Removing listener on endpointUri: http://localhost:7557/____ping____
19:32:07.057 | 07/10/2015 | INFO | Stopping: 'null'. Object is: HttpMessageReceiver
19:32:07.059 | 07/10/2015 | INFO | Disposing: 'null'. Object is: HttpMessageReceiver
19:32:07.059 | 07/10/2015 | INFO | Stopping service: ____ping____flow_____807729792.stage1
19:32:12.028 | 07/10/2015 | SYSTEM | Worker(52.74.74.41): Your application has started successfully.
19:32:15.041 | 07/10/2015 | INFO | Mule system health monitoring started for your application.
19:32:33.488 | 07/10/2015 | INFO | Stopping flow: myappFlow
19:32:33.489 | 07/10/2015 | INFO | Stopping service: myappFlow.stage1
19:32:37.061 | 07/10/2015 | SYSTEM | Application was updated successfully with zero downtime. The new version of your application has been launched and the old version has been stopped.
19:32:37.545 | 07/10/2015 | SYSTEM | Your application is started.
I found the solution to my problem. From the deployment logs:
19:31:01.644 | 07/10/2015 | INFO | Listening for requests on http://localhost:8085
The host should have been the default All interfaces [0.0.0.0], and the port 8085 is not allowed on CloudHub. And I must use the default port 8081.
I was running multiple Mule apps on my local machine at the same time, that's why I had used a different port for this app, and I wasn't aware that port 8085 is not allowed on CloudHub.
Thank you all for the response.
for the port please try using ${http.port} or ${https.port} as per your requirement when deployed to Cloud hub.
It worked for me.
I'm testing ActiveMQ 5.9.0 with Replicated LevelDB.
Running against a standalone ActiveMQ with a local LevelDB store, each producer.send(message) call takes about 1 ms. With my replicated setup with 3 zookeepers and 3 activemq brokers, producer.send(message) takes slightly more than 5 seconds to return! This happens even with sync="local_mem" in <replicatedLevelDB ... >. It's always just above 5 seconds, so there seems to be some strange wait/timeout involved.
Does this ring a bell?
It doesn't matter if I set brokerurl to failover:(<all three brokers>) or just tcp://brokerX, where brokerX is in the replicated LevelDB setup. There is no noticable delay sending messages in the brokerX web ui (hawtio). If I change to tcp://brokerY, where broker is an otherwise identical broker with <persistenceAdapter ...> set to <levelDB...> instead of <replicatedLevelDB...>, we're down at 1 ms per send.
Changing zookeeper tickTime etc makes no difference.
Debug log below. As you see, 5 seconds between "sent to queue", but zookeeper ping is quick.
2014-02-19 10:45:34,719 | DEBUG | Handling request for path /jolokia | io.hawt.web.AuthenticationFilter | qtp1217711018-227
2014-02-19 10:45:34,724 | DEBUG | localhost Message ID:<hostname>-57776-1392803129562-0:0:1:1:2 sent to queue://IO_stab_test_Q | org.apache.activemq.broker.region.Queue | ActiveMQ Transport: tcp:///<ip address>:54727#61616
2014-02-19 10:45:34,725 | DEBUG | IO_stab_test_Q toPageIn: 1, Inflight: 1, pagedInMessages.size 1, enqueueCount: 27, dequeueCount: 25 | org.apache.activemq.broker.region.Queue | ActiveMQ BrokerService[localhost] Task-20
2014-02-19 10:45:34,731 | DEBUG | Handling request for path /jolokia | io.hawt.web.AuthenticationFilter | qtp1217711018-222
2014-02-19 10:45:34,735 | DEBUG | Got ping response for sessionid: 0x244457fceb80003 after 0ms | org.apache.zookeeper.ClientCnxn | main-SendThread(<hostname>:2181)
2014-02-19 10:45:34,867 | DEBUG | Handling request for path /jolokia | io.hawt.web.AuthenticationFilter | qtp1217711018-222
2014-02-19 10:45:35,403 | DEBUG | Got ping response for sessionid: 0x244457fceb80003 after 0ms | org.apache.zookeeper.ClientCnxn | main-SendThread(<hostname>:2181)
2014-02-19 10:45:35,634 | DEBUG | Handling request for path /jolokia | io.hawt.web.AuthenticationFilter | qtp1217711018-227
2014-02-19 10:45:36,071 | DEBUG | Got ping response for sessionid: 0x244457fceb80003 after 0ms | org.apache.zookeeper.ClientCnxn | main-SendThread(<hostname>:2181)
2014-02-19 10:45:36,740 | DEBUG | Got ping response for sessionid: 0x244457fceb80003 after 0ms | org.apache.zookeeper.ClientCnxn | main-SendThread(<hostname>:2181)
2014-02-19 10:45:37,410 | DEBUG | Got ping response for sessionid: 0x244457fceb80003 after 0ms | org.apache.zookeeper.ClientCnxn | main-SendThread(<hostname>:2181)
2014-02-19 10:45:38,088 | DEBUG | Got ping response for sessionid: 0x244457fceb80003 after 8ms | org.apache.zookeeper.ClientCnxn | main-SendThread(<hostname>:2181)
2014-02-19 10:45:38,623 | DEBUG | Handling request for path /jolokia | io.hawt.web.AuthenticationFilter | qtp1217711018-222
2014-02-19 10:45:38,750 | DEBUG | Got ping response for sessionid: 0x244457fceb80003 after 0ms | org.apache.zookeeper.ClientCnxn | main-SendThread(<hostname>:2181)
2014-02-19 10:45:39,420 | DEBUG | Got ping response for sessionid: 0x244457fceb80003 after 0ms | org.apache.zookeeper.ClientCnxn | main-SendThread(<hostname>:2181)
2014-02-19 10:45:39,735 | DEBUG | localhost Message ID:<hostname>-57776-1392803129562-0:0:1:1:3 sent to queue://IO_stab_test_Q | org.apache.activemq.broker.region.Queue | ActiveMQ Transport: tcp:///<ip address>:54727#61616
2014-02-19 10:45:39,737 | DEBUG | IO_stab_test_Q toPageIn: 1, Inflight: 2, pagedInMessages.size 2, enqueueCount: 28, dequeueCount: 25 | org.apache.activemq.broker.region.Queue | ActiveMQ BrokerService[localhost] Task-24
2014-02-19 10:45:40,090 | DEBUG | Got ping response for sessionid: 0x244457fceb80003 after 0ms | org.apache.zookeeper.ClientCnxn | main-SendThread(<hostname>:2181)
Set queuePrefetch=0.
Some background on our situation...
Our message sizes are fairly small (<1kb xml) but our consumers vary from fast (<1 sec) to slow (10+ hours). Previously we had set prefetch=1, but even this would cause issues for us when a slow message is being worked and another message gets prefetched behind it.
We had noticed that our fast messages would often finish processing before the producer even gets the ack! We found that the producer.send() method was taking +5 seconds (exactly) to what we expect. That is what lead me to find this question.
Anyway, the solution for us was to set prefetch=0. This eliminated the 5 second delay completely for us, and resolved the other issue for us as well.
One script we have asks the user for a few values via successive JavaScript calls to window.prompt(). Selenium records this action, both the prompt texts and the values I typed in, but it doesn't seem to be able to play it back properly. It 'succeeds' in that no errors occur, but only the first prompt value actually makes it back to my script. Furthermore, the default ordering Selenium records makes the second value get returned in the first one's spot, and the rest still blank:
# [info] Executing: |answerOnNextPrompt | TEXT1 | |
# [info] Executing: |select | id | label=mychoice |
# [info] Executing: |answerOnNextPrompt | TEXT2 | |
# [info] Executing: |assertPrompt | Please enter a value for q1 | |
# [info] Executing: |answerOnNextPrompt | TEXT3 | |
# [info] Executing: |assertPrompt | Please enter a value for q2 | |
# [info] Executing: |answerOnNextPrompt | TEXT4 | |
# [info] Executing: |assertPrompt | Please enter a value for q3 | |
# [info] Executing: |assertPrompt | Please enter a value for q4 | |
I reordered it into what seems more sensible to me:
# [info] Executing: |answerOnNextPrompt | TEXT1 | |
# [info] Executing: |select | id | label=mychoice |
# [info] Executing: |assertPrompt | Please enter a value for q1 | |
# [info] Executing: |answerOnNextPrompt | TEXT2 | |
# [info] Executing: |assertPrompt | Please enter a value for q2 | |
# [info] Executing: |answerOnNextPrompt | TEXT3 | |
# [info] Executing: |assertPrompt | Please enter a value for q3 | |
# [info] Executing: |answerOnNextPrompt | TEXT4 | |
# [info] Executing: |assertPrompt | Please enter a value for q4 | |
After that I get TEXT1 as the first value, but the rest still blank.
I also tried waitForPrompt in place of each assertPrompt, but no dice.
My guess is that Selenium can't actually handle this situation because answerOnNextPrompt seems to need to come before the action that triggers the prompt, but it is the action that triggers the next prompt, so after the first one triggered by select there's no way to do it because they don't stack.
I'd like to be proven wrong, though...any ideas?
(If not, I might report it as a bug / something they need to change in the API, maybe by combining answerOnNextPrompt with assertPrompt: it could just take an optional argument with how the prompt ought to be answered.)
Platform is Selenium IDE 1.0.2 on Firefox 3.5.3 on win32.
This definately looks like a limitation in Selenium. The following is from the source of selenium-browserbot.js:
windowToModify.prompt = function(message) {
browserBot.recordedPrompts.push(message);
var result = !browserBot.nextConfirmResult ? null : browserBot.nextPromptResult;
browserBot.nextConfirmResult = true;
browserBot.nextPromptResult = '';
self.relayBotToRC.call(self, "browserbot.recordedPrompts");
return result;
};
It appears to process all prompts when the window is 'modified', and after each it sets the next answer to empty. I would raise a request for an improvement. Without giving it much thought I would suggest allowing stacking of the anwerOnNextPrompt command so that you can queue up the answers you want to give to each prompt in turn.
Update:
Something similar will also happen for consecutive JavaScript confirmations. The first will use the response set by choose*OnNextConfirmation, and all following confirmations will automatically select OK (true).
windowToModify.confirm = function(message) {
browserBot.recordedConfirmations.push(message);
var result = browserBot.nextConfirmResult;
browserBot.nextConfirmResult = true;
self.relayBotToRC.call(self, "browserbot.recordedConfirmations");
return result;
};
How about this one:
# [info] Executing: |select | id | label=mychoice |
# [info] Executing: |answerOnNextPrompt | TEXT1 | |
# [info] Executing: |assertPrompt | Please enter a value for q1 | |
# [info] Executing: |answerOnNextPrompt | TEXT2 | |
# [info] Executing: |assertPrompt | Please enter a value for q2 | |
# [info] Executing: |answerOnNextPrompt | TEXT3 | |
# [info] Executing: |assertPrompt | Please enter a value for q3 | |
# [info] Executing: |answerOnNextPrompt | TEXT4 | |
# [info] Executing: |assertPrompt | Please enter a value for q4 | |
BTW, why not using a regular HTML form instead so many of those annoying javascript prompts?