I have an Esper statement like:
select ...
from pattern[(A -> timer:interval(100 msec)) or timer:interval(500 msec)]
Usually the statement triggers once or not at all, but sometimes the statement triggers twice. Is this a bug or the expected behavior? If it is the expected behavior, what should I change in my statement so that it would only every trigger at most once?
Note: I'm using version 4.3 of Esper.
I'd recommend updating to a newer version. The version you have there is really old. If still having issues you can create an issue in Github and attach a test case.
Related
I understand that I cannot make backward incompatible changes to Workflows per:
How to make changes or fixes to Uber Cadence Workflow without breaking determinism?
However I am not sure what "backward incompatible" means here. Can I simply not deploy new code without using getVersion, period? Or as long as the history tracking that is used for restoration is compatible between the 2 versions then I can update without getVersion? Or I can update without getVersion under some under conditions?
Generally anything that can change the way the history is generated is considered backwards incompatible. The following changes are backwards compatible:
Any activity implementation.
Duration passed to sleep and timer creation function.
Changing arguments to activities.
Changing activity options and retry policies.
Changing values of variables that don't affect the workflow execution path. For example if some variable accumulates some data and this data is only used in a query.
We recommend saving a few histories and then replaying them as part of unit tests to find out about non compatible changes earlier.
As stated in title, is it possible to take the actual "context" in which a trigger is being run and incorporate that variable into my trigger code itself?
i.e. I want to run a slight part of extra code for the trigger if its a newly inserted record, but not if its an existing one being updated.
Yes, you can use trigger context variables to examine the context in which the trigger is running. There are a variety of examples in that article. For your use case, you can use an if statement like this:
if (Trigger.isInsert) {
// do something on insert (and not on update)
}
I am using Solr 4.10.0 with PostgreSql 9.3. I am able to configure my solr core properly using data-config.xml and search through the database different tables. However, I am not able to setup the autoCommit feature. Whenever any row gets added in the table, I expect them to start appearing in the results after the maxTime (1 minute) but that doesn't happen. I have to explicitly rebuild the index by doing a full data-import and then everything works fine.
My solrconfig.xml is:
<updateHandler class="solr.DirectUpdateHandler2">
<autoCommit>
<maxTime>60000</maxTime>
<openSearcher>true</openSearcher>
</autoCommit>
<autoSoftCommit>
<maxTime>${solr.autoSoftCommit.maxTime:-1}</maxTime>
</autoSoftCommit>
</updateHandler>
Is there something extra needs to be done for using autoCommit here? I checked my log files as well but there is no error / exception. What am I missing?
Please find the below link...
SOLR: What does an autoSoftCommit maxtime of -1 mean?
I think this is what is happening in your case..
First off, you can see the expression ${solr.autoSoftCommit.maxTime:-1} within the tag. This allows you to make use of Solr's variable substitution. That feature is described in detail here in the reference. If that variable has not been substituted by any of those means -1 is taken as value for that configuration.
Turning commitMaxTime to -1 effectively turns autocommit off.
We have a WebSphere cluster with four clones. Identical code runs on each of the clones. We have Quartz periodically kick off a job that runs the code.
The code tries to update a row in a table so that only one of the clones will be able to successfully update the table, and then that clone will run the rest of the job. Something like:
update <table> set status = 'RUNNING' where job_name = 'JOB1' and status = 'STOPPED'
We do not start a transaction when we execute the update statement.
What we see sometimes is that all four clones fail to update the table, and all get a lock timeout error (sql code -913).
We've also tried an alternative where we start a transaction, select to see if the row is marked as running, and if not, then performing an update and committing; and otherwise rolling back.
That had the same problem.
One solution we did not try yet is to modify the select to be a "select for update" although from my googleing, I have doubts as to whether that will help.
Any suggestions?
This ended up not being a problem (that's what I get for listening to someone without checking it out myself).
I tested this out in our development environment with two clones. One of the clones would see the -913 lock timeout error occasionally while the other clone would successfully update the table. Other than the ugly log message, everything worked as it should.
Usually, however, we would not get the -913 error, but rather a warning indicating that there was no row to update from one of the clones. Again, this behavior is fine.
So, as we originally thought, and Clockwork-Muse also suggests, using UPDATE statements in this manner to enforce a lock works just fine in DB2.
Is there a way to show the SQL query executed by phpPgAdmin as the way phpMyAdmin does?
For example, if I modify a column, it should show the ALTER command being executed.
If this is not possible, what other interface could I use to get this feature?
It's not possible with any currently released version of phpPgAdmin, although the feature could probably be added. You'd need to intercept the SQL being sent to the back-end, and then display this back out to the user. SQL execution is pretty well centralized, and if you look at the "history" feature you will see a way to trap/show queries, so munging those bits together would probably get you what you want. HTH, if someone implements this, please send a pull request!
As a quick dirty hack you could alter sources a bit to enable sql logging:
In classes/database/ADODB_base.php in
function execute($sql) {
...
}
add these lines at the beginning:
global $misc;
$misc->saveScriptHistory($sql);
This worked in my 5.0.3 version.