I have a very simple spring component:
#Component
public abstract class IgniteComponent {
protected final Ignite ignite;
/**
* Start the ignite
*/
public IgniteComponent() {
this.ignite = Ignition.getOrStart(new IgniteConfiguration());
}
/**
* Get the ignite
*
* #return The ignite
*/
public Ignite getIgnite() {
return this.ignite;
}
}
When I use this component in unit tests locally everything works fine.
But when I want to run my unit tests on a bamboo agent I always get the follwoing:
24-Jul-2018 13:36:38 2018-07-24 11:36:38.888 WARN 7259 --- [ Test worker] .i.p.c.GridCachePartitionExchangeManager : Failed to wait for initial partition map exchange. Possible reasons are:
24-Jul-2018 13:36:38 ^-- Transactions in deadlock.
24-Jul-2018 13:36:38 ^-- Long running transactions (ignore if this is the case).
24-Jul-2018 13:36:38 ^-- Unreleased explicit locks.
And I cant find any reason for this. The ignite version im working with is:
dependencySet (group: 'org.apache.ignite', version: '2.2.0') {
entry 'ignite-core'
entry 'ignite-spring'
}
What is usually the cause of this issue?
Multicast IP finder is used by default. If you run your Ignite on shared agent it will try and join any nodes that are present there with unexpected results. Try to disable multicast (by using VM finder for example) or provide the whole log of your instance.
I have an application with RabbitMQ where I get the number of messages in a Rabbit queue using the HTTP API (/api/queues/vhost/name).
However, it appears that this information is refreshed from time to time (by default every 5 seconds). I thought the information was always up to date, and it was the administration page that was updated in a given interval.
Is there any way to get the number of messages in a queue with real-time information?
Thank you
The management database is updated each 5 seconds by default.
use the command line rabbitmqctl list_queues for real-time values.
Try to use:
channel.messageCount(you_queue)
see if it works for you
/**
* Returns the number of messages in a queue ready to be delivered
* to consumers. This method assumes the queue exists. If it doesn't,
* an exception will be closed with an exception.
* #param queue the name of the queue
* #return the number of messages in ready state
* #throws IOException Problem transmitting method.
*/
long messageCount(String queue) throws IOException;
I am using Atomikos for JTA transaction.
I have following setting for JTA:
UserTransactionImp userTransactionImp = new UserTransactionImp();
userTransactionImp.setTransactionTimeout(900);
but when my code perform JTA transaction, then if it takes more than 5 minutes (which is default value) then it throws exception:
Caused by: com.atomikos.icatch.RollbackException: Prepare: NO vote
at com.atomikos.icatch.imp.ActiveStateHandler.prepare(ActiveStateHandler.java:231)
at com.atomikos.icatch.imp.CoordinatorImp.prepare(CoordinatorImp.java:681)
at com.atomikos.icatch.imp.CoordinatorImp.terminate(CoordinatorImp.java:970)
at com.atomikos.icatch.imp.CompositeTerminatorImp.commit(CompositeTerminatorImp.java:82)
at com.atomikos.icatch.imp.CompositeTransactionImp.commit(CompositeTransactionImp.java:336)
at com.atomikos.icatch.jta.TransactionImp.commit(TransactionImp.java:190)
... 25 common frames omitted
it looks like its taking the default jta transaction timeout (even though i am setting timeout explicitely (to 15 minutes/900 seconds).
I tried using following properties in application.properties file however it still takes the default timeout value(300 seconds).
spring.jta.atomikos.properties.max-timeout=600000
spring.jta.atomikos.properties.default-jta-timeout=10000
I have also tried with below property but no luck:
spring.transaction.default-timeout=900
Can anyone suggest if I need any other setting? I am using wildfly plugin, spring boot and atomikos api for JTA transaction.
From the Atomikos documentation:
com.atomikos.icatch.max_timeout
Specifies the maximum timeout (in milliseconds) that can be allowed for transactions. Defaults to 300000. This means that calls to UserTransaction.setTransactionTimeout() with a value higher than configured here will be max'ed to this value. For 4.x or higher, a value of 0 means no maximum (i.e., unlimited timeouts are allowed).
Indeed, if you take a look at the Atomikos library source code (for both versions 4.0.0M4 and 3.7.0), in the createCC method from class com.atomikos.icatch.imp.TransactionServiceImp you will see:
387: if ( timeout > maxTimeout_ ) {
388: timeout = maxTimeout_;
389: //FIXED 20188
390: LOGGER.logWarning ( "Attempt to create a transaction with a timeout that exceeds maximum - truncating to: " + maxTimeout_ );
391: }
So any attempt to specify a longer transaction timeout gets capped to maxTimeout_ which has a default value of 300000 set during initialization if none is specified.
You can set the com.atomikos.icatch.max_timeout as a JVM argument with:
-Dcom.atomikos.icatch.max_timeout=900000
or you could use The Advanced Case recipe specified in the Configuration for Spring Section from the Atomikos documentation.
I've resolved similar problem where configuration in application.yml (or application. properties) of Spring Boot did not get picked up.
There was even a log that I later found mentioned in official docs.
However, I added transactions.properties file (next to the application.yml) where I set mine desired properties.
# Atomikos properties
# Service must be defined!
com.atomikos.icatch.service = com.atomikos.icatch.standalone.UserTransactionServiceFactory
# Override default properties.
com.atomikos.icatch.log_base_dir = ./atomikos
Some properties can be set within transactions.properties and other within jta.properties file.
I'm use library CDEvents for monitor the file system.
When calling method flash Synchronously
- (void)flushSynchronously
{
FSEventStreamFlushSync(_eventStream);
}
get the message
(CarbonCore.framework) FSEventStreamFlushSync(): failed assertion '(SInt64)last_id > 0LL'
Here is the method signature FSEventStreamFlushSync() from FSEvents.h
/*
* FSEventStreamFlushSync()
*
* Discussion:
* Asks the FS Events service to flush out any events that have
* occurred but have not yet been delivered, due to the latency
* parameter that was supplied when the stream was created. This
* flushing occurs synchronously -- by the time this call returns,
* your callback will have been invoked for every event that had
* already occurred at the time you made this call.
* FSEventStreamFlushSync() can only be called after the stream has
* been started, via FSEventStreamStart().
*
* Parameters:
*
* streamRef:
* A valid stream.
*
* Availability:
* Mac OS X: in version 10.5 and later in CoreServices.framework
* CarbonLib: not available
* Non-Carbon CFM: not available
*/
extern void
FSEventStreamFlushSync(FSEventStreamRef streamRef) __OSX_AVAILABLE_STARTING(__MAC_10_5, __IPHONE_NA);
Does Selenium implicit wait always take the entire wait time or can it finish sooner? If I set the implicit wait to 10 seconds, could a call to .findElement finish in a few seconds or would it always take the entire 10 seconds?
This page implies that it waits the full 10 seconds, which is very confusing because its not what the javadoc implies.
The following code comment from WebDriver.java implies that its a polling action which can finish sooner than the implicit timeout is defined at. BUT, the last sentence in the comment really throws a wrench into that belief and makes me not totally sure about it. If it is actually polling, then how would it "adversely affect test time", since it wouldn't go the entire implicit wait duration?
/**
* from WebDriver.java
* Specifies the amount of time the driver should wait when searching for an element if
* it is not immediately present.
* <p/>
* When searching for a single element, the driver should poll the page until the
* element has been found, or this timeout expires before throwing a
* {#link NoSuchElementException}. When searching for multiple elements, the driver
* should poll the page until at least one element has been found or this timeout has
* expired.
* <p/>
* Increasing the implicit wait timeout should be used judiciously as it will have an
* adverse effect on test run time, especially when used with slower location
* strategies like XPath.
*
* #param time The amount of time to wait.
* #param unit The unit of measure for {#code time}.
* #return A self reference.
*/
Timeouts implicitlyWait(long time, TimeUnit unit);
Also, if anyone can provide information on how often the default "polling" occurs?
It can finish once it was able to find the element. If not it does throws the error and stops. The poll time is again very specific to the driver implementation ( not Java bindings , but the driver part, example: FireFox extension, Safari Extension etc.)
As I have mentioned here, these are very specific to the driver implementation. All driver related calls goes via execute method.
I'm putting up the gist over of the execute method (you can find the full source here):
protected Response execute(String driverCommand, Map<String, ?> parameters) {
Command command = new Command(sessionId, driverCommand, parameters);
Response response;
long start = System.currentTimeMillis();
String currentName = Thread.currentThread().getName();
Thread.currentThread().setName(
String.format("Forwarding %s on session %s to remote", driverCommand, sessionId));
try {
log(sessionId, command.getName(), command, When.BEFORE);
response = executor.execute(command);
log(sessionId, command.getName(), command, When.AFTER);
if (response == null) {
return null;
}
//other codes
}
The line:
response = executor.execute(command);
says the whole story. executor is of type CommandExecutor, so all calls goes to the specific driver class like ChromeCommandExecutor,SafariDriverCommandExecutor, which has their own handling.
So the polling is upto the driver implementation.
If you want to specify the polling time, then you should probably start using Explicit Waits.
As mentioned the code comment:
* When searching for a single element, the driver should poll the page until the
* element has been found, or this timeout expires before throwing a
* {#link NoSuchElementException}.
Its going to wait till that element present, or timeout occurs.
For example, If you set Implicit wait as 10 seconds, .findElement is going to wait maximum of 10 seconds for that element. Suppose that element available in the DOM in 5 seconds, then it will come out of "wait" and start executing next step.
Hope this clarifies.
To my knowledge polling period is not 0.5 seconds with implicit wait. It is the case with explicit wait. Explicit wait polls the DOM every 500ms. Implicit wait, if the element is not found on page load waits for the specified time and then checks again after time is run out. If not found it throws an error