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);
Related
We are migrating from spring 5 to 6. I am encountering issues with following methods related to spring-kafka.
SetErrorHandler deprecated in favor of CommonErrorHandler -> i replaced this with setCommonErrorHandler(Recoverer,Back off)
factory.setRetryTemplate(neverRetry...) -> removed in favor of CommonErrorHandler.
I want to set a "neverRetry" so that recoveryCallback can address the retries.
factory.setRecoveryCallback -> removed in favor of CommonErrorHandler.
I want to check the exception thrown and give it to errorhandler only for a specific exception and just log/return in case of all other exceptions.
I am looking for suggestions to handle point #2 and #3 after moving to 3.0.1. How can I set the commonErrorHandler effectively to replicate the same behavior we had when running on 2.7.14.
I replaced SetErrorHandler with setCommonErrorHandler(Recoverer,Back off) but this is not sufficient for our use case. We need to check the type of exception and use error handler only if reception is a specific one. (Which was earlier achieved through recoveryCallback method)
The use of a RetryTemplate has been deprecated for a long time.
See the DefaultErrorHandler...
/**
* Add exception types to the default list. By default, the following exceptions will
* not be retried:
* <ul>
* <li>{#link DeserializationException}</li>
* <li>{#link MessageConversionException}</li>
* <li>{#link ConversionException}</li>
* <li>{#link MethodArgumentResolutionException}</li>
* <li>{#link NoSuchMethodException}</li>
* <li>{#link ClassCastException}</li>
* </ul>
* All others will be retried, unless {#link #defaultFalse()} has been called.
* #param exceptionTypes the exception types.
* #see #removeClassification(Class)
* #see #setClassifications(Map, boolean)
*/
public final void addNotRetryableExceptions(Class<? extends Exception>... exceptionTypes) {
Exceptions that are not retryable are sent directly to the recoverer.
My application is running on ECS cluster and Redis is ap part of docker on ECS .
The application runs fine for a week or more but all of a sudden it started throwing Time out exception .
The issue reported in below block of query
api.query("MATCH (ag:dGrp{v:" + rec.DocGroupId + "}),(pg:resUGrp{v:" + rec.userGroupUID + "}) CREATE (pg)-[:dgE{ppv:" + ppv + ","+IdentifierFlag+":1}]->(ag)");
Full stack Trace
redis.clients.jedis.exceptions.JedisConnectionException: java.net.SocketTimeoutException: Read timed out
at redis.clients.jedis.util.RedisInputStream.ensureFill(RedisInputStream.java:205)
at redis.clients.jedis.util.RedisInputStream.readByte(RedisInputStream.java:43)
at redis.clients.jedis.Protocol.process(Protocol.java:155)
at redis.clients.jedis.Protocol.read(Protocol.java:220)
at redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:283)
at redis.clients.jedis.Connection.getOne(Connection.java:261)
at redis.clients.jedis.Jedis.sendCommand(Jedis.java:4119)
at com.redislabs.redisgraph.impl.api.ContextedRedisGraph.sendQuery(ContextedRedisGraph.java:52)
at com.redislabs.redisgraph.impl.api.RedisGraph.sendQuery(RedisGraph.java:68)
at com.redislabs.redisgraph.impl.api.AbstractRedisGraph.query(AbstractRedisGraph.java:46)
and this
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at java.net.SocketInputStream.read(SocketInputStream.java:127)
at redis.clients.jedis.util.RedisInputStream.ensureFill(RedisInputStream.java:199)
when we restart our ECS task the problem disappear and comes back after a week .
We have increased max connection to 160 .
When we try to re produce this issue in Lower env by putting heavy request and in bulk for a week also but this issue we were not able to re produce .
We are using Radis 3.5.1 version .
jedis redis -client.jar(version 3.5.1)
Redis Time out Configuration set in redis.conf file:
timeout 0
bind 127.0.0.1
tcp-backlog 511
tcp-keepalive 300
lua-time-limit 5000
loadmodule /usr/lib64/redis/modules/redisgraph.so
Socket Time out in my Code
socket.setSoTimeout(60000);//keep connection for max 60s when idle
this time out is from import java.net.Socket;
RedisGraph Query
And at Reis Graph Query Level we use this Method that does not Time out parameter so i assume it might be taking default one .
/**
* Execute a Cypher query.
* #param graphId a graph to perform the query on
* #param query Cypher query
* #return a result set
*/
public ResultSet query(String graphId, String query) {
return sendQuery(graphId, query);
}
But it has one method that has Timeout parameter also
/**
* Execute a Cypher query with timeout.
* #param graphId a graph to perform the query on
* #param timeout
* #param query Cypher query
* #return a result set
*/
#Override
public ResultSet query(String graphId, String query, long timeout) {
return sendQuery(graphId, query, timeout);
}
I see you are doing graph query which could take more time than general Redis commands. So, for this purpose you can try increasing socket timeout.
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;
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
I am developing a simple ejabberd client in C using libstrophe. It connects and begins to handle messages as it's supposed to do.
However, after a while (following two or three pings from the ejabberd server), my connection closes and the status is set to DISCONNECTED. Below is the tail of the debug lines:
xmpp DEBUG Unrecoverable TLS error, 5.
xmpp DEBUG Closing socket.
DEBUG: disconnected event DEBUG Stopping event loop.
event DEBUG Event
oop completed.
I initialize and connect as below.
xmpp_initialize();
/* read connection params */
if( set_xmpp_conn_params( &conn_params ) < 0 ) {
fprintf(stderr, "Could not retrieve connection params from %s\n",
SERVER_CONF_FILE);
return -1;
}
/* initialize the XMPP logger */
xmpp_log = xmpp_get_default_logger(XMPP_LOG_LEVEL);
xmpp_ctx = xmpp_ctx_new(NULL, xmpp_log);
/* create a connection */
xmpp_conn = xmpp_conn_new(xmpp_ctx);
/* login */
xmpp_conn_set_jid(xmpp_conn, conn_params.jid);
xmpp_conn_set_pass(xmpp_conn, conn_params.password);
/* create a client */
xmpp_connect_client( xmpp_conn, conn_params.host, 0,
agent_conn_handler, xmpp_ctx );
/* enter the event loop */
xmpp_run( xmpp_ctx );
/* the code below is executed
whenever connection handler #agent_conn_handler exits */
/* release the connection and context */
xmpp_conn_release(xmpp_conn);
xmpp_ctx_free(xmpp_ctx);
Why am I getting that TLS error message?
Thanks.
Error 5 is SSL_ERROR_SYSCALL. The OpenSSL docs say:
Some I/O error occurred. The OpenSSL error queue may contain more
information on the error. If the error queue is empty (i.e.
ERR_get_error() returns 0), ret can be used to find out more about the
error: If ret == 0, an EOF was observed that violates the protocol. If
ret == -1, the underlying BIO reported an I/O error (for socket I/O on
Unix systems, consult errno for details).
In practice, this may mean the server dropped your connection for some reason. I'd suggest doing a packet trace with WireShark to get more info. For example, we have seen this happen with servers that use the RSA libraries for TLS, when the client offers TLS version 1.1.